From nobody Fri Jul 5 12:34:12 2019 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 E9BE41200E5; Fri, 5 Jul 2019 12:34:10 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Vijay Gurbani via Datatracker To: Cc: draft-ietf-tram-turnbis.all@ietf.org, ietf@ietf.org, tram@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.98.2 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Vijay Gurbani Message-ID: <156235525081.22022.16028050139050508065@ietfa.amsl.com> Date: Fri, 05 Jul 2019 12:34:10 -0700 Archived-At: Subject: [tram] Genart telechat review of draft-ietf-tram-turnbis-27 X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.29 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, 05 Jul 2019 19:34:11 -0000 Reviewer: Vijay Gurbani Review result: Ready 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 wait for direction from your document shepherd or AD before posting a new version of the draft. For more information, please see the FAQ at . Document: draft-ietf-tram-turnbis-27 Reviewer: Vijay K. Gurbani Review Date: 2019-07-05 IETF LC End Date: None IESG Telechat date: 2019-07-11 Summary: Ready to proceed. I had reviewed -25 for Gen-ART and all of my comments and feedback from that review have been incorporated. I do not have any further comments or feedback on -27. Major issues: 0 Minor issues: 0 Nits/editorial comments: 0 From nobody Sun Jul 7 01:18:51 2019 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 57A4612002E; Sun, 7 Jul 2019 01:18:44 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: =?utf-8?q?=C3=89ric_Vyncke_via_Datatracker?= To: "The IESG" Cc: draft-ietf-tram-turnbis@ietf.org, Brandon Williams , tram-chairs@ietf.org, brandon.williams@akamai.com, tram@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.98.2 Auto-Submitted: auto-generated Precedence: bulk Reply-To: =?utf-8?q?=C3=89ric_Vyncke?= Message-ID: <156248752430.14312.15895119889558390147.idtracker@ietfa.amsl.com> Date: Sun, 07 Jul 2019 01:18:44 -0700 Archived-At: Subject: [tram] =?utf-8?q?=C3=89ric_Vyncke=27s_No_Objection_on_draft-ietf?= =?utf-8?q?-tram-turnbis-27=3A_=28with_COMMENT=29?= X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.29 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 Jul 2019 08:18:44 -0000 Éric Vyncke has entered the following ballot position for draft-ietf-tram-turnbis-27: 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-turnbis/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you all for the work put into this clear and well-written document. I also appreciate the fact that TURN server can be used to proxy between IPv4 and IPv6; on this topic, this specific use case could probably be described early in the document rather then in section 5 (e.g. when discussing the transport protocol between client and server or even earlier). For my own curiosity, isn't TURN scope broader than plain NAT: can it also be useful in the absence of NAT if inbound 'connection' are blocked by security policy ? == COMMENTS == -- Section 2 -- Please use the new boilerplate RFC 8174 ;-) -- Section 3.1 -- Is there any reason why MPTCP is not specified for the communication between TURN client and TURN server? There is a very short explanation in section 15 "TCP multi-path is not used by both SIP and WebRTC protocols [RFC7478] for media and non-media data" but it does not address the use of MPTCP between TURN client/server. -- Section 3.7 -- The 500 bytes guideline to avoid fragmentation, is there any data backing the sentence "...will generally avoid IP fragmentation." ? In the same section, the text about 'DF bit' should be clear that it is obviously for IPv4 (it is indicated 2 paragraphs below). -- Section 3.9 -- The TCP/UDP/DTLS discussion of 'happy eyeball' is confusing between "use the first TCP connection that is established" and "if connections are established on both IP address families..." Which sentence should be used? Why plain RFC 8305 is not enough? -- Section 7.2 -- What is the expected server behavior when receiving a DONT-FRAGMENT when the REQUESTED-ADDRESS-FAMILY is IPv6 ? The STUN document appears to use DONT-FRAGMENT only when receiving traffic from the peers. -- Section 9 -- About the permission based on the peer IP address, the text is about UDP, but what about ICMP messages? (obvioulsy their source could be any router on the path) The text should refer to section 11.5 From nobody Sun Jul 7 13:29:15 2019 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 34452120094; Sun, 7 Jul 2019 13:28:58 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Christopher Wood via Datatracker To: Cc: draft-ietf-tram-turnbis.all@ietf.org, ietf@ietf.org, tram@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.98.3 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Christopher Wood Message-ID: <156253133809.549.13521510978566357744@ietfa.amsl.com> Date: Sun, 07 Jul 2019 13:28:58 -0700 Archived-At: Subject: [tram] Secdir last call review of draft-ietf-tram-turnbis-27 X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.29 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 Jul 2019 20:28:59 -0000 Reviewer: Christopher Wood Review result: Has Nits I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. The summary of the review is: Ready with nits Summary: In general, the document is well written and clearly founded in operational experience. The security considerations are thorough, providing examples where necessary to highlight important problem areas. It draws a clear line between issues best addressed by applications outside of TURN, and provides sufficient detail for those issues in scope. My comments and questions are, hopefully, mostly nits. General comments: - TURN server authentication in the case of (D)TLS is underspecified. Are servers assumed to have WebPKI certificates, OOB-trusted raw public keys, or something else? Is there a preferred form of authentication? Relatedly, in Section 3.2, how do clients authenticate the server? - Section 3.7: Could TURN servers not chunk data from stream-oriented transports (TCP or TLS) to a preferred MTU size before relaying to peers? Specifically, there are likely some cases wherein the server could deal with the client data messages larger than the recommended 500B limit. On that point, should servers even accept data larger than this recommended size? - Section 3.9: There may be cases where the TLS connection post TCP connection establishment fails. It would therefore seems prudent to not declare victory for one connection over the other until TLS connects, too. - Section 3 could benefit from a subsection on replays and the nonce role. In particular, as later discussed in the security considerations, some of these attacks are not new to TURN and should therefore be dealt with by the application protocol (SRTP). This section might also describe nonce rotation policies with more specificity, as this is underspecified in the document. - Section 3 could also benefit from discussion about cleartext versus encryption transports between clients and servers. Encrypting the nonce, username, realm, etc., among other things, has obvious benefits. - Why are SOFTWARE and FINGERPRINT attributes recommended? It seems like clients should be discouraged from sending these if anything, especially if not used to make allocation decisions on the server. - Section 5: When servers receive data that exceeds an allocation’s bandwidth quota, servers silently discard this data. This means there’s no allocation-based flow control mechanism between client and server beyond what’s provided by the transport protocol, right? This seems fine, though perhaps some discussion of why this design decision was made would be helpful. For example, I could imagine explicit signals from servers to clients that indicate server state would reveal information about other allocations on the server, which might be problematic. - Section 7.2 suggests that servers can redirect client allocation requests to other servers. Can this create a loop, wherein two TURN servers redirect to one another? Moreover, is it acceptable for one TURN server to redirect to an unrelated TURN server? (It should be made clear here that these responses are authenticated, as otherwise it would be possible for an on-path adversary to redirect allocation requests to a server it owns.) - Section 21.1.2: Use of (D)TLS doesn’t help against dictionary attacks much, since presumably there’s low entropy in usernames and passwords alike. Thus, I question whether this is a “stronger” mitigation. - Section 12.1.6: “username” and “realm” are not considered sensitive? They seem sensitive to me. - As an extension, it seems possible to improve on what’s in STUN. For example, it may be worthwhile, here or elsewhere, to update STUN’s long term credential key derivation process (MD5(username + realm + password)) to something a bit more modern. This is quite likely out of scope, though in the context of client authentication it seems worth mentioning that TURN is limited to the mechanisms provided by STUN. Nits and other comments: - Section 2: “message-digest” is undefined in the Nonce definition. - Section 3: It’s probably worth citing RFC8446 as the recommended version of TLS. - Section 3.4: It might be worth mentioning that use of (D)TLS for the client-to-server transport mitigates the need for Send and Data authentication. - Section 3.4: What does “proper security” mean? - Figure 4: Adding another message exchange wherein a channel message is sent without a prior ChannelBind request would be useful to highlight this dependency and expected behavior from clients and servers. - Section 3.6: Another benefit of this user space design decision is use of (D)TLS links. - Section 5: Where did the 40 second request buffer timeout come from? Adding some details might help. - Section 6: “secure hash” is undefined, though presumably what is meant is a cryptographic hash with collision resistance. It would be good to clarify this requirement. - Section 7.4: What is the retry behavior if allocation requests timeout? - Section 12.5: The STUN requirement for 4-byte alignment should be cited when discussing the TCP and TLS padding requirement. - Section 15: Typo “DON’T FRAGMENT”. From nobody Mon Jul 8 06:56:09 2019 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 5D6C712022B; Mon, 8 Jul 2019 06:55:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mcafee.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CEdDrgFcC8xo; Mon, 8 Jul 2019 06:55:50 -0700 (PDT) Received: from DNVWSMAILOUT1.mcafee.com (dnvwsmailout1.mcafee.com [161.69.31.173]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D11C1201E6; Mon, 8 Jul 2019 06:55:49 -0700 (PDT) X-NAI-Header: Modified by McAfee Email Gateway (5500) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mcafee.com; s=s_mcafee; t=1562593522; h=From: To:CC:Subject:Thread-Topic:Thread-Index:Date: Message-ID:References:In-Reply-To:Accept-Language: Content-Language:X-MS-Has-Attach:X-MS-TNEF-Correlator: dlp-product:dlp-version:dlp-reaction:authentication-results: x-originating-ip:x-ms-publictraffictype:x-ms-office365-filtering-correlation-id: x-microsoft-antispam:x-ms-traffictypediagnostic: x-ms-exchange-purlcount:x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers:x-forefront-prvs: x-forefront-antispam-report:received-spf:x-ms-exchange-senderadcheck: x-microsoft-antispam-message-info:Content-Type: Content-Transfer-Encoding:MIME-Version:X-MS-Exchange-CrossTenant-Network-Message-Id: X-MS-Exchange-CrossTenant-originalarrivaltime: X-MS-Exchange-CrossTenant-fromentityheader: X-MS-Exchange-CrossTenant-id:X-MS-Exchange-CrossTenant-mailboxtype: X-MS-Exchange-CrossTenant-userprincipalname: X-MS-Exchange-Transport-CrossTenantHeadersStamped: X-OriginatorOrg:X-NAI-Spam-Flag:X-NAI-Spam-Level: X-NAI-Spam-Threshold:X-NAI-Spam-Score:X-NAI-Spam-Version; bh=vexcj4vjLTaEg2+rVMh7xbUjG24R7TCa1KRvsM gc4sM=; b=k2dmpEFFGrMV/KC9tLfiS0MGCRUtFcQHyIK08PYg 79spIOGhnTQa0OH9iX61qz4lSCjCGf6qY/dwLLfPR3qfY6dIiN 5YGxjgX1gliFfuYCx7PCbgvB1a1aumMW7Va1Rt9fbIKkfCfWYj nrrdqDVb6zbRFjUgn2IMIkML2O2t1yc= Received: from DNVEXAPP1N05.corpzone.internalzone.com (unknown [10.44.48.89]) by DNVWSMAILOUT1.mcafee.com with smtp (TLS: TLSv1/SSLv3,256bits,ECDHE-RSA-AES256-SHA384) id 6079_d6b0_1e12c0ed_269a_4886_b9ef_d471e54d910a; Mon, 08 Jul 2019 07:45:22 -0600 Received: from DNVEXAPP1N04.corpzone.internalzone.com (10.44.48.88) by DNVEXAPP1N05.corpzone.internalzone.com (10.44.48.89) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Mon, 8 Jul 2019 07:55:26 -0600 Received: from DNVO365EDGE1.corpzone.internalzone.com (10.44.176.66) by DNVEXAPP1N04.corpzone.internalzone.com (10.44.48.88) with Microsoft SMTP Server (TLS) id 15.0.1395.4 via Frontend Transport; Mon, 8 Jul 2019 07:55:26 -0600 Received: from NAM04-CO1-obe.outbound.protection.outlook.com (10.44.176.243) by edge.mcafee.com (10.44.176.66) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Mon, 8 Jul 2019 07:55:24 -0600 Received: from DM5PR16MB1705.namprd16.prod.outlook.com (10.172.44.147) by DM5PR16MB1481.namprd16.prod.outlook.com (10.173.212.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2052.18; Mon, 8 Jul 2019 13:55:24 +0000 Received: from DM5PR16MB1705.namprd16.prod.outlook.com ([fe80::570:2208:75c2:5f17]) by DM5PR16MB1705.namprd16.prod.outlook.com ([fe80::570:2208:75c2:5f17%8]) with mapi id 15.20.2052.019; Mon, 8 Jul 2019 13:55:24 +0000 From: "Konda, Tirumaleswar Reddy" To: =?utf-8?B?w4lyaWMgVnluY2tl?= , The IESG CC: "tram-chairs@ietf.org" , "draft-ietf-tram-turnbis@ietf.org" , "tram@ietf.org" , "brandon.williams@akamai.com" Thread-Topic: =?utf-8?B?W3RyYW1dIMOJcmljIFZ5bmNrZSdzIE5vIE9iamVjdGlvbiBvbiBkcmFmdC1p?= =?utf-8?Q?etf-tram-turnbis-27:_(with_COMMENT)?= Thread-Index: AQHVNJyeoaZBM6SyTEC4IXgEbhm1HqbARDZg Date: Mon, 8 Jul 2019 13:55:24 +0000 Message-ID: References: <156248752430.14312.15895119889558390147.idtracker@ietfa.amsl.com> In-Reply-To: <156248752430.14312.15895119889558390147.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.3.0.8 dlp-reaction: no-action authentication-results: spf=none (sender IP is ) smtp.mailfrom=TirumaleswarReddy_Konda@McAfee.com; x-originating-ip: [49.37.206.28] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 0a979ac0-7c90-4112-4e3c-08d703abed15 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:DM5PR16MB1481; x-ms-traffictypediagnostic: DM5PR16MB1481: x-ms-exchange-purlcount: 8 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 00922518D8 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(396003)(366004)(346002)(136003)(376002)(39860400002)(51914003)(13464003)(189003)(199004)(32952001)(99286004)(305945005)(8936002)(25786009)(11346002)(478600001)(7736002)(446003)(72206003)(110136005)(81156014)(476003)(80792005)(54906003)(81166006)(6436002)(14454004)(74316002)(6116002)(102836004)(53936002)(26005)(3846002)(9686003)(6306002)(53546011)(2906002)(55016002)(186003)(4326008)(6246003)(6506007)(66066001)(7696005)(76176011)(229853002)(33656002)(66574012)(76116006)(68736007)(66446008)(64756008)(66556008)(66476007)(486006)(5660300002)(52536014)(71190400001)(71200400001)(966005)(224303003)(73956011)(66946007)(86362001)(316002)(5024004)(14444005)(256004)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR16MB1481; H:DM5PR16MB1705.namprd16.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: McAfee.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: IHs9akpyL3aTgI49JzdmWCLr9ikhuvzxQ7LtHKMx8YKJ2uo2n32UXvIuKwCGFaCEOT/LW+uFmtlZ78UccOF4+a+QAxyjpBBb4kD1viNsQfXmaz8P0BDnuu1gri2HxD9EXarjk74ASXrGC/VzbUqfl/ffzeiVbCqDaSt76KEVN76F3kUtKgmUQ3OuSpPul73us06PA/TTUo1dR713ZtPAB4I5he3OIzSM2mFeueDpky0QAQdIO8XuL3Rt6awRECJzrrRkseP+KVrPoNNOXSom7XMEMNBuEyDaL160LIPrBltS5BXG7fLy78cPPr4Sdcq2F0Hlazm3Kqla5QXN0nXE231KLgsAdgEb8Jgv/gspswuLu4+oBlE9OidYl2g1uig33HKWprjdUSXU5uGcEZs6VT/JCEUknyJrubH4x/cIGgY= Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 0a979ac0-7c90-4112-4e3c-08d703abed15 X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Jul 2019 13:55:24.6770 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: TirumaleswarReddy_Konda@McAfee.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR16MB1481 X-OriginatorOrg: mcafee.com X-NAI-Spam-Flag: NO X-NAI-Spam-Level: X-NAI-Spam-Threshold: 15 X-NAI-Spam-Score: 0.2 X-NAI-Spam-Version: 2.3.0.9418 : core <6585> : inlines <7115> : streams <1826746> : uri <2865133> Archived-At: Subject: Re: [tram] =?utf-8?q?=C3=89ric_Vyncke=27s_No_Objection_on_draft-ietf?= =?utf-8?q?-tram-turnbis-27=3A_=28with_COMMENT=29?= X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.29 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 Jul 2019 13:56:02 -0000 SGkgRXJpYywNCg0KVGhhbmtzIGZvciB0aGUgcmV2aWV3LiBQbGVhc2Ugc2VlIGlubGluZSANCg0K PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiB0cmFtIDx0cmFtLWJvdW5jZXNA aWV0Zi5vcmc+IE9uIEJlaGFsZiBPZiDDiXJpYyBWeW5ja2UgdmlhDQo+IERhdGF0cmFja2VyDQo+ IFNlbnQ6IFN1bmRheSwgSnVseSA3LCAyMDE5IDE6NDkgUE0NCj4gVG86IFRoZSBJRVNHIDxpZXNn QGlldGYub3JnPg0KPiBDYzogdHJhbS1jaGFpcnNAaWV0Zi5vcmc7IGRyYWZ0LWlldGYtdHJhbS10 dXJuYmlzQGlldGYub3JnOyB0cmFtQGlldGYub3JnOw0KPiBicmFuZG9uLndpbGxpYW1zQGFrYW1h aS5jb20NCj4gU3ViamVjdDogW3RyYW1dIMOJcmljIFZ5bmNrZSdzIE5vIE9iamVjdGlvbiBvbiBk cmFmdC1pZXRmLXRyYW0tdHVybmJpcy0yNzoNCj4gKHdpdGggQ09NTUVOVCkNCj4gDQo+IFRoaXMg ZW1haWwgb3JpZ2luYXRlZCBmcm9tIG91dHNpZGUgb2YgdGhlIG9yZ2FuaXphdGlvbi4gRG8gbm90 IGNsaWNrIGxpbmtzIG9yDQo+IG9wZW4gYXR0YWNobWVudHMgdW5sZXNzIHlvdSByZWNvZ25pemUg dGhlIHNlbmRlciBhbmQga25vdyB0aGUgY29udGVudCBpcw0KPiBzYWZlLg0KPiANCj4gw4lyaWMg VnluY2tlIGhhcyBlbnRlcmVkIHRoZSBmb2xsb3dpbmcgYmFsbG90IHBvc2l0aW9uIGZvcg0KPiBk cmFmdC1pZXRmLXRyYW0tdHVybmJpcy0yNzogTm8gT2JqZWN0aW9uDQo+IA0KPiBXaGVuIHJlc3Bv bmRpbmcsIHBsZWFzZSBrZWVwIHRoZSBzdWJqZWN0IGxpbmUgaW50YWN0IGFuZCByZXBseSB0byBh bGwgZW1haWwNCj4gYWRkcmVzc2VzIGluY2x1ZGVkIGluIHRoZSBUbyBhbmQgQ0MgbGluZXMuIChG ZWVsIGZyZWUgdG8gY3V0IHRoaXMgaW50cm9kdWN0b3J5DQo+IHBhcmFncmFwaCwgaG93ZXZlci4p DQo+IA0KPiANCj4gUGxlYXNlIHJlZmVyIHRvIGh0dHBzOi8vd3d3LmlldGYub3JnL2llc2cvc3Rh dGVtZW50L2Rpc2N1c3MtY3JpdGVyaWEuaHRtbA0KPiBmb3IgbW9yZSBpbmZvcm1hdGlvbiBhYm91 dCBJRVNHIERJU0NVU1MgYW5kIENPTU1FTlQgcG9zaXRpb25zLg0KPiANCj4gDQo+IFRoZSBkb2N1 bWVudCwgYWxvbmcgd2l0aCBvdGhlciBiYWxsb3QgcG9zaXRpb25zLCBjYW4gYmUgZm91bmQgaGVy ZToNCj4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi10cmFtLXR1 cm5iaXMvDQo+IA0KPiANCj4gDQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gQ09NTUVOVDoNCj4gLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLQ0KPiANCj4gVGhhbmsgeW91IGFsbCBmb3IgdGhlIHdvcmsgcHV0IGludG8gdGhpcyBj bGVhciBhbmQgd2VsbC13cml0dGVuIGRvY3VtZW50LiBJDQo+IGFsc28gYXBwcmVjaWF0ZSB0aGUg ZmFjdCB0aGF0IFRVUk4gc2VydmVyIGNhbiBiZSB1c2VkIHRvIHByb3h5IGJldHdlZW4gSVB2NA0K PiBhbmQgSVB2Njsgb24gdGhpcyB0b3BpYywgdGhpcyBzcGVjaWZpYyB1c2UgY2FzZSBjb3VsZCBw cm9iYWJseSBiZSBkZXNjcmliZWQNCj4gZWFybHkgaW4gdGhlIGRvY3VtZW50IHJhdGhlciB0aGVu IGluIHNlY3Rpb24gNSAoZS5nLiB3aGVuIGRpc2N1c3NpbmcgdGhlDQo+IHRyYW5zcG9ydCBwcm90 b2NvbCBiZXR3ZWVuIGNsaWVudCBhbmQgc2VydmVyIG9yIGV2ZW4gZWFybGllcikuDQo+IA0KPiBG b3IgbXkgb3duIGN1cmlvc2l0eSwgaXNuJ3QgVFVSTiBzY29wZSBicm9hZGVyIHRoYW4gcGxhaW4g TkFUOiBjYW4gaXQgYWxzbyBiZQ0KPiB1c2VmdWwgaW4gdGhlIGFic2VuY2Ugb2YgTkFUIGlmIGlu Ym91bmQgJ2Nvbm5lY3Rpb24nIGFyZSBibG9ja2VkIGJ5IHNlY3VyaXR5DQo+IHBvbGljeSA/DQoN CkludGVyYWN0aXZlIENvbm5lY3Rpdml0eSBFc3RhYmxpc2htZW50IChJQ0UpIGhlbHBzIHNvbHZl IHRoZSBhYm92ZSBwcm9ibGVtIGJ5IHBlcmZvcm1pbmcgY29ubmVjdGl2aXR5IGNoZWNrcywgYnV0 IGRpcmVjdCBVRFAgY29ubmVjdGlvbiB3aWxsIG5vdCBiZSBwb3NzaWJsZSBldmVuIHdpdGggSUNF IGlmIGJvdGggZW5kcG9pbnRzIGFyZSBiZWhpbmQgTkFUcyB0aGF0IHBlcmZvcm0gYWRkcmVzcyBh bmQgcG9ydCBkZXBlbmRlbnQgbWFwcGluZy4gSW4gYWRkaXRpb24sIEVudGVycHJpc2UgZmlyZXdh bGwgbWF5IGJsb2NrIGRpcmVjdCBVRFAgY29ubmVjdGlvbnMgYnV0IGFsbG93IFVEUCB0cmFmZmlj IHJlbGF5ZWQgdGhyb3VnaCBhbiBFbnRlcnByaXNlIFRVUk4gc2VydmVyIChwbGVhc2Ugc2VlIGh0 dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM3NDc4I3NlY3Rpb24tMi4zLjUuMSkuIA0KDQo+ IA0KPiA9PSBDT01NRU5UUyA9PQ0KPiANCj4gLS0gU2VjdGlvbiAyIC0tDQo+IA0KPiBQbGVhc2Ug dXNlIHRoZSBuZXcgYm9pbGVycGxhdGUgUkZDIDgxNzQgOy0pDQoNCkZpeGVkLiANCg0KPiANCj4g LS0gU2VjdGlvbiAzLjEgLS0NCj4gDQo+IElzIHRoZXJlIGFueSByZWFzb24gd2h5IE1QVENQIGlz IG5vdCBzcGVjaWZpZWQgZm9yIHRoZSBjb21tdW5pY2F0aW9uDQo+IGJldHdlZW4gVFVSTiBjbGll bnQgYW5kIFRVUk4gc2VydmVyPyBUaGVyZSBpcyBhIHZlcnkgc2hvcnQgZXhwbGFuYXRpb24gaW4N Cj4gc2VjdGlvbiAxNSAiVENQIG11bHRpLXBhdGggaXMgbm90IHVzZWQgYnkgYm90aCBTSVAgYW5k IFdlYlJUQyBwcm90b2NvbHMNCj4gW1JGQzc0NzhdIGZvciBtZWRpYSBhbmQgbm9uLW1lZGlhIGRh dGEiIGJ1dCBpdCBkb2VzIG5vdCBhZGRyZXNzIHRoZSB1c2Ugb2YNCj4gTVBUQ1AgYmV0d2VlbiBU VVJOIGNsaWVudC9zZXJ2ZXIuDQoNClRVUk4gaXMgdHlwaWNhbGx5IHVzZWQgYnkgU0lQIGFuZCBX ZWJSVEMgcHJvdG9jb2xzIHRvIHJlbGF5IG1lZGlhIHN0cmVhbXMsIGJ1dCBSVFAgYXNzdW1lcyBh IHNpbmdsZSBwYXRoIGFuZCBtYWtlIGRlY2lzaW9ucyBiYXNlZCBvbiB0aGUgbWVhc3VyZWQgY2hh cmFjdGVyaXN0aWNzIG9mIHRoaXMgc2luZ2xlIHBhdGggKHdpdGggdGhlIGV4Y2VwdGlvbiBvZiBN dWx0aXBhdGggUlRQIGRpc2N1c3NlZCBpbiBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJh ZnQtaWV0Zi1hdnRjb3JlLW1wcnRwLTAzKS4NCg0KPiANCj4gLS0gU2VjdGlvbiAzLjcgLS0NCj4g DQo+IFRoZSA1MDAgYnl0ZXMgZ3VpZGVsaW5lIHRvIGF2b2lkIGZyYWdtZW50YXRpb24sIGlzIHRo ZXJlIGFueSBkYXRhIGJhY2tpbmcgdGhlDQo+IHNlbnRlbmNlICIuLi53aWxsIGdlbmVyYWxseSBh dm9pZCBJUCBmcmFnbWVudGF0aW9uLiIgPw0KDQpZZXMsIElmIHRoZSBQTVRVIGlzIG5vdCBrbm93 biwgYW5kIG9uIGxlZ2FjeSBvciBvdGhlcndpc2UgdW51c3VhbCBuZXR3b3JrcyB0aGUgZ3VpZGVs aW5lIHNob3VsZCB3b3JrIChzZWUgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzcyNTIj c2VjdGlvbi00LjYgYW5kIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXRz dndnLWRhdGFncmFtLXBscG10dWQtMDgpLg0KDQo+IA0KPiBJbiB0aGUgc2FtZSBzZWN0aW9uLCB0 aGUgdGV4dCBhYm91dCAnREYgYml0JyBzaG91bGQgYmUgY2xlYXIgdGhhdCBpdCBpcyBvYnZpb3Vz bHkNCj4gZm9yIElQdjQgKGl0IGlzIGluZGljYXRlZCAyIHBhcmFncmFwaHMgYmVsb3cpLg0KDQpE b25lLiANCg0KPiANCj4gLS0gU2VjdGlvbiAzLjkgLS0NCj4gDQo+IFRoZSBUQ1AvVURQL0RUTFMg ZGlzY3Vzc2lvbiBvZiAnaGFwcHkgZXllYmFsbCcgaXMgY29uZnVzaW5nIGJldHdlZW4gInVzZQ0K PiB0aGUgZmlyc3QgVENQIGNvbm5lY3Rpb24gdGhhdCBpcyBlc3RhYmxpc2hlZCIgYW5kICJpZiBj b25uZWN0aW9ucyBhcmUNCj4gZXN0YWJsaXNoZWQgb24gYm90aCBJUCBhZGRyZXNzIGZhbWlsaWVz Li4uIiBXaGljaCBzZW50ZW5jZSBzaG91bGQgYmUgdXNlZD8NCj4gV2h5IHBsYWluIFJGQw0KPiA4 MzA1IGlzIG5vdCBlbm91Z2g/DQoNCkdvb2QgcG9pbnQsIG1vZGlmaWVkIHRleHQgYXMgZm9sbG93 czoNCg0KICAgbyAgRm9yIFRDUCBvciBUTFMtb3Zlci1UQ1AsIHRoZSByZXN1bHRzIG9mIHRoZSBI YXBweSBFeWViYWxscw0KICAgICAgcHJvY2VkdXJlIFtSRkM4MzA1XSBhcmUgdXNlZCBieSB0aGUg VFVSTiBjbGllbnQgZm9yIHNlbmRpbmcgaXRzDQogICAgICBUVVJOIG1lc3NhZ2VzIHRvIHRoZSBz ZXJ2ZXIuDQoNCj4gDQo+IC0tIFNlY3Rpb24gNy4yIC0tDQo+IA0KPiBXaGF0IGlzIHRoZSBleHBl Y3RlZCBzZXJ2ZXIgYmVoYXZpb3Igd2hlbiByZWNlaXZpbmcgYSBET05ULUZSQUdNRU5UDQo+IHdo ZW4gdGhlIFJFUVVFU1RFRC1BRERSRVNTLUZBTUlMWSBpcyBJUHY2ID8gVGhlIFNUVU4gZG9jdW1l bnQNCj4gYXBwZWFycyB0byB1c2UgRE9OVC1GUkFHTUVOVCBvbmx5IHdoZW4gcmVjZWl2aW5nIHRy YWZmaWMgZnJvbSB0aGUgcGVlcnMuDQoNCkl0IGlzIGRpc2N1c3NlZCBpbiBTZWN0aW9ucyAxNCBh bmQgMTUuDQoNCj4gDQo+IC0tIFNlY3Rpb24gOSAtLQ0KPiANCj4gQWJvdXQgdGhlIHBlcm1pc3Np b24gYmFzZWQgb24gdGhlIHBlZXIgSVAgYWRkcmVzcywgdGhlIHRleHQgaXMgYWJvdXQgVURQLA0K PiBidXQgd2hhdCBhYm91dCBJQ01QIG1lc3NhZ2VzPyAob2J2aW91bHN5IHRoZWlyIHNvdXJjZSBj b3VsZCBiZSBhbnkgcm91dGVyDQo+IG9uIHRoZQ0KPiBwYXRoKSBUaGUgdGV4dCBzaG91bGQgcmVm ZXIgdG8gc2VjdGlvbiAxMS41DQoNClllcywgUGxlYXNlIHNlZSBodHRwczovL3Rvb2xzLmlldGYu b3JnL2h0bWwvZHJhZnQtaWV0Zi10cmFtLXR1cm5iaXMtMjcjc2VjdGlvbi0xMi43ICANCg0KQ2hl ZXJzLA0KLVRpcnUNCg0KPiANCj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQo+IHRyYW0gbWFpbGluZyBsaXN0DQo+IHRyYW1AaWV0Zi5vcmcNCj4g aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90cmFtDQo= From nobody Mon Jul 8 07:18:51 2019 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 7CD0A1201EC; Mon, 8 Jul 2019 07:18:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mcafee.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 483ZFm5wqlbF; Mon, 8 Jul 2019 07:18:46 -0700 (PDT) Received: from DNVWSMAILOUT1.mcafee.com (dnvwsmailout1.mcafee.com [161.69.31.173]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2CAE41201CD; Mon, 8 Jul 2019 07:18:45 -0700 (PDT) X-NAI-Header: Modified by McAfee Email Gateway (5500) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mcafee.com; s=s_mcafee; t=1562594892; h=From: To:CC:Subject:Thread-Topic:Thread-Index:Date: Message-ID:References:In-Reply-To:Accept-Language: Content-Language:X-MS-Has-Attach:X-MS-TNEF-Correlator: dlp-product:dlp-version:dlp-reaction:authentication-results: x-originating-ip:x-ms-publictraffictype:x-ms-office365-filtering-correlation-id: x-microsoft-antispam:x-ms-traffictypediagnostic: x-ms-exchange-purlcount:x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers:x-forefront-prvs: x-forefront-antispam-report:received-spf:x-ms-exchange-senderadcheck: x-microsoft-antispam-message-info:Content-Type: Content-Transfer-Encoding:MIME-Version:X-MS-Exchange-CrossTenant-Network-Message-Id: X-MS-Exchange-CrossTenant-originalarrivaltime: X-MS-Exchange-CrossTenant-fromentityheader: X-MS-Exchange-CrossTenant-id:X-MS-Exchange-CrossTenant-mailboxtype: X-MS-Exchange-CrossTenant-userprincipalname: X-MS-Exchange-Transport-CrossTenantHeadersStamped: X-OriginatorOrg:X-NAI-Spam-Flag:X-NAI-Spam-Level: X-NAI-Spam-Threshold:X-NAI-Spam-Score:X-NAI-Spam-Version; bh=GETm54WgCBWcPpWyWH+NxVojeB5cjpXhTG2ith 8H9+g=; b=OQwX5+D+kEIXRMn7K2Nq4GmtzrypnzY0yuJV3OEL iuXPc3NAEbjLriA7ClHAGlhG+R9FdUqlKFEJOOyihopGfYtQ4c YubIcqFrU/kxOgf0g+Mzeg8udOJ8zCVLsQZODHdATf1SXayq1Q y5Un2+cp2IWnh728JaVEyB4ALd5tdGc= Received: from DNVEXAPP1N06.corpzone.internalzone.com (unknown [10.44.48.90]) by DNVWSMAILOUT1.mcafee.com with smtp (TLS: TLSv1/SSLv3,256bits,ECDHE-RSA-AES256-SHA384) id 607d_9297_f2b6f823_38b6_40ce_a733_aeaf1269efd4; Mon, 08 Jul 2019 08:08:11 -0600 Received: from DNVEXAPP1N05.corpzone.internalzone.com (10.44.48.89) by DNVEXAPP1N06.corpzone.internalzone.com (10.44.48.90) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Mon, 8 Jul 2019 08:18:28 -0600 Received: from DNVO365EDGE2.corpzone.internalzone.com (10.44.176.74) by DNVEXAPP1N05.corpzone.internalzone.com (10.44.48.89) with Microsoft SMTP Server (TLS) id 15.0.1395.4 via Frontend Transport; Mon, 8 Jul 2019 08:18:28 -0600 Received: from NAM04-CO1-obe.outbound.protection.outlook.com (10.44.176.242) by edge.mcafee.com (10.44.176.74) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Mon, 8 Jul 2019 08:18:26 -0600 Received: from DM5PR16MB1705.namprd16.prod.outlook.com (10.172.44.147) by DM5PR16MB1403.namprd16.prod.outlook.com (10.173.215.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2052.18; Mon, 8 Jul 2019 14:18:26 +0000 Received: from DM5PR16MB1705.namprd16.prod.outlook.com ([fe80::570:2208:75c2:5f17]) by DM5PR16MB1705.namprd16.prod.outlook.com ([fe80::570:2208:75c2:5f17%8]) with mapi id 15.20.2052.019; Mon, 8 Jul 2019 14:18:26 +0000 From: "Konda, Tirumaleswar Reddy" To: Christopher Wood , "secdir@ietf.org" CC: "draft-ietf-tram-turnbis.all@ietf.org" , "ietf@ietf.org" , "tram@ietf.org" Thread-Topic: [tram] Secdir last call review of draft-ietf-tram-turnbis-27 Thread-Index: AQHVNQMAJeymFhPVnEO1ky4wx5pqrabAcMBw Date: Mon, 8 Jul 2019 14:18:26 +0000 Message-ID: References: <156253133809.549.13521510978566357744@ietfa.amsl.com> In-Reply-To: <156253133809.549.13521510978566357744@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.3.0.8 dlp-reaction: no-action authentication-results: spf=none (sender IP is ) smtp.mailfrom=TirumaleswarReddy_Konda@McAfee.com; x-originating-ip: [49.37.206.28] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 933ce875-82a7-4a58-e040-08d703af2494 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:DM5PR16MB1403; x-ms-traffictypediagnostic: DM5PR16MB1403: x-ms-exchange-purlcount: 11 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 00922518D8 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(366004)(396003)(136003)(39860400002)(346002)(376002)(32952001)(51914003)(13464003)(199004)(189003)(5660300002)(76116006)(4326008)(73956011)(52536014)(66446008)(81166006)(14454004)(72206003)(186003)(66946007)(478600001)(476003)(81156014)(26005)(64756008)(6246003)(86362001)(966005)(8676002)(66476007)(66556008)(76176011)(53546011)(71200400001)(2906002)(8936002)(25786009)(7696005)(55016002)(486006)(71190400001)(66066001)(9686003)(6506007)(6306002)(3846002)(99286004)(68736007)(6116002)(229853002)(33656002)(2501003)(316002)(54906003)(305945005)(446003)(102836004)(80792005)(256004)(5024004)(74316002)(110136005)(14444005)(7736002)(6436002)(53936002)(11346002)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR16MB1403; H:DM5PR16MB1705.namprd16.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: McAfee.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: GVZ/nyGTSnm/7dXWzIcqvhwsBj70cblOI7OGBk81+wmbWi6LfXECiY6gJEIMXLiqVp/irlsPFdZd1eMc9qd+1yjWBl+SG3P1JbkJc0t39Tue295/DTW+NS7cSVDrRWh3HmT+YqxnGULvA47vROlZLR3y+JtlWPkxCFXmBJjDuEmSv1D8UWs14oVPZEjdtCRHhiVV3tMJwl3cBoLyj89xKHd8k9Ms5nDDd37Mw16OL3KPIGkdOSh3SHj6RdOoc00TCbMu23O9bwqt900g92wAEs3HAqjEQV3ixTfPR+l7cdK9pZgkOYhblmqTFlif0Vgw0XmN+l4EvttQ13/tw6QyiYGKvfNTPwTkHoOOFh6XVARgWZa8MuvB4ngypW6D6uH5C4kVv+SzVOragZjlcDUZVRdxKKzQtdfd4XtUqwLwEME= Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 933ce875-82a7-4a58-e040-08d703af2494 X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Jul 2019 14:18:26.1669 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: TirumaleswarReddy_Konda@McAfee.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR16MB1403 X-OriginatorOrg: mcafee.com X-NAI-Spam-Flag: NO X-NAI-Spam-Level: X-NAI-Spam-Threshold: 15 X-NAI-Spam-Score: 0.1 X-NAI-Spam-Version: 2.3.0.9418 : core <6585> : inlines <7115> : streams <1826746> : uri <2865133> Archived-At: Subject: Re: [tram] Secdir last call review of draft-ietf-tram-turnbis-27 X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.29 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 Jul 2019 14:18:51 -0000 SGkgQ2hyaXN0b3BoZXIsDQoNClRoYW5rcyBmb3IgdGhlIGRldGFpbGVkIHJldmlldy4gUGxlYXNl IHNlZSBpbmxpbmUNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiB0cmFt IDx0cmFtLWJvdW5jZXNAaWV0Zi5vcmc+IE9uIEJlaGFsZiBPZiBDaHJpc3RvcGhlciBXb29kIHZp YQ0KPiBEYXRhdHJhY2tlcg0KPiBTZW50OiBNb25kYXksIEp1bHkgOCwgMjAxOSAxOjU5IEFNDQo+ IFRvOiBzZWNkaXJAaWV0Zi5vcmcNCj4gQ2M6IGRyYWZ0LWlldGYtdHJhbS10dXJuYmlzLmFsbEBp ZXRmLm9yZzsgaWV0ZkBpZXRmLm9yZzsgdHJhbUBpZXRmLm9yZw0KPiBTdWJqZWN0OiBbdHJhbV0g U2VjZGlyIGxhc3QgY2FsbCByZXZpZXcgb2YgZHJhZnQtaWV0Zi10cmFtLXR1cm5iaXMtMjcNCj4g DQo+IFRoaXMgZW1haWwgb3JpZ2luYXRlZCBmcm9tIG91dHNpZGUgb2YgdGhlIG9yZ2FuaXphdGlv bi4gRG8gbm90IGNsaWNrIGxpbmtzIG9yDQo+IG9wZW4gYXR0YWNobWVudHMgdW5sZXNzIHlvdSBy ZWNvZ25pemUgdGhlIHNlbmRlciBhbmQga25vdyB0aGUgY29udGVudCBpcw0KPiBzYWZlLg0KPiAN Cj4gUmV2aWV3ZXI6IENocmlzdG9waGVyIFdvb2QNCj4gUmV2aWV3IHJlc3VsdDogSGFzIE5pdHMN Cj4gDQo+IEkgaGF2ZSByZXZpZXdlZCB0aGlzIGRvY3VtZW50IGFzIHBhcnQgb2YgdGhlIHNlY3Vy aXR5IGRpcmVjdG9yYXRlJ3Mgb25nb2luZw0KPiBlZmZvcnQgdG8gcmV2aWV3IGFsbCBJRVRGIGRv Y3VtZW50cyBiZWluZyBwcm9jZXNzZWQgYnkgdGhlIElFU0cuIFRoZXNlDQo+IGNvbW1lbnRzIHdl cmUgd3JpdHRlbiBwcmltYXJpbHkgZm9yIHRoZSBiZW5lZml0IG9mIHRoZSBzZWN1cml0eSBhcmVh DQo+IGRpcmVjdG9ycy4NCj4gRG9jdW1lbnQgZWRpdG9ycyBhbmQgV0cgY2hhaXJzIHNob3VsZCB0 cmVhdCB0aGVzZSBjb21tZW50cyBqdXN0IGxpa2UgYW55DQo+IG90aGVyIGxhc3QgY2FsbCBjb21t ZW50cy4NCj4gDQo+IFRoZSBzdW1tYXJ5IG9mIHRoZSByZXZpZXcgaXM6IFJlYWR5IHdpdGggbml0 cw0KPiANCj4gU3VtbWFyeToNCj4gDQo+IEluIGdlbmVyYWwsIHRoZSBkb2N1bWVudCBpcyB3ZWxs IHdyaXR0ZW4gYW5kIGNsZWFybHkgZm91bmRlZCBpbiBvcGVyYXRpb25hbA0KPiBleHBlcmllbmNl LiBUaGUgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgYXJlIHRob3JvdWdoLCBwcm92aWRpbmcgZXhh bXBsZXMNCj4gd2hlcmUgbmVjZXNzYXJ5IHRvIGhpZ2hsaWdodCBpbXBvcnRhbnQgcHJvYmxlbSBh cmVhcy4gSXQgZHJhd3MgYSBjbGVhciBsaW5lDQo+IGJldHdlZW4gaXNzdWVzIGJlc3QgYWRkcmVz c2VkIGJ5IGFwcGxpY2F0aW9ucyBvdXRzaWRlIG9mIFRVUk4sIGFuZA0KPiBwcm92aWRlcyBzdWZm aWNpZW50IGRldGFpbCBmb3IgdGhvc2UgaXNzdWVzIGluIHNjb3BlLiBNeSBjb21tZW50cyBhbmQN Cj4gcXVlc3Rpb25zIGFyZSwgaG9wZWZ1bGx5LCBtb3N0bHkgbml0cy4NCj4gDQo+IEdlbmVyYWwg Y29tbWVudHM6DQo+IA0KPiAtIFRVUk4gc2VydmVyIGF1dGhlbnRpY2F0aW9uIGluIHRoZSBjYXNl IG9mIChEKVRMUyBpcyB1bmRlcnNwZWNpZmllZC4gQXJlDQo+IHNlcnZlcnMgYXNzdW1lZCB0byBo YXZlIFdlYlBLSSBjZXJ0aWZpY2F0ZXMsIE9PQi10cnVzdGVkIHJhdyBwdWJsaWMga2V5cywNCj4g b3Igc29tZXRoaW5nIGVsc2U/IElzIHRoZXJlIGEgcHJlZmVycmVkIGZvcm0gb2YgYXV0aGVudGlj YXRpb24/IA0KPiBSZWxhdGVkbHksIGluDQo+IFNlY3Rpb24gMy4yLCBob3cgZG8gY2xpZW50cyBh dXRoZW50aWNhdGUgdGhlIHNlcnZlcj8gDQoNClNlcnZlciBjZXJ0aWZpY2F0ZSB2YWxpZGF0aW9u IGlzIGRpc2N1c3NlZCBpbiBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi10 cmFtLXN0dW5iaXMtMjEjc2VjdGlvbi02LjIuMy4gIEkgaGF2ZSBtb2RpZmllZCB0aGUgdGV4dCBh cyBmb2xsb3dzOg0KDQpJZiAoRClUTFMgdHJhbnNwb3J0IGlzIHVzZWQgYmV0d2VlbiB0aGUgVFVS TiBjbGllbnQgYW5kIHRoZSBUVVJOIHNlcnZlciwgdGhlIGNpcGhlciBzdWl0ZXMsDQpzZXJ2ZXIg Y2VydGlmaWNhdGUgdmFsaWRhdGlvbiBhbmQgYXV0aGVudGljYXRpb24gb2YgVFVSTiBzZXJ2ZXIg YXJlDQpkaXNjdXNzZWQgaW4gU2VjdGlvbiA2LjIuMyBvZiBbSS1ELmlldGYtdHJhbS1zdHVuYmlz XQ0KDQo+LSBTZWN0aW9uIDMuNzogQ291bGQNCj4gVFVSTiBzZXJ2ZXJzIG5vdCBjaHVuayBkYXRh IGZyb20gc3RyZWFtLW9yaWVudGVkIHRyYW5zcG9ydHMgKFRDUCBvciBUTFMpDQo+IHRvIGEgcHJl ZmVycmVkIE1UVSBzaXplIGJlZm9yZSByZWxheWluZyB0byBwZWVycz8gDQo+IFNwZWNpZmljYWxs eSwgdGhlcmUgYXJlIGxpa2VseQ0KPiBzb21lIGNhc2VzIHdoZXJlaW4gdGhlIHNlcnZlciBjb3Vs ZCBkZWFsIHdpdGggdGhlIGNsaWVudCBkYXRhIG1lc3NhZ2VzDQo+IGxhcmdlciB0aGFuIHRoZSBy ZWNvbW1lbmRlZCA1MDBCIGxpbWl0LiBPbiB0aGF0IHBvaW50LCBzaG91bGQgc2VydmVycyBldmVu DQo+IGFjY2VwdCBkYXRhIGxhcmdlciB0aGFuIHRoaXMgcmVjb21tZW5kZWQgc2l6ZSA/IC0gDQoN ClBsZWFzZSBzZWUgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtdHJhbS10 dXJuYmlzLTI3I3NlY3Rpb24tMTUgZm9yIFRDUC10by1VRFAgcmVsYXkuIElmIHRoZSBQTVRVIGlz IG5vdCBrbm93biwgYW5kIG9uIGxlZ2FjeSBvciBvdGhlcndpc2UgdW51c3VhbCBuZXR3b3Jrcywg DQo1MDAgYnl0ZSBsaW1pdCBmb3IgYXBwbGljYXRpb24gZGF0YSBpcyByZWNvbW1lbmRlZC4NCg0K PiBTZWN0aW9uIDMuOTogVGhlcmUgbWF5IGJlDQo+IGNhc2VzIHdoZXJlIHRoZSBUTFMgY29ubmVj dGlvbiBwb3N0IFRDUCBjb25uZWN0aW9uIGVzdGFibGlzaG1lbnQgZmFpbHMuIEl0DQo+IHdvdWxk IHRoZXJlZm9yZSBzZWVtcyBwcnVkZW50IHRvIG5vdCBkZWNsYXJlIHZpY3RvcnkgZm9yIG9uZSBj b25uZWN0aW9uDQo+IG92ZXIgdGhlIG90aGVyIHVudGlsIFRMUyBjb25uZWN0cywgdG9vLiAtDQoN CkFncmVlZCwgRXJpYyAoYXMgcGFydCBvZiBJU0VHIHJldmlldykgc3VnZ2VzdGVkIHRvIHNpbXBs aWZ5IHRoZSB0ZXh0LiBJIGhhdmUgdXBkYXRlZCB0aGUgdGV4dCBhcyBmb2xsb3dzOg0KDQogICBv ICBGb3IgVENQIG9yIFRMUy1vdmVyLVRDUCwgdGhlIHJlc3VsdHMgb2YgdGhlIEhhcHB5IEV5ZWJh bGxzDQogICAgICBwcm9jZWR1cmUgW1JGQzgzMDVdIGFyZSB1c2VkIGJ5IHRoZSBUVVJOIGNsaWVu dCBmb3Igc2VuZGluZyBpdHMNCiAgICAgIFRVUk4gbWVzc2FnZXMgdG8gdGhlIHNlcnZlci4NCg0K PiBTZWN0aW9uIDMgY291bGQgYmVuZWZpdCBmcm9tIGENCj4gc3Vic2VjdGlvbiBvbiByZXBsYXlz IGFuZCB0aGUgbm9uY2Ugcm9sZS4gSW4gcGFydGljdWxhciwgYXMgbGF0ZXIgZGlzY3Vzc2VkIGlu DQo+IHRoZSBzZWN1cml0eSBjb25zaWRlcmF0aW9ucywgc29tZSBvZiB0aGVzZSBhdHRhY2tzIGFy ZSBub3QgbmV3IHRvIFRVUk4gYW5kDQo+IHNob3VsZCB0aGVyZWZvcmUgYmUgZGVhbHQgd2l0aCBi eSB0aGUgYXBwbGljYXRpb24gcHJvdG9jb2wgKFNSVFApLiBUaGlzDQo+IHNlY3Rpb24gbWlnaHQg YWxzbyBkZXNjcmliZSBub25jZSByb3RhdGlvbiBwb2xpY2llcyB3aXRoIG1vcmUgc3BlY2lmaWNp dHksIGFzDQo+IHRoaXMgaXMgdW5kZXJzcGVjaWZpZWQgaW4gdGhlIGRvY3VtZW50LiANCg0KSXQg aXMgZGlzY3Vzc2VkIGluIFNlY3Rpb24gNSBpbiB0aGUgc3BlY2lmaWNhdGlvbiwgdGhlIHNlcnZl ciBzaG91bGQgZXhwaXJlIHRoZSBub25jZSBhdCBsZWFzdCBvbmNlIGV2ZXJ5IGhvdXIgZHVyaW5n IHRoZSBsaWZldGltZSBvZiB0aGUgYWxsb2NhdGlvbi4NCg0KPi0gU2VjdGlvbiAzIGNvdWxkIGFs c28gYmVuZWZpdCBmcm9tDQo+IGRpc2N1c3Npb24gYWJvdXQgY2xlYXJ0ZXh0IHZlcnN1cyBlbmNy eXB0aW9uIHRyYW5zcG9ydHMgYmV0d2VlbiBjbGllbnRzIGFuZA0KPiBzZXJ2ZXJzLg0KDQpJdCBp cyBkaXNjdXNzZWQgaW4gaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtdHJh bS10dXJuYmlzLTI3I3NlY3Rpb24tMjEuMS42LiANCg0KPiBFbmNyeXB0aW5nIHRoZSBub25jZSwg dXNlcm5hbWUsIHJlYWxtLCBldGMuLCBhbW9uZyBvdGhlciB0aGluZ3MsIGhhcw0KPiBvYnZpb3Vz IGJlbmVmaXRzLiAtIFdoeSBhcmUgU09GVFdBUkUgYW5kIEZJTkdFUlBSSU5UIGF0dHJpYnV0ZXMN Cj4gcmVjb21tZW5kZWQ/ICBJdCBzZWVtcyBsaWtlIGNsaWVudHMgc2hvdWxkIGJlIGRpc2NvdXJh Z2VkIGZyb20gc2VuZGluZw0KPiB0aGVzZSBpZiBhbnl0aGluZywgZXNwZWNpYWxseSBpZiBub3Qg dXNlZCB0byBtYWtlIGFsbG9jYXRpb24gZGVjaXNpb25zIG9uIHRoZQ0KPiBzZXJ2ZXIuIA0KDQpV c2VybmFtZSBtYXkgbm90IGJlIHRoZSB1c2VyIGlkZW50aXR5LCBQbGVhc2Ugc2VlIGh0dHBzOi8v dG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM3NjM1KSwgSXQgY291bGQgYmUgYW4gZXBoZW1lcmFsIGFu ZCB1bmlxdWUga2V5IGlkZW50aWZpZXIuIEZ1cnRoZXIsIHVzZXJuYW1lIGNhbiBiZSBhbm9ueW1p emVkIChwbGVhc2Ugc2VlIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXRy YW0tc3R1bmJpcy0yMSNzZWN0aW9uLTE0LjQpLiAgIA0KU09GVFdBUkUgYW5kIEZJTkdFUlBSSU5U IGF0dHJpYnV0ZXMgYXJlIGRlZmluZWQgaW4gdGhlIFNUVU4gc3BlY2lmaWNhdGlvbiwgc2VlIGh0 dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXRyYW0tc3R1bmJpcy0yMS4gDQoN Ci0gU2VjdGlvbiA1OiBXaGVuIHNlcnZlcnMgcmVjZWl2ZSBkYXRhIHRoYXQgZXhjZWVkcyBhbiBh bGxvY2F0aW9u4oCZcw0KPiBiYW5kd2lkdGggcXVvdGEsIHNlcnZlcnMgc2lsZW50bHkgZGlzY2Fy ZCB0aGlzIGRhdGEuIFRoaXMgbWVhbnMgdGhlcmXigJlzIG5vDQo+IGFsbG9jYXRpb24tYmFzZWQg ZmxvdyBjb250cm9sIG1lY2hhbmlzbSBiZXR3ZWVuIGNsaWVudCBhbmQgc2VydmVyIGJleW9uZA0K PiB3aGF04oCZcyBwcm92aWRlZCBieSB0aGUgdHJhbnNwb3J0IHByb3RvY29sLCByaWdodD8gDQoN ClllcywgVURQIGRvZXMgbm90IGluY2x1ZGUgYSBjb25nZXN0aW9uIGNvbnRyb2wgbWVjaGFuaXNt LiAgDQoNCj4gVGhpcyBzZWVtcyBmaW5lLCB0aG91Z2gNCj4gcGVyaGFwcyBzb21lIGRpc2N1c3Np b24gb2Ygd2h5IHRoaXMgZGVzaWduIGRlY2lzaW9uIHdhcyBtYWRlIHdvdWxkIGJlDQo+IGhlbHBm dWwuIEZvciBleGFtcGxlLCBJIGNvdWxkIGltYWdpbmUgZXhwbGljaXQgc2lnbmFscyBmcm9tIHNl cnZlcnMgdG8gY2xpZW50cw0KPiB0aGF0IGluZGljYXRlIHNlcnZlciBzdGF0ZSB3b3VsZCByZXZl YWwgaW5mb3JtYXRpb24gYWJvdXQgb3RoZXIgYWxsb2NhdGlvbnMNCj4gb24gdGhlIHNlcnZlciwg d2hpY2ggbWlnaHQgYmUgcHJvYmxlbWF0aWMuIC0NCg0KVGhlIGVycm9ycyA0ODYgKEFsbG9jYXRp b24gUXVvdGEgRXhjZWVkZWQpIG9yIDUwOCAoSW5zdWZmaWNpZW50IENhcGFjaXR5KSAgZG8gbm90 IHJldmVhbCBpbmZvcm1hdGlvbiBvZiB3aGljaCBvdGhlciB1c2VycyBhcmUgdXNpbmcgdGhlIFRV Uk4gc2VydmVyLiANCg0KPiBTZWN0aW9uIDcuMiBzdWdnZXN0cyB0aGF0DQo+IHNlcnZlcnMgY2Fu IHJlZGlyZWN0IGNsaWVudCBhbGxvY2F0aW9uIHJlcXVlc3RzIHRvIG90aGVyIHNlcnZlcnMuIENh biB0aGlzDQo+IGNyZWF0ZSBhIGxvb3AsIHdoZXJlaW4gdHdvIFRVUk4gc2VydmVycyByZWRpcmVj dCB0byBvbmUgYW5vdGhlcj8gDQoNClRoZSBjbGllbnQgZGV0ZWN0IGFuZCBzdG9wIHRoZSBsb29w LCBpdCBpcyBzaW1pbGFyIHRvIEhUVFAgcmVkaXJlY3Rpb24uDQoNCj4gTW9yZW92ZXIsDQo+IGlz IGl0IGFjY2VwdGFibGUgZm9yIG9uZSBUVVJOIHNlcnZlciB0byByZWRpcmVjdCB0byBhbiB1bnJl bGF0ZWQgVFVSTiBzZXJ2ZXI/DQo+IChJdCBzaG91bGQgYmUgbWFkZSBjbGVhciBoZXJlIHRoYXQg dGhlc2UgcmVzcG9uc2VzIGFyZSBhdXRoZW50aWNhdGVkLCBhcw0KPiBvdGhlcndpc2UgaXQgd291 bGQgYmUgcG9zc2libGUgZm9yIGFuIG9uLXBhdGggYWR2ZXJzYXJ5IHRvIHJlZGlyZWN0IGFsbG9j YXRpb24NCj4gcmVxdWVzdHMgdG8gYSBzZXJ2ZXIgaXQgb3ducy4pIA0KDQpJdCBpcyBhbHJlYWR5 IGRpc2N1c3NlZCBpbiBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi10cmFt LXN0dW5iaXMtMjEjc2VjdGlvbi0xMCANCg0KPiAtIFNlY3Rpb24NCj4gMjEuMS4yOiBVc2Ugb2Yg KEQpVExTIGRvZXNu4oCZdCBoZWxwIGFnYWluc3QgZGljdGlvbmFyeSBhdHRhY2tzIG11Y2gsIHNp bmNlDQo+IHByZXN1bWFibHkgdGhlcmXigJlzIGxvdyBlbnRyb3B5IGluIHVzZXJuYW1lcyBhbmQg cGFzc3dvcmRzIGFsaWtlLiBUaHVzLCBJDQo+IHF1ZXN0aW9uIHdoZXRoZXIgdGhpcyBpcyBhIOKA nHN0cm9uZ2Vy4oCdIG1pdGlnYXRpb24uIA0KDQpUaGUgc2VjdGlvbiBvbmx5IGRpc2N1c3NlcyAi b2ZmbGluZSIgZGljdGlvbmFyeSBhdHRhY2ssIEhvdyBpcyBvZmZsaW5lIGRpY3Rpb25hcnkgYXR0 YWNrIHBvc3NpYmxlIHdpdGggKEQpVExTID8NCg0KPi0gU2VjdGlvbiAxMi4xLjY6IOKAnHVzZXJu YW1l4oCdDQo+IGFuZCDigJxyZWFsbeKAnSBhcmUgbm90IGNvbnNpZGVyZWQgc2Vuc2l0aXZlPyBU aGV5IHNlZW0gc2Vuc2l0aXZlIHRvIG1lLiAtIEFzIGFuDQo+IGV4dGVuc2lvbiwgaXQgc2VlbXMg cG9zc2libGUgdG8gaW1wcm92ZSBvbiB3aGF04oCZcyBpbiBTVFVOLiBGb3IgZXhhbXBsZSwgaXQN Cj4gbWF5IGJlIHdvcnRod2hpbGUsIGhlcmUgb3IgZWxzZXdoZXJlLCB0byB1cGRhdGUgU1RVTuKA mXMgbG9uZyB0ZXJtDQo+IGNyZWRlbnRpYWwga2V5IGRlcml2YXRpb24gcHJvY2VzcyAoTUQ1KHVz ZXJuYW1lICsgcmVhbG0gKyBwYXNzd29yZCkpIHRvDQo+IHNvbWV0aGluZyBhIGJpdCBtb3JlIG1v ZGVybi4gVGhpcyBpcyBxdWl0ZSBsaWtlbHkgb3V0IG9mIHNjb3BlLCB0aG91Z2ggaW4gdGhlDQo+ IGNvbnRleHQgb2YgY2xpZW50IGF1dGhlbnRpY2F0aW9uIGl0IHNlZW1zIHdvcnRoIG1lbnRpb25p bmcgdGhhdCBUVVJOIGlzDQo+IGxpbWl0ZWQgdG8gdGhlIG1lY2hhbmlzbXMgcHJvdmlkZWQgYnkg U1RVTi4NCg0KQXMgbWVudGlvbmVkIHByZXZpb3VzbHksIHVzZXJuYW1lIG1heSBub3QgYmUgdGhl IGVuZC11c2VyIHJlYWwgaWRlbnRpdHkgYW5kIHVzZXJuYW1lIGNhbiBiZSBhbm9ueW1pemVkLiAg IA0KDQo+IA0KPiBOaXRzIGFuZCBvdGhlciBjb21tZW50czoNCj4gDQo+IC0gU2VjdGlvbiAyOiDi gJxtZXNzYWdlLWRpZ2VzdOKAnSBpcyB1bmRlZmluZWQgaW4gdGhlIE5vbmNlIGRlZmluaXRpb24u DQoNClRoYW5rcywgcmVwbGFjZWQgIm1lc3NhZ2UtZGlnZXN0IiB3aXRoICJzZXJ2ZXIgcmVzcG9u c2UiDQoNCj4gLSBTZWN0aW9uIDM6IEl04oCZcyBwcm9iYWJseSB3b3J0aCBjaXRpbmcgUkZDODQ0 NiBhcyB0aGUgcmVjb21tZW5kZWQgdmVyc2lvbg0KPiBvZiBUTFMuIA0KDQpUaGUgZHJhZnQgc2F5 cyBndWlkYW5jZSBnaXZlbiBpbiBbUkZDNzUyNV0gTVVTVCBiZSBmb2xsb3dlZCB0byBhdm9pZCBh dHRhY2tzIG9uIChEKVRMUy4gUkZDNzUyNSBzYXlzIFRMUyAxLjMgcmVzb2x2ZXMgdGhlIHZ1bG5l cmFiaWxpdGllcyBmb3VuZCBpbiBwcmV2aW91cyBUTFMgdmVyc2lvbnMuDQoNCj4tIFNlY3Rpb24g My40OiBJdCBtaWdodCBiZSB3b3J0aCBtZW50aW9uaW5nIHRoYXQgdXNlIG9mIChEKVRMUyBmb3Ig dGhlDQo+IGNsaWVudC10by1zZXJ2ZXIgdHJhbnNwb3J0IG1pdGlnYXRlcyB0aGUgbmVlZCBmb3Ig U2VuZCBhbmQgRGF0YQ0KPiBhdXRoZW50aWNhdGlvbi4NCg0KaHR0cHM6Ly90b29scy5pZXRmLm9y Zy9odG1sL2RyYWZ0LWlldGYtdHJhbS10dXJuYmlzLTI3I3NlY3Rpb24tMjEuMS40IGRpc2N1c3Nl cyB0aGlzIGlzc3VlIGluIGRldGFpbC4gDQoNCj4gLSBTZWN0aW9uIDMuNDogV2hhdCBkb2VzIOKA nHByb3BlciBzZWN1cml0eeKAnSBtZWFuPyANCg0KVGhhbmtzLCByZXBsYWNlZCAicHJvcGVyIHNl Y3VyaXR5IiB3aXRoICJlbmQtdG8tZW5kIHNlY3VyaXR5Ii4NCg0KPi0gRmlndXJlIDQ6IEFkZGlu ZyBhbm90aGVyDQo+IG1lc3NhZ2UgZXhjaGFuZ2Ugd2hlcmVpbiBhIGNoYW5uZWwgbWVzc2FnZSBp cyBzZW50IHdpdGhvdXQgYSBwcmlvcg0KPiBDaGFubmVsQmluZCByZXF1ZXN0IHdvdWxkIGJlIHVz ZWZ1bCB0byBoaWdobGlnaHQgdGhpcyBkZXBlbmRlbmN5IGFuZA0KPiBleHBlY3RlZCBiZWhhdmlv ciBmcm9tIGNsaWVudHMgYW5kIHNlcnZlcnMuIA0KDQpodHRwczovL3Rvb2xzLmlldGYub3JnL2h0 bWwvZHJhZnQtaWV0Zi10cmFtLXR1cm5iaXMtMjcjc2VjdGlvbi0xMi42IGV4cGxhaW5zIHRoYXQg SWYgdGhlIENoYW5uZWxEYXRhIG1lc3NhZ2UgaXMgcmVjZWl2ZWQgb24gYSBjaGFubmVsIHRoYXQg aXMgbm90IGJvdW5kIHRvIGFueSBwZWVyLCB0aGVuIHRoZSBtZXNzYWdlIGlzIHNpbGVudGx5IGRp c2NhcmRlZC4NCg0KPiAtIFNlY3Rpb24gMy42OiBBbm90aGVyIGJlbmVmaXQgb2YNCj4gdGhpcyB1 c2VyIHNwYWNlIGRlc2lnbiBkZWNpc2lvbiBpcyB1c2Ugb2YgKEQpVExTIGxpbmtzLiAtDQoNCkdv b2QgcG9pbnQsIHVwZGF0ZWQgbGluZSB0byBzYXk6DQpmb3IgZXhhbXBsZSwgdG8gYWxsb3cgYSBU VVJOIHNlcnZlciB0byBiZSBpbnRlZ3JhdGVkIGludG8gYSBwZWVyLXRvLXBlZXIgYXBwbGljYXRp b24gc28gdGhhdCBvbmUgcGVlciBjYW4gb2ZmZXIgTkFUIHRyYXZlcnNhbCBzZXJ2aWNlcyB0byBh bm90aGVyIHBlZXIgYW5kIHRvIHVzZSAoRClUTFMgdG8gc2VjdXJlIHRoZSBUVVJOIGNvbm5lY3Rp b24uDQoNCiBTZWN0aW9uIDU6IFdoZXJlIGRpZA0KPiB0aGUgNDAgc2Vjb25kIHJlcXVlc3QgYnVm ZmVyIHRpbWVvdXQgY29tZSBmcm9tPyANCg0KSXQgaXMgY29taW5nIGZyb20gdGhlIFNUVU4gc3Bl Y2lmaWNhdGlvbiAoc2VlIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXRy YW0tc3R1bmJpcy0yMSNzZWN0aW9uLTYuMy4xKSANCg0KPiBBZGRpbmcgc29tZSBkZXRhaWxzDQo+ IG1pZ2h0IGhlbHAuIC0gU2VjdGlvbiA2OiDigJxzZWN1cmUgaGFzaOKAnSBpcyB1bmRlZmluZWQs IHRob3VnaCBwcmVzdW1hYmx5IHdoYXQNCj4gaXMgbWVhbnQgaXMgYSBjcnlwdG9ncmFwaGljIGhh c2ggd2l0aCBjb2xsaXNpb24gcmVzaXN0YW5jZS4gSXQgd291bGQgYmUgZ29vZCB0bw0KPiBjbGFy aWZ5IHRoaXMgcmVxdWlyZW1lbnQuIA0KDQpZZXMsIHJlcGxhY2VkIHdpdGggIiBjcnlwdG9ncmFw aGljIGhhc2giLiANCg0KPiAtIFNlY3Rpb24gNy40OiBXaGF0IGlzIHRoZSByZXRyeSBiZWhhdmlv ciBpZiBhbGxvY2F0aW9uDQo+IHJlcXVlc3RzIHRpbWVvdXQ/IA0KDQpUaGUgcmV0cnkgYmVoYXZp b3IgaXMgZGlzY3Vzc2VkIGFzIGZvbGxvd3M6DQoNCiAgIG8gIChSZXF1ZXN0IHRpbWVkIG91dCk6 IFRoZXJlIGlzIGVpdGhlciBhIHByb2JsZW0gd2l0aCB0aGUgc2VydmVyLCBvcg0KICAgICAgYSBw cm9ibGVtIHJlYWNoaW5nIHRoZSBzZXJ2ZXIgd2l0aCB0aGUgY2hvc2VuIHRyYW5zcG9ydC4gIFRo ZQ0KICAgICAgY2xpZW50IGNvbnNpZGVycyB0aGUgY3VycmVudCB0cmFuc2FjdGlvbiBhcyBoYXZp bmcgZmFpbGVkIGJ1dCBNQVkNCiAgICAgIGNob29zZSB0byByZXRyeSB0aGUgQWxsb2NhdGUgcmVx dWVzdCB1c2luZyBhIGRpZmZlcmVudCB0cmFuc3BvcnQNCiAgICAgIChlLmcuLCBUQ1AgaW5zdGVh ZCBvZiBVRFApLg0KDQoNCj4tIFNlY3Rpb24gMTIuNTogVGhlIFNUVU4gcmVxdWlyZW1lbnQgZm9y IDQtYnl0ZQ0KPiBhbGlnbm1lbnQgc2hvdWxkIGJlIGNpdGVkIHdoZW4gZGlzY3Vzc2luZyB0aGUg VENQIGFuZCBUTFMgcGFkZGluZw0KPiByZXF1aXJlbWVudC4gDQoNCkRvbmUuDQoNCj4gLSBTZWN0 aW9uIDE1OiBUeXBvIOKAnERPTuKAmVQgRlJBR01FTlTigJ0uDQoNCkZpeGVkLg0KDQpDaGVlcnMs DQotVGlydQ0KDQo+IA0KPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCj4gdHJhbSBtYWlsaW5nIGxpc3QNCj4gdHJhbUBpZXRmLm9yZw0KPiBodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RyYW0NCg== From nobody Mon Jul 8 07:43:00 2019 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 B81761201D6; Mon, 8 Jul 2019 07:42:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.5 X-Spam-Level: X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, 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 header.b=lIjIa9Cq; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=xQL5Q8s6 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 fsBLXH9aJhJx; Mon, 8 Jul 2019 07:42:55 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D98C12018A; Mon, 8 Jul 2019 07:42:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12242; q=dns/txt; s=iport; t=1562596975; x=1563806575; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=Ohpn1FmS6kocZ2tQ73rZl9WUp9Nuj97Xkx+5i9hgbRw=; b=lIjIa9CqojbmKWL67Q/79d/id87pg56/IFhqTBFoYd2x9WPkiG/5M7TK RuCoA1arPS6ZR+8TZ8VEtoxkFjEPDeEx6JXBifs8rgJRqcjffAnlaa6EV NDfdj9SMUSdpSE+l1MjDE26f4VI+k7+alTJwayBlyRM+nON0YMUTqhbQl U=; IronPort-PHdr: =?us-ascii?q?9a23=3AtCLlDxPh72Z19vd1IHMl6mtXPHoupqn0MwgJ65?= =?us-ascii?q?Eul7NJdOG58o//OFDEu6w/l0fHCIPc7f8My/HbtaztQyQh2d6AqzhDFf4ETB?= =?us-ascii?q?oZkYMTlg0kDtSCDBj1IfHjdTY7EOxJVURu+DewNk0GUMs=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AIAACeVSNd/5ldJa1lDgwBAQEBAQI?= =?us-ascii?q?BAQEBBwIBAQEBgVMFAQEBAQsBgUNQA2pVIAQLKIQcg0cDhFKJdYJbl0aBLhS?= =?us-ascii?q?BEANUCQEBAQwBASMKAgEBhEACF4IhIzQJDgEDAQEEAQECAQVtijcMhUoBAQE?= =?us-ascii?q?BAgESEREMAQE3AQ8CAQgRAwECAQICJgICAjAVCAgCBA4FIoMAAYFqAw4PAQI?= =?us-ascii?q?Mnl0CgTiIYHGBMoJ5AQEFgUZBgnIYghIDBoEMKAGLXheBQD+BEScfgkw+gmE?= =?us-ascii?q?CAQIBgSoBEQIBCBaDCjKCJowegiMvm2YJAoIXhlaNLhuCLIchc4MZiiWUcI9?= =?us-ascii?q?9AgQCBAUCDgEBBYFQOGdYEQhwFTsqAYJBgkEJGhSDOoUUhQQ7cgGBKIp4K4I?= =?us-ascii?q?lAQE?= X-IronPort-AV: E=Sophos;i="5.63,466,1557187200"; d="scan'208";a="589313764" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 08 Jul 2019 14:42:53 +0000 Received: from XCH-ALN-020.cisco.com (xch-aln-020.cisco.com [173.36.7.30]) by rcdn-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id x68Egr3P001151 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 8 Jul 2019 14:42:53 GMT Received: from xhs-rcd-002.cisco.com (173.37.227.247) by XCH-ALN-020.cisco.com (173.36.7.30) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 8 Jul 2019 09:42:52 -0500 Received: from xhs-aln-002.cisco.com (173.37.135.119) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 8 Jul 2019 09:42:52 -0500 Received: from NAM01-BN3-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Mon, 8 Jul 2019 09:42:51 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Ohpn1FmS6kocZ2tQ73rZl9WUp9Nuj97Xkx+5i9hgbRw=; b=xQL5Q8s6aeLSP8QZ7HKpbSWy1d77/i+Vu9QRCPNe2mjLgfWxSchutD70riIPqyhm8fELBluKGuYfjYmRKa6//nWg/wqBYDpQeM+ERSsGsE2HnETYsFHhk2vASwfr6Pxl2yt54F103fG4r400crY5ao1FrupVE/p6lIhbSqD7ZQI= Received: from SN6PR11MB2800.namprd11.prod.outlook.com (52.135.93.15) by SN6PR11MB3247.namprd11.prod.outlook.com (52.135.112.97) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2052.16; Mon, 8 Jul 2019 14:09:35 +0000 Received: from SN6PR11MB2800.namprd11.prod.outlook.com ([fe80::897:7870:e0c6:b2aa]) by SN6PR11MB2800.namprd11.prod.outlook.com ([fe80::897:7870:e0c6:b2aa%5]) with mapi id 15.20.2032.022; Mon, 8 Jul 2019 14:09:35 +0000 From: "Felipe Garrido (fegarrid)" To: Benjamin Kaduk CC: "iesg@ietf.org" , "draft-ietf-tram-stun-pmtud@ietf.org" , "tram-chairs@ietf.org" , "tasveren@rbbn.com" , "tram@ietf.org" Thread-Topic: Benjamin Kaduk's Discuss on draft-ietf-tram-stun-pmtud-10: (with DISCUSS and COMMENT) Thread-Index: AQHVCZroxitzvIrR+0WCBXUGWDqVCaZzxlWAgAG/uACAN8t6gIAB1OYAgBGw2AA= Date: Mon, 8 Jul 2019 14:09:34 +0000 Message-ID: References: <153791323613.5011.4854093713979605105.idtracker@ietfa.amsl.com> <6DB9C5F7-7150-431D-96D4-28594C918D31@cisco.com> <486F16F2-EE74-4ADE-89D8-4B69BEDB803E@cisco.com> <060C02FE-9636-46C9-A4AA-FCB65C35E8B5@cisco.com> <20190627040011.GE18345@kduck.mit.edu> In-Reply-To: <20190627040011.GE18345@kduck.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1a.0.190609 authentication-results: spf=none (sender IP is ) smtp.mailfrom=fegarrid@cisco.com; x-originating-ip: [2001:420:2280:1272:6501:8be9:d2b8:e11b] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: a6bc3fec-b604-4e01-cc9d-08d703ade7de x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:SN6PR11MB3247; x-ms-traffictypediagnostic: SN6PR11MB3247: x-ms-exchange-purlcount: 2 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 00922518D8 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(376002)(39860400002)(396003)(366004)(136003)(346002)(51444003)(189003)(199004)(66446008)(8936002)(2171002)(66946007)(33656002)(66556008)(64756008)(6246003)(76176011)(2616005)(66476007)(66574012)(54906003)(316002)(6506007)(58126008)(53546011)(76116006)(81166006)(81156014)(53936002)(73956011)(8676002)(91956017)(4326008)(5660300002)(25786009)(486006)(86362001)(446003)(476003)(11346002)(71200400001)(71190400001)(229853002)(46003)(36756003)(6116002)(478600001)(6486002)(186003)(6512007)(6306002)(102836004)(7736002)(68736007)(256004)(14454004)(2906002)(966005)(14444005)(6436002)(305945005)(99286004)(6916009); DIR:OUT; SFP:1101; SCL:1; SRVR:SN6PR11MB3247; H:SN6PR11MB2800.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: K8pHP8nz6NNn4HQ5UgUDlS32RzQbVLRaJO81BjGdcdP01ScR2ebAUaWfeBhnSCM0xLN4RmNJgl7PhNl8dvkSxJJW15H3JE+iaVxWkqqx6uOcLa0F/pp+Gfbsv57TgHh6mVBICZHEx845XXDW4/MgmmMCYdr5tqfmIBN9BtTWNf/g2eLOKjtLtpHNWxWlGHJTzZvmo+zWtMo2Z5Fv3EdNeIOWk5E8JMRxcl4v8FkIByeJoa+cBz0Q4d88f/XbztWrcNOrQxh7rec7+lwpx0AYhZtmR+VpPNvPiMUzM5UD3kPKeUezaGAzRQECdmDAouytZ6DMDc4GmF9XTJ3ZGftAvfqn6/ir/s6YimflePzQxe5Ev4NdvSiA7O4F4LQVNfjOPaoSH+Rq7bEPL/PqKT3NupHh6rlVOC5U7WxISSgmsF4= Content-Type: text/plain; charset="utf-8" Content-ID: <5EF78D3D0869EF408E5D1F17ED41AAD3@namprd11.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: a6bc3fec-b604-4e01-cc9d-08d703ade7de X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Jul 2019 14:09:34.9468 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: fegarrid@cisco.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN6PR11MB3247 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.30, xch-aln-020.cisco.com X-Outbound-Node: rcdn-core-2.cisco.com Archived-At: Subject: Re: [tram] Benjamin Kaduk's Discuss on draft-ietf-tram-stun-pmtud-10: (with DISCUSS and COMMENT) X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.29 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 Jul 2019 14:42:59 -0000 SGkgQmVuLCANCg0KVG90YWxseSBhZ3JlZSBub3cgdGhhdCBJJ3ZlIHJlLXJlYWQgaXQuIA0KDQpI ZXJlJ3MgdGhlIG5ldyBwcm9wb3NlZCB3b3JkaW5nLiANCg0KIlRoZSBwYWNrZXRzIHRoYXQgYXJl IHRvIGJlIGFzc29jaWF0ZWQgdG8gYW4gaWRlbnRpZmllciBhcmUgc2VsZWN0ZWQgYWNjb3JkaW5n IHRvIFNlY3Rpb24gNS4yIG9mIFtSRkM0ODIxXS4iDQoNCkhlcmUncyB0aGUgZnVsbCB0ZXh0LiAN Cg0KQSBzZXJ2ZXIgc3VwcG9ydGluZyB0aGlzIHNwZWNpZmljYXRpb24gd2lsbCBrZWVwIHRoZSBp ZGVudGlmaWVycyBvZg0KYWxsIHBhY2tldHMgcmVjZWl2ZWQgaW4gYSBjaHJvbm9sb2dpY2FsbHkg b3JkZXJlZCBsaXN0LiAgVGhlDQpwYWNrZXRzIHRoYXQgYXJlIHRvIGJlIGFzc29jaWF0ZWQgdG8g YW4gaWRlbnRpZmllciBhcmUgc2VsZWN0ZWQgDQphY2NvcmRpbmcgdG8gU2VjdGlvbiA1LjIgb2Yg W1JGQzQ4MjFdLiINCg0KVGhhbmtzLA0KLUZlbGlwZQ0KDQrvu79PbiA2LzI3LzE5LCAxMjowMCBB TSwgIkJlbmphbWluIEthZHVrIiA8a2FkdWtAbWl0LmVkdT4gd3JvdGU6DQoNCiAgICBIaSBGZWxp cGUsDQogICAgDQogICAgVGhhbmtzIGZvciBmb2xsb3dpbmcgdXAgLS0gaXQgbG9va3MgbGlrZSBJ IGZpbGVkIGF3YXkgdGhlIG9yaWdpbmFsIG1haWwNCiAgICB3aXRob3V0IHJlc3BvbmRpbmcgdG8g aXQsIHNvbWVob3coISkNCiAgICBUaGUgRGlzY3VzcyBwb2ludCdzIHJlc29sdXRpb24gaXMgZmlu ZTsgSSBqdXN0IGhhdmUgb25lIG1vcmUgcXVlc3Rpb24NCiAgICAoaW5saW5lKS4NCiAgICANCiAg ICAtQmVuDQogICAgDQogICAgT24gV2VkLCBKdW4gMjYsIDIwMTkgYXQgMDQ6MDE6NThBTSArMDAw MCwgRmVsaXBlIEdhcnJpZG8gKGZlZ2FycmlkKSB3cm90ZToNCiAgICA+IEhpIEJlbmphbWluLA0K ICAgID4gDQogICAgPiBKdXN0IGZvbGxvd2luZyB1cCBvbiBteSBwcmV2aW91cyBlbWFpbC4gTGV0 IG1lIGtub3cgaWYgdGhlIGJlbG93IHJlc3BvbnNlIHNhdGlzZmllcyB5b3VyIGNvbW1lbnRzLg0K ICAgID4gDQogICAgPiBUaGFua3MsDQogICAgPiAtRmVsaXBlDQogICAgPiANCiAgICA+IEZyb206 ICJGZWxpcGUgR2FycmlkbyAoZmVnYXJyaWQpIiA8ZmVnYXJyaWRAY2lzY28uY29tPg0KICAgID4g RGF0ZTogVHVlc2RheSwgTWF5IDIxLCAyMDE5IGF0IDExOjU5IEFNDQogICAgPiBUbzogImthZHVr QG1pdC5lZHUiIDxrYWR1a0BtaXQuZWR1PiwgImllc2dAaWV0Zi5vcmciIDxpZXNnQGlldGYub3Jn Pg0KICAgID4gQ2M6ICJkcmFmdC1pZXRmLXRyYW0tc3R1bi1wbXR1ZEBpZXRmLm9yZyIgPGRyYWZ0 LWlldGYtdHJhbS1zdHVuLXBtdHVkQGlldGYub3JnPiwgInRyYW0tY2hhaXJzQGlldGYub3JnIiA8 dHJhbS1jaGFpcnNAaWV0Zi5vcmc+LCAidGFzdmVyZW5AcmJibi5jb20iIDx0YXN2ZXJlbkByYmJu LmNvbT4sICJ0cmFtQGlldGYub3JnIiA8dHJhbUBpZXRmLm9yZz4NCiAgICA+IFN1YmplY3Q6IEJl bmphbWluIEthZHVrJ3MgRGlzY3VzcyBvbiBkcmFmdC1pZXRmLXRyYW0tc3R1bi1wbXR1ZC0xMDog KHdpdGggRElTQ1VTUyBhbmQgQ09NTUVOVCkNCiAgICA+IA0KICAgID4gDQogICAgPiBIaSBCZW5q YW1pbiwNCiAgICA+IA0KICAgID4gQXBvbG9naWVzIGZvciB0aGUgZGVsYXkgaW4gcmVzcG9uZGlu ZywgdGhlIGN1cnJlbnQgYXV0aG9ycyBhcmUgaGF2aW5nIHNjaGVkdWxpbmcgY29uZmxpY3RzIGFu ZCBoYXZlIGFkZGVkIG1lIHRvIGFkZHJlc3MgdGhlIGN1cnJlbnQgY29uY2VybnMuIFBsZWFzZSBz ZWUgbXkgcmVzcG9uc2VzIGlubGluZS4NCiAgICA+IA0KICAgID4gdGhhbmtzDQogICAgPiAtRmVs aXBlDQogICAgPiANCiAgICA+IA0KICAgID4gQmVuamFtaW4gS2FkdWsgaGFzIGVudGVyZWQgdGhl IGZvbGxvd2luZyBiYWxsb3QgcG9zaXRpb24gZm9yDQogICAgPiBkcmFmdC1pZXRmLXRyYW0tc3R1 bi1wbXR1ZC0xMDogRGlzY3Vzcw0KICAgID4gDQogICAgPiBXaGVuIHJlc3BvbmRpbmcsIHBsZWFz ZSBrZWVwIHRoZSBzdWJqZWN0IGxpbmUgaW50YWN0IGFuZCByZXBseSB0byBhbGwNCiAgICA+IGVt YWlsIGFkZHJlc3NlcyBpbmNsdWRlZCBpbiB0aGUgVG8gYW5kIENDIGxpbmVzLiAoRmVlbCBmcmVl IHRvIGN1dCB0aGlzDQogICAgPiBpbnRyb2R1Y3RvcnkgcGFyYWdyYXBoLCBob3dldmVyLikNCiAg ICA+IA0KICAgID4gDQogICAgPiBQbGVhc2UgcmVmZXIgdG8gaHR0cHM6Ly93d3cuaWV0Zi5vcmcv aWVzZy9zdGF0ZW1lbnQvZGlzY3Vzcy1jcml0ZXJpYS5odG1sDQogICAgPiBmb3IgbW9yZSBpbmZv cm1hdGlvbiBhYm91dCBJRVNHIERJU0NVU1MgYW5kIENPTU1FTlQgcG9zaXRpb25zLg0KICAgID4g DQogICAgPiANCiAgICA+IFRoZSBkb2N1bWVudCwgYWxvbmcgd2l0aCBvdGhlciBiYWxsb3QgcG9z aXRpb25zLCBjYW4gYmUgZm91bmQgaGVyZToNCiAgICA+IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0 Zi5vcmcvZG9jL2RyYWZ0LWlldGYtdHJhbS1zdHVuLXBtdHVkLw0KICAgID4gDQogICAgPiANCiAg ICA+IA0KICAgID4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KICAgID4gRElTQ1VTUzoNCiAgICA+IC0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0NCiAgICA+IA0KICAgID4gSSB3YXMgZ29pbmcgdG8gcmVwb3J0IHRoZSBzYW1lIHRoaW5n IGFzIEFkYW0sIGJ1dCB3aWxsIGp1c3Qgc2F5IHRoYXQgSSBzdXBwb3J0IGhpcyBEaXNjdXNzLg0K ICAgID4gW0ZHXTogSeKAmWxsIGJlIGFkZHJlc3NpbmcgdGhpcyBEaXNjdXNzIGluIEFkYW3igJlz IGZlZWRiYWNrLg0KICAgID4gDQogICAgPiBJIGFsc28gaGF2ZSBvbmUgb3RoZXIgKGFsc28gbWlu b3IgYW5kIGVhc3kgdG8gcmVzb2x2ZSkgRGlzY3VzcyBwb2ludDogIFNlY3Rpb24gNC4yLjYgbmVl ZHMNCiAgICA+IHRvIHN0YXRlIHdoYXQgdGhlIExlbmd0aCBmaWVsZCBpcyBtZWFzdXJpbmcgdGhl IGxlbmd0aCBvZi4NCiAgICA+IFtGR106IEFncmVlIHRoYXQgdGhpcyBpcyByZXF1aXJlZC4gQWRk aW5nIHRoZSBmb2xsb3dpbmcgdGV4dCB0byBTZWN0aW9uIDQuMi42Lg0KICAgID4g4oCcVGhlIExl bmd0aCBmaWVsZCBzcGVjaWZpZXMgdGhlIGxlbmd0aCBpbiBieXRlcyBvZiB0aGUgc2VxdWVuY2Ug bnVtYmVyIGFuZCBhcHBsaWNhdGlvbiBkYXRhIGZpZWxkcy7igJ0NCiAgICA+DQogICAgPiAtLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tDQogICAgPiBDT01NRU5UOg0KICAgID4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KICAgID4gDQog ICAgPiBJIHVuZGVyc3RhbmQgdGhhdCB0aGlzIGRvY3VtZW50IGluaGVyZW50bHkgaGFzIHRvIGJl IGluY29tcGxldGUgYW5kICJ2YWd1ZSIsDQogICAgPiBzaW5jZSB0aGUgcHJvY2VkdXJlIHNwZWNp ZmllZCB3aXRoaW4gaXMgb25seSBtZWFuaW5nZnVsIGluIHRoZSBjb250ZXh0IG9mIGENCiAgICA+ IFNUVU4gdXNhZ2Ugb3Igb3RoZXIgcHJvdG9jb2wuICBCdXQgaW4gZ2VuZXJhbCBpdCBzZWVtcyBs aWtlIHRoZXJlIGNvdWxkIGJlDQogICAgPiBncmVhdGVyIGNsYXJpdHkgZXZlbiB3aXRoaW4gdGhl IGNvbnN0cmFpbnRzIHRoYXQgd2UgbXVzdCB3b3JrIHVuZGVyLiAgTXkNCiAgICA+IHBvaW50cyBh cmUgcHJvYmFibHkgbGVzcyBpbnRlcmVzdGluZyB0aGFuIHRoZSBvbmVzIEFkYW0gcmFpc2VkIGFs cmVhZHksIHRob3VnaC4NCiAgICA+IFRoZSBvbmx5IGdlbmVyYWwgb2JzZXJ2YXRpb24gaW4gdGhp cyBzcGFjZSB0aGF0IEkgY2FuIG9mZmVyIGlzIHRoYXQgc29tZSBwYXJ0cyBvZg0KICAgID4gdGhl IHRleHQgcmVhZCBhcyBpZiBvbmx5IHRoZSBQcm9iZSBwYWNrZXRzIGFyZSBnb2luZyB0byBiZSBt b25pdG9yZWQgZm9yIHRoZQ0KICAgID4gcmVwb3J0IChidXQgdGhpcyBpcyBjbGVhcmx5IG5vdCB0 aGUgY2FzZSBnaXZlbiB0aGUgZG9jdW1lbnQgYXMgYSB3aG9sZSkuDQogICAgPiANCiAgICA+IFNl Y3Rpb24gNC4yDQogICAgPiANCiAgICA+ICAgVGhlIENvbXBsZXRlIFByb2JpbmcgbWVjaGFuaXNt IGlzIGltcGxlbWVudGVkIGJ5IHNlbmRpbmcgb25lIG9yIG1vcmUNCiAgICA+ICAgUHJvYmUgSW5k aWNhdGlvbnMgd2l0aCBhIFBBRERJTkcgYXR0cmlidXRlIG92ZXIgVURQIHdpdGggdGhlIERGIGJp dA0KICAgID4gICBzZXQgaW4gdGhlIElQIGhlYWRlciBmb2xsb3dlZCBieSBhIFJlcG9ydCBSZXF1 ZXN0IHRvIHRoZSBzYW1lIHNlcnZlci4NCiAgICA+ICAgQSByb3V0ZXIgb24gdGhlIHBhdGggdG8g dGhlIHNlcnZlciBjYW4gcmVqZWN0IHRoaXMgSW5kaWNhdGlvbiB3aXRoIGFuDQogICAgPiAgIElD TVAgbWVzc2FnZSBvciBkcm9wIGl0Lg0KICAgID4gDQogICAgPiBuaXQ6IEkgZG9uJ3QgdGhpbmsg InRoaXMiIGlzIHRoZSByaWdodCB3b3JkOyBwZXJoYXBzICJlYWNoIiB3b3VsZCBiZQ0KICAgID4g YmV0dGVyLg0KICAgID4gDQogICAgPiANCiAgICA+IA0KICAgID4gW0ZHXTogQWdyZWUsIHVwZGF0 ZXMgd2lsbCBiZSBtYWRlLg0KICAgID4gDQogICAgPiBTZWN0aW9uIDQuMi4zDQogICAgPiANCiAg ICA+ICAgQSBzZXJ2ZXIgc3VwcG9ydGluZyB0aGlzIHNwZWNpZmljYXRpb24gd2lsbCBrZWVwIHRo ZSBpZGVudGlmaWVycyBvZg0KICAgID4gICBhbGwgcGFja2V0cyByZWNlaXZlZCBpbiBhIGNocm9u b2xvZ2ljYWxseSBvcmRlcmVkIGxpc3QuICBUaGUgcGFja2V0cw0KICAgID4gICB0aGF0IGFyZSB0 byBiZSBhc3NvY2lhdGVkIHRvIGEgbGlzdCBhcmUgc2VsZWN0ZWQgYWNjb3JkaW5nIHRvDQogICAg PiAgIFNlY3Rpb24gNS4yIG9mIFtSRkM0ODIxXS4gIFsuLi5dDQogICAgPiANCiAgICA+IDQ4MjEg ZG9lc24ndCB0YWxrIGFib3V0ICJsaXN0InMgYXQgYWxsLCBhbmQgaW4gZmFjdCB0aGUgaW5kaWNh dGVkIHNlY3Rpb24NCiAgICA+IHNlZW1zIHRvIGJlIHRhbGtpbmcgbW9yZSBhYm91dCB3aGVyZSB0 byBzdG9yZSBhIFBNVFUgdmFsdWUgYWZ0ZXIgaXQgaGFzDQogICAgPiBiZWVuIGRldGVybWluZWQs IHJhdGhlciB0aGFuIHdoYXQgcGFja2V0cyB0byBiZSBjb25zaWRlcmluZyBmb3IgYSByZXBvcnQu DQogICAgPiBTbyBJJ20gcHJldHR5IGNvbmZ1c2VkIGFib3V0IHdoYXQgdGhpcyBzZW50ZW5jZSBp cyB0cnlpbmcgdG8gc2F5Lg0KICAgID4gDQogICAgPiANCiAgICA+IA0KICAgID4gW0ZHXTogQWdy ZWUuIFVwZGF0ZWQgd29yZGluZyB0byBtYWtlIHRoZSBzdGF0ZW1lbnQgZWFzaWVyIHRvIHJlYWQu DQogICAgPiDigJxUaGUgc2VsZWN0aW9uIHByb2Nlc3Mgc3BlY2lmaWVkIGluIFNlY3Rpb24gNS4y IG9mIFtSRkM0ODIxXSBpcyB0byBiZSB1c2VkIHRvIGRldGVybWluZSB3aGV0aGVyIGEgcGFja2V0 IGlzIGFkZGVkIHdpdGggYSBsaXN0LuKAnQ0KICAgIA0KICAgIEkgc3RpbGwgZG9uJ3QgdW5kZXJz dGFuZCB3aGF0ICJ0aGUgc2VsZWN0aW9uIHByb2Nlc3Mgc3BlY2lmaWVkIGluIFNlY3Rpb24NCiAg ICA1LjIgb2YgW1JGQzQ4MjFdIiBpcyAtLSBjYW4geW91IHBvaW50IG1lIHRvIHRoZSB0ZXh0IGZy b20gUkZDIDQ4MjENCiAgICBkZXNjcmliaW5nIHRoZSBwcm9jZXNzIGluIHF1ZXN0aW9uPw0KICAg IA0KICAgID4gU2VjdGlvbiA0LjIuNA0KICAgID4gDQogICAgPiBuaXQ6IEkgdGhpbmsgdGhhdCBh bGwgaW5zdGFuY2VzIG9mICJ0aGUgUHJvYmUgSW5kaWNhdGlvbiIgc2hvdWxkIGJlDQogICAgPiBy ZXBsYWNlZCB3aXRoICJhIFByb2JlIEluZGljYXRpb24iLCBpbiB0aGlzIHNlY3Rpb24uDQogICAg PiANCiAgICA+IA0KICAgID4gDQogICAgPiBbRkddOiBBZ3JlZSwgdXBkYXRlcyB3aWxsIGJlIG1h ZGUuDQogICAgPiANCiAgICA+IFNlY3Rpb24gNC4yLjUNCiAgICA+IA0KICAgID4gICBXaGVuIHVz aW5nIGEgY2hlY2tzdW0gYXMgYSBwYWNrZXQgaWRlbnRpZmllciwgdGhlIGNsaWVudCBjYWxjdWxh dGVzDQogICAgPiAgIHRoZSBjaGVja3N1bSBmb3IgZWFjaCBwYWNrZXQgc2VudCBvdmVyIFVEUCB0 aGF0IGlzIG5vdCBhIFNUVU4gUHJvYmUNCiAgICA+ICAgSW5kaWNhdGlvbiBvciBSZXF1ZXN0IGFu ZCBrZWVwcyB0aGlzIGNoZWNrc3VtIGluIGEgY2hyb25vbG9naWNhbGx5DQogICAgPiAgIG9yZGVy ZWQgbGlzdC4gIFRoZSBjbGllbnQgYWxzbyBrZWVwcyB0aGUgY2hlY2tzdW0gb2YgdGhlIFNUVU4g UHJvYmUNCiAgICA+ICAgSW5kaWNhdGlvbiBvciBSZXF1ZXN0IHNlbnQgaW4gdGhhdCBzYW1lIGNo cm9ub2xvZ2ljYWxseSBvcmRlcmVkIGxpc3QuDQogICAgPiAgIFRoZSBhbGdvcml0aG0gdXNlZCB0 byBjYWxjdWxhdGUgdGhlIGNoZWNrc3VtIGlzIHNpbWlsYXIgdG8gdGhlDQogICAgPiAgIGFsZ29y aXRobSB1c2VkIGZvciB0aGUgRklOR0VSUFJJTlQgYXR0cmlidXRlIChpLmUuLCB0aGUgQ1JDLTMy IG9mIHRoZQ0KICAgID4gICBwYXlsb2FkIFhPUidlZCB3aXRoIHRoZSAzMi1iaXQgdmFsdWUgMHg1 MzU0NTU0ZSBbSVRVLlY0Mi4yMDAyXSkuDQogICAgPiANCiAgICA+IChlZGl0b3JpYWwpIEl0J3Mg cHJldHR5IGNvbmZ1c2luZyB0byBzdGFydCBvdXQgd2l0aCB0aGUgc3BsaXQgYmV0d2VlbiBTVFVO DQogICAgPiBhbmQgbm9uLVNUVU4gbWVzc2FnZXMsIG9ubHkgbGF0ZXIgdG8gY2xhcmlmeSB0aGF0 IHRoaXMgaXMgYmVjYXVzZSB0aGUNCiAgICA+IEZJTkdFUlBSSU5UIGlzIHVzZWQgZm9yIFNUVU4g bWVzc2FnZXMuICBTbyBtYXliZToNCiAgICA+IA0KICAgID4gIFdoZW4gdXNpbmcgYSBjaGVja3N1 bSBhcyBhIHBhY2tldCBpZGVudGlmaWVyLCB0aGUgY2xpZW50IGtlZXBzIGENCiAgICA+ICBjaHJv bm9sb2dpY2FsbHkgb3JkZXJlZCBsaXN0IG9mIHRoZSBwYWNrZXRzIGl0IHRyYW5zbWl0cywgYWxv bmcgd2l0aCBhbg0KICAgID4gIGFzc29jaWF0ZWQgY2hlY2tzdW0gdmFsdWUuICBGb3IgU1RVTiBQ cm9iZSBJbmRpY2F0aW9uIG9yIFJlcXVlc3QgcGFja2V0cywNCiAgICA+ICB0aGUgYXNzb2NpYXRl ZCBjaGVja3N1bSB2YWx1ZSBpcyB0aGUgRklOR0VSUFJJTlQgdmFsdWUgZnJvbSB0aGUgcGFja2V0 OyBmb3INCiAgICA+ICBvdGhlciBwYWNrZXRzIGEgY2hlY2tzdW0gdmFsdWUgaXMgY29tcHV0ZWQg dXNpbmcgYSBzaW1pbGFyIGFsZ29yaXRobSB0byB0aGUNCiAgICA+ICBGSU5HRVJQUklOVCBjYWxj dWxhdGlvbi4NCiAgICA+IA0KICAgID4gDQogICAgPiANCiAgICA+IFtGR106IEFncmVlIHdpdGgg Y2hhbmdpbmcgb2YgdGhlIGxhbmd1YWdlLiBJdCBkb2VzbuKAmXQgY2hhbmdlIHRoZSBjb250ZW50 IGFuZCBlYXNpZXIgdG8gcmVhZC4NCiAgICA+IA0KICAgID4gU2VjdGlvbiA0LjIuNg0KICAgID4g DQogICAgPiAgIFdoZW4gdXNpbmcgc2VxdWVuY2UgbnVtYmVycywgYSBzbWFsbCBoZWFkZXIgc2lt aWxhciB0byB0aGUgVFVSTg0KICAgID4gICBDaGFubmVsRGF0YSBoZWFkZXIgWy4uLl0NCiAgICA+ IA0KICAgID4gUHJvYmFibHkgd2FudCBhbiBpbmZvcm1hdGl2ZSByZWZlcmVuY2UgZm9yIHRoaXMg aGVhZGVyLg0KICAgID4gDQogICAgPiANCiAgICA+IA0KICAgID4gW0ZHXTogQWdyZWUsIHVwZGF0 ZXMgd2lsbCBiZSBtYWRlIHRvIHJlZmVyZW5jZS4NCiAgICA+IFNlY3Rpb24gNi4yDQogICAgPiAN CiAgICA+IDYuMi4gIFBNVFVELVNVUFBPUlRFRA0KICAgID4gDQogICAgPiAgIFRoZSBQTVRVRC1T VVBQT1JURUQgYXR0cmlidXRlIGluZGljYXRlcyB0aGF0IGl0cyBzZW5kZXIgc3VwcG9ydHMgdGhp cw0KICAgID4gICBzcGVjaWZpY2F0aW9uLiAgVGhpcyBhdHRyaWJ1dGUgaGFzIG5vIHZhbHVlIHBh cnQgYW5kIHRodXMgdGhlDQogICAgPiAgIGF0dHJpYnV0ZSBsZW5ndGggZmllbGQgaXMgMC4NCiAg ICA+IA0KICAgID4gInRoaXMgc3BlY2lmaWNhdGlvbiIgaXMgbm90IHN1ZmZpY2llbnRseSBkZXRh aWxlZCB0byBpbnRlcm9wZXJhdGUsIHNvIEkNCiAgICA+IHRoaW5rIHRoaXMgbmVlZHMgdG8gYmUg cXVhbGlmaWVkIGFzIG1vcmUgbGlrZSAic3VwcG9ydHMgdGhpcyBtZWNoYW5pc20sIGFzDQogICAg PiBpbmNvcnBvcmF0ZWQgaW50byB0aGUgU1RVTiB1c2FnZSBvciBwcm90b2NvbCBiZWluZyB1c2Vk Ii4NCiAgICA+IA0KICAgID4gDQogICAgPiANCiAgICA+IFtGR106IEFncmVlLCB1cGRhdGVzIHdp bGwgYmUgbWFkZS4NCiAgICA+IA0KICAgID4gU2VjdGlvbiA3DQogICAgPiANCiAgICA+IFRoZSBj b250ZW50cyBvZiB0aGUgUEFERElORyBkbyBub3Qgc2VlbSB0byBiZSBzcGVjaWZpZWQgYW55d2hl cmUsIHNvIGl0DQogICAgPiBjb3VsZCBpbiB0aGVvcnkgYmUgdXNlZCBhcyBhIHNpZGUgY2hhbm5l bCB0byBjb252ZXkgb3RoZXIgaW5mb3JtYXRpb24sDQogICAgPiB3aGljaCBoYXMgc29tZSBwb3Rl bnRpYWwgcHJpdmFjeSBjb25zaWRlcmF0aW9ucy4gIE5vd2FkYXlzIHdlIHRlbmQgdG8gYXNrDQog ICAgPiBmb3IgdGhlIHZhbHVlIG9mIHRoZSBwYWRkaW5nIGJ5dGVzIHRvIGJlIGRldGVybWluaXN0 aWMgKGJ1dCB2YWxpZGF0aW9uDQogICAgPiByZW1haW5zIG9wdGlvbmFsKTsgSSBmb3JnZXQgaWYg dGhlcmUgYXJlIFNUVU4tc3BlY2lmaWMgY29uc2lkZXJhdGlvbnMgdGhhdA0KICAgID4gd291bGQg ZGlzY291cmFnZSBqdXN0IHNldHRpbmcgdGhlbSBhbGwgdG8gemVyby4NCiAgICA+IA0KICAgID4g DQogICAgPiANCiAgICA+IFtGR106IEFncmVlLiAgQWRkaW5nIGxhbmd1YWdlIHRvIHN0YXRlIGNv bnRlbnRzIG9mIFBBRERJTkcuDQogICAgPiDigJxUaGUgcGFkZGluZyBiaXRzIE1VU1QgYmUgc2V0 IHRvIHplcm8gb24gc2VuZGluZyBhbmQgTVVTVCBiZSBpZ25vcmVkIGJ5IHRoZSByZWNlaXZlci7i gJ0NCiAgICA+IA0KICAgID4gDQogICAgPiANCiAgICA+IA0KICAgID4gDQogICAgDQoNCg== From nobody Mon Jul 8 14:35:39 2019 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 0BF06120342; Mon, 8 Jul 2019 14:35:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.5 X-Spam-Level: X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, 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 header.b=G7Nkwjc8; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=BMPSzzkY 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 UErTlEwxhrzM; Mon, 8 Jul 2019 14:35:21 -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 D8323120347; Mon, 8 Jul 2019 14:35:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4512; q=dns/txt; s=iport; t=1562621721; x=1563831321; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=11KZ1lcwjVclig+hKA1t7PW7Ign5udjtF8kF0qb5HCY=; b=G7Nkwjc8HT5He6RSb4jXIdpmN71o4DDQ/PZxF4KnN4yVyzcquvHGPGOG XaP80ks9aDOeQC/fkZOuDzE4ScBdP+7P1dBgMJZ9aZwmNtytJ/eha4nPS R6Gp40JnBdal2LT9LfPrPMiC1Hrd7WQ3afZ01f4b08utFlis7BHUNpuH0 4=; IronPort-PHdr: =?us-ascii?q?9a23=3AwS5y8BSeen0x7+f0o7GbRMSoF9psv++ubAcI9p?= =?us-ascii?q?oqja5Pea2//pPkeVbS/uhpkESXBdfA8/wRje3QvuigQmEG7Zub+FE6OJ1XH1?= =?us-ascii?q?5g640NmhA4RsuMCEn1NvnvOiEkDcJJV1JN9HCgOk8TE8H7NBXf?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AXAACytiNd/5tdJa1fBhsBAQEBAwE?= =?us-ascii?q?BAQcDAQEBgVMGAQEBCwGBQ1ADalUgBAsohByDRwOEUol2gjYll0aBLhSBEAN?= =?us-ascii?q?UCQEBAQwBASMKAgEBhEACF4IhIzQJDgEDAQEEAQECAQVtijcMhUoBAQEBAgE?= =?us-ascii?q?SEREMAQE3AQsEAgEIEQQBAQMCJgICAjAVBQMIAgQBDQUigwABgWoDDg8BAgy?= =?us-ascii?q?fOAKBOIhgcYEygnkBAQWBNgKDRRiCEgMGgQwoAYteF4FAP4ERJwwTgkw+gmE?= =?us-ascii?q?BAQIBgSImCA4HECOCUDKCJot6gnabZgkCgheGVo0uFAeCLIchjjGDJYoLh0C?= =?us-ascii?q?PfQIEAgQFAg4BAQWBUDiBWHAVZQGCQYJBCRoUgzqFFIU/cgEBAYEmjUQBAQ?= X-IronPort-AV: E=Sophos;i="5.63,468,1557187200"; d="scan'208";a="579194422" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 08 Jul 2019 21:35:18 +0000 Received: from XCH-ALN-016.cisco.com (xch-aln-016.cisco.com [173.36.7.26]) by rcdn-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id x68LZIne020718 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 8 Jul 2019 21:35:19 GMT Received: from xhs-rtp-002.cisco.com (64.101.210.229) by XCH-ALN-016.cisco.com (173.36.7.26) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 8 Jul 2019 16:35:18 -0500 Received: from xhs-aln-001.cisco.com (173.37.135.118) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 8 Jul 2019 17:35:16 -0400 Received: from NAM01-SN1-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-001.cisco.com (173.37.135.118) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Mon, 8 Jul 2019 16:35:16 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=11KZ1lcwjVclig+hKA1t7PW7Ign5udjtF8kF0qb5HCY=; b=BMPSzzkYu2sFJMHmJU7x2DzCzOEuPp23ZnDUje5xUP2KJaeVO4UepqluZplOKQExCTWfOaue5eA8G+6URZz9vCIrEyP+G+JyQ70EwuziKL1/fm9bpcpL2VuZfa/wV9tkWShV58kYM5glYTzt4N2HF9yBne6XzcvWEFGm1z9QWlA= Received: from MN2PR11MB4144.namprd11.prod.outlook.com (20.179.150.210) by MN2PR11MB3903.namprd11.prod.outlook.com (10.255.180.78) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2052.19; Mon, 8 Jul 2019 21:19:27 +0000 Received: from MN2PR11MB4144.namprd11.prod.outlook.com ([fe80::b179:dc88:3c29:4474]) by MN2PR11MB4144.namprd11.prod.outlook.com ([fe80::b179:dc88:3c29:4474%6]) with mapi id 15.20.2052.020; Mon, 8 Jul 2019 21:19:27 +0000 From: "Eric Vyncke (evyncke)" To: "Konda, Tirumaleswar Reddy" , The IESG CC: "tram-chairs@ietf.org" , "draft-ietf-tram-turnbis@ietf.org" , "tram@ietf.org" , "brandon.williams@akamai.com" Thread-Topic: =?utf-8?B?W3RyYW1dIMOJcmljIFZ5bmNrZSdzIE5vIE9iamVjdGlvbiBvbiBkcmFmdC1p?= =?utf-8?Q?etf-tram-turnbis-27:_(with_COMMENT)?= Thread-Index: AQHVNJyeoaZBM6SyTEC4IXgEbhm1HqbARDZggAEZuwA= Date: Mon, 8 Jul 2019 21:19:27 +0000 Message-ID: References: <156248752430.14312.15895119889558390147.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: fr-BE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1a.0.190609 authentication-results: spf=none (sender IP is ) smtp.mailfrom=evyncke@cisco.com; x-originating-ip: [2001:420:c0c0:1002::92] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: bb79f418-7042-4795-7896-08d703e9f569 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:MN2PR11MB3903; x-ms-traffictypediagnostic: MN2PR11MB3903: x-ms-exchange-purlcount: 4 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 00922518D8 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(376002)(396003)(346002)(366004)(136003)(39860400002)(189003)(199004)(51914003)(13464003)(53546011)(102836004)(6506007)(86362001)(4326008)(99286004)(486006)(14454004)(446003)(11346002)(2616005)(25786009)(476003)(66446008)(91956017)(76116006)(66476007)(73956011)(7736002)(224303003)(5660300002)(66556008)(64756008)(36756003)(186003)(76176011)(33656002)(68736007)(316002)(8936002)(46003)(2906002)(6512007)(53936002)(6436002)(6306002)(81166006)(81156014)(305945005)(66946007)(14444005)(66574012)(256004)(6116002)(966005)(478600001)(54906003)(71200400001)(6486002)(58126008)(110136005)(6246003)(71190400001)(229853002); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB3903; H:MN2PR11MB4144.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: 5uCB/F4wz+5rT4ZhG5jrPy38yWi2m2+3PgAiXbfptTArxnzGO44T9BMkqM6Cenla7LDSNHxdBkRq79pATFE1ZoxtCQb8Go1Qxd2PjB2DMGUOlmomAmHAvOpQaa8myuQCeiqlpVaAZQ+fAtyQGl6OrXM6vhDvtqfhod8C/Dmz3/drVBjc9wZoEJodTuC/3FKtvsGGyvxTzaM2ajcKyObh+8+kVX5SJ9QBHd+DPzi+LYGP1XBg2jZEOJK/FY4+dgR0Xz/RGZrzc552cu5V60Rdphs2GUyd8UGHKXWSc5n8puxbOXxtZYGg0foS1VnDmrnb1ruEFMCcExl2e+lcs6R3FvhoRJEkFZJGnh2NGorZi37DylKLzY1PkdlxxJq/IBHHnG7H0kNx723oWQVi8ih/LzS/vPAkvbNMz5ziXxCgcIY= Content-Type: text/plain; charset="utf-8" Content-ID: <0DD28ED8891C3C4D90157E43B2B39767@namprd11.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: bb79f418-7042-4795-7896-08d703e9f569 X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Jul 2019 21:19:27.4538 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: evyncke@cisco.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB3903 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.26, xch-aln-016.cisco.com X-Outbound-Node: rcdn-core-4.cisco.com Archived-At: Subject: Re: [tram] =?utf-8?q?=C3=89ric_Vyncke=27s_No_Objection_on_draft-ietf?= =?utf-8?q?-tram-turnbis-27=3A_=28with_COMMENT=29?= X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.29 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 Jul 2019 21:35:37 -0000 VGlydQ0KDQpUaGFuayB5b3UgZm9yIHlvdXIgcmVwbHkgYW5kIHlvdXIgY29tbWVudHMgYW5kIGFj dGlvbnMuDQoNClBsZWFzZSBzZWUgcmVtYWluaW5nIHBvaW50cyBpbmxpbmUgZm9yIGxpbmVzIHN0 YXJ0aW5nIHdpdGggRVY+DQoNClJlZ2FyZHMNCg0KLcOpcmljDQoNCu+7v09uIDA4LzA3LzIwMTks IDE1OjU1LCAiS29uZGEsIFRpcnVtYWxlc3dhciBSZWRkeSIgPFRpcnVtYWxlc3dhclJlZGR5X0tv bmRhQE1jQWZlZS5jb20+IHdyb3RlOg0KDQogICAgSGkgRXJpYywNCiAgICANCiAgICBUaGFua3Mg Zm9yIHRoZSByZXZpZXcuIFBsZWFzZSBzZWUgaW5saW5lIA0KICAgIA0KICAgID4gLS0tLS1Pcmln aW5hbCBNZXNzYWdlLS0tLS0NCiAgICA+IEZyb206IHRyYW0gPHRyYW0tYm91bmNlc0BpZXRmLm9y Zz4gT24gQmVoYWxmIE9mIMOJcmljIFZ5bmNrZSB2aWENCiAgICA+IERhdGF0cmFja2VyDQogICAg PiBTZW50OiBTdW5kYXksIEp1bHkgNywgMjAxOSAxOjQ5IFBNDQogICAgPiBUbzogVGhlIElFU0cg PGllc2dAaWV0Zi5vcmc+DQogICAgPiBDYzogdHJhbS1jaGFpcnNAaWV0Zi5vcmc7IGRyYWZ0LWll dGYtdHJhbS10dXJuYmlzQGlldGYub3JnOyB0cmFtQGlldGYub3JnOw0KICAgID4gYnJhbmRvbi53 aWxsaWFtc0Bha2FtYWkuY29tDQogICAgPiBTdWJqZWN0OiBbdHJhbV0gw4lyaWMgVnluY2tlJ3Mg Tm8gT2JqZWN0aW9uIG9uIGRyYWZ0LWlldGYtdHJhbS10dXJuYmlzLTI3Og0KICAgID4gKHdpdGgg Q09NTUVOVCkNCiAgICA+IA0KICAgIA0KICAgID4gRm9yIG15IG93biBjdXJpb3NpdHksIGlzbid0 IFRVUk4gc2NvcGUgYnJvYWRlciB0aGFuIHBsYWluIE5BVDogY2FuIGl0IGFsc28gYmUNCiAgICA+ IHVzZWZ1bCBpbiB0aGUgYWJzZW5jZSBvZiBOQVQgaWYgaW5ib3VuZCAnY29ubmVjdGlvbicgYXJl IGJsb2NrZWQgYnkgc2VjdXJpdHkNCiAgICA+IHBvbGljeSA/DQogICAgDQogICAgSW50ZXJhY3Rp dmUgQ29ubmVjdGl2aXR5IEVzdGFibGlzaG1lbnQgKElDRSkgaGVscHMgc29sdmUgdGhlIGFib3Zl IHByb2JsZW0gYnkgcGVyZm9ybWluZyBjb25uZWN0aXZpdHkgY2hlY2tzLCBidXQgZGlyZWN0IFVE UCBjb25uZWN0aW9uIHdpbGwgbm90IGJlIHBvc3NpYmxlIGV2ZW4gd2l0aCBJQ0UgaWYgYm90aCBl bmRwb2ludHMgYXJlIGJlaGluZCBOQVRzIHRoYXQgcGVyZm9ybSBhZGRyZXNzIGFuZCBwb3J0IGRl cGVuZGVudCBtYXBwaW5nLiBJbiBhZGRpdGlvbiwgRW50ZXJwcmlzZSBmaXJld2FsbCBtYXkgYmxv Y2sgZGlyZWN0IFVEUCBjb25uZWN0aW9ucyBidXQgYWxsb3cgVURQIHRyYWZmaWMgcmVsYXllZCB0 aHJvdWdoIGFuIEVudGVycHJpc2UgVFVSTiBzZXJ2ZXIgKHBsZWFzZSBzZWUgaHR0cHM6Ly90b29s cy5pZXRmLm9yZy9odG1sL3JmYzc0Nzgjc2VjdGlvbi0yLjMuNS4xKS4gDQogIA0KRVY+IEkgYW0g ZmFtaWxpYXIgd2l0aCBJQ0UgX18gYW5kIHlvdXIgbGFzdCBzZW50ZW5jZSBpcyBleGFjdGx5IHdo YXQgbXkgaW5pdGlhbCBjb21tZW50IHdhcyBhYm91dDogcGxlYXNlIGdvZXMgYmV5b25kIHRoZSBO QVQgdHlwaWNhbC9jb21tb24gdXNlIGNhc2Ugb2YgVFVSTiBhbmQgYWxzbyBjaXRlIHRoZSBmaXJl d2FsbCBibG9ja2luZyBpbmJvdW5kIFVEUC4gSnVzdCB0byBpbXByb3ZlIHVuZGVyc3RhbmRpbmcg YnkgdGhlIHJlYWRlcnMuDQogIA0KICAgID4gDQogICAgPiA9PSBDT01NRU5UUyA9PQ0KPiANCiAg ICA+IC0tIFNlY3Rpb24gMy4xIC0tDQogICAgPiANCiAgICA+IElzIHRoZXJlIGFueSByZWFzb24g d2h5IE1QVENQIGlzIG5vdCBzcGVjaWZpZWQgZm9yIHRoZSBjb21tdW5pY2F0aW9uDQogICAgPiBi ZXR3ZWVuIFRVUk4gY2xpZW50IGFuZCBUVVJOIHNlcnZlcj8gVGhlcmUgaXMgYSB2ZXJ5IHNob3J0 IGV4cGxhbmF0aW9uIGluDQogICAgPiBzZWN0aW9uIDE1ICJUQ1AgbXVsdGktcGF0aCBpcyBub3Qg dXNlZCBieSBib3RoIFNJUCBhbmQgV2ViUlRDIHByb3RvY29scw0KICAgID4gW1JGQzc0NzhdIGZv ciBtZWRpYSBhbmQgbm9uLW1lZGlhIGRhdGEiIGJ1dCBpdCBkb2VzIG5vdCBhZGRyZXNzIHRoZSB1 c2Ugb2YNCiAgICA+IE1QVENQIGJldHdlZW4gVFVSTiBjbGllbnQvc2VydmVyLg0KICAgIA0KICAg IFRVUk4gaXMgdHlwaWNhbGx5IHVzZWQgYnkgU0lQIGFuZCBXZWJSVEMgcHJvdG9jb2xzIHRvIHJl bGF5IG1lZGlhIHN0cmVhbXMsIGJ1dCBSVFAgYXNzdW1lcyBhIHNpbmdsZSBwYXRoIGFuZCBtYWtl IGRlY2lzaW9ucyBiYXNlZCBvbiB0aGUgbWVhc3VyZWQgY2hhcmFjdGVyaXN0aWNzIG9mIHRoaXMg c2luZ2xlIHBhdGggKHdpdGggdGhlIGV4Y2VwdGlvbiBvZiBNdWx0aXBhdGggUlRQIGRpc2N1c3Nl ZCBpbiBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1hdnRjb3JlLW1wcnRw LTAzKS4NCiAgIA0KRVY+IHN1Z2dlc3QgdG8gYWRkIGFuIGluZm9ybWF0aXZlIHJlZmVyZW5jZSB0 byB0aGUgSS1EDQogDQogICAgPiANCiAgICA+IC0tIFNlY3Rpb24gMy43IC0tDQogICAgPiANCiAg ICA+IFRoZSA1MDAgYnl0ZXMgZ3VpZGVsaW5lIHRvIGF2b2lkIGZyYWdtZW50YXRpb24sIGlzIHRo ZXJlIGFueSBkYXRhIGJhY2tpbmcgdGhlDQogICAgPiBzZW50ZW5jZSAiLi4ud2lsbCBnZW5lcmFs bHkgYXZvaWQgSVAgZnJhZ21lbnRhdGlvbi4iID8NCiAgICANCiAgICBZZXMsIElmIHRoZSBQTVRV IGlzIG5vdCBrbm93biwgYW5kIG9uIGxlZ2FjeSBvciBvdGhlcndpc2UgdW51c3VhbCBuZXR3b3Jr cyB0aGUgZ3VpZGVsaW5lIHNob3VsZCB3b3JrIChzZWUgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9o dG1sL3JmYzcyNTIjc2VjdGlvbi00LjYgYW5kIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9k cmFmdC1pZXRmLXRzdndnLWRhdGFncmFtLXBscG10dWQtMDgpLg0KICAgIA0KRVY+IFJGQyA3MjUy IGlzIGFib3V0IENvQVAgYW5kIGlzIG5vdCAiYSBndWlkZWxpbmUiIHBlciBzZSBidXQgYSByZWZl cmVuY2UgdG8gdGhlIElQdjQgJ2Fzc3VtZWQnIE1UVSBvZiA1NzYuIEkgd291bGQgcHJlZmVyIGEg cmVmZXJlbmNlIHRvIFJGQyA3MjUyIHdpdGggNTc2IGZvciBJUHY0IGFuZCAxMjgwIGZvciBJUHY2 IGZvciBNVFUuIEkgYW0gYWZyYWlkIHRoYXQgZ2l2aW5nIHRoZSBudW1iZXIgIjUwMCIgaXMga2lu ZCBvZiBtaXNsZWFkaW5nIHRoZSByZWFkZXIuIEF0IHRoZSBiYXJlIG1pbmltdW0sIEkgc3VnZ2Vz dCB0byBhZGQgdGhlIHJlZmVyZW5jZSB0byBDT0FQLCBhbmQgdXNlIHRoZSBudW1iZXIgZnJvbSBD b0FQIGlmIHlvdSB3YW50IHRvIHNwZWNpZnkgbnVtYmVycy4gDQoNCg0KIA0KDQo= From nobody Tue Jul 9 01:10:16 2019 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 F15E2120116; Tue, 9 Jul 2019 01:10:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 s6W8ehgYKhIm; Tue, 9 Jul 2019 01:10:05 -0700 (PDT) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-eopbgr130074.outbound.protection.outlook.com [40.107.13.74]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7755312010C; Tue, 9 Jul 2019 01:10:04 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=CYvkC3u6g53Obp9/MNjQgrpKoISi/b+zr5FeN9dViBEfw8/qx2tCs5pVF3/bEAEVgO+2fAuKgXxZmJXaiViWcex/NQxKjzXEA5CuXTXWgSBsPJId2aiv4pPHiIXwrLWY6UK+ayXD80AEWF/RSyMlfmaQFSWrH84CMpJR9Th9iYRICoaFHJbEn8NlljzQBhoBTJzRXTpW/ouDssNjZEqq/N53hea6mIYDkyMJNreBWOjxNWrUzLKM+JWx7FHvFtgmjvT2mJyJhllGJmzkVHYA2t22MxftuhyF1RJ8daDVyfp8lkjGw6rCgjztcRwk9egqIP9UqyBF4kdiqdj/zaOvLQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ymMGrU7B2hTB+H3rhtdkjFZp5rfI/dZT2Bhs6MT7yEw=; b=ZDyhK9vARD+SKpBy6CTUIbZHxhgakk+7RkFU3MqZCD7kHWDumN7E3V14qzQzO/+cDtLj8fwlWsIa/QCw9Z/Qwn3Ic2mm+rumJ6OrxeQnKzaP3D3bChs5VGTYQx2LuyBveWduBEoDYxzqSoQNEne7zgwmuWrCRZqO3CNpgyiPDzJLJmqArg/O6YCQJ/uUA1zmukF8LW2R8oDTVcOuavxwmaaTHYylvlkqORd8uJI7uRARfruWlwQfQc+/o0BFo2usTv670JBxq74uPCzG4sBkmuY9MIuMPGJzhTAfj6BuvtPiDhEv/iDOhiikyjjWHLbbbTYDcU2PVXoq1HZwZER3gQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1;spf=pass smtp.mailfrom=ericsson.com;dmarc=pass action=none header.from=ericsson.com;dkim=pass header.d=ericsson.com;arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ymMGrU7B2hTB+H3rhtdkjFZp5rfI/dZT2Bhs6MT7yEw=; b=eZZQS38SkqiaU+cz6dQplVID92WXHJeELzEyrPCy+Fu3u3Aaa4jiWzjRKd7KCwSchaaRLzH4IvzyvXf3EerMB0r9VG9e7hN2Ao6k005vnSZ/VEFs3CAl0hJ8MhY5GbVaJvupZTyZSRxbRJYAZzhNeG1VmtOI7yL4FXiZrQc3lmw= Received: from HE1PR0701MB2522.eurprd07.prod.outlook.com (10.168.128.149) by HE1PR0701MB2410.eurprd07.prod.outlook.com (10.168.128.142) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2073.5; Tue, 9 Jul 2019 08:10:01 +0000 Received: from HE1PR0701MB2522.eurprd07.prod.outlook.com ([fe80::3418:2814:2ee2:a22b]) by HE1PR0701MB2522.eurprd07.prod.outlook.com ([fe80::3418:2814:2ee2:a22b%4]) with mapi id 15.20.2073.008; Tue, 9 Jul 2019 08:10:01 +0000 From: Magnus Westerlund To: "iesg@ietf.org" , "TirumaleswarReddy_Konda@McAfee.com" , "evyncke@cisco.com" CC: "tram@ietf.org" , "brandon.williams@akamai.com" , "tram-chairs@ietf.org" , "draft-ietf-tram-turnbis@ietf.org" Thread-Topic: =?utf-8?B?W3RyYW1dICDDiXJpYyBWeW5ja2UncyBObyBPYmplY3Rpb24gb24gZHJhZnQt?= =?utf-8?Q?ietf-tram-turnbis-27:_(with_COMMENT)?= Thread-Index: AQHVNdUl0GHEV+QPGUCKSongPIraDKbB77yA Date: Tue, 9 Jul 2019 08:10:01 +0000 Message-ID: <4e999e5ae34e102ab5ca3a65c1b11a88647b5667.camel@ericsson.com> References: <156248752430.14312.15895119889558390147.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=magnus.westerlund@ericsson.com; x-originating-ip: [192.176.1.87] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: a32bc71e-5ebc-40e5-26b0-08d70444d754 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(49563074)(7193020); SRVR:HE1PR0701MB2410; x-ms-traffictypediagnostic: HE1PR0701MB2410: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0093C80C01 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(979002)(4636009)(376002)(366004)(396003)(346002)(136003)(39860400002)(199004)(189003)(99936001)(76116006)(73956011)(66446008)(64756008)(66556008)(66476007)(66946007)(71200400001)(71190400001)(66616009)(66066001)(36756003)(86362001)(224303003)(2201001)(5660300002)(6512007)(6306002)(44832011)(81156014)(4326008)(81166006)(25786009)(6486002)(478600001)(966005)(2616005)(305945005)(11346002)(446003)(476003)(6116002)(7736002)(3846002)(68736007)(6436002)(53936002)(6506007)(8936002)(229853002)(14454004)(14444005)(102836004)(256004)(118296001)(99286004)(486006)(186003)(26005)(2906002)(316002)(2501003)(54906003)(110136005)(76176011)(6246003)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR0701MB2410; H:HE1PR0701MB2522.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: SpL583fIdYg8ovZVZevh9WPAfSZlfUEs3dZA4Ze0YtSXXvNF561+LOzGPRgMGeEr+nZu9JE3WlYhxT0xMJbyjAhlJkcmW4WnMUJkBimeAVFmxNk+sAmMkW6HjxV4d9XJzrHDBq131qrjKdBzEnTfIsc6uz/ZKbTUXkMJfL9vSMfWzpuwmSwoGqEpcqwP9hYolHnzaQks3CrSH4l9l7uT2b/oa8u4qtLJuGZlqAgHOARqgVIhecF2jjuRn11hEbmalUpBGsmaeCj1MJBlUQWOlXJfIwbAV90BtzAGgLmInqYyReh7IMO7PaGugbwPoAkO297emVmJr/gb1E5HP+jkb7F7WCKcPMh8zAxj28SEaql6btQVzJrVZ2NimUKL07OwZICQNNMA3an/nEiUXERnuBiN/sBR3EnJrX5xRuXVezA= Content-Type: multipart/signed; micalg="sha-256"; protocol="application/x-pkcs7-signature"; boundary="=-H6NxlAsNqg31cx0nHBGv" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: a32bc71e-5ebc-40e5-26b0-08d70444d754 X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Jul 2019 08:10:01.1898 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: magnus.westerlund@ericsson.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB2410 Archived-At: Subject: Re: [tram] =?utf-8?q?=C3=89ric_Vyncke=27s_No_Objection_on_draft-ietf?= =?utf-8?q?-tram-turnbis-27=3A_=28with_COMMENT=29?= X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.29 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 Jul 2019 08:10:09 -0000 --=-H6NxlAsNqg31cx0nHBGv Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, A comment inline regarding MP-TCP. On Mon, 2019-07-08 at 21:19 +0000, Eric Vyncke (evyncke) wrote: > Tiru >=20 > Thank you for your reply and your comments and actions. >=20 > Please see remaining points inline for lines starting with EV> >=20 > Regards >=20 > -=C3=A9ric >=20 > =EF=BB=BFOn 08/07/2019, 15:55, "Konda, Tirumaleswar Reddy" < > TirumaleswarReddy_Konda@McAfee.com> wrote: >=20 >=20 > >=20 > > =3D=3D COMMENTS =3D=3D > >=20 >=20 > > -- Section 3.1 -- > >=20 > > Is there any reason why MPTCP is not specified for the > communication > > between TURN client and TURN server? There is a very short > explanation in > > section 15 "TCP multi-path is not used by both SIP and WebRTC > protocols > > [RFC7478] for media and non-media data" but it does not address > the use of > > MPTCP between TURN client/server. > =20 > TURN is typically used by SIP and WebRTC protocols to relay media > streams, but RTP assumes a single path and make decisions based on > the measured characteristics of this single path (with the exception > of Multipath RTP discussed in=20 > https://tools.ietf.org/html/draft-ietf-avtcore-mprtp-03). > =20 > EV> suggest to add an informative reference to the I-D So on the client to server path there is a possibility to use MP-TCP to potentially improve that specific leg of the communication. It can be negotiated in the TCP connection if desired. However, to be clear I don't think there is a reason to recommend and definitely not mandate MP-TCP support if one supports the TCP transport in the client to server interface. Also it creates a potentially interesting interactions between the framework using TURN, like ICE when a mobility events happen. It may also result in sub-optimal routing in cases where a client selects to use multiple interfaces to have one MP-TCP connection to one TURN server, rather than the best TURN server per interface.=20 Also, I think discussing MP-RTP here is missleading. Because with MP- RTP I would treat the TURN relayed address as one particular point of presence for the TURN client side implementation, in addition to any direct from the corresponding interface that may be possible to establish. There are some discussion of this in the MP-RTP draft.=20 So it would be possible to state that an TURN client MAY attempt to negotiate MP-TCP with the TURN server but support of MP-TCP in TURN servers are OPTIONAL. In addition TURN clients on hosts with multiple interfaces and access to multiple TURN servers should consider if there are certain interfaces and TURN server combinations that results in shorter paths, and therefore can benefit from using multiple TURN servers, even if they can be reached from multiple interfaces.=20 Cheers > =20 > >=20 > > -- Section 3.7 -- > >=20 > > The 500 bytes guideline to avoid fragmentation, is there any > data backing the > > sentence "...will generally avoid IP fragmentation." ? > =20 > Yes, If the PMTU is not known, and on legacy or otherwise unusual > networks the guideline should work (see=20 > https://tools.ietf.org/html/rfc7252#section-4.6 and=20 > https://tools.ietf.org/html/draft-ietf-tsvwg-datagram-plpmtud-08). > =20 > EV> RFC 7252 is about CoAP and is not "a guideline" per se but a > reference to the IPv4 'assumed' MTU of 576. I would prefer a > reference to RFC 7252 with 576 for IPv4 and 1280 for IPv6 for MTU. I > am afraid that giving the number "500" is kind of misleading the > reader. At the bare minimum, I suggest to add the reference to COAP, > and use the number from CoAP if you want to specify numbers.=20 I think I mostly agree with Eric here. So 576 is a recommendation on the IPv4 minimal required packet size reception capability. Then you have subtracted the overhead for TURN roughly. And still 576 bytes IPv4 packets may be fragmented, the true minimal size is 68 bytes. And the use of an assumption of 1280 minus TURN overhead is almost as likely to not result in fragmentation as 500 bytes. Becasue the networks that will have issues with your 1200 payload is likely going to have issues with 500 bytes too. So from my perspective giving that very low recommendation does not reflect today's network. And the COAP recommendation of meeting 576 bytes total is for constrained devices and their link layers. TURN's primary users in media applications are normally not targeting that type of link layers that has such a limited MTU.=20 =20 Cheers Magnus Westerlund=20 ---------------------------------------------------------------------- Network Architecture & Protocols, Ericsson Research ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Torshamnsgatan 23 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- --=-H6NxlAsNqg31cx0nHBGv Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCEtww ggYHMIID76ADAgECAhALRm3NcHtuMGWutmt5cXntMA0GCSqGSIb3DQEBCwUAMEcxCzAJBgNVBAYT AlNFMREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBD QSB2MzAeFw0xNzEyMTUwNzIyMjNaFw0yMDEyMTUwNzIyMjJaMHAxETAPBgNVBAoMCEVyaWNzc29u MRowGAYDVQQDDBFNYWdudXMgV2VzdGVybHVuZDEtMCsGCSqGSIb3DQEJARYebWFnbnVzLndlc3Rl cmx1bmRAZXJpY3Nzb24uY29tMRAwDgYDVQQFEwdlcmFtc3dkMIIBIjANBgkqhkiG9w0BAQEFAAOC AQ8AMIIBCgKCAQEAsKlHZvB3TsmLEDtPSiFFKAh73S2wApt+laqg5eXTqonqnzT9ykEGL2dx9mBT +2WZiIKxo4w2sisVl3EEYTqXTkctpur7cN29gLC8F3tJHGI2sUVpO9AwpVrN+UuHEVetHt7hdxW9 uYd0LJJ8TP6/wGkIfAFaZxlZUn79O2eHElfih1iVIiTZXLcEe1rBJtzhUNRHWgOm2vQlDJ4sCpig GFq5w+XSRviEQMkQZRvw1CQmb35QS/C/T36ogzIRHDuAdkoSaiUOY/S2dLp4HkwvOOg+tADpaHkr bdmdnjKGrYSnJigmxw14pJugxL/Vb2EeVcgpAfVVst7Lm4POPRI8+wIDAQABo4IBxDCCAcAwSAYD VR0fBEEwPzA9oDugOYY3aHR0cDovL2NybC50cnVzdC50ZWxpYS5jb20vZXJpY3Nzb25ubGluZGl2 aWR1YWxjYXYzLmNybDCBggYIKwYBBQUHAQEEdjB0MCgGCCsGAQUFBzABhhxodHRwOi8vb2NzcDIu dHJ1c3QudGVsaWEuY29tMEgGCCsGAQUFBzAChjxodHRwOi8vY2EudHJ1c3QudGVsaWFzb25lcmEu Y29tL2VyaWNzc29ubmxpbmRpdmlkdWFsY2F2My5jZXIwKQYDVR0RBCIwIIEebWFnbnVzLndlc3Rl cmx1bmRAZXJpY3Nzb24uY29tMFUGA1UdIAROMEwwSgYMKwYBBAGCDwIDAQESMDowOAYIKwYBBQUH AgEWLGh0dHBzOi8vcmVwb3NpdG9yeS50cnVzdC50ZWxpYXNvbmVyYS5jb20vQ1BTMB0GA1UdJQQW MBQGCCsGAQUFBwMEBggrBgEFBQcDAjAdBgNVHQ4EFgQU5ivuhpU51W4UhBDBWwf8XsU837YwHwYD VR0jBBgwFoAUHHsZnpecdqwgPdjc45Fq49stplMwDgYDVR0PAQH/BAQDAgWgMA0GCSqGSIb3DQEB CwUAA4ICAQBn0FKukg00UN/c/ESpxSIaYTrsd8liHHMu5rLpOBNOacpGNBMGNgUDDt4QihhoQR3c vhYXCrAM59NTvw0HNlgqHZoEeVY7YnJJYnJXDCLUfkK5Dn28E3QrzykkF6giUOXDyF9mhWYbSAkJ yx0Yj0Xc8en3wYNyoFYEqjlKtZrdV0pcgFzEeXVLS8DWrzSy7+KfUtDOEiM6H3zO3nsq++KBmsOi SKkWn4oYERZg5KElEAHis9av+3KIaEPnOAt8QRWRpFfGZ4d89F16qFvElup5n7l864FqxnC2friD o4hLQY6ENaOaYIihXhbl2UYxAGDk89aJm/S5pYyq7wzm+KK3IcUl60rmc8SJlt6QXKw0wXEOE1Mu bauYKMsad2s8jD+rEkXp+agTRl+sezWaRxHBpxuUKDd6MhwDig3SZi1qP7D/Ds4V+JLIjjUJc25l 9tvMGC9+lqI0P+vMI3Zyrou0NNfb55uLQaq18O+7BZ8Kv7jvFdxYyUgbxQ0SPEiyhylcLHAmJeLC QaiZHmCREBkCLKSf0O4lE2TrVzdOD38wjzuQ27U3UddVCD9EQ3tF7o6EVhpxJJUlB6xe/2UWwy4Z la71dKLUhakdVrN5abzxqFWvzOAT9nBa2HzYVBtpbcu6KGh72YJ+M79fa9iIkcQCgUnw3gIAeWd/ /n4YbY2QhDCCBgcwggPvoAMCAQICEAtGbc1we24wZa62a3lxee0wDQYJKoZIhvcNAQELBQAwRzEL MAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRp dmlkdWFsIENBIHYzMB4XDTE3MTIxNTA3MjIyM1oXDTIwMTIxNTA3MjIyMlowcDERMA8GA1UECgwI RXJpY3Nzb24xGjAYBgNVBAMMEU1hZ251cyBXZXN0ZXJsdW5kMS0wKwYJKoZIhvcNAQkBFh5tYWdu dXMud2VzdGVybHVuZEBlcmljc3Nvbi5jb20xEDAOBgNVBAUTB2VyYW1zd2QwggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQCwqUdm8HdOyYsQO09KIUUoCHvdLbACm36VqqDl5dOqieqfNP3K QQYvZ3H2YFP7ZZmIgrGjjDayKxWXcQRhOpdORy2m6vtw3b2AsLwXe0kcYjaxRWk70DClWs35S4cR V60e3uF3Fb25h3QsknxM/r/AaQh8AVpnGVlSfv07Z4cSV+KHWJUiJNlctwR7WsEm3OFQ1EdaA6ba 9CUMniwKmKAYWrnD5dJG+IRAyRBlG/DUJCZvflBL8L9PfqiDMhEcO4B2ShJqJQ5j9LZ0ungeTC84 6D60AOloeStt2Z2eMoathKcmKCbHDXikm6DEv9VvYR5VyCkB9VWy3subg849Ejz7AgMBAAGjggHE MIIBwDBIBgNVHR8EQTA/MD2gO6A5hjdodHRwOi8vY3JsLnRydXN0LnRlbGlhLmNvbS9lcmljc3Nv bm5saW5kaXZpZHVhbGNhdjMuY3JsMIGCBggrBgEFBQcBAQR2MHQwKAYIKwYBBQUHMAGGHGh0dHA6 Ly9vY3NwMi50cnVzdC50ZWxpYS5jb20wSAYIKwYBBQUHMAKGPGh0dHA6Ly9jYS50cnVzdC50ZWxp YXNvbmVyYS5jb20vZXJpY3Nzb25ubGluZGl2aWR1YWxjYXYzLmNlcjApBgNVHREEIjAggR5tYWdu dXMud2VzdGVybHVuZEBlcmljc3Nvbi5jb20wVQYDVR0gBE4wTDBKBgwrBgEEAYIPAgMBARIwOjA4 BggrBgEFBQcCARYsaHR0cHM6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhc29uZXJhLmNvbS9DUFMw HQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMB0GA1UdDgQWBBTmK+6GlTnVbhSEEMFbB/xe xTzftjAfBgNVHSMEGDAWgBQcexmel5x2rCA92NzjkWrj2y2mUzAOBgNVHQ8BAf8EBAMCBaAwDQYJ KoZIhvcNAQELBQADggIBAGfQUq6SDTRQ39z8RKnFIhphOux3yWIccy7msuk4E05pykY0EwY2BQMO 3hCKGGhBHdy+FhcKsAzn01O/DQc2WCodmgR5VjtickliclcMItR+QrkOfbwTdCvPKSQXqCJQ5cPI X2aFZhtICQnLHRiPRdzx6ffBg3KgVgSqOUq1mt1XSlyAXMR5dUtLwNavNLLv4p9S0M4SIzoffM7e eyr74oGaw6JIqRafihgRFmDkoSUQAeKz1q/7cohoQ+c4C3xBFZGkV8Znh3z0XXqoW8SW6nmfuXzr gWrGcLZ+uIOjiEtBjoQ1o5pgiKFeFuXZRjEAYOTz1omb9LmljKrvDOb4orchxSXrSuZzxImW3pBc rDTBcQ4TUy5tq5goyxp3azyMP6sSRen5qBNGX6x7NZpHEcGnG5QoN3oyHAOKDdJmLWo/sP8OzhX4 ksiONQlzbmX228wYL36WojQ/68wjdnKui7Q019vnm4tBqrXw77sFnwq/uO8V3FjJSBvFDRI8SLKH KVwscCYl4sJBqJkeYJEQGQIspJ/Q7iUTZOtXN04PfzCPO5DbtTdR11UIP0RDe0XujoRWGnEklSUH rF7/ZRbDLhmVrvV0otSFqR1Ws3lpvPGoVa/M4BP2cFrYfNhUG2lty7ooaHvZgn4zv19r2IiRxAKB SfDeAgB5Z3/+fhhtjZCEMIIGwjCCBKqgAwIBAgIQU7h+g+GcmSiTsJtJHOy46zANBgkqhkiG9w0B AQsFADA3MRQwEgYDVQQKDAtUZWxpYVNvbmVyYTEfMB0GA1UEAwwWVGVsaWFTb25lcmEgUm9vdCBD QSB2MTAeFw0xNTEwMjcxMjE2NDZaFw0yNTEwMjcxMjE2NDZaMEcxCzAJBgNVBAYTAlNFMREwDwYD VQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MzCCAiIw DQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBAOzy3wAAuFDyp7vYVLfGk/fjwao71MNGNLSzzl5D tjQtMtl2ZLPZyX6ViqzTN9JOb7uZ6KxuGSpReQvt8XOh7iIhkKH9W5hRpbjTsJmUMJd6zifhOpNK 6iSU3q44+FjsQL1lVtcguUuFG6aZN0N3GFVbgt6jRrASF8t/3wy9bHPAIfMyPybpg6Y2PH5/1Nwk TepoDSmK69LGV+lV2IK6U9OWayZXZFIFIDCoGyFlhFxAEgN+qZ2+Rqg/0TM0oCHvKO2ELSGmAdnJ kwizR42ji/Y9SYTSuG75mzSe6OfCGWM8Db/xvy/20aLEPXNu1PvOgzY63WZ6cmkWnjMlVJ90pWC2 haqDm3Yf8TRdjUvAl7Pz1bTuexwShzIGakL7MkCYrEqHMRaojI/VStloQgW76E76zQ2byw5QxrhO UbisBSKRzlTlOZQgYFFAbG6ViF8DOpJh/ygtQwuTLUM5r15G7eynQV1AMTNCWcX+HUvgArUw6RfW 9L58uA68GjktFTV8s9RlDsUqsNcLqeXaV28S2WMday0YGaq/bloS8AD7KuumUKH+Ri9IGO9mJvP0 5tvDHjKpLvv80c3WLJnJU/aznYHYEt2+jjKHOTqdGTxL/zMdpRSQFSuu+KM8NoYrkU1VJqKga+QL sgqKghMp99gu1P1e6KsqseWHdXORrMbjqkBXAgMBAAGjggG4MIIBtDCBigYIKwYBBQUHAQEEfjB8 MC0GCCsGAQUFBzABhiFodHRwOi8vb2NzcC50cnVzdC50ZWxpYXNvbmVyYS5jb20wSwYIKwYBBQUH MAKGP2h0dHA6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhc29uZXJhLmNvbS90ZWxpYXNvbmVyYXJv b3RjYXYxLmNlcjASBgNVHRMBAf8ECDAGAQH/AgEAMFUGA1UdIAROMEwwSgYMKwYBBAGCDwIDAQEC MDowOAYIKwYBBQUHAgEWLGh0dHBzOi8vcmVwb3NpdG9yeS50cnVzdC50ZWxpYXNvbmVyYS5jb20v Q1BTMEsGA1UdHwREMEIwQKA+oDyGOmh0dHA6Ly9jcmwtMy50cnVzdC50ZWxpYXNvbmVyYS5jb20v dGVsaWFzb25lcmFyb290Y2F2MS5jcmwwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMA4G A1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUHHsZnpecdqwgPdjc45Fq49stplMwHwYDVR0jBBgwFoAU 8I9ZOACz9Y+algzV6/p7qhfoExIwDQYJKoZIhvcNAQELBQADggIBAFBYa/HVjDu0LqtXQ8iMp8PL Fpqchf41ksQY6R1AsoZbaBUu0NQlAQ9GzlC1pmI5s0cJnuaZI0xV6TiWS3/R2p9UgW61XD9CTIUb AL31mY3BdJf3P46gzKgQEca/DlFjq9GVmuPS4q90BLNgvgoxoHubc3C6s0OaY1sbnay5EhnvrAE4 Q511FlxmJPLnRmQGpieeXa3cPegFfY1kJDKyyFRypF1RuRLXcdMIgKEy5NX1bS3M9dQ4mgmUmVT2 d33UiKSEYQ6s/B+LFaaz4LywXSv2o3W4kbHoQs86IWst821ww0wxsCpEfClIvF7fBw2QkbG/1Pwu zAuLVStEhDzkAqOrMGctKyNEaBsyAn7Eq2eCa8QDXnkmagp9QPsNFs/oqnXj9j1cVtH9a4OPzhtg 0pd7gd0NzU/5QxibXqbYvouQgihGXHQDmaL4ruN7C4arMUqRo82YnREsKL7h3j/jtmzcMLc9Q07F 04QQd/iSR1Y5pIi6PdNBiE2/4uyAXS6KOIGZrPbNQUNrZtwiQpqQNl8AUzgegfPwrYFlFocpaF3d 1m5r+2VKKqiRQVfYPGYeZnWfkcz06JoAhc/9mjbHXSP9hvWYzeLRuoZqHGUdjOX9DIQb926OneV7 C5WMIjSY8ORkamG/HKqngmjypL3gSc6oG/E6B+1i6Ds5j0Qpj5aQMYICzTCCAskCAQEwWzBHMQsw CQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIEluZGl2 aWR1YWwgQ0EgdjMCEAtGbc1we24wZa62a3lxee0wDQYJYIZIAWUDBAIBBQCgggFDMBgGCSqGSIb3 DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE5MDcwOTA4MTAwMFowLwYJKoZIhvcN AQkEMSIEICds3aVdzVBqM19B6a3CVsXkmHLKX/gi3JFqyCXotamnMGoGCSsGAQQBgjcQBDFdMFsw RzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJ bmRpdmlkdWFsIENBIHYzAhALRm3NcHtuMGWutmt5cXntMGwGCyqGSIb3DQEJEAILMV2gWzBHMQsw CQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIEluZGl2 aWR1YWwgQ0EgdjMCEAtGbc1we24wZa62a3lxee0wDQYJKoZIhvcNAQEBBQAEggEAGFSxtE4owEo1 qoErkEvapb+JCJMdQPBQSqwtIInRRab+dhsPr1HGdF4soZxl6fd4RWZ3AiIcsJ0DpK7WcegDP5/B GVHpOjydYsoMxCSaQlW04NKSyZhVCd4mwiajR/3Iusu8DGrp/7f7c3zMTHMdUylVYY2nc1TPE+SK cn3fTM1n5SP9Ywx9oOsUFf6tLWp4riNmVCbHVA1oMQ9Bkhc7lo+6YSKMOrjvtJg1ixByKZUu5UJm WNjpHy9JZC+ksdE2oVhPpWVR9X75KQa8NlCLd1SMorSDTI2WnLWsyMAoZ8Hwm2qSphA9LF4Zwpmr IMAfpDXP3xhC1I3GeDomSDi3vgAAAAAAAA== --=-H6NxlAsNqg31cx0nHBGv-- From nobody Tue Jul 9 02:01:00 2019 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 D760A1203B3; Tue, 9 Jul 2019 02:00:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mcafee.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WMSZWnV252i9; Tue, 9 Jul 2019 02:00:55 -0700 (PDT) Received: from DNVWSMAILOUT1.mcafee.com (dnvwsmailout1.mcafee.com [161.69.31.173]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D66B312010C; Tue, 9 Jul 2019 02:00:54 -0700 (PDT) X-NAI-Header: Modified by McAfee Email Gateway (5500) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mcafee.com; s=s_mcafee; t=1562662222; h=ARC-Seal: ARC-Message-Signature:ARC-Authentication-Results: From:To:CC:Subject:Thread-Topic:Thread-Index: Date:Message-ID:References:In-Reply-To:Accept-Language: Content-Language:X-MS-Has-Attach:X-MS-TNEF-Correlator: dlp-product:dlp-version:dlp-reaction:authentication-results: x-originating-ip:x-ms-publictraffictype:x-ms-office365-filtering-correlation-id: x-microsoft-antispam:x-ms-traffictypediagnostic: x-ms-exchange-purlcount:x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers:x-forefront-prvs: x-forefront-antispam-report:received-spf:x-ms-exchange-senderadcheck: x-microsoft-antispam-message-info:Content-Type: Content-Transfer-Encoding:MIME-Version:X-MS-Exchange-CrossTenant-Network-Message-Id: X-MS-Exchange-CrossTenant-originalarrivaltime: X-MS-Exchange-CrossTenant-fromentityheader: X-MS-Exchange-CrossTenant-id:X-MS-Exchange-CrossTenant-mailboxtype: X-MS-Exchange-CrossTenant-userprincipalname: X-MS-Exchange-Transport-CrossTenantHeadersStamped: X-OriginatorOrg:X-NAI-Spam-Flag:X-NAI-Spam-Level: X-NAI-Spam-Threshold:X-NAI-Spam-Score:X-NAI-Spam-Version; bh=ReN7VkvjvwY5zJ50qRbHHW/0jPe7YJvxsQTM27 qch40=; b=hNzrNDKBYcyaC+FYd7t4egoT3MclJy7a63JXx3/v qQxJk8dpWON/wDQ5iDFn/FDN7wkoDe2enCLzCUduIarfzRbjSl ozxzAyhRLLNMEVq0SLZN5FR/SA71pcQ8bPB/U+Cow7a/kp9oXF qpLFqDRNdtzpfNwZge9WodjzfSy40Yk= Received: from DNVEXAPP1N06.corpzone.internalzone.com (DNVEXAPP1N06.corpzone.internalzone.com [10.44.48.90]) by DNVWSMAILOUT1.mcafee.com with smtp (TLS: TLSv1/SSLv3,256bits,ECDHE-RSA-AES256-SHA384) id 23b1_0d05_9652b85a_dbc5_422d_acf1_0da656253a44; Tue, 09 Jul 2019 02:50:21 -0600 Received: from DNVEXAPP1N06.corpzone.internalzone.com (10.44.48.90) by DNVEXAPP1N06.corpzone.internalzone.com (10.44.48.90) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Tue, 9 Jul 2019 03:00:23 -0600 Received: from DNVO365EDGE2.corpzone.internalzone.com (10.44.176.74) by DNVEXAPP1N06.corpzone.internalzone.com (10.44.48.90) with Microsoft SMTP Server (TLS) id 15.0.1395.4 via Frontend Transport; Tue, 9 Jul 2019 03:00:23 -0600 Received: from NAM04-BN3-obe.outbound.protection.outlook.com (10.44.176.243) by edge.mcafee.com (10.44.176.74) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Tue, 9 Jul 2019 03:00:22 -0600 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=PpaQzaexJ3j8DiNQtkbwQCaZZTGek4woxwgSO+qCUQSW1w8AMz85iTso45lia9ulUCI2/wxAQZSoQZZHW/+YZoRw6oanJtL91IJKbTxAvOaJUGHPZZRBU2DLU/00vEZ7aRSTJPRubKNRBesLn4uDDMjW/KjsdACdAORg42jqHyX7DWB+2syPFI+KAyax60+dN2JJmthc1K5UPygHlotzTmhH94L5TcAW72SfT+7HMwTmibnswn2nOPplFG33UliYnDK7H/TJGVHEaLt32GsUbXOef2mZ5UjOjawlppFuN8YYjZbzhzA5ANKdkjDgM+AWBOoIYmHkavZkA04ni1v04Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ReN7VkvjvwY5zJ50qRbHHW/0jPe7YJvxsQTM27qch40=; b=MyYTkUS8vByfkTNgQTiJRGXGNCq9kosikn1Q0L83WPn1fSAvIRX7VofcPrEMTRORBF6rFNT3EqcWvTR+PIBARVZtqMCGAOd80Kem4pl1PB6BOxCUmIeZao+1YjdnJmelmcOOtm/Ntrmsvkfbf4NDlro2f7l79Z5baAFxrRPijJrNi47PzrG2utY49R/mASR7nSyqtTXYe/Ms3XiR2jQe3+mlEaApFG0w6OJQBe/z/pgAmkwwSbyol/gfpG5Bjzj1YJd5rFvkbyJTjDkdR5w7B2H+xjgJQukVPNIwM6ksQ18gReva6GTlaQKhjXROD+8CPEmJ1XuOECFJ18O6Pt8XdQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1;spf=pass smtp.mailfrom=mcafee.com;dmarc=pass action=none header.from=mcafee.com;dkim=pass header.d=mcafee.com;arc=none Received: from DM5PR16MB1705.namprd16.prod.outlook.com (10.172.44.147) by DM5PR16MB2360.namprd16.prod.outlook.com (52.132.142.163) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2073.10; Tue, 9 Jul 2019 09:00:21 +0000 Received: from DM5PR16MB1705.namprd16.prod.outlook.com ([fe80::570:2208:75c2:5f17]) by DM5PR16MB1705.namprd16.prod.outlook.com ([fe80::570:2208:75c2:5f17%8]) with mapi id 15.20.2052.019; Tue, 9 Jul 2019 09:00:21 +0000 From: "Konda, Tirumaleswar Reddy" To: "Eric Vyncke (evyncke)" , The IESG CC: "tram-chairs@ietf.org" , "draft-ietf-tram-turnbis@ietf.org" , "tram@ietf.org" , "brandon.williams@akamai.com" Thread-Topic: =?utf-8?B?W3RyYW1dIMOJcmljIFZ5bmNrZSdzIE5vIE9iamVjdGlvbiBvbiBkcmFmdC1p?= =?utf-8?Q?etf-tram-turnbis-27:_(with_COMMENT)?= Thread-Index: AQHVNJyeoaZBM6SyTEC4IXgEbhm1HqbARDZggAEZuwCAAJhF4A== Date: Tue, 9 Jul 2019 09:00:21 +0000 Message-ID: References: <156248752430.14312.15895119889558390147.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.3.0.16 dlp-reaction: no-action authentication-results: spf=none (sender IP is ) smtp.mailfrom=TirumaleswarReddy_Konda@McAfee.com; x-originating-ip: [103.245.47.20] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: d72b96f5-21b1-4c30-4dc9-08d7044bdf85 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:DM5PR16MB2360; x-ms-traffictypediagnostic: DM5PR16MB2360: x-ms-exchange-purlcount: 5 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0093C80C01 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(366004)(136003)(376002)(39850400004)(346002)(396003)(189003)(199004)(32952001)(51914003)(13464003)(52536014)(110136005)(99286004)(53546011)(66574012)(76176011)(966005)(5660300002)(71200400001)(71190400001)(7696005)(68736007)(6506007)(186003)(76116006)(66066001)(2906002)(66476007)(64756008)(66446008)(72206003)(14454004)(66946007)(66556008)(73956011)(74316002)(4326008)(26005)(305945005)(102836004)(478600001)(446003)(229853002)(33656002)(256004)(14444005)(224303003)(486006)(81166006)(11346002)(6436002)(7736002)(3846002)(6116002)(81156014)(55016002)(8936002)(80792005)(6306002)(9686003)(53936002)(25786009)(6246003)(5024004)(316002)(54906003)(86362001)(476003)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR16MB2360; H:DM5PR16MB1705.namprd16.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: McAfee.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: MFmi8Lh55LfSLCt4k5VNTdfzZhFsOHQxKcAA2vZvx7WvW1YSCx0ND85bN1dI3y2+zMJSZSDHpH9eByjaunhjL0Rhjl9/1HIwLvyhddwAOSGzgQzslZK6QAzW6G6ztg/muHzNZO3z5TjRZmOx7gRdRowiOvWVGs9hOiGqllo5KAu/wkH76s7CL4IZtia2pXAMgS4xtHt3nEDjnRWBeu23DpxB+SFYt49bvaj8j6onSgOIzbqXcZn228NXnWCm7YI296OCmH1qiTx+rCpJZVcJAhdnft/QqZqyE/sKEs9u/LgcAvlz9MWXVqkkaiwjbopG4mO64pI3Vdxvq1j+hLgi5yahPhVBcY4Y55qvfsGmBZ/SBQSkQc4XbsIFN89V6TEAcmh+b/WUjOn479teL6I+SBI8hlk6l2K7gHk3S7UDv+8= Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: d72b96f5-21b1-4c30-4dc9-08d7044bdf85 X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Jul 2019 09:00:21.3456 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: TirumaleswarReddy_Konda@McAfee.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR16MB2360 X-OriginatorOrg: mcafee.com X-NAI-Spam-Flag: NO X-NAI-Spam-Level: X-NAI-Spam-Threshold: 15 X-NAI-Spam-Score: 0.2 X-NAI-Spam-Version: 2.3.0.9418 : core <6585> : inlines <7115> : streams <1826836> : uri <2865490> Archived-At: Subject: Re: [tram] =?utf-8?q?=C3=89ric_Vyncke=27s_No_Objection_on_draft-ietf?= =?utf-8?q?-tram-turnbis-27=3A_=28with_COMMENT=29?= X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.29 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 Jul 2019 09:00:59 -0000 SGkgRXJpYywNCg0KUGxlYXNlIHNlZSBpbmxpbmUNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2Ut LS0tLQ0KPiBGcm9tOiBFcmljIFZ5bmNrZSAoZXZ5bmNrZSkgPGV2eW5ja2VAY2lzY28uY29tPg0K PiBTZW50OiBUdWVzZGF5LCBKdWx5IDksIDIwMTkgMjo0OSBBTQ0KPiBUbzogS29uZGEsIFRpcnVt YWxlc3dhciBSZWRkeQ0KPiA8VGlydW1hbGVzd2FyUmVkZHlfS29uZGFATWNBZmVlLmNvbT47IFRo ZSBJRVNHIDxpZXNnQGlldGYub3JnPg0KPiBDYzogdHJhbS1jaGFpcnNAaWV0Zi5vcmc7IGRyYWZ0 LWlldGYtdHJhbS10dXJuYmlzQGlldGYub3JnOyB0cmFtQGlldGYub3JnOw0KPiBicmFuZG9uLndp bGxpYW1zQGFrYW1haS5jb20NCj4gU3ViamVjdDogUmU6IFt0cmFtXSDDiXJpYyBWeW5ja2UncyBO byBPYmplY3Rpb24gb24gZHJhZnQtaWV0Zi10cmFtLXR1cm5iaXMtMjc6DQo+ICh3aXRoIENPTU1F TlQpDQo+IA0KPiBUaGlzIGVtYWlsIG9yaWdpbmF0ZWQgZnJvbSBvdXRzaWRlIG9mIHRoZSBvcmdh bml6YXRpb24uIERvIG5vdCBjbGljayBsaW5rcyBvcg0KPiBvcGVuIGF0dGFjaG1lbnRzIHVubGVz cyB5b3UgcmVjb2duaXplIHRoZSBzZW5kZXIgYW5kIGtub3cgdGhlIGNvbnRlbnQgaXMNCj4gc2Fm ZS4NCj4gDQo+IFRpcnUNCj4gDQo+IFRoYW5rIHlvdSBmb3IgeW91ciByZXBseSBhbmQgeW91ciBj b21tZW50cyBhbmQgYWN0aW9ucy4NCj4gDQo+IFBsZWFzZSBzZWUgcmVtYWluaW5nIHBvaW50cyBp bmxpbmUgZm9yIGxpbmVzIHN0YXJ0aW5nIHdpdGggRVY+DQo+IA0KPiBSZWdhcmRzDQo+IA0KPiAt w6lyaWMNCj4gDQo+IO+7v09uIDA4LzA3LzIwMTksIDE1OjU1LCAiS29uZGEsIFRpcnVtYWxlc3dh ciBSZWRkeSINCj4gPFRpcnVtYWxlc3dhclJlZGR5X0tvbmRhQE1jQWZlZS5jb20+IHdyb3RlOg0K PiANCj4gICAgIEhpIEVyaWMsDQo+IA0KPiAgICAgVGhhbmtzIGZvciB0aGUgcmV2aWV3LiBQbGVh c2Ugc2VlIGlubGluZQ0KPiANCj4gICAgID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4g ICAgID4gRnJvbTogdHJhbSA8dHJhbS1ib3VuY2VzQGlldGYub3JnPiBPbiBCZWhhbGYgT2Ygw4ly aWMgVnluY2tlIHZpYQ0KPiAgICAgPiBEYXRhdHJhY2tlcg0KPiAgICAgPiBTZW50OiBTdW5kYXks IEp1bHkgNywgMjAxOSAxOjQ5IFBNDQo+ICAgICA+IFRvOiBUaGUgSUVTRyA8aWVzZ0BpZXRmLm9y Zz4NCj4gICAgID4gQ2M6IHRyYW0tY2hhaXJzQGlldGYub3JnOyBkcmFmdC1pZXRmLXRyYW0tdHVy bmJpc0BpZXRmLm9yZzsgdHJhbUBpZXRmLm9yZzsNCj4gICAgID4gYnJhbmRvbi53aWxsaWFtc0Bh a2FtYWkuY29tDQo+ICAgICA+IFN1YmplY3Q6IFt0cmFtXSDDiXJpYyBWeW5ja2UncyBObyBPYmpl Y3Rpb24gb24gZHJhZnQtaWV0Zi10cmFtLXR1cm5iaXMtMjc6DQo+ICAgICA+ICh3aXRoIENPTU1F TlQpDQo+ICAgICA+DQo+IA0KPiAgICAgPiBGb3IgbXkgb3duIGN1cmlvc2l0eSwgaXNuJ3QgVFVS TiBzY29wZSBicm9hZGVyIHRoYW4gcGxhaW4gTkFUOiBjYW4gaXQgYWxzbw0KPiBiZQ0KPiAgICAg PiB1c2VmdWwgaW4gdGhlIGFic2VuY2Ugb2YgTkFUIGlmIGluYm91bmQgJ2Nvbm5lY3Rpb24nIGFy ZSBibG9ja2VkIGJ5DQo+IHNlY3VyaXR5DQo+ICAgICA+IHBvbGljeSA/DQo+IA0KPiAgICAgSW50 ZXJhY3RpdmUgQ29ubmVjdGl2aXR5IEVzdGFibGlzaG1lbnQgKElDRSkgaGVscHMgc29sdmUgdGhl IGFib3ZlIHByb2JsZW0NCj4gYnkgcGVyZm9ybWluZyBjb25uZWN0aXZpdHkgY2hlY2tzLCBidXQg ZGlyZWN0IFVEUCBjb25uZWN0aW9uIHdpbGwgbm90IGJlDQo+IHBvc3NpYmxlIGV2ZW4gd2l0aCBJ Q0UgaWYgYm90aCBlbmRwb2ludHMgYXJlIGJlaGluZCBOQVRzIHRoYXQgcGVyZm9ybQ0KPiBhZGRy ZXNzIGFuZCBwb3J0IGRlcGVuZGVudCBtYXBwaW5nLiBJbiBhZGRpdGlvbiwgRW50ZXJwcmlzZSBm aXJld2FsbCBtYXkNCj4gYmxvY2sgZGlyZWN0IFVEUCBjb25uZWN0aW9ucyBidXQgYWxsb3cgVURQ IHRyYWZmaWMgcmVsYXllZCB0aHJvdWdoIGFuDQo+IEVudGVycHJpc2UgVFVSTiBzZXJ2ZXIgKHBs ZWFzZSBzZWUNCj4gaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzc0Nzgjc2VjdGlvbi0y LjMuNS4xKS4NCj4gDQo+IEVWPiBJIGFtIGZhbWlsaWFyIHdpdGggSUNFIF9fIGFuZCB5b3VyIGxh c3Qgc2VudGVuY2UgaXMgZXhhY3RseSB3aGF0IG15IGluaXRpYWwNCj4gY29tbWVudCB3YXMgYWJv dXQ6IHBsZWFzZSBnb2VzIGJleW9uZCB0aGUgTkFUIHR5cGljYWwvY29tbW9uIHVzZSBjYXNlDQo+ IG9mIFRVUk4gYW5kIGFsc28gY2l0ZSB0aGUgZmlyZXdhbGwgYmxvY2tpbmcgaW5ib3VuZCBVRFAu IEp1c3QgdG8gaW1wcm92ZQ0KPiB1bmRlcnN0YW5kaW5nIGJ5IHRoZSByZWFkZXJzLg0KDQpTdXJl LCBhZGRlZCB0aGUgZm9sbG93aW5nIHBhcmFncmFwaCB0byB0aGUgSW50cm9kdWN0aW9uIHNlY3Rp b24gOg0KDQogICBJbiBtYW55IGVudGVycHJpc2UgbmV0d29ya3MsIGRpcmVjdCBVRFAgdHJhbnNt aXNzaW9ucyBhcmUgbm90DQogICBwZXJtaXR0ZWQgYmV0d2VlbiBjbGllbnRzIG9uIHRoZSBpbnRl cm5hbCBuZXR3b3JrcyBhbmQgZXh0ZXJuYWwgSVANCiAgIGFkZHJlc3Nlcy4gIFRvIHBlcm1pdCBt ZWRpYSBzZXNzaW9ucyBpbiBzdWNoIGEgc2l0dWF0aW9uIHRvIHVzZSBVRFANCiAgIGFuZCB0byBh dm9pZCBmb3JjaW5nIHRoZSBtZWRpYSBzZXNzaW9ucyB0aHJvdWdoIFRDUCwgRW50ZXJwcmlzZQ0K ICAgRmlyZXdhbGwgY2FuIGJlIGNvbmZpZ3VyZWQgdG8gYWxsb3cgVURQIHRyYWZmaWMgcmVsYXll ZCB0aHJvdWdoIGFuDQogICBFbnRlcnByaXNlIHJlbGF5IHNlcnZlci4gIFRoaXMgc2NlbmFyaW8g aXMgcmVxdWlyZWQgdG8gYmUgc3VwcG9ydGVkDQogICBieSB0aGUgV2ViUlRDIHJlcXVpcmVtZW50 cyAoU2VjdGlvbiAyLjMuNS4xIGluIFtSRkM3NDc4XSkuDQoNCg0KPiANCj4gICAgID4NCj4gICAg ID4gPT0gQ09NTUVOVFMgPT0NCj4gPg0KPiAgICAgPiAtLSBTZWN0aW9uIDMuMSAtLQ0KPiAgICAg Pg0KPiAgICAgPiBJcyB0aGVyZSBhbnkgcmVhc29uIHdoeSBNUFRDUCBpcyBub3Qgc3BlY2lmaWVk IGZvciB0aGUgY29tbXVuaWNhdGlvbg0KPiAgICAgPiBiZXR3ZWVuIFRVUk4gY2xpZW50IGFuZCBU VVJOIHNlcnZlcj8gVGhlcmUgaXMgYSB2ZXJ5IHNob3J0IGV4cGxhbmF0aW9uDQo+IGluDQo+ICAg ICA+IHNlY3Rpb24gMTUgIlRDUCBtdWx0aS1wYXRoIGlzIG5vdCB1c2VkIGJ5IGJvdGggU0lQIGFu ZCBXZWJSVEMgcHJvdG9jb2xzDQo+ICAgICA+IFtSRkM3NDc4XSBmb3IgbWVkaWEgYW5kIG5vbi1t ZWRpYSBkYXRhIiBidXQgaXQgZG9lcyBub3QgYWRkcmVzcyB0aGUgdXNlDQo+IG9mDQo+ICAgICA+ IE1QVENQIGJldHdlZW4gVFVSTiBjbGllbnQvc2VydmVyLg0KPiANCj4gICAgIFRVUk4gaXMgdHlw aWNhbGx5IHVzZWQgYnkgU0lQIGFuZCBXZWJSVEMgcHJvdG9jb2xzIHRvIHJlbGF5IG1lZGlhIHN0 cmVhbXMsDQo+IGJ1dCBSVFAgYXNzdW1lcyBhIHNpbmdsZSBwYXRoIGFuZCBtYWtlIGRlY2lzaW9u cyBiYXNlZCBvbiB0aGUgbWVhc3VyZWQNCj4gY2hhcmFjdGVyaXN0aWNzIG9mIHRoaXMgc2luZ2xl IHBhdGggKHdpdGggdGhlIGV4Y2VwdGlvbiBvZiBNdWx0aXBhdGggUlRQDQo+IGRpc2N1c3NlZCBp biBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1hdnRjb3JlLW1wcnRwLTAz KS4NCj4gDQo+IEVWPiBzdWdnZXN0IHRvIGFkZCBhbiBpbmZvcm1hdGl2ZSByZWZlcmVuY2UgdG8g dGhlIEktRA0KDQpkcmFmdC1pZXRmLWF2dGNvcmUtbXBydHAgaGFzIGV4cGlyZWQgY291cGxlIG9m IHllYXJzIGJhY2suIEkgZG9uJ3QgdGhpbmsgYSByZWZlcmVuY2UgdG8gTVBSVFAgaXMgcmVxdWly ZWQuDQoNCj4gDQo+ICAgICA+DQo+ICAgICA+IC0tIFNlY3Rpb24gMy43IC0tDQo+ICAgICA+DQo+ ICAgICA+IFRoZSA1MDAgYnl0ZXMgZ3VpZGVsaW5lIHRvIGF2b2lkIGZyYWdtZW50YXRpb24sIGlz IHRoZXJlIGFueSBkYXRhIGJhY2tpbmcNCj4gdGhlDQo+ICAgICA+IHNlbnRlbmNlICIuLi53aWxs IGdlbmVyYWxseSBhdm9pZCBJUCBmcmFnbWVudGF0aW9uLiIgPw0KPiANCj4gICAgIFllcywgSWYg dGhlIFBNVFUgaXMgbm90IGtub3duLCBhbmQgb24gbGVnYWN5IG9yIG90aGVyd2lzZSB1bnVzdWFs DQo+IG5ldHdvcmtzIHRoZSBndWlkZWxpbmUgc2hvdWxkIHdvcmsgKHNlZQ0KPiBodHRwczovL3Rv b2xzLmlldGYub3JnL2h0bWwvcmZjNzI1MiNzZWN0aW9uLTQuNiBhbmQNCj4gaHR0cHM6Ly90b29s cy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtdHN2d2ctZGF0YWdyYW0tcGxwbXR1ZC0wOCkuDQo+ IA0KPiBFVj4gUkZDIDcyNTIgaXMgYWJvdXQgQ29BUCBhbmQgaXMgbm90ICJhIGd1aWRlbGluZSIg cGVyIHNlIGJ1dCBhIHJlZmVyZW5jZSB0bw0KPiB0aGUgSVB2NCAnYXNzdW1lZCcgTVRVIG9mIDU3 Ni4gSSB3b3VsZCBwcmVmZXIgYSByZWZlcmVuY2UgdG8gUkZDIDcyNTIgd2l0aA0KPiA1NzYgZm9y IElQdjQgYW5kIDEyODAgZm9yIElQdjYgZm9yIE1UVS4gSSBhbSBhZnJhaWQgdGhhdCBnaXZpbmcg dGhlIG51bWJlcg0KPiAiNTAwIiBpcyBraW5kIG9mIG1pc2xlYWRpbmcgdGhlIHJlYWRlci4gQXQg dGhlIGJhcmUgbWluaW11bSwgSSBzdWdnZXN0IHRvIGFkZA0KPiB0aGUgcmVmZXJlbmNlIHRvIENP QVAsIGFuZCB1c2UgdGhlIG51bWJlciBmcm9tIENvQVAgaWYgeW91IHdhbnQgdG8NCj4gc3BlY2lm eSBudW1iZXJzLg0KDQpUaGUgYWJvdmUgSVB2NC9JUHY2IG51bWJlcnMgYXJlIHVzZWQgaW4gc2V2 ZXJhbCBvdGhlciBzcGVjaWZpY2F0aW9ucyBieSBvbmx5IHJlZmVycmluZyB0byBbUkZDNzkxXSBh bmQgW1JGQzExMjJdLCBmb3IgZXhhbXBsZSBzZWUgU0lHLTAwMiBpbiBodHRwczovL3Rvb2xzLmll dGYub3JnL2h0bWwvcmZjODYxMiANCg0KQ2hlZXJzLA0KLVRpcnUNCg0KPiANCj4gDQo+IA0KDQo= From nobody Tue Jul 9 02:21:17 2019 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 049F31203E9; Tue, 9 Jul 2019 02:21:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mcafee.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Frq2qhWPy4uh; Tue, 9 Jul 2019 02:21:13 -0700 (PDT) Received: from DNVWSMAILOUT1.mcafee.com (dnvwsmailout1.mcafee.com [161.69.31.173]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9831E1203E8; Tue, 9 Jul 2019 02:21:12 -0700 (PDT) X-NAI-Header: Modified by McAfee Email Gateway (5500) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mcafee.com; s=s_mcafee; t=1562663436; h=From: To:CC:Subject:Thread-Topic:Thread-Index:Date: Message-ID:References:In-Reply-To:Accept-Language: Content-Language:X-MS-Has-Attach:X-MS-TNEF-Correlator: dlp-product:dlp-version:dlp-reaction:authentication-results: x-originating-ip:x-ms-publictraffictype:x-ms-office365-filtering-correlation-id: x-microsoft-antispam:x-ms-traffictypediagnostic: x-ms-exchange-purlcount:x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers:x-forefront-prvs: x-forefront-antispam-report:received-spf:x-ms-exchange-senderadcheck: x-microsoft-antispam-message-info:Content-Type: Content-Transfer-Encoding:MIME-Version:X-MS-Exchange-CrossTenant-Network-Message-Id: X-MS-Exchange-CrossTenant-originalarrivaltime: X-MS-Exchange-CrossTenant-fromentityheader: X-MS-Exchange-CrossTenant-id:X-MS-Exchange-CrossTenant-mailboxtype: X-MS-Exchange-CrossTenant-userprincipalname: X-MS-Exchange-Transport-CrossTenantHeadersStamped: X-OriginatorOrg:X-NAI-Spam-Flag:X-NAI-Spam-Level: X-NAI-Spam-Threshold:X-NAI-Spam-Score:X-NAI-Spam-Version; bh=DgMZvfl+6M0bE6Y9qnzWbFBWogb9aqxWYKduxw bCD7M=; b=N6Rc2Fo414G9TxFPGvUdWlR2TVwUAYGIv9akyz23 HVpeycdbdRyDK/LhVmwNKUho0kLiYktPTlOzxyBAvyXQYvdZU8 7N9Lej8Bo73jAHxECAC9m7/0a6PqHPu1a4nf6FXv5C238DpUIg BBbg5vnVlrIRMkASWjmnj7abfbK9r2c= Received: from DNVEXAPP1N05.corpzone.internalzone.com (unknown [10.44.48.89]) by DNVWSMAILOUT1.mcafee.com with smtp (TLS: TLSv1/SSLv3,256bits,ECDHE-RSA-AES256-SHA384) id 23c0_ba09_d983f600_9732_4dac_a1a4_f06134271c5b; Tue, 09 Jul 2019 03:10:35 -0600 Received: from DNVEXAPP1N05.corpzone.internalzone.com (10.44.48.89) by DNVEXAPP1N05.corpzone.internalzone.com (10.44.48.89) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Tue, 9 Jul 2019 03:20:37 -0600 Received: from DNVO365EDGE2.corpzone.internalzone.com (10.44.176.74) by DNVEXAPP1N05.corpzone.internalzone.com (10.44.48.89) with Microsoft SMTP Server (TLS) id 15.0.1395.4 via Frontend Transport; Tue, 9 Jul 2019 03:20:37 -0600 Received: from NAM03-BY2-obe.outbound.protection.outlook.com (10.44.176.241) by edge.mcafee.com (10.44.176.74) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Tue, 9 Jul 2019 03:20:36 -0600 Received: from DM5PR16MB1705.namprd16.prod.outlook.com (10.172.44.147) by DM5PR16MB2389.namprd16.prod.outlook.com (52.132.143.10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2052.17; Tue, 9 Jul 2019 09:20:36 +0000 Received: from DM5PR16MB1705.namprd16.prod.outlook.com ([fe80::570:2208:75c2:5f17]) by DM5PR16MB1705.namprd16.prod.outlook.com ([fe80::570:2208:75c2:5f17%8]) with mapi id 15.20.2052.019; Tue, 9 Jul 2019 09:20:36 +0000 From: "Konda, Tirumaleswar Reddy" To: Magnus Westerlund , "iesg@ietf.org" , "evyncke@cisco.com" CC: "tram@ietf.org" , "brandon.williams@akamai.com" , "tram-chairs@ietf.org" , "draft-ietf-tram-turnbis@ietf.org" Thread-Topic: =?utf-8?B?W3RyYW1dICDDiXJpYyBWeW5ja2UncyBObyBPYmplY3Rpb24gb24gZHJhZnQt?= =?utf-8?Q?ietf-tram-turnbis-27:_(with_COMMENT)?= Thread-Index: AQHVNi3IZIYvEl7BokaSxtNPnPUXBKbB+V8g Date: Tue, 9 Jul 2019 09:20:36 +0000 Message-ID: References: <156248752430.14312.15895119889558390147.idtracker@ietfa.amsl.com> <4e999e5ae34e102ab5ca3a65c1b11a88647b5667.camel@ericsson.com> In-Reply-To: <4e999e5ae34e102ab5ca3a65c1b11a88647b5667.camel@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.3.0.16 dlp-reaction: no-action authentication-results: spf=none (sender IP is ) smtp.mailfrom=TirumaleswarReddy_Konda@McAfee.com; x-originating-ip: [103.245.47.20] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: c99bf8ba-c78e-4a99-6049-08d7044eb393 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:DM5PR16MB2389; x-ms-traffictypediagnostic: DM5PR16MB2389: x-ms-exchange-purlcount: 4 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0093C80C01 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(396003)(376002)(346002)(39860400002)(136003)(366004)(189003)(32952001)(199004)(13464003)(229853002)(316002)(7736002)(486006)(2906002)(71190400001)(71200400001)(74316002)(256004)(14444005)(305945005)(54906003)(11346002)(186003)(476003)(446003)(68736007)(81166006)(33656002)(2201001)(86362001)(8936002)(110136005)(6436002)(6246003)(76116006)(2501003)(80792005)(3846002)(99286004)(6116002)(66066001)(6506007)(102836004)(76176011)(25786009)(7696005)(966005)(53546011)(4326008)(478600001)(72206003)(52536014)(81156014)(66946007)(66476007)(64756008)(5660300002)(66556008)(224303003)(26005)(66446008)(55016002)(14454004)(73956011)(53936002)(6306002)(9686003)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR16MB2389; H:DM5PR16MB1705.namprd16.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: McAfee.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: fvtCG2Qxl6gt8x/6T/oGNEiFjS5aB9SiaAH9yjcxA2GakGh8FL+TPGfwwwkXewHl5NaXhxUctOTI973jvWpT+2iD7zUnThpRHBVo27YJKaT6SETqGzfzx10/WZbvSu6TDn+CuAsCxHe968ZKI/MwgNbcCOoFlTNgjWg7V6DT0id/qrD92zOIYssIvwxbUi649d9NQqO8IZJLENPki0IMbMgme/6XKUQuX7aTTilu+KtLYYpXJxZFMCjkrgIp2o3op4/X7/9hIh15UEuJSo+LryIZhB4bvx+14YBxYDktNteFHacTpQzQ4FPGHbrSUHHs1wdEwqCV5gMPeEeatY82D9F1aXF86lmMe0CShdAPWE9hCdZ+UOaFQ1+EnNfDH4KOf2zwAiFuNhvyjCWVQCrB+jAG1ZBYKj6eZ5DLdMtUsD8= Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: c99bf8ba-c78e-4a99-6049-08d7044eb393 X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Jul 2019 09:20:36.0923 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: TirumaleswarReddy_Konda@McAfee.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR16MB2389 X-OriginatorOrg: mcafee.com X-NAI-Spam-Flag: NO X-NAI-Spam-Level: X-NAI-Spam-Threshold: 15 X-NAI-Spam-Score: 0.2 X-NAI-Spam-Version: 2.3.0.9418 : core <6585> : inlines <7115> : streams <1826837> : uri <2865497> Archived-At: Subject: Re: [tram] =?utf-8?q?=C3=89ric_Vyncke=27s_No_Objection_on_draft-ietf?= =?utf-8?q?-tram-turnbis-27=3A_=28with_COMMENT=29?= X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.29 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 Jul 2019 09:21:16 -0000 SGkgTWFnbnVzLA0KDQpQbGVhc2Ugc2VlIGlubGluZSANCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3Nh Z2UtLS0tLQ0KPiBGcm9tOiBNYWdudXMgV2VzdGVybHVuZCA8bWFnbnVzLndlc3Rlcmx1bmRAZXJp Y3Nzb24uY29tPg0KPiBTZW50OiBUdWVzZGF5LCBKdWx5IDksIDIwMTkgMTo0MCBQTQ0KPiBUbzog aWVzZ0BpZXRmLm9yZzsgS29uZGEsIFRpcnVtYWxlc3dhciBSZWRkeQ0KPiA8VGlydW1hbGVzd2Fy UmVkZHlfS29uZGFATWNBZmVlLmNvbT47IGV2eW5ja2VAY2lzY28uY29tDQo+IENjOiB0cmFtQGll dGYub3JnOyBicmFuZG9uLndpbGxpYW1zQGFrYW1haS5jb207IHRyYW0tY2hhaXJzQGlldGYub3Jn Ow0KPiBkcmFmdC1pZXRmLXRyYW0tdHVybmJpc0BpZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTogW3Ry YW1dIMOJcmljIFZ5bmNrZSdzIE5vIE9iamVjdGlvbiBvbiBkcmFmdC1pZXRmLXRyYW0tdHVybmJp cy0yNzoNCj4gKHdpdGggQ09NTUVOVCkNCj4gDQo+IEhpLA0KPiANCj4gQSBjb21tZW50IGlubGlu ZSByZWdhcmRpbmcgTVAtVENQLg0KPiANCj4gDQo+IE9uIE1vbiwgMjAxOS0wNy0wOCBhdCAyMTox OSArMDAwMCwgRXJpYyBWeW5ja2UgKGV2eW5ja2UpIHdyb3RlOg0KPiA+IFRpcnUNCj4gPg0KPiA+ IFRoYW5rIHlvdSBmb3IgeW91ciByZXBseSBhbmQgeW91ciBjb21tZW50cyBhbmQgYWN0aW9ucy4N Cj4gPg0KPiA+IFBsZWFzZSBzZWUgcmVtYWluaW5nIHBvaW50cyBpbmxpbmUgZm9yIGxpbmVzIHN0 YXJ0aW5nIHdpdGggRVY+DQo+ID4NCj4gPiBSZWdhcmRzDQo+ID4NCj4gPiAtw6lyaWMNCj4gPg0K PiA+IO+7v09uIDA4LzA3LzIwMTksIDE1OjU1LCAiS29uZGEsIFRpcnVtYWxlc3dhciBSZWRkeSIg PA0KPiA+IFRpcnVtYWxlc3dhclJlZGR5X0tvbmRhQE1jQWZlZS5jb20+IHdyb3RlOg0KPiA+DQo+ ID4NCj4gPiAgICAgPg0KPiA+ICAgICA+ID09IENPTU1FTlRTID09DQo+ID4gPg0KPiA+DQo+ID4g ICAgID4gLS0gU2VjdGlvbiAzLjEgLS0NCj4gPiAgICAgPg0KPiA+ICAgICA+IElzIHRoZXJlIGFu eSByZWFzb24gd2h5IE1QVENQIGlzIG5vdCBzcGVjaWZpZWQgZm9yIHRoZQ0KPiA+IGNvbW11bmlj YXRpb24NCj4gPiAgICAgPiBiZXR3ZWVuIFRVUk4gY2xpZW50IGFuZCBUVVJOIHNlcnZlcj8gVGhl cmUgaXMgYSB2ZXJ5IHNob3J0DQo+ID4gZXhwbGFuYXRpb24gaW4NCj4gPiAgICAgPiBzZWN0aW9u IDE1ICJUQ1AgbXVsdGktcGF0aCBpcyBub3QgdXNlZCBieSBib3RoIFNJUCBhbmQgV2ViUlRDDQo+ ID4gcHJvdG9jb2xzDQo+ID4gICAgID4gW1JGQzc0NzhdIGZvciBtZWRpYSBhbmQgbm9uLW1lZGlh IGRhdGEiIGJ1dCBpdCBkb2VzIG5vdCBhZGRyZXNzDQo+ID4gdGhlIHVzZSBvZg0KPiA+ICAgICA+ IE1QVENQIGJldHdlZW4gVFVSTiBjbGllbnQvc2VydmVyLg0KPiA+DQo+ID4gICAgIFRVUk4gaXMg dHlwaWNhbGx5IHVzZWQgYnkgU0lQIGFuZCBXZWJSVEMgcHJvdG9jb2xzIHRvIHJlbGF5IG1lZGlh DQo+ID4gc3RyZWFtcywgYnV0IFJUUCBhc3N1bWVzIGEgc2luZ2xlIHBhdGggYW5kIG1ha2UgZGVj aXNpb25zIGJhc2VkIG9uDQo+ID4gdGhlIG1lYXN1cmVkIGNoYXJhY3RlcmlzdGljcyBvZiB0aGlz IHNpbmdsZSBwYXRoICh3aXRoIHRoZSBleGNlcHRpb24NCj4gPiBvZiBNdWx0aXBhdGggUlRQIGRp c2N1c3NlZCBpbg0KPiA+IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWF2 dGNvcmUtbXBydHAtMDMpLg0KPiA+DQo+ID4gRVY+IHN1Z2dlc3QgdG8gYWRkIGFuIGluZm9ybWF0 aXZlIHJlZmVyZW5jZSB0byB0aGUgSS1EDQo+IA0KPiBTbyBvbiB0aGUgY2xpZW50IHRvIHNlcnZl ciBwYXRoIHRoZXJlIGlzIGEgcG9zc2liaWxpdHkgdG8gdXNlIE1QLVRDUCB0bw0KPiBwb3RlbnRp YWxseSBpbXByb3ZlIHRoYXQgc3BlY2lmaWMgbGVnIG9mIHRoZSBjb21tdW5pY2F0aW9uLiBJdCBj YW4gYmUNCj4gbmVnb3RpYXRlZCBpbiB0aGUgVENQIGNvbm5lY3Rpb24gaWYgZGVzaXJlZC4gSG93 ZXZlciwgdG8gYmUgY2xlYXIgSQ0KPiBkb24ndCB0aGluayB0aGVyZSBpcyBhIHJlYXNvbiB0byBy ZWNvbW1lbmQgYW5kIGRlZmluaXRlbHkgbm90IG1hbmRhdGUNCj4gTVAtVENQIHN1cHBvcnQgaWYg b25lIHN1cHBvcnRzIHRoZSBUQ1AgdHJhbnNwb3J0IGluIHRoZSBjbGllbnQgdG8NCj4gc2VydmVy IGludGVyZmFjZS4gQWxzbyBpdCBjcmVhdGVzIGEgcG90ZW50aWFsbHkgaW50ZXJlc3RpbmcNCj4g aW50ZXJhY3Rpb25zIGJldHdlZW4gdGhlIGZyYW1ld29yayB1c2luZyBUVVJOLCBsaWtlIElDRSB3 aGVuIGEgbW9iaWxpdHkNCj4gZXZlbnRzIGhhcHBlbi4gSXQgbWF5IGFsc28gcmVzdWx0IGluIHN1 Yi1vcHRpbWFsIHJvdXRpbmcgaW4gY2FzZXMgd2hlcmUNCj4gYSBjbGllbnQgc2VsZWN0cyB0byB1 c2UgbXVsdGlwbGUgaW50ZXJmYWNlcyB0byBoYXZlIG9uZSBNUC1UQ1ANCj4gY29ubmVjdGlvbiB0 byBvbmUgVFVSTiBzZXJ2ZXIsIHJhdGhlciB0aGFuIHRoZSBiZXN0IFRVUk4gc2VydmVyIHBlcg0K PiBpbnRlcmZhY2UuDQo+IA0KPiBBbHNvLCBJIHRoaW5rIGRpc2N1c3NpbmcgTVAtUlRQIGhlcmUg aXMgbWlzc2xlYWRpbmcuIEJlY2F1c2Ugd2l0aCBNUC0NCj4gUlRQIEkgd291bGQgdHJlYXQgdGhl IFRVUk4gcmVsYXllZCBhZGRyZXNzIGFzIG9uZSBwYXJ0aWN1bGFyIHBvaW50IG9mDQo+IHByZXNl bmNlIGZvciB0aGUgVFVSTiBjbGllbnQgc2lkZSBpbXBsZW1lbnRhdGlvbiwgaW4gYWRkaXRpb24g dG8gYW55DQo+IGRpcmVjdCBmcm9tIHRoZSBjb3JyZXNwb25kaW5nIGludGVyZmFjZSB0aGF0IG1h eSBiZSBwb3NzaWJsZSB0bw0KPiBlc3RhYmxpc2guIFRoZXJlIGFyZSBzb21lIGRpc2N1c3Npb24g b2YgdGhpcyBpbiB0aGUgTVAtUlRQIGRyYWZ0Lg0KPiANCj4gU28gaXQgd291bGQgYmUgcG9zc2li bGUgdG8gc3RhdGUgdGhhdCBhbiBUVVJOIGNsaWVudCBNQVkgYXR0ZW1wdCB0bw0KPiBuZWdvdGlh dGUgTVAtVENQIHdpdGggdGhlIFRVUk4gc2VydmVyIGJ1dCBzdXBwb3J0IG9mIE1QLVRDUCBpbiBU VVJODQo+IHNlcnZlcnMgYXJlIE9QVElPTkFMLiBJbiBhZGRpdGlvbiBUVVJOIGNsaWVudHMgb24g aG9zdHMgd2l0aCBtdWx0aXBsZQ0KPiBpbnRlcmZhY2VzIGFuZCBhY2Nlc3MgdG8gbXVsdGlwbGUg VFVSTiBzZXJ2ZXJzIHNob3VsZCBjb25zaWRlciBpZiB0aGVyZQ0KPiBhcmUgY2VydGFpbiBpbnRl cmZhY2VzIGFuZCBUVVJOIHNlcnZlciBjb21iaW5hdGlvbnMgdGhhdCByZXN1bHRzIGluDQo+IHNo b3J0ZXIgcGF0aHMsIGFuZCB0aGVyZWZvcmUgY2FuIGJlbmVmaXQgZnJvbSB1c2luZyBtdWx0aXBs ZSBUVVJODQo+IHNlcnZlcnMsIGV2ZW4gaWYgdGhleSBjYW4gYmUgcmVhY2hlZCBmcm9tIG11bHRp cGxlIGludGVyZmFjZXMuDQoNCklmIHRoZSBob3N0IGhhcyBtdWx0aXBsZSBpbnRlcmZhY2VzIGFu ZCBkaXNjb3ZlcnMgbXVsdGlwbGUgVFVSTiBzZXJ2ZXJzLCBodHRwczovL3Rvb2xzLmlldGYub3Jn L2h0bWwvcmZjNzk4MiBkaXNjdXNzZXMgbWVjaGFuaXNtIHRvIGluZmx1ZW5jZSB0aGUgVFVSTiBz ZXJ2ZXIgc2VsZWN0aW9uLiBJIGNhbiBhZGQgdGhlIGZvbGxvd2luZyBsaW5lOg0KSWYgYSBob3N0 IHdpdGggbXVsdGlwbGUgaW50ZXJmYWNlcyBkaXNjb3ZlcnMgYSBUVVJOIHNlcnZlciBpbiBlYWNo IGludGVyZmFjZSwgdGhlIG1lY2hhbmlzbSBkZXNjcmliZWQgaW4gW1JGQzc5ODJdIGNhbiBiZSB1 c2VkIGJ5IHRoZSBUVVJOIGNsaWVudCB0byBpbmZsdWVuY2UgdGhlIFRVUk4gc2VydmVyIHNlbGVj dGlvbi4NCg0KLVRpcnUNCg0KPiANCj4gQ2hlZXJzDQo+IA0KPiANCj4gPg0KPiA+ICAgICA+DQo+ ID4gICAgID4gLS0gU2VjdGlvbiAzLjcgLS0NCj4gPiAgICAgPg0KPiA+ICAgICA+IFRoZSA1MDAg Ynl0ZXMgZ3VpZGVsaW5lIHRvIGF2b2lkIGZyYWdtZW50YXRpb24sIGlzIHRoZXJlIGFueQ0KPiA+ IGRhdGEgYmFja2luZyB0aGUNCj4gPiAgICAgPiBzZW50ZW5jZSAiLi4ud2lsbCBnZW5lcmFsbHkg YXZvaWQgSVAgZnJhZ21lbnRhdGlvbi4iID8NCj4gPg0KPiA+ICAgICBZZXMsIElmIHRoZSBQTVRV IGlzIG5vdCBrbm93biwgYW5kIG9uIGxlZ2FjeSBvciBvdGhlcndpc2UgdW51c3VhbA0KPiA+IG5l dHdvcmtzIHRoZSBndWlkZWxpbmUgc2hvdWxkIHdvcmsgKHNlZQ0KPiA+IGh0dHBzOi8vdG9vbHMu aWV0Zi5vcmcvaHRtbC9yZmM3MjUyI3NlY3Rpb24tNC42IGFuZA0KPiA+IGh0dHBzOi8vdG9vbHMu aWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXRzdndnLWRhdGFncmFtLXBscG10dWQtMDgpLg0KPiA+ DQo+ID4gRVY+IFJGQyA3MjUyIGlzIGFib3V0IENvQVAgYW5kIGlzIG5vdCAiYSBndWlkZWxpbmUi IHBlciBzZSBidXQgYQ0KPiA+IHJlZmVyZW5jZSB0byB0aGUgSVB2NCAnYXNzdW1lZCcgTVRVIG9m IDU3Ni4gSSB3b3VsZCBwcmVmZXIgYQ0KPiA+IHJlZmVyZW5jZSB0byBSRkMgNzI1MiB3aXRoIDU3 NiBmb3IgSVB2NCBhbmQgMTI4MCBmb3IgSVB2NiBmb3IgTVRVLiBJDQo+ID4gYW0gYWZyYWlkIHRo YXQgZ2l2aW5nIHRoZSBudW1iZXIgIjUwMCIgaXMga2luZCBvZiBtaXNsZWFkaW5nIHRoZQ0KPiA+ IHJlYWRlci4gQXQgdGhlIGJhcmUgbWluaW11bSwgSSBzdWdnZXN0IHRvIGFkZCB0aGUgcmVmZXJl bmNlIHRvIENPQVAsDQo+ID4gYW5kIHVzZSB0aGUgbnVtYmVyIGZyb20gQ29BUCBpZiB5b3Ugd2Fu dCB0byBzcGVjaWZ5IG51bWJlcnMuDQo+IA0KPiBJIHRoaW5rIEkgbW9zdGx5IGFncmVlIHdpdGgg RXJpYyBoZXJlLiBTbyA1NzYgaXMgYSByZWNvbW1lbmRhdGlvbiBvbg0KPiB0aGUgSVB2NCBtaW5p bWFsIHJlcXVpcmVkIHBhY2tldCBzaXplIHJlY2VwdGlvbiBjYXBhYmlsaXR5LiBUaGVuIHlvdQ0K PiBoYXZlIHN1YnRyYWN0ZWQgdGhlIG92ZXJoZWFkIGZvciBUVVJOIHJvdWdobHkuIEFuZCBzdGls bCA1NzYgYnl0ZXMgSVB2NA0KPiBwYWNrZXRzIG1heSBiZSBmcmFnbWVudGVkLCB0aGUgdHJ1ZSBt aW5pbWFsIHNpemUgaXMgNjggYnl0ZXMuIEFuZCB0aGUNCj4gdXNlIG9mIGFuIGFzc3VtcHRpb24g b2YgMTI4MCBtaW51cyBUVVJOIG92ZXJoZWFkIGlzIGFsbW9zdCBhcyBsaWtlbHkgdG8NCj4gbm90 IHJlc3VsdCBpbiBmcmFnbWVudGF0aW9uIGFzIDUwMCBieXRlcy4gQmVjYXN1ZSB0aGUgbmV0d29y a3MgdGhhdA0KPiB3aWxsIGhhdmUgaXNzdWVzIHdpdGggeW91ciAxMjAwIHBheWxvYWQgaXMgbGlr ZWx5IGdvaW5nIHRvIGhhdmUgaXNzdWVzDQo+IHdpdGggNTAwIGJ5dGVzIHRvby4gU28gZnJvbSBt eSBwZXJzcGVjdGl2ZSBnaXZpbmcgdGhhdCB2ZXJ5IGxvdw0KPiByZWNvbW1lbmRhdGlvbiBkb2Vz IG5vdCByZWZsZWN0IHRvZGF5J3MgbmV0d29yay4gQW5kIHRoZSBDT0FQDQo+IHJlY29tbWVuZGF0 aW9uIG9mIG1lZXRpbmcgNTc2IGJ5dGVzIHRvdGFsIGlzIGZvciBjb25zdHJhaW5lZCBkZXZpY2Vz DQo+IGFuZCB0aGVpciBsaW5rIGxheWVycy4gVFVSTidzIHByaW1hcnkgdXNlcnMgaW4gbWVkaWEg YXBwbGljYXRpb25zIGFyZQ0KPiBub3JtYWxseSBub3QgdGFyZ2V0aW5nIHRoYXQgdHlwZSBvZiBs aW5rIGxheWVycyB0aGF0IGhhcyBzdWNoIGEgbGltaXRlZA0KPiBNVFUuDQo+IA0KPiBDaGVlcnMN Cj4gDQo+IE1hZ251cyBXZXN0ZXJsdW5kDQo+IA0KPiANCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiBOZXR3 b3JrIEFyY2hpdGVjdHVyZSAmIFByb3RvY29scywgRXJpY3Nzb24gUmVzZWFyY2gNCj4gLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLQ0KPiBFcmljc3NvbiBBQiAgICAgICAgICAgICAgICAgfCBQaG9uZSAgKzQ2IDEwIDcx NDgyODcNCj4gVG9yc2hhbW5zZ2F0YW4gMjMgICAgICAgICAgIHwgTW9iaWxlICs0NiA3MyAwOTQ5 MDc5DQo+IFNFLTE2NCA4MCBTdG9ja2hvbG0sIFN3ZWRlbiB8IG1haWx0bzogbWFnbnVzLndlc3Rl cmx1bmRAZXJpY3Nzb24uY29tDQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0K From nobody Tue Jul 9 11:15:49 2019 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 C6CF3120968; Tue, 9 Jul 2019 11:15:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.5 X-Spam-Level: X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, 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 header.b=MH2XMesH; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=NzhqH5hL 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 FLGBLbg0kNKL; Tue, 9 Jul 2019 11:15:39 -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 3A488120946; Tue, 9 Jul 2019 11:15:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1482; q=dns/txt; s=iport; t=1562696139; x=1563905739; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=M2mY7g191DDu+jpEw4H0MombnwasXwYvGkOtYOVpHzw=; b=MH2XMesHLsRu2KAVef95cbFL5wY/53AEq94IQMyDE7awRNUR5nsXWrN5 tH0rDqFmRr+A+Ebij0mBnntsYm8Sm7XucQpwnZXhdsxk7OR2UpHu+kZiR oi8Js/mECM4mBVPHSS/3CRgGAruwdj9Re5LpcXEV3BzrEfohfxS9zHV98 c=; IronPort-PHdr: =?us-ascii?q?9a23=3AtSNfgBROIKAMolh5ZFPu8eCkntpsv++ubAcI9p?= =?us-ascii?q?oqja5Pea2//pPkeVbS/uhpkESXBdfA8/wRje3QvuigQmEG7Zub+FE6OJ1XH1?= =?us-ascii?q?5g640NmhA4RsuMCEn1NvnvOiEkDcJJV1JN9HCgOk8TE8H7NBXf?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0A1AAC62CRd/49dJa1mGwEBAQEDAQE?= =?us-ascii?q?BBwMBAQGBVQQBAQELAYFDJCwDgT8gBAsoCoQSg0cDjkuCNpdrgS4UgRADVAk?= =?us-ascii?q?BAQEMAQEtAgEBhEACF4IsIzYHDgEDAQEEAQECAQVthTwMhUsCAQMSEREMAQE?= =?us-ascii?q?3AQ8CAQgaAiYCAgIwFQULAgQBDQUigwCBawMdAQKhRQKBOIhgcYEygnkBAQW?= =?us-ascii?q?FAhiCEgmBDCgBi14XgUA/gTgME4JMPoQIJhYXgnMygiaOcJtmCQKCF5QFG5g?= =?us-ascii?q?AgyWKC5c+AgQCBAUCDgEBBYFXATCBWHAVZQGCQYJBN4M6ilNygSmNDgGBIAE?= =?us-ascii?q?B?= X-IronPort-AV: E=Sophos;i="5.63,471,1557187200"; d="scan'208";a="580127765" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 09 Jul 2019 18:15:37 +0000 Received: from XCH-ALN-007.cisco.com (xch-aln-007.cisco.com [173.36.7.17]) by rcdn-core-7.cisco.com (8.15.2/8.15.2) with ESMTPS id x69IFbJo012701 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 9 Jul 2019 18:15:37 GMT Received: from xhs-rcd-002.cisco.com (173.37.227.247) by XCH-ALN-007.cisco.com (173.36.7.17) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 9 Jul 2019 13:15:36 -0500 Received: from xhs-rtp-002.cisco.com (64.101.210.229) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 9 Jul 2019 13:15:35 -0500 Received: from NAM03-DM3-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Tue, 9 Jul 2019 14:15:33 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=M2mY7g191DDu+jpEw4H0MombnwasXwYvGkOtYOVpHzw=; b=NzhqH5hL2AjxzTnfmBCQ3SNfD4PPNihpttLgN1YCk446Vd/QaRX+KPKWzb7okZI50q352IXhVblU4hQPgOnhlNb5ysJqcA3MXGJxmH60zPTH7h4XFkXtJB7+KveU2Qjesk8COE5IEm/5uanuvH3lrt5jWKEJgw3BXIP6Ca+HLgc= Received: from MN2PR11MB4144.namprd11.prod.outlook.com (20.179.150.210) by MN2PR11MB4047.namprd11.prod.outlook.com (20.179.149.157) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2052.19; Tue, 9 Jul 2019 18:00:35 +0000 Received: from MN2PR11MB4144.namprd11.prod.outlook.com ([fe80::b179:dc88:3c29:4474]) by MN2PR11MB4144.namprd11.prod.outlook.com ([fe80::b179:dc88:3c29:4474%6]) with mapi id 15.20.2052.020; Tue, 9 Jul 2019 18:00:35 +0000 From: "Eric Vyncke (evyncke)" To: Magnus Westerlund , "iesg@ietf.org" , "TirumaleswarReddy_Konda@McAfee.com" CC: "tram-chairs@ietf.org" , "draft-ietf-tram-turnbis@ietf.org" , "tram@ietf.org" , "brandon.williams@akamai.com" Thread-Topic: =?utf-8?B?W3RyYW1dICDDiXJpYyBWeW5ja2UncyBObyBPYmplY3Rpb24gb24gZHJhZnQt?= =?utf-8?Q?ietf-tram-turnbis-27:_(with_COMMENT)?= Thread-Index: AQHVNi3EaeTMORFVP0eb2cYMMOxj2abCtZOA Date: Tue, 9 Jul 2019 18:00:34 +0000 Message-ID: <2C1E13AD-E40B-4C78-8751-A405E3B1DE8F@cisco.com> References: <156248752430.14312.15895119889558390147.idtracker@ietfa.amsl.com> <4e999e5ae34e102ab5ca3a65c1b11a88647b5667.camel@ericsson.com> In-Reply-To: <4e999e5ae34e102ab5ca3a65c1b11a88647b5667.camel@ericsson.com> Accept-Language: fr-BE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1a.0.190609 authentication-results: spf=none (sender IP is ) smtp.mailfrom=evyncke@cisco.com; x-originating-ip: [173.38.220.58] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 2b21bbed-30f9-4058-d07b-08d704975782 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:MN2PR11MB4047; x-ms-traffictypediagnostic: MN2PR11MB4047: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 0093C80C01 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(376002)(346002)(366004)(136003)(396003)(39860400002)(189003)(199004)(58126008)(4326008)(186003)(316002)(11346002)(224303003)(2906002)(256004)(26005)(486006)(6246003)(25786009)(110136005)(86362001)(478600001)(54906003)(68736007)(446003)(36756003)(2501003)(476003)(14454004)(71200400001)(33656002)(71190400001)(7736002)(6486002)(53936002)(3846002)(305945005)(6116002)(6512007)(66556008)(229853002)(2201001)(99286004)(76116006)(66066001)(81166006)(6506007)(81156014)(73956011)(5660300002)(66946007)(76176011)(102836004)(64756008)(66476007)(4744005)(91956017)(8936002)(66446008)(2616005)(6436002); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB4047; H:MN2PR11MB4144.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: Lf1uU+USEo3esq0wFQtAWqq5BD+2R3pmg4FM0VUP4JhcDJw8myZrRDHT7b0wY37i64r+gKPv+6rqCLLbsVlChwPTvx3BtIh4yEfBVwfLasrbfKDSrftLdg4hI4zZSPnwE3h0b0GpN0KM8X9Z5BCDIx3h1U/l2gx/sbjl5AY6b9YjXvtA9dFh7thRvKCbYGvQoZ6H+UjQw+DrHDHM9sIP74bIoaw0NKuWVkDk2Bg191Ju2hRavAZwbSL0QxXjdY+xaUfHka+XArNsRB5xJPzlqMgRNohYqkuAis2ZzRGukprpA/tspweyJaI/s/qDPwIYg24BB54/Mj5iJHMcTslw/Cxy+i1iOCByQuzYEUtLIUmimgXyseTWMlsgTdW9eZzTwxIGq2uUluNZYVVJF+pz1dPXw1Esl0qID2TVFiRW1CA= Content-Type: text/plain; charset="utf-8" Content-ID: <9CD81E90F9E97D48A66E84165465B34C@namprd11.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 2b21bbed-30f9-4058-d07b-08d704975782 X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Jul 2019 18:00:34.9439 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: evyncke@cisco.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB4047 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.17, xch-aln-007.cisco.com X-Outbound-Node: rcdn-core-7.cisco.com Archived-At: Subject: Re: [tram] =?utf-8?q?=C3=89ric_Vyncke=27s_No_Objection_on_draft-ietf?= =?utf-8?q?-tram-turnbis-27=3A_=28with_COMMENT=29?= X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.29 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 Jul 2019 18:15:42 -0000 TWFnbnVzLA0KDQpUaGFuayB5b3UgZm9yIHRoZSBhZGRlZCBpbmZvcm1hdGlvbiAmIGNvbW1lbnRz Og0KDQoNCu+7v09uIDA5LzA3LzIwMTksIDEwOjEwLCAiaWVzZyBvbiBiZWhhbGYgb2YgTWFnbnVz IFdlc3Rlcmx1bmQiIDxpZXNnLWJvdW5jZXNAaWV0Zi5vcmcgb24gYmVoYWxmIG9mIG1hZ251cy53 ZXN0ZXJsdW5kQGVyaWNzc29uLmNvbT4gd3JvdGU6DQoNCiAgICANCiAgICBTbyBvbiB0aGUgY2xp ZW50IHRvIHNlcnZlciBwYXRoIHRoZXJlIGlzIGEgcG9zc2liaWxpdHkgdG8gdXNlIE1QLVRDUCB0 bw0KICAgIHBvdGVudGlhbGx5IGltcHJvdmUgdGhhdCBzcGVjaWZpYyBsZWcgb2YgdGhlIGNvbW11 bmljYXRpb24uIEl0IGNhbiBiZQ0KICAgIG5lZ290aWF0ZWQgaW4gdGhlIFRDUCBjb25uZWN0aW9u IGlmIGRlc2lyZWQuIEhvd2V2ZXIsIHRvIGJlIGNsZWFyIEkNCiAgICBkb24ndCB0aGluayB0aGVy ZSBpcyBhIHJlYXNvbiB0byByZWNvbW1lbmQgYW5kIGRlZmluaXRlbHkgbm90IG1hbmRhdGUNCiAg ICBNUC1UQ1Agc3VwcG9ydCBpZiBvbmUgc3VwcG9ydHMgdGhlIFRDUCB0cmFuc3BvcnQgaW4gdGhl IGNsaWVudCB0bw0KICAgIHNlcnZlciBpbnRlcmZhY2UuIEFsc28gaXQgY3JlYXRlcyBhIHBvdGVu dGlhbGx5IGludGVyZXN0aW5nDQogICAgaW50ZXJhY3Rpb25zIGJldHdlZW4gdGhlIGZyYW1ld29y ayB1c2luZyBUVVJOLCBsaWtlIElDRSB3aGVuIGEgbW9iaWxpdHkNCiAgICBldmVudHMgaGFwcGVu LiBJdCBtYXkgYWxzbyByZXN1bHQgaW4gc3ViLW9wdGltYWwgcm91dGluZyBpbiBjYXNlcyB3aGVy ZQ0KICAgIGEgY2xpZW50IHNlbGVjdHMgdG8gdXNlIG11bHRpcGxlIGludGVyZmFjZXMgdG8gaGF2 ZSBvbmUgTVAtVENQDQogICAgY29ubmVjdGlvbiB0byBvbmUgVFVSTiBzZXJ2ZXIsIHJhdGhlciB0 aGFuIHRoZSBiZXN0IFRVUk4gc2VydmVyIHBlcg0KICAgIGludGVyZmFjZS4gDQoNCkVWPiB0aGUg dXN1YWwgZGlzY3Vzc2lvbiBvbiB3aGljaCBsYXllciB0byBwcm92aWRlIG1vYmlsaXR5OiBsYXll ciAyLCBsYXllciAzLCBsYXllciA0IG9yIGluIHRoZSBhcHBsaWNhdGlvbiA7LSkNCg0KIA0KDQo= From nobody Tue Jul 9 13:31:16 2019 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 B324C12004F; Tue, 9 Jul 2019 13:30:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 6Nq6v59nuhvh; Tue, 9 Jul 2019 13:30:56 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 6AB8C120025; Tue, 9 Jul 2019 13:30:56 -0700 (PDT) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x69KUj20017200 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 9 Jul 2019 16:30:48 -0400 Date: Tue, 9 Jul 2019 15:30:45 -0500 From: Benjamin Kaduk To: "Konda, Tirumaleswar Reddy" Cc: Christopher Wood , "secdir@ietf.org" , "draft-ietf-tram-turnbis.all@ietf.org" , "ietf@ietf.org" , "tram@ietf.org" Message-ID: <20190709203044.GD24351@kduck.mit.edu> References: <156253133809.549.13521510978566357744@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [tram] Secdir last call review of draft-ietf-tram-turnbis-27 X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.29 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 Jul 2019 20:31:00 -0000 Chris, thanks for the review. Some more questions/comments inline as I prepare to ballot on this document... On Mon, Jul 08, 2019 at 02:18:26PM +0000, Konda, Tirumaleswar Reddy wrote: > Hi Christopher, > > Thanks for the detailed review. Please see inline > > > -----Original Message----- > > From: tram On Behalf Of Christopher Wood via > > Datatracker > > Sent: Monday, July 8, 2019 1:59 AM > > To: secdir@ietf.org > > Cc: draft-ietf-tram-turnbis.all@ietf.org; ietf@ietf.org; tram@ietf.org > > Subject: [tram] Secdir last call review of draft-ietf-tram-turnbis-27 > > > > This email originated from outside of the organization. Do not click links or > > open attachments unless you recognize the sender and know the content is > > safe. > > > > Reviewer: Christopher Wood > > Review result: Has Nits > > > > I have reviewed this document as part of the security directorate's ongoing > > effort to review all IETF documents being processed by the IESG. These > > comments were written primarily for the benefit of the security area > > directors. > > Document editors and WG chairs should treat these comments just like any > > other last call comments. > > > > The summary of the review is: Ready with nits > > > > Summary: > > > > In general, the document is well written and clearly founded in operational > > experience. The security considerations are thorough, providing examples > > where necessary to highlight important problem areas. It draws a clear line > > between issues best addressed by applications outside of TURN, and > > provides sufficient detail for those issues in scope. My comments and > > questions are, hopefully, mostly nits. > > > > General comments: > > > > - TURN server authentication in the case of (D)TLS is underspecified. Are > > servers assumed to have WebPKI certificates, OOB-trusted raw public keys, > > or something else? Is there a preferred form of authentication? > > Relatedly, in > > Section 3.2, how do clients authenticate the server? > > Server certificate validation is discussed in https://tools.ietf.org/html/draft-ietf-tram-stunbis-21#section-6.2.3. I have modified the text as follows: > > If (D)TLS transport is used between the TURN client and the TURN server, the cipher suites, > server certificate validation and authentication of TURN server are > discussed in Section 6.2.3 of [I-D.ietf-tram-stunbis] That helps, but it would still be nice to give some indication of what certificate PKI(s) are expected to be used. Is anything other than the Web PKI under consideration? > >- Section 3.7: Could > > TURN servers not chunk data from stream-oriented transports (TCP or TLS) > > to a preferred MTU size before relaying to peers? > > Specifically, there are likely > > some cases wherein the server could deal with the client data messages > > larger than the recommended 500B limit. On that point, should servers even > > accept data larger than this recommended size ? - > > Please see https://tools.ietf.org/html/draft-ietf-tram-turnbis-27#section-15 for TCP-to-UDP relay. If the PMTU is not known, and on legacy or otherwise unusual networks, > 500 byte limit for application data is recommended. > > > Section 3.9: There may be > > cases where the TLS connection post TCP connection establishment fails. It > > would therefore seems prudent to not declare victory for one connection > > over the other until TLS connects, too. - > > Agreed, Eric (as part of ISEG review) suggested to simplify the text. I have updated the text as follows: > > o For TCP or TLS-over-TCP, the results of the Happy Eyeballs > procedure [RFC8305] are used by the TURN client for sending its > TURN messages to the server. Is the editor's copy available for viewing somewhere? It would be good to see this (and other changes) in context. > > Section 3 could benefit from a > > subsection on replays and the nonce role. In particular, as later discussed in > > the security considerations, some of these attacks are not new to TURN and > > should therefore be dealt with by the application protocol (SRTP). This > > section might also describe nonce rotation policies with more specificity, as > > this is underspecified in the document. > > It is discussed in Section 5 in the specification, the server should expire the nonce at least once every hour during the lifetime of the allocation. > > >- Section 3 could also benefit from > > discussion about cleartext versus encryption transports between clients and > > servers. > > It is discussed in https://tools.ietf.org/html/draft-ietf-tram-turnbis-27#section-21.1.6. There's not much discussion about potential information leakage via (e.g.) USERNAME/USERHASH, and really just a claim that the peer address is the "primary protocol content". > > Encrypting the nonce, username, realm, etc., among other things, has > > obvious benefits. - Why are SOFTWARE and FINGERPRINT attributes > > recommended? It seems like clients should be discouraged from sending > > these if anything, especially if not used to make allocation decisions on the > > server. > > Username may not be the user identity, Please see https://tools.ietf.org/html/rfc7635), It could be an ephemeral and unique key identifier. Further, username can be anonymized (please see https://tools.ietf.org/html/draft-ietf-tram-stunbis-21#section-14.4). > SOFTWARE and FINGERPRINT attributes are defined in the STUN specification, see https://tools.ietf.org/html/draft-ietf-tram-stunbis-21. These mechanisms are partial mitigations but can still be susceptible to cross-connection correlation attacks. > - Section 5: When servers receive data that exceeds an allocation’s > > bandwidth quota, servers silently discard this data. This means there’s no > > allocation-based flow control mechanism between client and server beyond > > what’s provided by the transport protocol, right? > > Yes, UDP does not include a congestion control mechanism. > > > This seems fine, though > > perhaps some discussion of why this design decision was made would be > > helpful. For example, I could imagine explicit signals from servers to clients > > that indicate server state would reveal information about other allocations > > on the server, which might be problematic. - > > The errors 486 (Allocation Quota Exceeded) or 508 (Insufficient Capacity) do not reveal information of which other users are using the TURN server. At least the latter seems to give some indication that many other users are using the server at the time (so that it's overloaded), though not information about *which* users that is. > > Section 7.2 suggests that > > servers can redirect client allocation requests to other servers. Can this > > create a loop, wherein two TURN servers redirect to one another? > > The client detect and stop the loop, it is similar to HTTP redirection. Where is this specified? Thanks, Ben > > Moreover, > > is it acceptable for one TURN server to redirect to an unrelated TURN server? > > (It should be made clear here that these responses are authenticated, as > > otherwise it would be possible for an on-path adversary to redirect allocation > > requests to a server it owns.) > > It is already discussed in https://tools.ietf.org/html/draft-ietf-tram-stunbis-21#section-10 > > > - Section > > 21.1.2: Use of (D)TLS doesn’t help against dictionary attacks much, since > > presumably there’s low entropy in usernames and passwords alike. Thus, I > > question whether this is a “stronger” mitigation. > > The section only discusses "offline" dictionary attack, How is offline dictionary attack possible with (D)TLS ? > > >- Section 12.1.6: “username” > > and “realm” are not considered sensitive? They seem sensitive to me. - As an > > extension, it seems possible to improve on what’s in STUN. For example, it > > may be worthwhile, here or elsewhere, to update STUN’s long term > > credential key derivation process (MD5(username + realm + password)) to > > something a bit more modern. This is quite likely out of scope, though in the > > context of client authentication it seems worth mentioning that TURN is > > limited to the mechanisms provided by STUN. > > As mentioned previously, username may not be the end-user real identity and username can be anonymized. > > > > > Nits and other comments: > > > > - Section 2: “message-digest” is undefined in the Nonce definition. > > Thanks, replaced "message-digest" with "server response" > > > - Section 3: It’s probably worth citing RFC8446 as the recommended version > > of TLS. > > The draft says guidance given in [RFC7525] MUST be followed to avoid attacks on (D)TLS. RFC7525 says TLS 1.3 resolves the vulnerabilities found in previous TLS versions. > > >- Section 3.4: It might be worth mentioning that use of (D)TLS for the > > client-to-server transport mitigates the need for Send and Data > > authentication. > > https://tools.ietf.org/html/draft-ietf-tram-turnbis-27#section-21.1.4 discusses this issue in detail. > > > - Section 3.4: What does “proper security” mean? > > Thanks, replaced "proper security" with "end-to-end security". > > >- Figure 4: Adding another > > message exchange wherein a channel message is sent without a prior > > ChannelBind request would be useful to highlight this dependency and > > expected behavior from clients and servers. > > https://tools.ietf.org/html/draft-ietf-tram-turnbis-27#section-12.6 explains that If the ChannelData message is received on a channel that is not bound to any peer, then the message is silently discarded. > > > - Section 3.6: Another benefit of > > this user space design decision is use of (D)TLS links. - > > Good point, updated line to say: > for example, to allow a TURN server to be integrated into a peer-to-peer application so that one peer can offer NAT traversal services to another peer and to use (D)TLS to secure the TURN connection. > > Section 5: Where did > > the 40 second request buffer timeout come from? > > It is coming from the STUN specification (see https://tools.ietf.org/html/draft-ietf-tram-stunbis-21#section-6.3.1) > > > Adding some details > > might help. - Section 6: “secure hash” is undefined, though presumably what > > is meant is a cryptographic hash with collision resistance. It would be good to > > clarify this requirement. > > Yes, replaced with " cryptographic hash". > > > - Section 7.4: What is the retry behavior if allocation > > requests timeout? > > The retry behavior is discussed as follows: > > o (Request timed out): There is either a problem with the server, or > a problem reaching the server with the chosen transport. The > client considers the current transaction as having failed but MAY > choose to retry the Allocate request using a different transport > (e.g., TCP instead of UDP). > > > >- Section 12.5: The STUN requirement for 4-byte > > alignment should be cited when discussing the TCP and TLS padding > > requirement. > > Done. > > > - Section 15: Typo “DON’T FRAGMENT”. > > Fixed. > > Cheers, > -Tiru > > > > > > > _______________________________________________ > > tram mailing list > > tram@ietf.org > > https://www.ietf.org/mailman/listinfo/tram From nobody Tue Jul 9 16:41:38 2019 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 88044120075 for ; Tue, 9 Jul 2019 16:41:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.454 X-Spam-Level: X-Spam-Status: No, score=-0.454 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, PDS_NO_HELO_DNS=1.295, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3JXIpSpVhBC5 for ; Tue, 9 Jul 2019 16:41:36 -0700 (PDT) Received: from mail-ot1-x32d.google.com (mail-ot1-x32d.google.com [IPv6:2607:f8b0:4864:20::32d]) (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 48909120020 for ; Tue, 9 Jul 2019 16:41:36 -0700 (PDT) Received: by mail-ot1-x32d.google.com with SMTP id z23so250080ote.13 for ; Tue, 09 Jul 2019 16:41:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=IN0pDbEM3jMbe/yL0WqG3I4oaFrT5iui3+JrJYSZfqA=; b=KuBHZnsCe8wxMizQks9O2LgBLqLmnuNfI6u3fajDZ1QJS1+XnhhFUu9CPBozRePrPD GlrbDJaQ+qHYpW/SzEQXou1lY3G31oboFgdt1TJTSDQ6Q8joOTET8bAFL2dTXyaYOffZ YTes6qKO7EoidX6byZYckPq0Y/gtY+P0UXz+g4EP/WNn3rdMSPYyYji8LgSvUx0+yYHJ WmMpGXWzfeqn8h8nBRe1NSfqqyeeW+tEHmIPfmnVymTjKjOZ3X1KoV0VAIcrp5V41P2F vX9AjT7S/b8eYVVBfXQZ+3N4LjzO7+G8W3VzVhBSrQqxAlPWTvdnam9Pvk4OzSIJWKFu YAew== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=IN0pDbEM3jMbe/yL0WqG3I4oaFrT5iui3+JrJYSZfqA=; b=Ac3ZayHruDXQ+6EdC+45Urj67ARsojm1L77I4Ym77pzaSo10CX7RKJsASIwiweTIgw PGAVE7e27VBXkH8EouIh+JwKDQCZc5/UOie06a1XrKK6c8kQ5dKDeZyjAbMRO5ezzswh 8YftN2UXM8mTGovPiyWeY/L1ZtLrGiWpvDFUDIGaA5doja+YCgP2jFu3ywyHEEEcjaWU t42162O8fCPxuI/rtQve0ihj/Z8APgoW6R0a5GvK5wEriI2jnHkgYf6XZn9GlKMpH0nD +isibAylVyRjPwYAz2R/L7Y7Vxkgw9yKrYKXCUqO27A/DWrY8b6F0xRNbqm2v/4UD+iT S3NQ== X-Gm-Message-State: APjAAAVrkvc1ncu4ieg32JUB91fg4/nLJmhVxoU3CTo4ig0jc+rqBJEy NOQF3WHAtwjRytCnHhXV7R7EO1q5CN5F40TH1bUN+vLe X-Google-Smtp-Source: APXvYqzEaZ0/cMEtE1/RalAUR9e4hH4tv9EtXZu3uigxrsuC11nFUnw+t8JF8mHFJp4XwN3P35ihiSMvTS5+vesqIxY= X-Received: by 2002:a9d:57c6:: with SMTP id q6mr21318380oti.17.1562715695502; Tue, 09 Jul 2019 16:41:35 -0700 (PDT) MIME-Version: 1.0 From: Noriyuki Torii Date: Wed, 10 Jul 2019 08:41:24 +0900 Message-ID: To: tram@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [tram] some nits in i-d turnbis-27 X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.29 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 Jul 2019 23:41:37 -0000 To whom it may concern, I had read I-D of TURNbis-27 and found some points would like to be shared. Hope this may help for improvements. page 25 > 6. Allocations > > All TURN operations revolve around allocations, and all TURN messages > are associated with either a single or dual allocation. The document refers to single and dual allocation for the first time here, but there seems no explicit definitions about what a single or dual allocation actually is in any section of the document. Readers can only infer meanings of those from later description. I guess it would be preferrable having some explanations about these words in the terminology of section 2. --- page 30 > If the > server can partially meet the request, i.e. if it can only > allocate one relayed transport address of a specific address > type, then it includes ADDRESS-ERROR-CODE attribute in the > response to inform the client the reason for partial failure of > the request. The error code value signaled in the ADDRESS- > ERROR-CODE attribute could be 440 (Address Family not Supported) > or 508 (Insufficient Capacity). Readers may wonder (at least I did) whether a server will reply with Allocate success or error response when a request resulted into partial failure. Readers must wait until section 7.3 to get the answer for this question. Perhaps some additional explanation will be appreciated here. --- page 32 > Once the allocation is created, the server replies with a success > response. The success response contains: > > o An XOR-RELAYED-ADDRESS attribute containing the relayed transport > address. Here seems only a single allocation is in concern. Additional description for a dual allocation will be needed. --- page 47 > o If the XOR-PEER-ADDRESS attribute contains an address of an > address family that is not the same as that of a relayed transport > address for the allocation, the server MUST generate an error > response with the 443 (Peer Address Family Mismatch) response > code. > > If any of these tests fail, the server replies with a 400 (Bad > Request) error. The document says initially "response with the 443" and later "replies with a 400", so the acutual response is ambiguous. --- page 61 > 18.4. DATA > > The DATA attribute is present in all Send and Data indications. I think not all Data indications have the DATA attribute, especially when a Data indication carries an ICMP notification with the ICMP attribute, although section 11.5. doesn't say explicitly that such an indication MUST NOT have the DATA attribute. --- page 62 > RFFU: Reserved For Future Use. > > The other 7 bits of the attribute's value must be set to zero on > transmission and ignored on reception. "The other 7 bits" actually refers to the RFFU field, so some fix seems to be needed. --- page 63 > 18.12. ADDRESS-ERROR-CODE Attribute and page 64 > 18.13. ICMP Attribute These words "Attribute" seem to be unnecessary and removal would be preferable for alignment with other attribute descriptions in section 18. --- page 64 > Reserved: at this point, the 13 bits in the Reserved field MUST be > set to zero by the client and MUST be ignored by the server. Each fields of ADDRESS-ERROR-CODE Attribute must be set by the server, so this description is the other way around. --- page 75 > An attacker can send packets to B as if they came > from A by sending packets towards A with a spoofed IP address of B. Host A and B are replaced each other in before half and latter half. --- Best regards, Noriyuki Torii From nobody Tue Jul 9 22:50:19 2019 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 8FC3B120045; Tue, 9 Jul 2019 22:50:18 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Adam Roach via Datatracker To: "The IESG" Cc: draft-ietf-tram-turnbis@ietf.org, Brandon Williams , tram-chairs@ietf.org, brandon.williams@akamai.com, tram@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.98.3 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Adam Roach Message-ID: <156273781850.15858.12819016613039810127.idtracker@ietfa.amsl.com> Date: Tue, 09 Jul 2019 22:50:18 -0700 Archived-At: Subject: [tram] Adam Roach's Yes on draft-ietf-tram-turnbis-27: (with COMMENT) X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.29 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 Jul 2019 05:50:19 -0000 Adam Roach has entered the following ballot position for draft-ietf-tram-turnbis-27: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-tram-turnbis/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for all the work everyone did to update the TURN specification. I am balloting "Yes," as I think these are important changes to have published. I do have a small handful of comments that, while they don't rise to the level of a DISCUSS, are nonetheless rather important to consider before progressing this draft to an RFC. --------------------------------------------------------------------------- §5: > The server SHOULD > include the SOFTWARE attribute in all Allocate and Refresh responses > (either success or failure) and MAY include it in other responses or > indications. The Security Considerations section should probably include some mention of this behavior, and the trade-offs between allowing clients to know which software (and version) the server is running against providing this information to potential attackers who can use it to determine what software vulnerabilities may exist in that specific server and version. --------------------------------------------------------------------------- §11.5: > It also verifies that the IP > packet in the ICMP packet payload contains a UDP header. It's not clear what is being asked of implementations here. Is this just a check of the protocol field, or is it more involved than that? Is the intention that the server also check that the checksum is valid (i.e., matches the computed checksum or is zero)? If so, please spell it out more precisely. If this language is intended to imply even more rigorous checks, then it needs a lot more text. --------------------------------------------------------------------------- §12: > 0x5000-0xFFFF: Reserved (For DTLS-SRTP multiplexing collision > avoidance, see [RFC7983]. Given that values through 0x7FFF were permitted by the previous version of the protocol, it's unclear what what recovery path this document anticipates for legacy clients that might request channels in the 0x5000 - 0x7FFE range. The server behavior is well defined (the server sends a 400 response), but this seems to represent a fundamental backwards incompatibility, given that the client will take this to be a final request error and presumably abandon the attempt to use the TURN server. If the assumption is that no existing deployed legacy clients use channel numbers greater than 0x4FFF, please include that as a note. If the intention is instead that we're breaking backwards compatibility in a limited fashion, please include that as a note. If the rationale is some explanation other than these two, please include it as a note. --------------------------------------------------------------------------- §18.12: > Reason Phrase: The recommended reason phrases for error codes 440 > and 508 are explained in Section 19. The reason phrase MUST be a > UTF-8 [RFC3629] encoded sequence of less than 128 characters > (which can be as long as 509 bytes when encoding them or 763 bytes > when decoding them). This doesn't make a lot of sense to me. If arbitrary sequences of 128 UTF-8 characters are allowed, then the on-the-wire encoding might be as long as 512 bytes (rather than 509), even if this would only result from the use of unusual strings (e.g., 128 consecutive emoji). I'm even more lost by the indication of "763 bytes," as I can't figure out what "decoding" operation is being indicated here, nor can I figure out what kind of decoded sequence would use 5.96 bytes per character. Please double-check your numbers, and add more text indicating what is meant by "encoding" and "decoding" in this sentence. Also, nit: "...fewer than 128 characters..." From nobody Tue Jul 9 23:03:00 2019 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 B00611200DB for ; Tue, 9 Jul 2019 23:02:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.999 X-Spam-Level: X-Spam-Status: No, score=-3.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=mcafee.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qFEluj6JrB9t for ; Tue, 9 Jul 2019 23:02:53 -0700 (PDT) Received: from us-smtp-delivery-210.mimecast.com (us-smtp-delivery-210.mimecast.com [63.128.21.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 875191200FD for ; Tue, 9 Jul 2019 23:02:52 -0700 (PDT) X-NAI-Header: Modified by McAfee Email Gateway (5500) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mcafee.com; s=s_mcafee; t=1562737938; h=ARC-Seal: ARC-Message-Signature:ARC-Authentication-Results: From:To:CC:Subject:Thread-Topic:Thread-Index: Date:Message-ID:References:In-Reply-To:Accept-Language: Content-Language:X-MS-Has-Attach:X-MS-TNEF-Correlator: dlp-product:dlp-version:dlp-reaction:authentication-results: x-originating-ip:x-ms-publictraffictype:x-ms-office365-filtering-correlation-id: x-microsoft-antispam:x-ms-traffictypediagnostic: x-ms-exchange-purlcount:x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers:x-forefront-prvs: x-forefront-antispam-report:received-spf:x-ms-exchange-senderadcheck: x-microsoft-antispam-message-info:Content-Type: Content-Transfer-Encoding:MIME-Version:X-MS-Exchange-CrossTenant-Network-Message-Id: X-MS-Exchange-CrossTenant-originalarrivaltime: X-MS-Exchange-CrossTenant-fromentityheader: X-MS-Exchange-CrossTenant-id:X-MS-Exchange-CrossTenant-mailboxtype: X-MS-Exchange-CrossTenant-userprincipalname: X-MS-Exchange-Transport-CrossTenantHeadersStamped: X-OriginatorOrg:X-NAI-Spam-Flag:X-NAI-Spam-Level: X-NAI-Spam-Threshold:X-NAI-Spam-Score:X-NAI-Spam-Version; bh=7q3kL6vB23s7VvGOluhEOsfudXvBavpAnt/sgh mjh0Q=; b=S3jaFSvw28oKmArtoZuq+n4uFUyEkvOYI7pNDOEM 87+lC34ZMDBCuFnDYfF9wAt+qMWadZGCX4c9K0IcjkeqP/0ygD PwpxO/msSr45bCR/IXj7nsCJZo/xu8rUywRHvwTR8oyqClRupw FdOPT2To8YXofXyNyISEbSan+8o+Nzw= Received: from DNVWSMAILOUT1.mcafee.com (dnvwsmailout1.mcafee.com [161.69.31.173]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-142-dXF7an3pMUat5MhNrjItXA-1; Wed, 10 Jul 2019 02:02:47 -0400 Received: from DNVEXAPP1N06.corpzone.internalzone.com (unknown [10.44.48.90]) by DNVWSMAILOUT1.mcafee.com with smtp (TLS: TLSv1/SSLv3,256bits,ECDHE-RSA-AES256-SHA384) id 6fb3_110f_859a8967_b672_4a36_be0b_3230eff210e3; Tue, 09 Jul 2019 23:52:18 -0600 Received: from DNVEXAPP1N05.corpzone.internalzone.com (10.44.48.89) by DNVEXAPP1N06.corpzone.internalzone.com (10.44.48.90) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Wed, 10 Jul 2019 00:02:24 -0600 Received: from DNVO365EDGE1.corpzone.internalzone.com (10.44.176.66) by DNVEXAPP1N05.corpzone.internalzone.com (10.44.48.89) with Microsoft SMTP Server (TLS) id 15.0.1395.4 via Frontend Transport; Wed, 10 Jul 2019 00:02:23 -0600 Received: from NAM01-SN1-obe.outbound.protection.outlook.com (10.44.176.243) by edge.mcafee.com (10.44.176.66) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Wed, 10 Jul 2019 00:02:23 -0600 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=lUmBR/IJb26rELHhZmDAPGUeehzSXutPLgJFd2tzmIks0mfpwsn/n85h1uKlxKncyidHIZ63ffpc3xl/b5g7c7uZA13kLHCXc6F2wc8ukteMwKBC0VoyEERzAT7EnUQAYFuL2BD8P7lHEc8kzUsARS6wKmRXRO3iRtSgDZVT7jEXeZHRF+hPXyBAAOHOQf90XM1FR9LnYV+ClAKiynNyXKGw3Vk/+PUIVKIy11E8RS4adtVeAt9PzcqsF+wuHbTL9xO764gxRloYJUkOw5lyFzOuTCWLZBqHNYa8BSqtj/L5jRzu3Lnum6Uhe7DIhwntOjV9hQYkoIu8J6Q4qFJnPQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=7q3kL6vB23s7VvGOluhEOsfudXvBavpAnt/sghmjh0Q=; b=CsI4U7NfDUdpGEXUVvra+LGlPFpR6BFWeaiPLqtHO5v9ewmpW2vo/+1vQDlv3IcBxbwGVmoKM2jwkACPr/1zLkbLqX5k4fauU/nFg+3oxuwmnrhWr9qu1shwKoaFOo4aAD20WbhH4jDMSjM0Rzk7symQiEecz4D5/pHfOl+mePMcSKKun8X/anE7IW0r5bZPUyHCs4BMBAc0hNlaiGVRhSXCPpIlYbJx6jGwdmqJ4nfxUKRFeAp9GIOemoS+OB/rA8nRaqDZxreTfzEQ319dxE3dmOMRJ0AjzuLOdx3CqJzIrzh0B6lqE5nPcYffMa8lb/JdW1wXOT7vJefzae4NOg== ARC-Authentication-Results: i=1; mx.microsoft.com 1;spf=pass smtp.mailfrom=mcafee.com;dmarc=pass action=none header.from=mcafee.com;dkim=pass header.d=mcafee.com;arc=none Received: from DM5PR16MB1705.namprd16.prod.outlook.com (10.172.44.147) by DM5PR16MB1818.namprd16.prod.outlook.com (10.174.177.150) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2073.10; Wed, 10 Jul 2019 06:02:21 +0000 Received: from DM5PR16MB1705.namprd16.prod.outlook.com ([fe80::570:2208:75c2:5f17]) by DM5PR16MB1705.namprd16.prod.outlook.com ([fe80::570:2208:75c2:5f17%8]) with mapi id 15.20.2052.019; Wed, 10 Jul 2019 06:02:21 +0000 From: "Konda, Tirumaleswar Reddy" To: "Eric Vyncke (evyncke)" , Magnus Westerlund , "iesg@ietf.org" CC: "tram-chairs@ietf.org" , "draft-ietf-tram-turnbis@ietf.org" , "tram@ietf.org" , "brandon.williams@akamai.com" Thread-Topic: =?utf-8?B?W3RyYW1dICDDiXJpYyBWeW5ja2UncyBObyBPYmplY3Rpb24gb24gZHJhZnQt?= =?utf-8?Q?ietf-tram-turnbis-27:_(with_COMMENT)?= Thread-Index: AQHVNi3IZIYvEl7BokaSxtNPnPUXBKbClA0AgADI+vA= Date: Wed, 10 Jul 2019 06:02:21 +0000 Message-ID: References: <156248752430.14312.15895119889558390147.idtracker@ietfa.amsl.com> <4e999e5ae34e102ab5ca3a65c1b11a88647b5667.camel@ericsson.com> <2C1E13AD-E40B-4C78-8751-A405E3B1DE8F@cisco.com> In-Reply-To: <2C1E13AD-E40B-4C78-8751-A405E3B1DE8F@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.3.0.16 dlp-reaction: no-action x-originating-ip: [103.245.47.20] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 5a73474b-ea68-4823-dd57-08d704fc2c1a x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:DM5PR16MB1818; x-ms-traffictypediagnostic: DM5PR16MB1818: x-ms-exchange-purlcount: 1 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 0094E3478A x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(366004)(136003)(396003)(346002)(376002)(39860400002)(189003)(199004)(13464003)(32952001)(76176011)(26005)(66066001)(76116006)(102836004)(6116002)(3846002)(53546011)(4326008)(6506007)(64756008)(2501003)(66476007)(66556008)(66446008)(53936002)(256004)(5024004)(71200400001)(476003)(55016002)(6306002)(9686003)(66946007)(6436002)(7696005)(6246003)(71190400001)(2906002)(99286004)(229853002)(14454004)(68736007)(80792005)(478600001)(74316002)(86362001)(5660300002)(110136005)(54906003)(966005)(316002)(52536014)(486006)(446003)(11346002)(186003)(305945005)(7736002)(33656002)(8936002)(224303003)(81156014)(25786009)(81166006)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR16MB1818; H:DM5PR16MB1705.namprd16.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: O1+cjMPItZwyPwHAd7ynMdQPq83XrPlfVxG7uCbOhosT8UnC6aHFMaMerNp4ywB7zKparei3ZO9auT6oiMF3WowMCFJm1f057kPwJHxmX5bDIf9wfnB8Q6xXCF8q1RYjb+M509ywaHN2/9elO3lKTYShfVCd/l/7AjK5pztnYK+4XdpFyHeti4jHpTEMp5a6yjMoyuhimkdfBPQD0uDpmdLT8IvLYLcDc5vxvRNz/pE7aGJnnWVr6aRRnOSlIZCxj8hw20iUmKaR10ZByj1fZ23YrSmzYfMXVP7TUKLmf5v7HGblGsA1AhnD+8sY+BZ0LvsQ04ZYYjlRQWlC0bxnF+STgWOz1KqiTPpcoBLJVCB6Mir8Pjb5K/oviGpEf8l0FITToyk0ViFnWE59YAuq5F+fYEt9PGEoOZ7/Cd5dvH4= MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 5a73474b-ea68-4823-dd57-08d704fc2c1a X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Jul 2019 06:02:21.2390 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: TirumaleswarReddy_Konda@McAfee.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR16MB1818 X-OriginatorOrg: mcafee.com X-NAI-Spam-Flag: NO X-NAI-Spam-Level: X-NAI-Spam-Threshold: 15 X-NAI-Spam-Score: 0.4 X-NAI-Spam-Version: 2.3.0.9418 : core <6586> : inlines <7115> : streams <1826919> : uri <2865832> X-MC-Unique: dXF7an3pMUat5MhNrjItXA-1 X-Mimecast-Spam-Score: 0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Archived-At: Subject: Re: [tram] =?utf-8?q?=C3=89ric_Vyncke=27s_No_Objection_on_draft-ietf?= =?utf-8?q?-tram-turnbis-27=3A_=28with_COMMENT=29?= X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.29 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 Jul 2019 06:02:59 -0000 PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBFcmljIFZ5bmNrZSAoZXZ5bmNr ZSkgPGV2eW5ja2VAY2lzY28uY29tPg0KPiBTZW50OiBUdWVzZGF5LCBKdWx5IDksIDIwMTkgMTE6 MzEgUE0NCj4gVG86IE1hZ251cyBXZXN0ZXJsdW5kIDxtYWdudXMud2VzdGVybHVuZEBlcmljc3Nv bi5jb20+OyBpZXNnQGlldGYub3JnOw0KPiBLb25kYSwgVGlydW1hbGVzd2FyIFJlZGR5IDxUaXJ1 bWFsZXN3YXJSZWRkeV9Lb25kYUBNY0FmZWUuY29tPg0KPiBDYzogdHJhbS1jaGFpcnNAaWV0Zi5v cmc7IGRyYWZ0LWlldGYtdHJhbS10dXJuYmlzQGlldGYub3JnOyB0cmFtQGlldGYub3JnOw0KPiBi cmFuZG9uLndpbGxpYW1zQGFrYW1haS5jb20NCj4gU3ViamVjdDogUmU6IFt0cmFtXSDDiXJpYyBW eW5ja2UncyBObyBPYmplY3Rpb24gb24gZHJhZnQtaWV0Zi10cmFtLXR1cm5iaXMtMjc6DQo+ICh3 aXRoIENPTU1FTlQpDQo+IA0KPiBUaGlzIGVtYWlsIG9yaWdpbmF0ZWQgZnJvbSBvdXRzaWRlIG9m IHRoZSBvcmdhbml6YXRpb24uIERvIG5vdCBjbGljayBsaW5rcyBvcg0KPiBvcGVuIGF0dGFjaG1l bnRzIHVubGVzcyB5b3UgcmVjb2duaXplIHRoZSBzZW5kZXIgYW5kIGtub3cgdGhlIGNvbnRlbnQg aXMNCj4gc2FmZS4NCj4gDQo+IE1hZ251cywNCj4gDQo+IFRoYW5rIHlvdSBmb3IgdGhlIGFkZGVk IGluZm9ybWF0aW9uICYgY29tbWVudHM6DQo+IA0KPiANCj4g77u/T24gMDkvMDcvMjAxOSwgMTA6 MTAsICJpZXNnIG9uIGJlaGFsZiBvZiBNYWdudXMgV2VzdGVybHVuZCIgPGllc2ctDQo+IGJvdW5j ZXNAaWV0Zi5vcmcgb24gYmVoYWxmIG9mIG1hZ251cy53ZXN0ZXJsdW5kQGVyaWNzc29uLmNvbT4g d3JvdGU6DQo+IA0KPiANCj4gICAgIFNvIG9uIHRoZSBjbGllbnQgdG8gc2VydmVyIHBhdGggdGhl cmUgaXMgYSBwb3NzaWJpbGl0eSB0byB1c2UgTVAtVENQIHRvDQo+ICAgICBwb3RlbnRpYWxseSBp bXByb3ZlIHRoYXQgc3BlY2lmaWMgbGVnIG9mIHRoZSBjb21tdW5pY2F0aW9uLiBJdCBjYW4gYmUN Cj4gICAgIG5lZ290aWF0ZWQgaW4gdGhlIFRDUCBjb25uZWN0aW9uIGlmIGRlc2lyZWQuIEhvd2V2 ZXIsIHRvIGJlIGNsZWFyIEkNCj4gICAgIGRvbid0IHRoaW5rIHRoZXJlIGlzIGEgcmVhc29uIHRv IHJlY29tbWVuZCBhbmQgZGVmaW5pdGVseSBub3QgbWFuZGF0ZQ0KPiAgICAgTVAtVENQIHN1cHBv cnQgaWYgb25lIHN1cHBvcnRzIHRoZSBUQ1AgdHJhbnNwb3J0IGluIHRoZSBjbGllbnQgdG8NCj4g ICAgIHNlcnZlciBpbnRlcmZhY2UuIEFsc28gaXQgY3JlYXRlcyBhIHBvdGVudGlhbGx5IGludGVy ZXN0aW5nDQo+ICAgICBpbnRlcmFjdGlvbnMgYmV0d2VlbiB0aGUgZnJhbWV3b3JrIHVzaW5nIFRV Uk4sIGxpa2UgSUNFIHdoZW4gYSBtb2JpbGl0eQ0KPiAgICAgZXZlbnRzIGhhcHBlbi4gSXQgbWF5 IGFsc28gcmVzdWx0IGluIHN1Yi1vcHRpbWFsIHJvdXRpbmcgaW4gY2FzZXMgd2hlcmUNCj4gICAg IGEgY2xpZW50IHNlbGVjdHMgdG8gdXNlIG11bHRpcGxlIGludGVyZmFjZXMgdG8gaGF2ZSBvbmUg TVAtVENQDQo+ICAgICBjb25uZWN0aW9uIHRvIG9uZSBUVVJOIHNlcnZlciwgcmF0aGVyIHRoYW4g dGhlIGJlc3QgVFVSTiBzZXJ2ZXIgcGVyDQo+ICAgICBpbnRlcmZhY2UuDQo+IA0KPiBFVj4gdGhl IHVzdWFsIGRpc2N1c3Npb24gb24gd2hpY2ggbGF5ZXIgdG8gcHJvdmlkZSBtb2JpbGl0eTogbGF5 ZXIgMiwgbGF5ZXIgMywNCj4gbGF5ZXIgNCBvciBpbiB0aGUgYXBwbGljYXRpb24gOy0pDQoNCklQ IGFkZHJlc3MgbW9iaWxpdHkgdXNpbmcgVFVSTiBpcyBoYW5kbGVkIGJ5IGh0dHBzOi8vdG9vbHMu aWV0Zi5vcmcvaHRtbC9yZmM4MDE2IA0KDQotVGlydQ0KDQo+IA0KPiANCg0K From nobody Wed Jul 10 05:42:26 2019 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 946ED1202E6 for ; Wed, 10 Jul 2019 05:42:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=mcafee.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ysSAT8XX-ynD for ; Wed, 10 Jul 2019 05:42:15 -0700 (PDT) Received: from us-smtp-delivery-210.mimecast.com (us-smtp-delivery-210.mimecast.com [216.205.24.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 313BA12030C for ; Wed, 10 Jul 2019 05:42:02 -0700 (PDT) X-NAI-Header: Modified by McAfee Email Gateway (5500) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mcafee.com; s=s_mcafee; t=1562761813; h=ARC-Seal: ARC-Message-Signature:ARC-Authentication-Results: From:To:CC:Subject:Thread-Topic:Thread-Index: Date:Message-ID:References:In-Reply-To:Accept-Language: Content-Language:X-MS-Has-Attach:X-MS-TNEF-Correlator: dlp-product:dlp-version:dlp-reaction:authentication-results: x-originating-ip:x-ms-publictraffictype:x-ms-office365-filtering-correlation-id: x-microsoft-antispam:x-ms-traffictypediagnostic: x-ms-exchange-purlcount:x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers:x-forefront-prvs: x-forefront-antispam-report:received-spf:x-ms-exchange-senderadcheck: x-microsoft-antispam-message-info:Content-Type: Content-Transfer-Encoding:MIME-Version:X-MS-Exchange-CrossTenant-Network-Message-Id: X-MS-Exchange-CrossTenant-originalarrivaltime: X-MS-Exchange-CrossTenant-fromentityheader: X-MS-Exchange-CrossTenant-id:X-MS-Exchange-CrossTenant-mailboxtype: X-MS-Exchange-CrossTenant-userprincipalname: X-MS-Exchange-Transport-CrossTenantHeadersStamped: X-OriginatorOrg:X-NAI-Spam-Flag:X-NAI-Spam-Level: X-NAI-Spam-Threshold:X-NAI-Spam-Score:X-NAI-Spam-Version; bh=tYV0Mxd/EHV7xQvZjZoVWECZR4eGEOW6Yv37ey YSbQ8=; b=h3hqW0zDaQ6aS3OxKUMdsLwPgZZ//CTfaWt7/5+P NYaBtWegF5Z7JRsSbD5HK0OoiGgi6MmLTrAHk4A6l2vMn5rROt NCIDZ3B+txT5ZdU6rxQ9T/0XiIJpg4dxGdL04cTq88gM40igN0 KlkC/lhXuPbFASu5mKvqxu3QaBwWogY= Received: from DNVWSMAILOUT1.mcafee.com (dnvwsmailout1.mcafee.com [161.69.31.173]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-69-6T7oguXnO2GWuWGMOirQnA-1; Wed, 10 Jul 2019 08:40:43 -0400 Received: from DNVEXAPP1N05.corpzone.internalzone.com (DNVEXAPP1N05.corpzone.internalzone.com [10.44.48.89]) by DNVWSMAILOUT1.mcafee.com with smtp (TLS: TLSv1/SSLv3,256bits,ECDHE-RSA-AES256-SHA384) id 6fce_6c22_8546be77_e434_43e5_8158_5cdcb3449957; Wed, 10 Jul 2019 06:30:11 -0600 Received: from DNVEXAPP1N05.corpzone.internalzone.com (10.44.48.89) by DNVEXAPP1N05.corpzone.internalzone.com (10.44.48.89) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Wed, 10 Jul 2019 06:40:39 -0600 Received: from DNVO365EDGE1.corpzone.internalzone.com (10.44.176.66) by DNVEXAPP1N05.corpzone.internalzone.com (10.44.48.89) with Microsoft SMTP Server (TLS) id 15.0.1395.4 via Frontend Transport; Wed, 10 Jul 2019 06:40:39 -0600 Received: from NAM02-BL2-obe.outbound.protection.outlook.com (10.44.176.240) by edge.mcafee.com (10.44.176.66) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Wed, 10 Jul 2019 06:40:37 -0600 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=d0PbQH7S5pEdBBJdLPBuCg/0G3dmP0KmLvLN0NRhPjoTnGzeIUQSOyRfDx+eMm2NZYUqlqeSfd19TUJ2TN9Rbq6nwlmepjb8cSPwg2qYzJCe+wP/l1SnHmUJYpohOpm48DWSOu2sEgT2mZlZMLJznsFO8Oa0ortJbpjMIMZ8TUvzVJnjJgUrECXR8dWX4qVJZxJomgnTfFXEcppfB2JWgFeM4N/8vn+gLKTXGpxWzATGShGpyKQtxjPGtO5E0jSrZZ26ThyqhnBuA9fo2KU+KOtr7ErjF/OdlGgpFf6Q3ZhqLvUXxLYPvkXuNWs2UfnaK7VyhY2crLRDk+Lzdlk3OQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=tYV0Mxd/EHV7xQvZjZoVWECZR4eGEOW6Yv37eyYSbQ8=; b=nP3uRIsI/HW5j3WmXuQkxV509rFqTAuONPNZMsvoj5kl45OD6XFFjWq6tbKZGU3sUaDvf3DciQuHYVa6NXF8Z+q14skO6aCY1w4XkEqOv6EkwMfffTbakhUP4F1RHR+pxMry9sEYuEIJhrf7y2voMoxkmpuz4E9vC3eVJHy1oKIlkf1MMxI1YgEAaS9Qb3Q030pTQ/3wIiChJ8OiZbVi4xxkNwZ3EGwiJCt+u1STR4J2OslStv47viQFd1mb7oBPoe3aoQE/2e4/Y34tiKgWaq2C/+HjJyfBmyop3VpzaxTArbZB6BK66m7BvULPr8yHkB1d69wWwcuPsVFBDKcWLA== ARC-Authentication-Results: i=1; mx.microsoft.com 1;spf=pass smtp.mailfrom=mcafee.com;dmarc=pass action=none header.from=mcafee.com;dkim=pass header.d=mcafee.com;arc=none Received: from DM5PR16MB1705.namprd16.prod.outlook.com (10.172.44.147) by DM5SPR00MB242.namprd16.prod.outlook.com (10.168.120.149) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2073.10; Wed, 10 Jul 2019 12:40:37 +0000 Received: from DM5PR16MB1705.namprd16.prod.outlook.com ([fe80::570:2208:75c2:5f17]) by DM5PR16MB1705.namprd16.prod.outlook.com ([fe80::570:2208:75c2:5f17%8]) with mapi id 15.20.2052.019; Wed, 10 Jul 2019 12:40:37 +0000 From: "Konda, Tirumaleswar Reddy" To: Benjamin Kaduk CC: Christopher Wood , "secdir@ietf.org" , "draft-ietf-tram-turnbis.all@ietf.org" , "ietf@ietf.org" , "tram@ietf.org" Thread-Topic: [tram] Secdir last call review of draft-ietf-tram-turnbis-27 Thread-Index: AQHVNQMAJeymFhPVnEO1ky4wx5pqrabAcMBwgAJPmICAAKIlAA== Date: Wed, 10 Jul 2019 12:40:37 +0000 Message-ID: References: <156253133809.549.13521510978566357744@ietfa.amsl.com> <20190709203044.GD24351@kduck.mit.edu> In-Reply-To: <20190709203044.GD24351@kduck.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.3.0.16 dlp-reaction: no-action x-originating-ip: [49.37.206.28] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: fdf60297-a4c7-448a-b521-08d70533cf56 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:DM5SPR00MB242; x-ms-traffictypediagnostic: DM5SPR00MB242: x-ms-exchange-purlcount: 14 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0094E3478A x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(136003)(396003)(346002)(376002)(39860400002)(366004)(189003)(199004)(32952001)(51914003)(13464003)(99286004)(68736007)(53936002)(966005)(7736002)(71200400001)(71190400001)(6916009)(316002)(6306002)(76176011)(9686003)(2171002)(54906003)(305945005)(33656002)(30864003)(476003)(25786009)(478600001)(229853002)(7696005)(486006)(66066001)(6246003)(14454004)(2906002)(5660300002)(186003)(8676002)(102836004)(26005)(81156014)(81166006)(11346002)(52536014)(8936002)(66476007)(66946007)(80792005)(66556008)(64756008)(66446008)(6506007)(53546011)(55016002)(76116006)(6116002)(3846002)(86362001)(446003)(5024004)(74316002)(4326008)(6436002)(256004)(14444005)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5SPR00MB242; H:DM5PR16MB1705.namprd16.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: 2oOIAYrY6AykjsFJHqTeFjwsec7f9EEWYLGK50ohHYrsid7zgpX8n85jeEdudbnMpcHLvsCzvWm85RiP6cEsAZlwXvFvxUs+RC7CRk8rL/E0VLoJcbog701+/z+yXAYlNoGARXGsBPfUVrO2iXuJKZSQbZFT26eK1FKmtlx3DrqIivbbFD4uEV0MjbcomuiMOQbmqpdLeCO6ww0jNmymISIoxvsiWjBCB8tCCEKb8JccfFRthXgyytwn0/JTDLHrHIz6xkPBKjXrM6dZ1r7BzNLaXM+JywGtse1sWYRrgrq9v8K3m/E4LsDp1zvmsQT2I7ELFzpffrNDblJsAVBMX/WFln2dIxfbkkR+qYhUag6O+Qoxl2F7hytaJ5ui+IfVijQdhlsf5G82ver5MFP1IbDFTlwrqwtfGOjq2E5rZzk= MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: fdf60297-a4c7-448a-b521-08d70533cf56 X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Jul 2019 12:40:37.5160 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: TirumaleswarReddy_Konda@McAfee.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5SPR00MB242 X-OriginatorOrg: mcafee.com X-NAI-Spam-Flag: NO X-NAI-Spam-Level: X-NAI-Spam-Threshold: 15 X-NAI-Spam-Score: 0.1 X-NAI-Spam-Version: 2.3.0.9418 : core <6586> : inlines <7115> : streams <1826946> : uri <2865937> X-MC-Unique: 6T7oguXnO2GWuWGMOirQnA-1 X-Mimecast-Spam-Score: 0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Archived-At: Subject: Re: [tram] Secdir last call review of draft-ietf-tram-turnbis-27 X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.29 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 Jul 2019 12:42:24 -0000 SGkgQmVuLA0KDQpUaGFua3MgZm9yIHRoZSByZXZpZXcuIFBsZWFzZSBzZWUgaW5saW5lLg0KDQo+ IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IEJlbmphbWluIEthZHVrIDxrYWR1 a0BtaXQuZWR1Pg0KPiBTZW50OiBXZWRuZXNkYXksIEp1bHkgMTAsIDIwMTkgMjowMSBBTQ0KPiBU bzogS29uZGEsIFRpcnVtYWxlc3dhciBSZWRkeSA8VGlydW1hbGVzd2FyUmVkZHlfS29uZGFATWNB ZmVlLmNvbT4NCj4gQ2M6IENocmlzdG9waGVyIFdvb2QgPGNhd0BoZWFwaW5nYml0cy5uZXQ+OyBz ZWNkaXJAaWV0Zi5vcmc7IGRyYWZ0LWlldGYtDQo+IHRyYW0tdHVybmJpcy5hbGxAaWV0Zi5vcmc7 IGlldGZAaWV0Zi5vcmc7IHRyYW1AaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6IFt0cmFtXSBTZWNk aXIgbGFzdCBjYWxsIHJldmlldyBvZiBkcmFmdC1pZXRmLXRyYW0tdHVybmJpcy0yNw0KPiANCj4g VGhpcyBlbWFpbCBvcmlnaW5hdGVkIGZyb20gb3V0c2lkZSBvZiB0aGUgb3JnYW5pemF0aW9uLiBE byBub3QgY2xpY2sgbGlua3Mgb3INCj4gb3BlbiBhdHRhY2htZW50cyB1bmxlc3MgeW91IHJlY29n bml6ZSB0aGUgc2VuZGVyIGFuZCBrbm93IHRoZSBjb250ZW50IGlzDQo+IHNhZmUuDQo+IA0KPiBD aHJpcywgdGhhbmtzIGZvciB0aGUgcmV2aWV3LiAgU29tZSBtb3JlIHF1ZXN0aW9ucy9jb21tZW50 cyBpbmxpbmUgYXMgSQ0KPiBwcmVwYXJlIHRvIGJhbGxvdCBvbiB0aGlzIGRvY3VtZW50Li4uDQo+ IA0KPiBPbiBNb24sIEp1bCAwOCwgMjAxOSBhdCAwMjoxODoyNlBNICswMDAwLCBLb25kYSwgVGly dW1hbGVzd2FyIFJlZGR5IHdyb3RlOg0KPiA+IEhpIENocmlzdG9waGVyLA0KPiA+DQo+ID4gVGhh bmtzIGZvciB0aGUgZGV0YWlsZWQgcmV2aWV3LiBQbGVhc2Ugc2VlIGlubGluZQ0KPiA+DQo+ID4g PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+ID4gRnJvbTogdHJhbSA8dHJhbS1ib3Vu Y2VzQGlldGYub3JnPiBPbiBCZWhhbGYgT2YgQ2hyaXN0b3BoZXIgV29vZCB2aWENCj4gPiA+IERh dGF0cmFja2VyDQo+ID4gPiBTZW50OiBNb25kYXksIEp1bHkgOCwgMjAxOSAxOjU5IEFNDQo+ID4g PiBUbzogc2VjZGlyQGlldGYub3JnDQo+ID4gPiBDYzogZHJhZnQtaWV0Zi10cmFtLXR1cm5iaXMu YWxsQGlldGYub3JnOyBpZXRmQGlldGYub3JnOw0KPiA+ID4gdHJhbUBpZXRmLm9yZw0KPiA+ID4g U3ViamVjdDogW3RyYW1dIFNlY2RpciBsYXN0IGNhbGwgcmV2aWV3IG9mDQo+ID4gPiBkcmFmdC1p ZXRmLXRyYW0tdHVybmJpcy0yNw0KPiA+ID4NCj4gPiA+IFRoaXMgZW1haWwgb3JpZ2luYXRlZCBm cm9tIG91dHNpZGUgb2YgdGhlIG9yZ2FuaXphdGlvbi4gRG8gbm90IGNsaWNrDQo+ID4gPiBsaW5r cyBvciBvcGVuIGF0dGFjaG1lbnRzIHVubGVzcyB5b3UgcmVjb2duaXplIHRoZSBzZW5kZXIgYW5k IGtub3cNCj4gPiA+IHRoZSBjb250ZW50IGlzIHNhZmUuDQo+ID4gPg0KPiA+ID4gUmV2aWV3ZXI6 IENocmlzdG9waGVyIFdvb2QNCj4gPiA+IFJldmlldyByZXN1bHQ6IEhhcyBOaXRzDQo+ID4gPg0K PiA+ID4gSSBoYXZlIHJldmlld2VkIHRoaXMgZG9jdW1lbnQgYXMgcGFydCBvZiB0aGUgc2VjdXJp dHkgZGlyZWN0b3JhdGUncw0KPiA+ID4gb25nb2luZyBlZmZvcnQgdG8gcmV2aWV3IGFsbCBJRVRG IGRvY3VtZW50cyBiZWluZyBwcm9jZXNzZWQgYnkgdGhlDQo+ID4gPiBJRVNHLiBUaGVzZSBjb21t ZW50cyB3ZXJlIHdyaXR0ZW4gcHJpbWFyaWx5IGZvciB0aGUgYmVuZWZpdCBvZiB0aGUNCj4gPiA+ IHNlY3VyaXR5IGFyZWEgZGlyZWN0b3JzLg0KPiA+ID4gRG9jdW1lbnQgZWRpdG9ycyBhbmQgV0cg Y2hhaXJzIHNob3VsZCB0cmVhdCB0aGVzZSBjb21tZW50cyBqdXN0IGxpa2UNCj4gPiA+IGFueSBv dGhlciBsYXN0IGNhbGwgY29tbWVudHMuDQo+ID4gPg0KPiA+ID4gVGhlIHN1bW1hcnkgb2YgdGhl IHJldmlldyBpczogUmVhZHkgd2l0aCBuaXRzDQo+ID4gPg0KPiA+ID4gU3VtbWFyeToNCj4gPiA+ DQo+ID4gPiBJbiBnZW5lcmFsLCB0aGUgZG9jdW1lbnQgaXMgd2VsbCB3cml0dGVuIGFuZCBjbGVh cmx5IGZvdW5kZWQgaW4NCj4gPiA+IG9wZXJhdGlvbmFsIGV4cGVyaWVuY2UuIFRoZSBzZWN1cml0 eSBjb25zaWRlcmF0aW9ucyBhcmUgdGhvcm91Z2gsDQo+ID4gPiBwcm92aWRpbmcgZXhhbXBsZXMg d2hlcmUgbmVjZXNzYXJ5IHRvIGhpZ2hsaWdodCBpbXBvcnRhbnQgcHJvYmxlbQ0KPiA+ID4gYXJl YXMuIEl0IGRyYXdzIGEgY2xlYXIgbGluZSBiZXR3ZWVuIGlzc3VlcyBiZXN0IGFkZHJlc3NlZCBi eQ0KPiA+ID4gYXBwbGljYXRpb25zIG91dHNpZGUgb2YgVFVSTiwgYW5kIHByb3ZpZGVzIHN1ZmZp Y2llbnQgZGV0YWlsIGZvcg0KPiA+ID4gdGhvc2UgaXNzdWVzIGluIHNjb3BlLiBNeSBjb21tZW50 cyBhbmQgcXVlc3Rpb25zIGFyZSwgaG9wZWZ1bGx5LCBtb3N0bHkNCj4gbml0cy4NCj4gPiA+DQo+ ID4gPiBHZW5lcmFsIGNvbW1lbnRzOg0KPiA+ID4NCj4gPiA+IC0gVFVSTiBzZXJ2ZXIgYXV0aGVu dGljYXRpb24gaW4gdGhlIGNhc2Ugb2YgKEQpVExTIGlzDQo+ID4gPiB1bmRlcnNwZWNpZmllZC4g QXJlIHNlcnZlcnMgYXNzdW1lZCB0byBoYXZlIFdlYlBLSSBjZXJ0aWZpY2F0ZXMsDQo+ID4gPiBP T0ItdHJ1c3RlZCByYXcgcHVibGljIGtleXMsIG9yIHNvbWV0aGluZyBlbHNlPyBJcyB0aGVyZSBh IHByZWZlcnJlZA0KPiBmb3JtIG9mIGF1dGhlbnRpY2F0aW9uPw0KPiA+ID4gUmVsYXRlZGx5LCBp bg0KPiA+ID4gU2VjdGlvbiAzLjIsIGhvdyBkbyBjbGllbnRzIGF1dGhlbnRpY2F0ZSB0aGUgc2Vy dmVyPw0KPiA+DQo+ID4gU2VydmVyIGNlcnRpZmljYXRlIHZhbGlkYXRpb24gaXMgZGlzY3Vzc2Vk IGluIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC0NCj4gaWV0Zi10cmFtLXN0dW5i aXMtMjEjc2VjdGlvbi02LjIuMy4gIEkgaGF2ZSBtb2RpZmllZCB0aGUgdGV4dCBhcyBmb2xsb3dz Og0KPiA+DQo+ID4gSWYgKEQpVExTIHRyYW5zcG9ydCBpcyB1c2VkIGJldHdlZW4gdGhlIFRVUk4g Y2xpZW50IGFuZCB0aGUgVFVSTg0KPiA+IHNlcnZlciwgdGhlIGNpcGhlciBzdWl0ZXMsIHNlcnZl ciBjZXJ0aWZpY2F0ZSB2YWxpZGF0aW9uIGFuZA0KPiA+IGF1dGhlbnRpY2F0aW9uIG9mIFRVUk4g c2VydmVyIGFyZSBkaXNjdXNzZWQgaW4gU2VjdGlvbiA2LjIuMyBvZg0KPiA+IFtJLUQuaWV0Zi10 cmFtLXN0dW5iaXNdDQo+IA0KPiBUaGF0IGhlbHBzLCBidXQgaXQgd291bGQgc3RpbGwgYmUgbmlj ZSB0byBnaXZlIHNvbWUgaW5kaWNhdGlvbiBvZiB3aGF0IGNlcnRpZmljYXRlDQo+IFBLSShzKSBh cmUgZXhwZWN0ZWQgdG8gYmUgdXNlZC4gIElzIGFueXRoaW5nIG90aGVyIHRoYW4gdGhlIFdlYiBQ S0kgdW5kZXINCj4gY29uc2lkZXJhdGlvbiA/DQoNCk5vLiBQbGVhc2Ugc2VlIGh0dHBzOi8vdG9v bHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXRyYW0tc3R1bmJpcy0yMSNzZWN0aW9uLTYuMi4z LCBJdCBkaXNjdXNzZXMgdG8gdmVyaWZ5IHRoZSBjZXJ0aWZpY2F0ZSBwYXRoIGFuZCBpZGVudGl0 eSBvZiB0aGUgc2VydmVyLg0KDQo+IA0KPiA+ID4tIFNlY3Rpb24gMy43OiBDb3VsZA0KPiA+ID4g VFVSTiBzZXJ2ZXJzIG5vdCBjaHVuayBkYXRhIGZyb20gc3RyZWFtLW9yaWVudGVkIHRyYW5zcG9y dHMgKFRDUCBvcg0KPiA+ID5UTFMpICB0byBhIHByZWZlcnJlZCBNVFUgc2l6ZSBiZWZvcmUgcmVs YXlpbmcgdG8gcGVlcnM/DQo+ID4gPiBTcGVjaWZpY2FsbHksIHRoZXJlIGFyZSBsaWtlbHkNCj4g PiA+IHNvbWUgY2FzZXMgd2hlcmVpbiB0aGUgc2VydmVyIGNvdWxkIGRlYWwgd2l0aCB0aGUgY2xp ZW50IGRhdGENCj4gPiA+bWVzc2FnZXMgIGxhcmdlciB0aGFuIHRoZSByZWNvbW1lbmRlZCA1MDBC IGxpbWl0LiBPbiB0aGF0IHBvaW50LA0KPiA+ID5zaG91bGQgc2VydmVycyBldmVuICBhY2NlcHQg ZGF0YSBsYXJnZXIgdGhhbiB0aGlzIHJlY29tbWVuZGVkIHNpemUgPw0KPiA+ID4tDQo+ID4NCj4g PiBQbGVhc2Ugc2VlDQo+ID4gaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYt dHJhbS10dXJuYmlzLTI3I3NlY3Rpb24tMTUgZm9yDQo+ID4gVENQLXRvLVVEUCByZWxheS4gSWYg dGhlIFBNVFUgaXMgbm90IGtub3duLCBhbmQgb24gbGVnYWN5IG9yIG90aGVyd2lzZQ0KPiA+IHVu dXN1YWwgbmV0d29ya3MsDQo+ID4gNTAwIGJ5dGUgbGltaXQgZm9yIGFwcGxpY2F0aW9uIGRhdGEg aXMgcmVjb21tZW5kZWQuDQo+ID4NCj4gPiA+IFNlY3Rpb24gMy45OiBUaGVyZSBtYXkgYmUNCj4g PiA+IGNhc2VzIHdoZXJlIHRoZSBUTFMgY29ubmVjdGlvbiBwb3N0IFRDUCBjb25uZWN0aW9uIGVz dGFibGlzaG1lbnQNCj4gPiA+IGZhaWxzLiBJdCB3b3VsZCB0aGVyZWZvcmUgc2VlbXMgcHJ1ZGVu dCB0byBub3QgZGVjbGFyZSB2aWN0b3J5IGZvcg0KPiA+ID4gb25lIGNvbm5lY3Rpb24gb3ZlciB0 aGUgb3RoZXIgdW50aWwgVExTIGNvbm5lY3RzLCB0b28uIC0NCj4gPg0KPiA+IEFncmVlZCwgRXJp YyAoYXMgcGFydCBvZiBJU0VHIHJldmlldykgc3VnZ2VzdGVkIHRvIHNpbXBsaWZ5IHRoZSB0ZXh0 LiBJIGhhdmUNCj4gdXBkYXRlZCB0aGUgdGV4dCBhcyBmb2xsb3dzOg0KPiA+DQo+ID4gICAgbyAg Rm9yIFRDUCBvciBUTFMtb3Zlci1UQ1AsIHRoZSByZXN1bHRzIG9mIHRoZSBIYXBweSBFeWViYWxs cw0KPiA+ICAgICAgIHByb2NlZHVyZSBbUkZDODMwNV0gYXJlIHVzZWQgYnkgdGhlIFRVUk4gY2xp ZW50IGZvciBzZW5kaW5nIGl0cw0KPiA+ICAgICAgIFRVUk4gbWVzc2FnZXMgdG8gdGhlIHNlcnZl ci4NCj4gDQo+IElzIHRoZSBlZGl0b3IncyBjb3B5IGF2YWlsYWJsZSBmb3Igdmlld2luZyBzb21l d2hlcmU/ICBJdCB3b3VsZCBiZSBnb29kIHRvDQo+IHNlZSB0aGlzIChhbmQgb3RoZXIgY2hhbmdl cykgaW4gY29udGV4dC4NCg0KWWVzLCBQbGVhc2Ugc2VlIGh0dHBzOi8vZ2l0aHViLmNvbS90aXJl ZGR5Mi9UVVJOYmlzIA0KDQo+IA0KPiA+ID4gU2VjdGlvbiAzIGNvdWxkIGJlbmVmaXQgZnJvbSBh DQo+ID4gPiBzdWJzZWN0aW9uIG9uIHJlcGxheXMgYW5kIHRoZSBub25jZSByb2xlLiBJbiBwYXJ0 aWN1bGFyLCBhcyBsYXRlcg0KPiA+ID4gZGlzY3Vzc2VkIGluIHRoZSBzZWN1cml0eSBjb25zaWRl cmF0aW9ucywgc29tZSBvZiB0aGVzZSBhdHRhY2tzIGFyZQ0KPiA+ID4gbm90IG5ldyB0byBUVVJO IGFuZCBzaG91bGQgdGhlcmVmb3JlIGJlIGRlYWx0IHdpdGggYnkgdGhlDQo+ID4gPiBhcHBsaWNh dGlvbiBwcm90b2NvbCAoU1JUUCkuIFRoaXMgc2VjdGlvbiBtaWdodCBhbHNvIGRlc2NyaWJlIG5v bmNlDQo+ID4gPiByb3RhdGlvbiBwb2xpY2llcyB3aXRoIG1vcmUgc3BlY2lmaWNpdHksIGFzIHRo aXMgaXMgdW5kZXJzcGVjaWZpZWQgaW4gdGhlDQo+IGRvY3VtZW50Lg0KPiA+DQo+ID4gSXQgaXMg ZGlzY3Vzc2VkIGluIFNlY3Rpb24gNSBpbiB0aGUgc3BlY2lmaWNhdGlvbiwgdGhlIHNlcnZlciBz aG91bGQgZXhwaXJlIHRoZQ0KPiBub25jZSBhdCBsZWFzdCBvbmNlIGV2ZXJ5IGhvdXIgZHVyaW5n IHRoZSBsaWZldGltZSBvZiB0aGUgYWxsb2NhdGlvbi4NCj4gPg0KPiA+ID4tIFNlY3Rpb24gMyBj b3VsZCBhbHNvIGJlbmVmaXQgZnJvbQ0KPiA+ID4gZGlzY3Vzc2lvbiBhYm91dCBjbGVhcnRleHQg dmVyc3VzIGVuY3J5cHRpb24gdHJhbnNwb3J0cyBiZXR3ZWVuDQo+ID4gPmNsaWVudHMgYW5kICBz ZXJ2ZXJzLg0KPiA+DQo+ID4gSXQgaXMgZGlzY3Vzc2VkIGluIGh0dHBzOi8vdG9vbHMuaWV0Zi5v cmcvaHRtbC9kcmFmdC1pZXRmLXRyYW0tdHVybmJpcy0NCj4gMjcjc2VjdGlvbi0yMS4xLjYuDQo+ IA0KPiBUaGVyZSdzIG5vdCBtdWNoIGRpc2N1c3Npb24gYWJvdXQgcG90ZW50aWFsIGluZm9ybWF0 aW9uICBsZWFrYWdlIHZpYSAoZS5nLikNCj4gVVNFUk5BTUUvVVNFUkhBU0gsIGFuZCByZWFsbHkg anVzdCBhIGNsYWltIHRoYXQgdGhlIHBlZXIgYWRkcmVzcyBpcyB0aGUNCj4gInByaW1hcnkgcHJv dG9jb2wgY29udGVudCIuDQoNCkFncmVlZCwgYWRkZWQgdGhlIGZvbGxvd2luZyBwYXJhZ3JhcGgg Og0KDQpJZiB0aGUgVFVSTiBjbGllbnQgYW5kIHNlcnZlciB1c2UgdGhlIFNUVU4gRXh0ZW5zaW9u IGZvciBUaGlyZC1QYXJ0eSBBdXRob3JpemF0aW9uIFtSRkM3NjM1XSwgdGhlIHVzZXJuYW1lIGRv ZXMgbm90IHJldmVhbCB0aGUNCnJlYWwgdXNlcidzIGlkZW50aXR5LCB0aGUgVVNFUk5BTUUgYXR0 cmlidXRlIGNhcnJpZXMgYW4gZXBoZW1lcmFsIGFuZCB1bmlxdWUga2V5IGlkZW50aWZpZXIsIGFu ZCB0aGUga2V5IGlkZW50aWZpZXIgY2FuIGNoYW5nZSBwZXIgY2FsbC4NCklmIHRoZSBUVVJOIGNs aWVudCBhbmQgc2VydmVyIHVzZSB0aGUgU1RVTiBsb25nLXRlcm0gY3JlZGVudGlhbCBtZWNoYW5p c20gYW5kIHRoZSB1c2VybmFtZSByZXZlYWxzIHRoZQ0KcmVhbCB1c2VyJ3MgaWRlbnRpdHksIHRo ZSBjbGllbnQgbmVlZCB0byBlaXRoZXIgdXNlIChEKVRMUyB0cmFuc3BvcnQgYmV0d2VlbiB0aGUg Y2xpZW50IGFuZCB0aGUgc2VydmVyIG9yIHVzZSANCnRoZSBVU0VSSEFTSCBhdHRyaWJ1dGUgaW5z dGVhZCBvZiB0aGUgVVNFUk5BTUUgYXR0cmlidXRlIHRvIGFub255bm1pemUgdGhlIHVzZXJuYW1l Lg0KDQo+IA0KPiA+ID4gRW5jcnlwdGluZyB0aGUgbm9uY2UsIHVzZXJuYW1lLCByZWFsbSwgZXRj LiwgYW1vbmcgb3RoZXIgdGhpbmdzLCBoYXMNCj4gPiA+IG9idmlvdXMgYmVuZWZpdHMuIC0gV2h5 IGFyZSBTT0ZUV0FSRSBhbmQgRklOR0VSUFJJTlQgYXR0cmlidXRlcw0KPiA+ID4gcmVjb21tZW5k ZWQ/ICBJdCBzZWVtcyBsaWtlIGNsaWVudHMgc2hvdWxkIGJlIGRpc2NvdXJhZ2VkIGZyb20NCj4g PiA+IHNlbmRpbmcgdGhlc2UgaWYgYW55dGhpbmcsIGVzcGVjaWFsbHkgaWYgbm90IHVzZWQgdG8g bWFrZSBhbGxvY2F0aW9uDQo+ID4gPiBkZWNpc2lvbnMgb24gdGhlIHNlcnZlci4NCj4gPg0KPiA+ IFVzZXJuYW1lIG1heSBub3QgYmUgdGhlIHVzZXIgaWRlbnRpdHksIFBsZWFzZSBzZWUNCj4gaHR0 cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzc2MzUpLCBJdCBjb3VsZCBiZSBhbiBlcGhlbWVy YWwgYW5kIHVuaXF1ZQ0KPiBrZXkgaWRlbnRpZmllci4gRnVydGhlciwgdXNlcm5hbWUgY2FuIGJl IGFub255bWl6ZWQgKHBsZWFzZSBzZWUNCj4gaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2Ry YWZ0LWlldGYtdHJhbS1zdHVuYmlzLTIxI3NlY3Rpb24tMTQuNCkuDQo+ID4gU09GVFdBUkUgYW5k IEZJTkdFUlBSSU5UIGF0dHJpYnV0ZXMgYXJlIGRlZmluZWQgaW4gdGhlIFNUVU4NCj4gc3BlY2lm aWNhdGlvbiwgc2VlIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXRyYW0t c3R1bmJpcy0yMS4NCj4gDQo+IFRoZXNlIG1lY2hhbmlzbXMgIGFyZSBwYXJ0aWFsIG1pdGlnYXRp b25zIGJ1dCBjYW4gc3RpbGwgYmUgc3VzY2VwdGlibGUgdG8gY3Jvc3MtDQo+IGNvbm5lY3Rpb24g Y29ycmVsYXRpb24gYXR0YWNrcy4NCg0KVGhlIHVzZSBvZiBGSU5HRVJQUklOVCBpcyBub3QgbWFu ZGF0b3J5LCB0aGUgVFVSTiBjbGllbnQgYW5kIHNlcnZlciBtYXkgaW5jbHVkZSB0aGUgRklOR0VS UFJJTlQgYXR0cmlidXRlLiAgTm90ZSB0aGF0IElDRSAoaHR0cHM6Ly90b29scy5pZXRmLm9yZy9o dG1sL3JmYzg0NDUpIG1hbmRhdGVzIHRoZSB1c2Ugb2YgRklOR0VSUFJJTlQgYXR0cmlidXRlLiBB ZGRlZCB0aGUgZm9sbG93aW5nIGxpbmUgZm9yIFNPRlRXQVJFIGF0dHJpYnV0ZSAoVFVSTmJpcyBp cyB1c2luZyB0aGUgc2FtZSBiZWhhdmlvciBkZWZpbmVkIGluIFJGQzU3NjYgdG8gdXNlIFNPRlRX QVJFIGF0dHJpYnV0ZSkgIDoNCg0KU09GV0FURSBhdHRyaWJ1dGUgY2FuIHJldmVhbCB0aGUgc3Bl Y2lmaWMgc29mdHdhcmUgdmVyc2lvbiBvZiB0aGUgVFVSTiBjbGllbnQgYW5kIHNlcnZlciB0byBl YXZlc2Ryb3BwZXIgYW5kIGl0IG1pZ2h0IHBvc3NpYmx5IGFsbG93IGF0dGFja3MgYWdhaW5zdCB2 dWxuZXJhYmxlIHNvZnR3YXJlIHRoYXQgaXMga25vd24gdG8gY29udGFpbiBzZWN1cml0eSBob2xl cy4gSWYgaXQgaXMgaW1wb3J0YW50IHRvIHByZXZlbnQgYW4gZWF2ZXNkcm9wcGVyIGZyb20gbGVh cm5pbmcgdGhlIHNvZnR3YXJlIHZlcnNpb24sIFRVUk4gY2FuIGJlIHJ1biBvdmVyIChEKVRMUy4N Cg0KDQo+IA0KPiA+IC0gU2VjdGlvbiA1OiBXaGVuIHNlcnZlcnMgcmVjZWl2ZSBkYXRhIHRoYXQg ZXhjZWVkcyBhbiBhbGxvY2F0aW9u4oCZcw0KPiA+ID4gYmFuZHdpZHRoIHF1b3RhLCBzZXJ2ZXJz IHNpbGVudGx5IGRpc2NhcmQgdGhpcyBkYXRhLiBUaGlzIG1lYW5zDQo+ID4gPiB0aGVyZeKAmXMg bm8gYWxsb2NhdGlvbi1iYXNlZCBmbG93IGNvbnRyb2wgbWVjaGFuaXNtIGJldHdlZW4gY2xpZW50 DQo+ID4gPiBhbmQgc2VydmVyIGJleW9uZCB3aGF04oCZcyBwcm92aWRlZCBieSB0aGUgdHJhbnNw b3J0IHByb3RvY29sLCByaWdodD8NCj4gPg0KPiA+IFllcywgVURQIGRvZXMgbm90IGluY2x1ZGUg YSBjb25nZXN0aW9uIGNvbnRyb2wgbWVjaGFuaXNtLg0KPiA+DQo+ID4gPiBUaGlzIHNlZW1zIGZp bmUsIHRob3VnaA0KPiA+ID4gcGVyaGFwcyBzb21lIGRpc2N1c3Npb24gb2Ygd2h5IHRoaXMgZGVz aWduIGRlY2lzaW9uIHdhcyBtYWRlIHdvdWxkDQo+ID4gPiBiZSBoZWxwZnVsLiBGb3IgZXhhbXBs ZSwgSSBjb3VsZCBpbWFnaW5lIGV4cGxpY2l0IHNpZ25hbHMgZnJvbQ0KPiA+ID4gc2VydmVycyB0 byBjbGllbnRzIHRoYXQgaW5kaWNhdGUgc2VydmVyIHN0YXRlIHdvdWxkIHJldmVhbA0KPiA+ID4g aW5mb3JtYXRpb24gYWJvdXQgb3RoZXIgYWxsb2NhdGlvbnMgb24gdGhlIHNlcnZlciwgd2hpY2gg bWlnaHQgYmUNCj4gPiA+IHByb2JsZW1hdGljLiAtDQo+ID4NCj4gPiBUaGUgZXJyb3JzIDQ4NiAo QWxsb2NhdGlvbiBRdW90YSBFeGNlZWRlZCkgb3IgNTA4IChJbnN1ZmZpY2llbnQgQ2FwYWNpdHkp DQo+IGRvIG5vdCByZXZlYWwgaW5mb3JtYXRpb24gb2Ygd2hpY2ggb3RoZXIgdXNlcnMgYXJlIHVz aW5nIHRoZSBUVVJOIHNlcnZlci4NCj4gDQo+IEF0IGxlYXN0IHRoZSBsYXR0ZXIgc2VlbXMgdG8g Z2l2ZSBzb21lIGluZGljYXRpb24gdGhhdCBtYW55IG90aGVyIHVzZXJzIGFyZQ0KPiB1c2luZyB0 aGUgc2VydmVyIGF0IHRoZSAgdGltZSAoc28gdGhhdCBpdCdzIG92ZXJsb2FkZWQpLCB0aG91Z2gg bm90IGluZm9ybWF0aW9uDQo+IGFib3V0ICp3aGljaCogdXNlcnMgdGhhdCBpcy4NCg0KWWVzLCBz aW1pbGFyIHRvIDUwMyBIVFRQIGVycm9yIHJlc3BvbnNlLg0KDQo+IA0KPiA+ID4gU2VjdGlvbiA3 LjIgc3VnZ2VzdHMgdGhhdA0KPiA+ID4gc2VydmVycyBjYW4gcmVkaXJlY3QgY2xpZW50IGFsbG9j YXRpb24gcmVxdWVzdHMgdG8gb3RoZXIgc2VydmVycy4NCj4gPiA+IENhbiB0aGlzIGNyZWF0ZSBh IGxvb3AsIHdoZXJlaW4gdHdvIFRVUk4gc2VydmVycyByZWRpcmVjdCB0byBvbmUgYW5vdGhlcj8N Cj4gPg0KPiA+IFRoZSBjbGllbnQgZGV0ZWN0IGFuZCBzdG9wIHRoZSBsb29wLCBpdCBpcyBzaW1p bGFyIHRvIEhUVFAgcmVkaXJlY3Rpb24uDQo+IA0KPiBXaGVyZSBpcyB0aGlzIHNwZWNpZmllZD8N Cg0KSXQgaXMgc3BlY2lmaWVkIGluIHRoZSBsYXN0IHBhcmFncmFwaCBvZiBodHRwczovL3Rvb2xz LmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi10cmFtLXN0dW5iaXMtMjEjc2VjdGlvbi0xMCANCg0K PHNuaXA+DQpJZiB0aGUgY2xpZW50IGhhcyBiZWVuIHJlZGlyZWN0ZWQgdG8gYQ0Kc2VydmVyIHRv IHdoaWNoIGl0IGhhcyBhbHJlYWR5IHNlbnQgdGhpcyByZXF1ZXN0IHdpdGhpbiB0aGUgbGFzdCBm aXZlDQptaW51dGVzLCBpdCBNVVNUIGlnbm9yZSB0aGUgcmVkaXJlY3Rpb24gYW5kIGNvbnNpZGVy IHRoZSB0cmFuc2FjdGlvbg0KdG8gaGF2ZSBmYWlsZWQuICBUaGlzIHByZXZlbnRzIGluZmluaXRl IHBpbmctcG9uZ2luZyBiZXR3ZWVuIHNlcnZlcnMNCmluIGNhc2Ugb2YgcmVkaXJlY3Rpb24gbG9v cHMuDQo8L3NuaXA+DQoNCkNoZWVycywNCi1UaXJ1DQoNCj4gDQo+IFRoYW5rcywNCj4gDQo+IEJl bg0KPiANCj4gPiA+IE1vcmVvdmVyLA0KPiA+ID4gaXMgaXQgYWNjZXB0YWJsZSBmb3Igb25lIFRV Uk4gc2VydmVyIHRvIHJlZGlyZWN0IHRvIGFuIHVucmVsYXRlZCBUVVJODQo+IHNlcnZlcj8NCj4g PiA+IChJdCBzaG91bGQgYmUgbWFkZSBjbGVhciBoZXJlIHRoYXQgdGhlc2UgcmVzcG9uc2VzIGFy ZQ0KPiA+ID4gYXV0aGVudGljYXRlZCwgYXMgb3RoZXJ3aXNlIGl0IHdvdWxkIGJlIHBvc3NpYmxl IGZvciBhbiBvbi1wYXRoDQo+ID4gPiBhZHZlcnNhcnkgdG8gcmVkaXJlY3QgYWxsb2NhdGlvbiBy ZXF1ZXN0cyB0byBhIHNlcnZlciBpdCBvd25zLikNCj4gPg0KPiA+IEl0IGlzIGFscmVhZHkgZGlz Y3Vzc2VkIGluDQo+ID4gaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtdHJh bS1zdHVuYmlzLTIxI3NlY3Rpb24tMTANCj4gPg0KPiA+ID4gLSBTZWN0aW9uDQo+ID4gPiAyMS4x LjI6IFVzZSBvZiAoRClUTFMgZG9lc27igJl0IGhlbHAgYWdhaW5zdCBkaWN0aW9uYXJ5IGF0dGFj a3MgbXVjaCwNCj4gPiA+IHNpbmNlIHByZXN1bWFibHkgdGhlcmXigJlzIGxvdyBlbnRyb3B5IGlu IHVzZXJuYW1lcyBhbmQgcGFzc3dvcmRzDQo+ID4gPiBhbGlrZS4gVGh1cywgSSBxdWVzdGlvbiB3 aGV0aGVyIHRoaXMgaXMgYSDigJxzdHJvbmdlcuKAnSBtaXRpZ2F0aW9uLg0KPiA+DQo+ID4gVGhl IHNlY3Rpb24gb25seSBkaXNjdXNzZXMgIm9mZmxpbmUiIGRpY3Rpb25hcnkgYXR0YWNrLCBIb3cg aXMgb2ZmbGluZQ0KPiBkaWN0aW9uYXJ5IGF0dGFjayBwb3NzaWJsZSB3aXRoIChEKVRMUyA/DQo+ ID4NCj4gPiA+LSBTZWN0aW9uIDEyLjEuNjog4oCcdXNlcm5hbWXigJ0NCj4gPiA+IGFuZCDigJxy ZWFsbeKAnSBhcmUgbm90IGNvbnNpZGVyZWQgc2Vuc2l0aXZlPyBUaGV5IHNlZW0gc2Vuc2l0aXZl IHRvIG1lLg0KPiA+ID4tIEFzIGFuICBleHRlbnNpb24sIGl0IHNlZW1zIHBvc3NpYmxlIHRvIGlt cHJvdmUgb24gd2hhdOKAmXMgaW4gU1RVTi4NCj4gPiA+Rm9yIGV4YW1wbGUsIGl0ICBtYXkgYmUg d29ydGh3aGlsZSwgaGVyZSBvciBlbHNld2hlcmUsIHRvIHVwZGF0ZQ0KPiA+ID5TVFVO4oCZcyBs b25nIHRlcm0gIGNyZWRlbnRpYWwga2V5IGRlcml2YXRpb24gcHJvY2VzcyAoTUQ1KHVzZXJuYW1l ICsNCj4gPiA+cmVhbG0gKyBwYXNzd29yZCkpIHRvICBzb21ldGhpbmcgYSBiaXQgbW9yZSBtb2Rl cm4uIFRoaXMgaXMgcXVpdGUNCj4gPiA+bGlrZWx5IG91dCBvZiBzY29wZSwgdGhvdWdoIGluIHRo ZSAgY29udGV4dCBvZiBjbGllbnQgYXV0aGVudGljYXRpb24NCj4gPiA+aXQgc2VlbXMgd29ydGgg bWVudGlvbmluZyB0aGF0IFRVUk4gaXMgIGxpbWl0ZWQgdG8gdGhlIG1lY2hhbmlzbXMNCj4gcHJv dmlkZWQgYnkgU1RVTi4NCj4gPg0KPiA+IEFzIG1lbnRpb25lZCBwcmV2aW91c2x5LCB1c2VybmFt ZSBtYXkgbm90IGJlIHRoZSBlbmQtdXNlciByZWFsIGlkZW50aXR5DQo+IGFuZCB1c2VybmFtZSBj YW4gYmUgYW5vbnltaXplZC4NCj4gPg0KPiA+ID4NCj4gPiA+IE5pdHMgYW5kIG90aGVyIGNvbW1l bnRzOg0KPiA+ID4NCj4gPiA+IC0gU2VjdGlvbiAyOiDigJxtZXNzYWdlLWRpZ2VzdOKAnSBpcyB1 bmRlZmluZWQgaW4gdGhlIE5vbmNlIGRlZmluaXRpb24uDQo+ID4NCj4gPiBUaGFua3MsIHJlcGxh Y2VkICJtZXNzYWdlLWRpZ2VzdCIgd2l0aCAic2VydmVyIHJlc3BvbnNlIg0KPiA+DQo+ID4gPiAt IFNlY3Rpb24gMzogSXTigJlzIHByb2JhYmx5IHdvcnRoIGNpdGluZyBSRkM4NDQ2IGFzIHRoZSBy ZWNvbW1lbmRlZA0KPiA+ID4gdmVyc2lvbiBvZiBUTFMuDQo+ID4NCj4gPiBUaGUgZHJhZnQgc2F5 cyBndWlkYW5jZSBnaXZlbiBpbiBbUkZDNzUyNV0gTVVTVCBiZSBmb2xsb3dlZCB0byBhdm9pZA0K PiBhdHRhY2tzIG9uIChEKVRMUy4gUkZDNzUyNSBzYXlzIFRMUyAxLjMgcmVzb2x2ZXMgdGhlIHZ1 bG5lcmFiaWxpdGllcyBmb3VuZCBpbg0KPiBwcmV2aW91cyBUTFMgdmVyc2lvbnMuDQo+ID4NCj4g PiA+LSBTZWN0aW9uIDMuNDogSXQgbWlnaHQgYmUgd29ydGggbWVudGlvbmluZyB0aGF0IHVzZSBv ZiAoRClUTFMgZm9yDQo+ID4gPnRoZSAgY2xpZW50LXRvLXNlcnZlciB0cmFuc3BvcnQgbWl0aWdh dGVzIHRoZSBuZWVkIGZvciBTZW5kIGFuZCBEYXRhDQo+ID4gPmF1dGhlbnRpY2F0aW9uLg0KPiA+ DQo+ID4gaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtdHJhbS10dXJuYmlz LTI3I3NlY3Rpb24tMjEuMS40DQo+IGRpc2N1c3NlcyB0aGlzIGlzc3VlIGluIGRldGFpbC4NCj4g Pg0KPiA+ID4gLSBTZWN0aW9uIDMuNDogV2hhdCBkb2VzIOKAnHByb3BlciBzZWN1cml0eeKAnSBt ZWFuPw0KPiA+DQo+ID4gVGhhbmtzLCByZXBsYWNlZCAicHJvcGVyIHNlY3VyaXR5IiB3aXRoICJl bmQtdG8tZW5kIHNlY3VyaXR5Ii4NCj4gPg0KPiA+ID4tIEZpZ3VyZSA0OiBBZGRpbmcgYW5vdGhl cg0KPiA+ID4gbWVzc2FnZSBleGNoYW5nZSB3aGVyZWluIGEgY2hhbm5lbCBtZXNzYWdlIGlzIHNl bnQgd2l0aG91dCBhIHByaW9yDQo+ID4gPkNoYW5uZWxCaW5kIHJlcXVlc3Qgd291bGQgYmUgdXNl ZnVsIHRvIGhpZ2hsaWdodCB0aGlzIGRlcGVuZGVuY3kgYW5kDQo+ID4gPmV4cGVjdGVkIGJlaGF2 aW9yIGZyb20gY2xpZW50cyBhbmQgc2VydmVycy4NCj4gPg0KPiA+IGh0dHBzOi8vdG9vbHMuaWV0 Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXRyYW0tdHVybmJpcy0yNyNzZWN0aW9uLTEyLjYgZXhwbGFp bnMNCj4gdGhhdCBJZiB0aGUgQ2hhbm5lbERhdGEgbWVzc2FnZSBpcyByZWNlaXZlZCBvbiBhIGNo YW5uZWwgdGhhdCBpcyBub3QgYm91bmQgdG8NCj4gYW55IHBlZXIsIHRoZW4gdGhlIG1lc3NhZ2Ug aXMgc2lsZW50bHkgZGlzY2FyZGVkLg0KPiA+DQo+ID4gPiAtIFNlY3Rpb24gMy42OiBBbm90aGVy IGJlbmVmaXQgb2YNCj4gPiA+IHRoaXMgdXNlciBzcGFjZSBkZXNpZ24gZGVjaXNpb24gaXMgdXNl IG9mIChEKVRMUyBsaW5rcy4gLQ0KPiA+DQo+ID4gR29vZCBwb2ludCwgdXBkYXRlZCBsaW5lIHRv IHNheToNCj4gPiBmb3IgZXhhbXBsZSwgdG8gYWxsb3cgYSBUVVJOIHNlcnZlciB0byBiZSBpbnRl Z3JhdGVkIGludG8gYSBwZWVyLXRvLXBlZXINCj4gYXBwbGljYXRpb24gc28gdGhhdCBvbmUgcGVl ciBjYW4gb2ZmZXIgTkFUIHRyYXZlcnNhbCBzZXJ2aWNlcyB0byBhbm90aGVyIHBlZXINCj4gYW5k IHRvIHVzZSAoRClUTFMgdG8gc2VjdXJlIHRoZSBUVVJOIGNvbm5lY3Rpb24uDQo+ID4NCj4gPiAg U2VjdGlvbiA1OiBXaGVyZSBkaWQNCj4gPiA+IHRoZSA0MCBzZWNvbmQgcmVxdWVzdCBidWZmZXIg dGltZW91dCBjb21lIGZyb20/DQo+ID4NCj4gPiBJdCBpcyBjb21pbmcgZnJvbSB0aGUgU1RVTiBz cGVjaWZpY2F0aW9uIChzZWUNCj4gPiBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQt aWV0Zi10cmFtLXN0dW5iaXMtMjEjc2VjdGlvbi02LjMuMSkNCj4gPg0KPiA+ID4gQWRkaW5nIHNv bWUgZGV0YWlscw0KPiA+ID4gbWlnaHQgaGVscC4gLSBTZWN0aW9uIDY6IOKAnHNlY3VyZSBoYXNo 4oCdIGlzIHVuZGVmaW5lZCwgdGhvdWdoDQo+ID4gPiBwcmVzdW1hYmx5IHdoYXQgaXMgbWVhbnQg aXMgYSBjcnlwdG9ncmFwaGljIGhhc2ggd2l0aCBjb2xsaXNpb24NCj4gPiA+IHJlc2lzdGFuY2Uu IEl0IHdvdWxkIGJlIGdvb2QgdG8gY2xhcmlmeSB0aGlzIHJlcXVpcmVtZW50Lg0KPiA+DQo+ID4g WWVzLCByZXBsYWNlZCB3aXRoICIgY3J5cHRvZ3JhcGhpYyBoYXNoIi4NCj4gPg0KPiA+ID4gLSBT ZWN0aW9uIDcuNDogV2hhdCBpcyB0aGUgcmV0cnkgYmVoYXZpb3IgaWYgYWxsb2NhdGlvbiByZXF1 ZXN0cw0KPiA+ID4gdGltZW91dD8NCj4gPg0KPiA+IFRoZSByZXRyeSBiZWhhdmlvciBpcyBkaXNj dXNzZWQgYXMgZm9sbG93czoNCj4gPg0KPiA+ICAgIG8gIChSZXF1ZXN0IHRpbWVkIG91dCk6IFRo ZXJlIGlzIGVpdGhlciBhIHByb2JsZW0gd2l0aCB0aGUgc2VydmVyLCBvcg0KPiA+ICAgICAgIGEg cHJvYmxlbSByZWFjaGluZyB0aGUgc2VydmVyIHdpdGggdGhlIGNob3NlbiB0cmFuc3BvcnQuICBU aGUNCj4gPiAgICAgICBjbGllbnQgY29uc2lkZXJzIHRoZSBjdXJyZW50IHRyYW5zYWN0aW9uIGFz IGhhdmluZyBmYWlsZWQgYnV0IE1BWQ0KPiA+ICAgICAgIGNob29zZSB0byByZXRyeSB0aGUgQWxs b2NhdGUgcmVxdWVzdCB1c2luZyBhIGRpZmZlcmVudCB0cmFuc3BvcnQNCj4gPiAgICAgICAoZS5n LiwgVENQIGluc3RlYWQgb2YgVURQKS4NCj4gPg0KPiA+DQo+ID4gPi0gU2VjdGlvbiAxMi41OiBU aGUgU1RVTiByZXF1aXJlbWVudCBmb3IgNC1ieXRlICBhbGlnbm1lbnQgc2hvdWxkIGJlDQo+ID4g PmNpdGVkIHdoZW4gZGlzY3Vzc2luZyB0aGUgVENQIGFuZCBUTFMgcGFkZGluZyAgcmVxdWlyZW1l bnQuDQo+ID4NCj4gPiBEb25lLg0KPiA+DQo+ID4gPiAtIFNlY3Rpb24gMTU6IFR5cG8g4oCcRE9O 4oCZVCBGUkFHTUVOVOKAnS4NCj4gPg0KPiA+IEZpeGVkLg0KPiA+DQo+ID4gQ2hlZXJzLA0KPiA+ IC1UaXJ1DQo+ID4NCj4gPiA+DQo+ID4gPg0KPiA+ID4gX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCj4gPiA+IHRyYW0gbWFpbGluZyBsaXN0DQo+ID4gPiB0 cmFtQGlldGYub3JnDQo+ID4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L3RyYW0NCg== From nobody Wed Jul 10 05:48:08 2019 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 0FE4E1201AA for ; Wed, 10 Jul 2019 05:48:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=mcafee.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id esnYXIkENsJ2 for ; Wed, 10 Jul 2019 05:48:00 -0700 (PDT) Received: from us-smtp-delivery-210.mimecast.com (us-smtp-delivery-210.mimecast.com [216.205.24.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 45C50120153 for ; Wed, 10 Jul 2019 05:47:56 -0700 (PDT) X-NAI-Header: Modified by McAfee Email Gateway (5500) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mcafee.com; s=s_mcafee; t=1562762178; h=ARC-Seal: ARC-Message-Signature:ARC-Authentication-Results: From:To:CC:Subject:Thread-Topic:Thread-Index: Date:Message-ID:References:In-Reply-To:Accept-Language: Content-Language:X-MS-Has-Attach:X-MS-TNEF-Correlator: dlp-product:dlp-version:dlp-reaction:authentication-results: x-originating-ip:x-ms-publictraffictype:x-ms-office365-filtering-correlation-id: x-microsoft-antispam:x-ms-traffictypediagnostic: x-ms-exchange-purlcount:x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers:x-forefront-prvs: x-forefront-antispam-report:received-spf:x-ms-exchange-senderadcheck: x-microsoft-antispam-message-info:Content-Type: Content-Transfer-Encoding:MIME-Version:X-MS-Exchange-CrossTenant-Network-Message-Id: X-MS-Exchange-CrossTenant-originalarrivaltime: X-MS-Exchange-CrossTenant-fromentityheader: X-MS-Exchange-CrossTenant-id:X-MS-Exchange-CrossTenant-mailboxtype: X-MS-Exchange-CrossTenant-userprincipalname: X-MS-Exchange-Transport-CrossTenantHeadersStamped: X-OriginatorOrg:X-NAI-Spam-Flag:X-NAI-Spam-Level: X-NAI-Spam-Threshold:X-NAI-Spam-Score:X-NAI-Spam-Version; bh=S4ZOrgv3S/qMXxPATjrxOXaelnm7l5vg/3KBQi PKozg=; b=eC97pau9w0IY94xi+f8TpEeNo6WE+YFJmRccTY7W UVSDbFiw+CCifoQ1g4Wm/PIqPXQZ5GY57GoYXEh4TVub9ahHB6 4lbT0b5Z1FhaLmixPRdvS00r0dw5uvZF8ziq7ncGMd4coLG5sS 7G7xfNqfreNvJj3XUEEKQYSxG8g9CsU= Received: from DNVWSMAILOUT1.mcafee.com (dnvwsmailout1.mcafee.com [161.69.31.173]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-137-CRZ7qwlHNQyp075D9M7vYw-1; Wed, 10 Jul 2019 08:46:48 -0400 Received: from DNVEXAPP1N05.corpzone.internalzone.com (DNVEXAPP1N05.corpzone.internalzone.com [10.44.48.89]) by DNVWSMAILOUT1.mcafee.com with smtp (TLS: TLSv1/SSLv3,256bits,ECDHE-RSA-AES256-SHA384) id 6fce_8093_bf7170fc_b22f_40d2_ba5e_a84fccaedc88; Wed, 10 Jul 2019 06:36:16 -0600 Received: from DNVEXAPP1N05.corpzone.internalzone.com (10.44.48.89) by DNVEXAPP1N05.corpzone.internalzone.com (10.44.48.89) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Wed, 10 Jul 2019 06:46:43 -0600 Received: from DNVO365EDGE1.corpzone.internalzone.com (10.44.176.66) by DNVEXAPP1N05.corpzone.internalzone.com (10.44.48.89) with Microsoft SMTP Server (TLS) id 15.0.1395.4 via Frontend Transport; Wed, 10 Jul 2019 06:46:43 -0600 Received: from NAM05-DM3-obe.outbound.protection.outlook.com (10.44.176.242) by edge.mcafee.com (10.44.176.66) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Wed, 10 Jul 2019 06:46:41 -0600 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=KWXaFCEKll1SCTBoCz42U57yLwWKHb7YMDser4v+jFWbDoJ/Hz6/jEgyaDEc42YyxKNBUHmUp62TzZzeXliBLioHVX0aivLOI1yisyCqGgZi/z2SLNYa9YKMpzBJ1qtlcID/wUqkFoKd3MyTp1zf4tsbCNZdsLRaJSR2gK46Jjf0KXUAY5/qOyEea65927lI25alC1/eCBAATzdtAP8AShtMINqV7ehggfz7P7k/WVxwpdsujFFMh0NV/QU+9QxeAb4ZhRnrQhsYtUx32pmxLl0TO0oTXykxKCyqydHWscHu37W3lnEQ+9isLB/LZv8dFhTETePRKe3dZZWtlkN8kw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=S4ZOrgv3S/qMXxPATjrxOXaelnm7l5vg/3KBQiPKozg=; b=oXwvkvthVceMDm5hboNYz3iB5s3GbbGg/aDE+6twSV9gLTIi22kFphq8CDI0v8Sp29ScjPe+KsY36mn68l1qCYa5lrT/+h47WNZ3waRzRZQ7zlrTuIrlyeaMLqsQy26d7MmqL2c0sxL8Qh+Kku3Z7zsH4mnATBIyf/6QPznXlKjPNfvIHTdSINko0rA292HETffvxAmurNBYWacLlMcpvUFdeyBxHafVZkapsT8C8YpVv9wcYRXJ2LC0XCJyVT0Wb+fSN37ySiGhYe/ZOljM2jIO6rc6eveBXYofmsjQPu5Ejx/hgGRffoE9V+yQSDwmfK5rPuYU5XD882ylwnSAPQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1;spf=pass smtp.mailfrom=mcafee.com;dmarc=pass action=none header.from=mcafee.com;dkim=pass header.d=mcafee.com;arc=none Received: from DM5PR16MB1705.namprd16.prod.outlook.com (10.172.44.147) by DM5PR16MB1801.namprd16.prod.outlook.com (10.174.176.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2073.10; Wed, 10 Jul 2019 12:46:42 +0000 Received: from DM5PR16MB1705.namprd16.prod.outlook.com ([fe80::570:2208:75c2:5f17]) by DM5PR16MB1705.namprd16.prod.outlook.com ([fe80::570:2208:75c2:5f17%8]) with mapi id 15.20.2052.019; Wed, 10 Jul 2019 12:46:42 +0000 From: "Konda, Tirumaleswar Reddy" To: Adam Roach , The IESG CC: "tram-chairs@ietf.org" , "draft-ietf-tram-turnbis@ietf.org" , "tram@ietf.org" , "brandon.williams@akamai.com" Thread-Topic: [tram] Adam Roach's Yes on draft-ietf-tram-turnbis-27: (with COMMENT) Thread-Index: AQHVNuNvk6w2nRIeqkCYsEyuEMwziqbDjUlA Date: Wed, 10 Jul 2019 12:46:42 +0000 Message-ID: References: <156273781850.15858.12819016613039810127.idtracker@ietfa.amsl.com> In-Reply-To: <156273781850.15858.12819016613039810127.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.3.0.16 dlp-reaction: no-action x-originating-ip: [49.37.206.28] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 31cc8d32-befc-420e-dac8-08d70534a8c2 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:DM5PR16MB1801; x-ms-traffictypediagnostic: DM5PR16MB1801: x-ms-exchange-purlcount: 4 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0094E3478A x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(366004)(346002)(396003)(136003)(376002)(39860400002)(189003)(32952001)(51914003)(199004)(13464003)(476003)(6306002)(11346002)(74316002)(55016002)(9686003)(486006)(229853002)(305945005)(446003)(71190400001)(53936002)(71200400001)(6436002)(81166006)(80792005)(25786009)(8676002)(81156014)(478600001)(8936002)(966005)(33656002)(7736002)(256004)(14444005)(4326008)(68736007)(14454004)(66476007)(66446008)(66946007)(64756008)(7696005)(66556008)(99286004)(6246003)(186003)(26005)(3846002)(76116006)(76176011)(53546011)(6506007)(102836004)(52536014)(316002)(6116002)(110136005)(86362001)(5660300002)(54906003)(2906002)(66066001)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR16MB1801; H:DM5PR16MB1705.namprd16.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: CjN0Hyt6dmPpDjqscCNNvXk5fCjvt/W/zsr7t3hURjGuq1nMZyysvXNK5faMFaTxLO4QY1lrpKgwpS2zSyOGYVUWANyxdV5gaHHxQI+zuG3wzBs/6x7fS3HfUuU07fWYitgaatNFkGYudBCsg0phs/YLzVUCv3M98ig2JN4ox4K5v20m3f6p+zkbEZXe8B4lkYTxcCmfofuNOXPrfHxYfO+nKKBhpnfvzwTO3PkML6bLyX0WEjCn3RhsNmDePHDEeAd5+LqXMc0OlHR19ImgBDgw2NDMZuZCcYassp7OuH2+jf4mGKY8HsGWDgFJcgV1bSEn7sCY0ec24qGt51eOUOjY+1yK+hf1c239k5FtNocnroOj2pSxAWRF4h1nZ5C2sZ1xPbp71WWKT+QkQHasUDBoo9KnZwVzlGRL+5sdIu4= MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 31cc8d32-befc-420e-dac8-08d70534a8c2 X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Jul 2019 12:46:42.2233 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: TirumaleswarReddy_Konda@McAfee.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR16MB1801 X-OriginatorOrg: mcafee.com X-NAI-Spam-Flag: NO X-NAI-Spam-Level: X-NAI-Spam-Threshold: 15 X-NAI-Spam-Score: 0.3 X-NAI-Spam-Version: 2.3.0.9418 : core <6586> : inlines <7115> : streams <1826946> : uri <2865939> X-MC-Unique: CRZ7qwlHNQyp075D9M7vYw-1 X-Mimecast-Spam-Score: 0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Archived-At: Subject: Re: [tram] Adam Roach's Yes on draft-ietf-tram-turnbis-27: (with COMMENT) X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.29 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 Jul 2019 12:48:03 -0000 SGkgQWRhbSwNCg0KVGhhbmtzIGZvciB0aGUgcmV2aWV3LiBQbGVhc2Ugc2VlIGlubGluZQ0KDQo+ IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IHRyYW0gPHRyYW0tYm91bmNlc0Bp ZXRmLm9yZz4gT24gQmVoYWxmIE9mIEFkYW0gUm9hY2ggdmlhDQo+IERhdGF0cmFja2VyDQo+IFNl bnQ6IFdlZG5lc2RheSwgSnVseSAxMCwgMjAxOSAxMToyMCBBTQ0KPiBUbzogVGhlIElFU0cgPGll c2dAaWV0Zi5vcmc+DQo+IENjOiB0cmFtLWNoYWlyc0BpZXRmLm9yZzsgZHJhZnQtaWV0Zi10cmFt LXR1cm5iaXNAaWV0Zi5vcmc7IHRyYW1AaWV0Zi5vcmc7DQo+IGJyYW5kb24ud2lsbGlhbXNAYWth bWFpLmNvbQ0KPiBTdWJqZWN0OiBbdHJhbV0gQWRhbSBSb2FjaCdzIFllcyBvbiBkcmFmdC1pZXRm LXRyYW0tdHVybmJpcy0yNzogKHdpdGgNCj4gQ09NTUVOVCkNCj4gDQo+IA0KPiANCj4gQWRhbSBS b2FjaCBoYXMgZW50ZXJlZCB0aGUgZm9sbG93aW5nIGJhbGxvdCBwb3NpdGlvbiBmb3INCj4gZHJh ZnQtaWV0Zi10cmFtLXR1cm5iaXMtMjc6IFllcw0KPiANCj4gV2hlbiByZXNwb25kaW5nLCBwbGVh c2Uga2VlcCB0aGUgc3ViamVjdCBsaW5lIGludGFjdCBhbmQgcmVwbHkgdG8gYWxsIGVtYWlsDQo+ IGFkZHJlc3NlcyBpbmNsdWRlZCBpbiB0aGUgVG8gYW5kIENDIGxpbmVzLiAoRmVlbCBmcmVlIHRv IGN1dCB0aGlzIGludHJvZHVjdG9yeQ0KPiBwYXJhZ3JhcGgsIGhvd2V2ZXIuKQ0KPiANCj4gDQo+ IFBsZWFzZSByZWZlciB0byBodHRwczovL3d3dy5pZXRmLm9yZy9pZXNnL3N0YXRlbWVudC9kaXNj dXNzLWNyaXRlcmlhLmh0bWwNCj4gZm9yIG1vcmUgaW5mb3JtYXRpb24gYWJvdXQgSUVTRyBESVND VVNTIGFuZCBDT01NRU5UIHBvc2l0aW9ucy4NCj4gDQo+IA0KPiBUaGUgZG9jdW1lbnQsIGFsb25n IHdpdGggb3RoZXIgYmFsbG90IHBvc2l0aW9ucywgY2FuIGJlIGZvdW5kIGhlcmU6DQo+IGh0dHBz Oi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtdHJhbS10dXJuYmlzLw0KPiAN Cj4gDQo+IA0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IENPTU1FTlQ6DQo+IC0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4g DQo+IFRoYW5rcyBmb3IgYWxsIHRoZSB3b3JrIGV2ZXJ5b25lIGRpZCB0byB1cGRhdGUgdGhlIFRV Uk4gc3BlY2lmaWNhdGlvbi4gSSBhbQ0KPiBiYWxsb3RpbmcgIlllcywiIGFzIEkgdGhpbmsgdGhl c2UgYXJlIGltcG9ydGFudCBjaGFuZ2VzIHRvIGhhdmUgcHVibGlzaGVkLiBJIGRvDQo+IGhhdmUg YSBzbWFsbCBoYW5kZnVsIG9mIGNvbW1lbnRzIHRoYXQsIHdoaWxlIHRoZXkgZG9uJ3QgcmlzZSB0 byB0aGUgbGV2ZWwgb2YgYQ0KPiBESVNDVVNTLCBhcmUgbm9uZXRoZWxlc3MgcmF0aGVyIGltcG9y dGFudCB0byBjb25zaWRlciBiZWZvcmUgcHJvZ3Jlc3NpbmcNCj4gdGhpcyBkcmFmdCB0byBhbiBS RkMuDQo+IA0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gDQo+IMKnNToNCj4gDQo+ID4gIFRoZSBz ZXJ2ZXIgU0hPVUxEDQo+ID4gIGluY2x1ZGUgdGhlIFNPRlRXQVJFIGF0dHJpYnV0ZSBpbiBhbGwg QWxsb2NhdGUgYW5kIFJlZnJlc2ggcmVzcG9uc2VzDQo+ID4gKGVpdGhlciBzdWNjZXNzIG9yIGZh aWx1cmUpIGFuZCBNQVkgaW5jbHVkZSBpdCBpbiBvdGhlciByZXNwb25zZXMgb3INCj4gPiBpbmRp Y2F0aW9ucy4NCj4gDQo+IFRoZSBTZWN1cml0eSBDb25zaWRlcmF0aW9ucyBzZWN0aW9uIHNob3Vs ZCBwcm9iYWJseSBpbmNsdWRlIHNvbWUgbWVudGlvbg0KPiBvZiB0aGlzIGJlaGF2aW9yLCBhbmQg dGhlIHRyYWRlLW9mZnMgYmV0d2VlbiBhbGxvd2luZyBjbGllbnRzIHRvIGtub3cgd2hpY2gNCj4g c29mdHdhcmUgKGFuZCB2ZXJzaW9uKSB0aGUgc2VydmVyIGlzIHJ1bm5pbmcgYWdhaW5zdCBwcm92 aWRpbmcgdGhpcw0KPiBpbmZvcm1hdGlvbiB0byBwb3RlbnRpYWwgYXR0YWNrZXJzIHdobyBjYW4g dXNlIGl0IHRvIGRldGVybWluZSB3aGF0DQo+IHNvZnR3YXJlIHZ1bG5lcmFiaWxpdGllcyBtYXkg ZXhpc3QgaW4gdGhhdCBzcGVjaWZpYyBzZXJ2ZXIgYW5kIHZlcnNpb24uDQoNClllcywgQmVuIGFu ZCBDaHJpc3RvcGhlciByYWlzZWQgc2ltaWxhciBwb2ludCBhcyBwYXJ0IG9mIFNlY2RpciByZXZp ZXcuICBJIHByb3Bvc2VkIHRvIHVwZGF0ZSBTZWN1cml0eSBDb25zaWRlcmF0aW9ucyBzZWN0aW9u IGFzIGZvbGxvd3M6DQpTT0ZXQVRFIGF0dHJpYnV0ZSBjYW4gcmV2ZWFsIHRoZSBzcGVjaWZpYyBz b2Z0d2FyZSB2ZXJzaW9uIG9mIHRoZSBUVVJOIGNsaWVudCBhbmQgc2VydmVyIHRvIGVhdmVzZHJv cHBlciBhbmQgaXQgbWlnaHQgcG9zc2libHkgYWxsb3cgYXR0YWNrcyBhZ2FpbnN0IHZ1bG5lcmFi bGUgc29mdHdhcmUgdGhhdCBpcyBrbm93biB0byBjb250YWluIHNlY3VyaXR5IGhvbGVzLiBJZiBp dCBpcyBpbXBvcnRhbnQgdG8gcHJldmVudCBhbiBlYXZlc2Ryb3BwZXIgZnJvbSBsZWFybmluZyB0 aGUgc29mdHdhcmUgdmVyc2lvbiwgDQpUVVJOIGNhbiBiZSBydW4gb3ZlciAoRClUTFMuDQoNCj4g DQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiANCj4gwqcxMS41Og0KPiANCj4gPiAgIEl0IGFsc28g dmVyaWZpZXMgdGhhdCB0aGUgSVANCj4gPiAgIHBhY2tldCBpbiB0aGUgSUNNUCBwYWNrZXQgcGF5 bG9hZCBjb250YWlucyBhIFVEUCBoZWFkZXIuDQo+IA0KPiBJdCdzIG5vdCBjbGVhciB3aGF0IGlz IGJlaW5nIGFza2VkIG9mIGltcGxlbWVudGF0aW9ucyBoZXJlLiBJcyB0aGlzIGp1c3QgYSBjaGVj aw0KPiBvZiB0aGUgcHJvdG9jb2wgZmllbGQsIG9yIGlzIGl0IG1vcmUgaW52b2x2ZWQgdGhhbiB0 aGF0PyBJcyB0aGUgaW50ZW50aW9uIHRoYXQgdGhlDQo+IHNlcnZlciBhbHNvIGNoZWNrIHRoYXQg dGhlIGNoZWNrc3VtIGlzIHZhbGlkIChpLmUuLCBtYXRjaGVzIHRoZSBjb21wdXRlZA0KPiBjaGVj a3N1bSBvciBpcyB6ZXJvKT8gSWYgc28sIHBsZWFzZSBzcGVsbCBpdCBvdXQgbW9yZSBwcmVjaXNl bHkuDQo+IElmIHRoaXMgbGFuZ3VhZ2UgaXMgaW50ZW5kZWQgdG8gaW1wbHkgZXZlbiBtb3JlIHJp Z29yb3VzIGNoZWNrcywgdGhlbiBpdCBuZWVkcw0KPiBhIGxvdCBtb3JlIHRleHQuDQoNClRoZSBj aGVjayBpcyBvbmx5IHRvIGV4dHJhY3QgdGhlIFVEUCBzb3VyY2UgYW5kIGRlc3RpbmF0aW9uIHBv cnRzLiBJIHdpbGwgdXBkYXRlIHRoZSBsaW5lIGFzIGZvbGxvd3M6DQpJdCBhbHNvIHZlcmlmaWVz IHRoYXQgdGhlIElQIHBhY2tldCBpbiB0aGUgSUNNUCBwYWNrZXQgcGF5bG9hZCBjb250YWlucyBh IFVEUCBoZWFkZXIsIGFuZCBpZiBhIFVEUCBoZWFkZXIgaXMgcHJlc2VudCwgdGhlIHNlcnZlciBl eHRyYWN0cyB0aGUgVURQIHNvdXJjZSBhbmQgZGVzdGluYXRpb24gcG9ydCBpbmZvcm1hdGlvbi4N Cg0KPiANCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IA0KPiDCpzEyOg0KPiANCj4gPiAgICAgMHg1 MDAwLTB4RkZGRjogUmVzZXJ2ZWQgKEZvciBEVExTLVNSVFAgbXVsdGlwbGV4aW5nIGNvbGxpc2lv bg0KPiA+ICAgICBhdm9pZGFuY2UsIHNlZSBbUkZDNzk4M10uDQo+IA0KPiBHaXZlbiB0aGF0IHZh bHVlcyB0aHJvdWdoIDB4N0ZGRiB3ZXJlIHBlcm1pdHRlZCBieSB0aGUgcHJldmlvdXMgdmVyc2lv biBvZg0KPiB0aGUgcHJvdG9jb2wsIGl0J3MgdW5jbGVhciB3aGF0IHdoYXQgcmVjb3ZlcnkgcGF0 aCB0aGlzIGRvY3VtZW50IGFudGljaXBhdGVzDQo+IGZvciBsZWdhY3kgY2xpZW50cyB0aGF0IG1p Z2h0IHJlcXVlc3QgY2hhbm5lbHMgaW4gdGhlIDB4NTAwMCAtIDB4N0ZGRSByYW5nZS4NCj4gVGhl IHNlcnZlciBiZWhhdmlvciBpcyB3ZWxsIGRlZmluZWQgKHRoZSBzZXJ2ZXIgc2VuZHMgYSA0MDAg cmVzcG9uc2UpLCBidXQNCj4gdGhpcyBzZWVtcyB0byByZXByZXNlbnQgYSBmdW5kYW1lbnRhbCBi YWNrd2FyZHMgaW5jb21wYXRpYmlsaXR5LCBnaXZlbiB0aGF0DQo+IHRoZSBjbGllbnQgd2lsbCB0 YWtlIHRoaXMgdG8gYmUgYSBmaW5hbCByZXF1ZXN0IGVycm9yIGFuZCBwcmVzdW1hYmx5IGFiYW5k b24NCj4gdGhlIGF0dGVtcHQgdG8gdXNlIHRoZSBUVVJOIHNlcnZlci4NCj4gDQo+IElmIHRoZSBh c3N1bXB0aW9uIGlzIHRoYXQgbm8gZXhpc3RpbmcgZGVwbG95ZWQgbGVnYWN5IGNsaWVudHMgdXNl IGNoYW5uZWwNCj4gbnVtYmVycyBncmVhdGVyIHRoYW4gMHg0RkZGLCBwbGVhc2UgaW5jbHVkZSB0 aGF0IGFzIGEgbm90ZS4gSWYgdGhlIGludGVudGlvbiBpcw0KPiBpbnN0ZWFkIHRoYXQgd2UncmUg YnJlYWtpbmcgYmFja3dhcmRzIGNvbXBhdGliaWxpdHkgaW4gYSBsaW1pdGVkIGZhc2hpb24sDQo+ IHBsZWFzZSBpbmNsdWRlIHRoYXQgYXMgYSBub3RlLiBJZiB0aGUgcmF0aW9uYWxlIGlzIHNvbWUg ZXhwbGFuYXRpb24gb3RoZXIgdGhhbg0KPiB0aGVzZSB0d28sIHBsZWFzZSBpbmNsdWRlIGl0IGFz IGEgbm90ZS4NCg0KR29vZCBwb2ludCwgYWRkZWQgdGhlIGZvbGxvd2luZyBub3RlOg0KTm90ZSB0 aGF0IHRoZSBjaGFubmVsIG51bWJlciByYW5nZSBpcyBub3QgYmFja3dhcmRzIGNvbXBhdGlibGUg d2l0aCBSRkM1NzY2LCBhbmQgY2Fubm90IGJlIHVzZWQgaW4gZW52aXJvbm1lbnRzIHdoZXJlIHN1 Y2ggY29tcGF0aWJpbGl0eSBpcyByZXF1aXJlZC4NCg0KPiANCj4gLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t DQo+IA0KPiDCpzE4LjEyOg0KPiANCj4gPiAgUmVhc29uIFBocmFzZTogIFRoZSByZWNvbW1lbmRl ZCByZWFzb24gcGhyYXNlcyBmb3IgZXJyb3IgY29kZXMgNDQwDQo+ID4gICAgIGFuZCA1MDggYXJl IGV4cGxhaW5lZCBpbiBTZWN0aW9uIDE5LiAgVGhlIHJlYXNvbiBwaHJhc2UgTVVTVCBiZSBhDQo+ ID4gICAgIFVURi04IFtSRkMzNjI5XSBlbmNvZGVkIHNlcXVlbmNlIG9mIGxlc3MgdGhhbiAxMjgg Y2hhcmFjdGVycw0KPiA+ICAgICAod2hpY2ggY2FuIGJlIGFzIGxvbmcgYXMgNTA5IGJ5dGVzIHdo ZW4gZW5jb2RpbmcgdGhlbSBvciA3NjMgYnl0ZXMNCj4gPiAgICAgd2hlbiBkZWNvZGluZyB0aGVt KS4NCj4gDQo+IFRoaXMgZG9lc24ndCBtYWtlIGEgbG90IG9mIHNlbnNlIHRvIG1lLiBJZiBhcmJp dHJhcnkgc2VxdWVuY2VzIG9mIDEyOCBVVEYtOA0KPiBjaGFyYWN0ZXJzIGFyZSBhbGxvd2VkLCB0 aGVuIHRoZSBvbi10aGUtd2lyZSBlbmNvZGluZyBtaWdodCBiZSBhcyBsb25nIGFzDQo+IDUxMiBi eXRlcyAocmF0aGVyIHRoYW4gNTA5KSwgZXZlbiBpZiB0aGlzIHdvdWxkIG9ubHkgcmVzdWx0IGZy b20gdGhlIHVzZSBvZg0KPiB1bnVzdWFsIHN0cmluZ3MgKGUuZy4sIDEyOCBjb25zZWN1dGl2ZSBl bW9qaSkuIEknbSBldmVuIG1vcmUgbG9zdCBieSB0aGUNCj4gaW5kaWNhdGlvbiBvZg0KPiAiNzYz IGJ5dGVzLCIgYXMgSSBjYW4ndCBmaWd1cmUgb3V0IHdoYXQgImRlY29kaW5nIiBvcGVyYXRpb24g aXMgYmVpbmcgaW5kaWNhdGVkDQo+IGhlcmUsIG5vciBjYW4gSSBmaWd1cmUgb3V0IHdoYXQga2lu ZCBvZiBkZWNvZGVkIHNlcXVlbmNlIHdvdWxkIHVzZSA1Ljk2DQo+IGJ5dGVzIHBlciBjaGFyYWN0 ZXIuIFBsZWFzZSBkb3VibGUtY2hlY2sgeW91ciBudW1iZXJzLCBhbmQgYWRkIG1vcmUgdGV4dA0K PiBpbmRpY2F0aW5nIHdoYXQgaXMgbWVhbnQgYnkgImVuY29kaW5nIiBhbmQgImRlY29kaW5nIiBp biB0aGlzIHNlbnRlbmNlLg0KPiANCj4gQWxzbywgbml0OiAiLi4uZmV3ZXIgdGhhbiAxMjggY2hh cmFjdGVycy4uLiINCg0KV2UgYXJlIHJlLXVzaW5nIHRoZSByZWFzb24gcGhyYXNlIGRlZmluZWQg aW4gaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtdHJhbS1zdHVuYmlzLTIx I3NlY3Rpb24tMTQuOC4gSXQgc2F5cyAiVGhlIHJlYXNvbiBwaHJhc2UgTVVTVCBiZSBhIFVURi04 IFtSRkMzNjI5XSBlbmNvZGVkIHNlcXVlbmNlIG9mIGxlc3MgdGhhbiAxMjggY2hhcmFjdGVycyAo d2hpY2ggY2FuIGJlIGFzIGxvbmcgYXMgNTA5IGJ5dGVzIHdoZW4gDQplbmNvZGluZyB0aGVtIG9y IDc2MyBieXRlcyB3aGVuIGRlY29kaW5nIHRoZW0pLiIgIA0KDQpDaGVlcnMsDQotVGlydQ0KDQo+ IA0KPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N Cj4gdHJhbSBtYWlsaW5nIGxpc3QNCj4gdHJhbUBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RyYW0NCg== From nobody Wed Jul 10 07:04:06 2019 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 AD93D12015F; Wed, 10 Jul 2019 07:03:51 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Suresh Krishnan via Datatracker To: "The IESG" Cc: draft-ietf-tram-turnbis@ietf.org, Brandon Williams , tram-chairs@ietf.org, brandon.williams@akamai.com, tram@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.98.3 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Suresh Krishnan Message-ID: <156276743162.15103.11217512835677641225.idtracker@ietfa.amsl.com> Date: Wed, 10 Jul 2019 07:03:51 -0700 Archived-At: Subject: [tram] Suresh Krishnan's No Objection on draft-ietf-tram-turnbis-27: (with COMMENT) X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.29 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 Jul 2019 14:03:57 -0000 Suresh Krishnan has entered the following ballot position for draft-ietf-tram-turnbis-27: 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-turnbis/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- * Section 3.7 I think an informative reference to [draft-ietf-intarea-frag-fragile] would be very useful here. It is a BCP that covers this issue in great detail and has specific recommendations for different audiences. * Section 13.2 Page 53 "If the packet is being sent to the peer" The term "the packet" is ambiguous here. This could potentially refer to the ICMPv6 packet being sent or the original packet that caused the error. Can you please clarify which one you mean here? * References I do have a better citation for the Fragmentation Considered Harmful paper if you want to use it. [Kent] Kent, C. and J. Mogul, ""Fragmentation Considered Harmful", In Proc. SIGCOMM '87 Workshop on Frontiers in Computer Communications Technology, DOI 10.1145/55483.55524", August 1987, . From nobody Wed Jul 10 08:40:06 2019 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 8594B120305; Wed, 10 Jul 2019 08:40:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=cooperw.in header.b=JCnQEhM1; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=SPhSZ44Y 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 pQa04rJBMpai; Wed, 10 Jul 2019 08:40:02 -0700 (PDT) Received: from wout4-smtp.messagingengine.com (wout4-smtp.messagingengine.com [64.147.123.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B0AA1201EB; Wed, 10 Jul 2019 08:40:02 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.west.internal (Postfix) with ESMTP id 020A64A7; Wed, 10 Jul 2019 11:40:00 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute7.internal (MEProxy); Wed, 10 Jul 2019 11:40:01 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cooperw.in; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm3; bh=b HAHqET/2N1lNNv628tTTc84deuq1IRjjMvqSyNVybQ=; b=JCnQEhM1A3P4k8S6P O6m8U+TWohOsMhKZ3pTdwAr2837O1u3XGUO6eyZvOeA5Gmuo2I/tbrTDP3p2MheO hz0i960YZn2BJ+GNAC/2GMCyQ+bzUgZm7fuHf7NlTncshRW9YP5Pk82PD7WalzBX q3Wt/+Fz02t/AO9fPzODWiAf+Bddrq7wpveXY/JhiSHRvnxJXBnzGjW8kpbHaB90 YmiXDmfaXD021Yf2bsbfx/VCfAb0kZRY6nkyISPULUJ94X5dypaMdAzGZvcP1uoT z0zr0ytt4s0OIl0w+kI8X28L1tPF6vTnfPqkNcZ7KfRna6Y2UB/STws89iXy0Yf5 gM7Tw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=bHAHqET/2N1lNNv628tTTc84deuq1IRjjMvqSyNVy bQ=; b=SPhSZ44Y4iqWFTWFnUvygUhvVgzYpj/DWyaqzISCL9kDxnzSMtARy0qMa kWPRvxAVi1mGR0UWZf4kcx87fsNZm1dxz9LfasQ7cTMPthaDrwiU2TDHXDz9s54R KrANTLh+6iHZkoDh50Fq5eiMToEWdA0JozuvCazF6lnovVRICG9M4eFJp58LOEwm 3q7aVhcirOzsDir68FkkTP47qIbJv4F39X2bqu3rxnOuQmx0IqGnjIRSAzZzZDE9 RHDqPeUHPmRBuhwOizylasq9s56QRuElMTSAl8lNJ3OoUV4fcpLxMvYIwO6Lh0Vp U9ISa6+MskmkArdpR+NGxLJ2G2Pnw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduvddrgeeigdelfecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpegtggfuhfgjfffgkfhfvffosehtqhhmtdhhtddvnecuhfhrohhmpeetlhhishhs rgcuvehoohhpvghruceorghlihhsshgrsegtohhophgvrhifrdhinheqnecuffhomhgrih hnpehivghtfhdrohhrghenucfkphepudejfedrfeekrdduudejrdeludenucfrrghrrghm pehmrghilhhfrhhomheprghlihhsshgrsegtohhophgvrhifrdhinhenucevlhhushhtvg hrufhiiigvpedt X-ME-Proxy: Received: from rtp-alcoop-nitro2.cisco.com (unknown [173.38.117.91]) by mail.messagingengine.com (Postfix) with ESMTPA id E68D58005A; Wed, 10 Jul 2019 11:39:59 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Alissa Cooper In-Reply-To: <156235525081.22022.16028050139050508065@ietfa.amsl.com> Date: Wed, 10 Jul 2019 11:39:59 -0400 Cc: gen-art@ietf.org, draft-ietf-tram-turnbis.all@ietf.org, ietf@ietf.org, tram@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <3A5EBA14-8560-428B-A8A5-47F70B272A60@cooperw.in> References: <156235525081.22022.16028050139050508065@ietfa.amsl.com> To: Vijay Gurbani X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [tram] [Gen-art] Genart telechat review of draft-ietf-tram-turnbis-27 X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.29 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 Jul 2019 15:40:04 -0000 Vijay, thank you for your reviews of this document. Tiru, thank you for = your responses. I entered a Yes ballot.=20 Alissa > On Jul 5, 2019, at 3:34 PM, Vijay Gurbani via Datatracker = wrote: >=20 > Reviewer: Vijay Gurbani > Review result: Ready >=20 > 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 wait for direction from your > document shepherd or AD before posting a new version of the draft. >=20 > For more information, please see the FAQ at >=20 > . >=20 > Document: draft-ietf-tram-turnbis-27 > Reviewer: Vijay K. Gurbani > Review Date: 2019-07-05 > IETF LC End Date: None > IESG Telechat date: 2019-07-11 >=20 > Summary: Ready to proceed. I had reviewed -25 for Gen-ART and all of = my > comments and feedback from that review have been incorporated. I do = not have > any further comments or feedback on -27. >=20 > Major issues: 0 >=20 > Minor issues: 0 >=20 > Nits/editorial comments: 0 >=20 >=20 > _______________________________________________ > Gen-art mailing list > Gen-art@ietf.org > https://www.ietf.org/mailman/listinfo/gen-art From nobody Wed Jul 10 08:55:23 2019 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 A751012023E; Wed, 10 Jul 2019 08:55:14 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: =?utf-8?q?Mirja_K=C3=BChlewind_via_Datatracker?= To: "The IESG" Cc: draft-ietf-tram-turnbis@ietf.org, Brandon Williams , tram-chairs@ietf.org, brandon.williams@akamai.com, tram@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.98.3 Auto-Submitted: auto-generated Precedence: bulk Reply-To: =?utf-8?q?Mirja_K=C3=BChlewind?= Message-ID: <156277411459.15353.13243689830942672102.idtracker@ietfa.amsl.com> Date: Wed, 10 Jul 2019 08:55:14 -0700 Archived-At: Subject: [tram] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf-?= =?utf-8?q?tram-turnbis-27=3A_=28with_DISCUSS_and_COMMENT=29?= X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.29 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 Jul 2019 15:55:15 -0000 Mirja Kühlewind has entered the following ballot position for draft-ietf-tram-turnbis-27: 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-turnbis/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- One quick discussion which probably is only an oversight and therefore should be easy got fix: I'm bit confused about the requirement on using authentication. This draft says in section 5 (as RFC5766 does): "The server MUST demand that all requests from the client be authenticated using this mechanism, or that a equally strong or stronger mechanism for client authentication is used." However, RFC 8155 which is even now cited in this draft, updates RFC5766 and relaxes this requirement. Later in the section 7.2. this draft says: "The server SHOULD require that the request be authenticated." I assume the requirement in section 5 is an oversight? I also recommend to only specify this requirement normatively in one place. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Some other technical comments/questions: 1) Sec 3.7: "or use UDP fragmentation [I-D.ietf-tsvwg-udp-options]." I believe the possibility to use UDP fragmentation was brought up by the TSV-ART review (Thanks Joe!). However, I would like to mention that this can only be used if supported by both endpoints and that should probably also be remarked here. The next sentence in the draft indicated this by saying "until UDP fragmentation support is available", however, this actually seem to be editorially a bit misplaced there and could explain more. See also this text in draft-ietf-tsvwg-udp-options: "FRAG needs to be used with extreme care because it will present incorrect datagram boundaries to a legacy receiver, unless encoded as LITE data (see Section 5.8)." Also note that draft-ietf-tsvwg-udp-options is still under development and we don't have much deployment experience with it yet. And further, in the same section. There is also draft-ietf-tsvwg-datagram-plpmtud on "Packetization Layer Path MTU Discovery for Datagram Transports". Please also be aware that there is an extensive TSV-ART for draft-ietf-tram-stun-pmtud. Both might impact the final content of this section. 2) sec 11.5: "When the server receives an ICMP packet, the server verifies that the type is either 3 or 11 for an ICMPv4 [RFC0792] packet or either 1, 2, or 3 for an ICMPv6 [RFC4443] packet." Restricting to a set of known types, doesn't seem to support future extensibility very well... 3) sec 12.5: "Over TCP and TLS-over-TCP, the ChannelData message MUST be padded to a multiple of four bytes in order to ensure the alignment of subsequent messages." Not exactly sure why this is useful...? Is this to align with STUN and therefore make processing somehow easier? Is that really needed. And exception should be easy to implement and should save some bytes which is the as I understood it the whole purpose of channels, no? 4) 12.6: "Note that if the Length field in the ChannelData message is 0, then there will be no data in the UDP datagram, but the UDP datagram is still formed and sent." Can you maybe add some more text and explain why this is useful? 5) sec 15: RFC6824 will soon be obsoleted by draft-ietf-mptcp-rfc6824bis and please s/TCP multi-path/Multipath TCP/. 6) Just a thought looking at section 14 and 16: It could have been nice to provide an ECN feedback field from the server to the client in case a ECN marked packet is received from the peer... however, I guess that future work at this point in the process... 7) sec 18.13: Maybe I missed this because I reviewed this doc over 3 days, but is only the ICMP Attribute send to the client or is the actual ICMP packets or as much as possible of that packet includes as well? 8) sec 23: "Response: TURN will no longer be needed once there are no longer any NATs. Unfortunately, as of the date of publication of this document, it no longer seems very likely that NATs will go away any time soon. However, the need for TURN will also decrease as the number of NATs with the mapping property of Endpoint-Independent Mapping [RFC4787] increases." Yes... so you don't think that IPv6 will be any help here? Editorial comments: 1) Sec 6: "The relayed transport address MUST be unique across all allocations, so it can be used to uniquely identify the allocation. Both the relayed transport address and the 5-tuple MUST be unique across all allocations, so either one can be used to uniquely identify the allocation, [...]" These two sentences seem quite redundant. The first one was added in this draft. The second one was already there in RFC5766. 2) sec 7.1: "Since this specification only allows UDP between the server and the peers, it is RECOMMENDED that [...]" Wordings ("only allows") seems weird to me given use of other proposals is at least to some extend discussed. Nits: sec 7.1.: s/the client pick a currently unused transport address/the client picks a currently unused transport address/ From nobody Wed Jul 10 15:50:04 2019 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 D562812006A; Wed, 10 Jul 2019 15:49:51 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Roman Danyliw via Datatracker To: "The IESG" Cc: draft-ietf-tram-turnbis@ietf.org, Brandon Williams , tram-chairs@ietf.org, brandon.williams@akamai.com, tram@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.98.3 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Roman Danyliw Message-ID: <156279899179.15443.1948808943181719878.idtracker@ietfa.amsl.com> Date: Wed, 10 Jul 2019 15:49:51 -0700 Archived-At: Subject: [tram] Roman Danyliw's Discuss on draft-ietf-tram-turnbis-27: (with DISCUSS and COMMENT) X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.29 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 Jul 2019 22:49:52 -0000 Roman Danyliw has entered the following ballot position for draft-ietf-tram-turnbis-27: 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-turnbis/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- (1) Section 12.1.6. (Per the back-and-forth on Chris Wood’s SECDIR review – thank you Chris!) Per “Confidentiality is only a secondary concern, as TURN control messages do not include information that is particularly sensitive”, wouldn’t the USERNAME and REALM potentially be privacy sensitive? If they aren’t sensitive in all cases (e.g., usernames might be ephemeral), this should be noted and cited. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- (2) This draft relies on the draft-ietf-tram-stunbis’s STUN Password Algo Registry which has MD5 and SHA-256. Section 16.1.1 of that draft already discusses the limitation of SHA-256 (which it might be useful to reference). Nevertheless, are there cases where MD5 should be used over SHA-256 if there is a choice? Is there a reason not to recommend that implementations “SHOULD NOT use MD5”? (3) Section 5. Per “The client SHOULD include the SOFTWARE …” and “The client and the server MAY include the FINGERPRINT attribute …”, why is the sending of SOFTWARE not a “MAY” too? (4) Section 5. (Per the back-and-forth on Chris Wood’s SECDIR review) Recommend citing Section 6.3.1 of [draft-ietf-tram-stunbis] as source of 40 second request buffer timeout (5) Section 21.4. Per “It is RECOMMENDED that TURN servers not accept allocation or channel binding requests from addresses known to be tunneled”, I concur with the advice. How would one recognize that the address is being tunneled? From nobody Wed Jul 10 22:32:54 2019 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 355B0120048 for ; Wed, 10 Jul 2019 22:32:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.454 X-Spam-Level: X-Spam-Status: No, score=-0.454 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, PDS_NO_HELO_DNS=1.295, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WtH5gMpr9tF9 for ; Wed, 10 Jul 2019 22:32:51 -0700 (PDT) Received: from mail-oi1-x234.google.com (mail-oi1-x234.google.com [IPv6:2607:f8b0:4864:20::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7CC2E120018 for ; Wed, 10 Jul 2019 22:32:51 -0700 (PDT) Received: by mail-oi1-x234.google.com with SMTP id w196so3539169oie.7 for ; Wed, 10 Jul 2019 22:32:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=XCSfKBMHlA5hK2+1ARxWGwAdPcacx//OaFGaqTmXbIg=; b=Pi/2seCuW/sTYwJL6U16Yt/5/CHevDdTgFJ6fRoYjlY0C0TNY/pttx1wEBvlgP4m7F BASMC6CqoGRwebEc9TE+UArh0gjsE1ADzdmv0g+TVMC6Ukbpzc830QqRiiPB/rKZTSCT l7uCHZdPSTlsWK1MU9ihCQzm++VeXDTir62sWGxaKTN5/MbCEvqMcOr+GZlB/rhyC3nG BjnTGCY5kz8SZE6TzJhanxAasEX184x7o5E1+sGY0jWSPXfuRpUoC2UrCwWZv6ZBuIXQ HvAzTlOpECen7POe5ikMezGLiSboOIGFecOtNHEdkdY7NMN3rKEZEGhWAQ1wPUSFPqJO +XWw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=XCSfKBMHlA5hK2+1ARxWGwAdPcacx//OaFGaqTmXbIg=; b=HzRtgXNepv08AkodpUqx2G/qg6NXzC2MxOXYoUtP4ayjSYhwdX6fTvIR4uJ9Mo0d9P D6iYxMT2DDV437IP/KFbdwz0rpVvYQXCKagdrB2nGheT/9QuYJ1XnsL6LaRSx+zVpk1+ VhasrEbiJVGSNNHk9kAlRIOYNkkrwN+XKrkWdU1rOG1L91E4aBluDfFC/6BkJsrEPJPn zVav4nyZBszYruceauyuQYmMP3ydxx+0hJGJHqhv4H8cB1q1vU1vlP9tMZbKsRL+AMTI DFI9NvY1gZC01VhclRKDsieUzc5vUO+ATWJNIF+EIkrCyH9YSuw+r7Kj6CGnicTkcv/r 7Tow== X-Gm-Message-State: APjAAAXBqIJXLXJuu5BP81UdlHPprRDEDGRumoInXF+ZpFvXcMdwQ2p3 OPAxonGT0KF3zdF5Hd/SoPen/BhUafnA4/2xj2HiAd5R X-Google-Smtp-Source: APXvYqz0Z3qfaYESrx0T27senZVbTx+kgfxYMSZ3q7/7/ZlSZar2dNA1sqxAhujJz57gKuDOfDTiMeFq6k7/ztyf/Rs= X-Received: by 2002:aca:4bce:: with SMTP id y197mr1322244oia.38.1562823170659; Wed, 10 Jul 2019 22:32:50 -0700 (PDT) MIME-Version: 1.0 From: Noriyuki Torii Date: Thu, 11 Jul 2019 14:32:39 +0900 Message-ID: To: tram@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [tram] some more nits in draft-ietf-tram-turnbis-27 X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.29 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, 11 Jul 2019 05:32:53 -0000 To whom it may concern, I found some more points in draft-ietf-tram-turnbis-27, in addition to my previos mail. So I would like to report here. Hope this may help for improvements. in page 67 TURN TURN Peer Peer client server A B | | | | |--- Allocate request -------------->| | | | Transaction-Id=0xA56250D3F17ABE679422DE85 | | | SOFTWARE="Example client, version 1.03" | | | LIFETIME=3600 (1 hour) | | | | REQUESTED-TRANSPORT=17 (UDP) | | | | DONT-FRAGMENT | | | | | | | |<-- Allocate error response --------| | | | Transaction-Id=0xA56250D3F17ABE679422DE85 | | | SOFTWARE="Example server, version 1.17" | | | ERROR-CODE=401 (Unauthorized) | | | | REALM="example.com" | | | | NONCE="obMatJos2AAABadl7W7PeDU4hKE72jda" | | | PASSWORD-ALGORITHMS=MD5 and SHA256 | | | | | | |--- Allocate request -------------->| | | | Transaction-Id=0xC271E932AD7446A32C234492 | | | SOFTWARE="Example client 1.03" | | | | LIFETIME=3600 (1 hour) | | | | REQUESTED-TRANSPORT=17 (UDP) | | | | DONT-FRAGMENT | | | | USERNAME="George" | | | | REALM="example.com" | | | | NONCE="obMatJos2AAABadl7W7PeDU4hKE72jda" | | | PASSWORD-ALGORITHMS=MD5 and SHA256 | | | PASSWORD-ALGORITHM=SHA256 | | | | MESSAGE-INTEGRITY=... | | | | MESSAGE-INTEGRITY-SHA256=... | | | | | | | |<-- Allocate success response ------| | | | Transaction-Id=0xC271E932AD7446A32C234492 | | | SOFTWARE="Example server, version 1.17" | | | LIFETIME=1200 (20 minutes) | | | | XOR-RELAYED-ADDRESS=192.0.2.15:50000 | | | XOR-MAPPED-ADDRESS=192.0.2.1:7000 | | | MESSAGE-INTEGRITY=... | | | Above example shows the server's final response includes MESSAGE-INTEGRITY. But the section 9.2.4 of STUNbis says --- If these checks pass, the server continues to process the request. Any response generated by the server MUST include MESSAGE-INTEGRITY- SHA256 attribute, computed using the username and password utilized to authenticate the request, unless the request was processed as though PASSWORD-ALGORITHM was MD5 (because the request contained neither PASSWORD-ALGORITHMS nor PASSWORD-ALGORITHM). In that case the MESSAGE-INTEGRITY attribute MUST be used instead of the MESSAGE- INTEGRITY-SHA256 attribute. --- So, the final response in this diagram must include the MESSAGE-INTEGRITY- SHA256, not the MESSAGE-INTEGRITY. in page 71 (and subsequent diagrams ...) TURN TURN Peer Peer client server A B |--- CreatePermission request ------>| | | | Transaction-Id=0xE5913A8F460956CA277D3319 | | | XOR-PEER-ADDRESS=192.0.2.150:0 | | | | USERNAME="George" | | | | REALM="example.com" | | | | NONCE="obMatJos2AAABadl7W7PeDU4hKE72jda" | | | MESSAGE-INTEGRITY=... | | | | | | | |<-- CreatePermission success resp.--| | | | Transaction-Id=0xE5913A8F460956CA277D3319 | | | MESSAGE-INTEGRITY=... | | | The MESSAGE-INTEGRITY is utilized here nevertheless the MESSAGE-INTEGRITY-SHA256 should be chosen in previous Allocate example. As a result, the authentication strength is degraded. Section 9.2.3.2 of STUNbis says --- The client SHOULD cache the username, password, realm, and nonce for subsequent communications with the server. When the client sends a subsequent request, it MUST include either the USERNAME or USERHASH, REALM, NONCE, and PASSWORD-ALGORITHM attributes with these cached values. It MUST include a MESSAGE-INTEGRITY attribute or a MESSAGE-INTEGRITY- SHA256 attribute, computed as described in Section 14.5 and Section 14.6 using the cached password. The choice between the two attributes depends on the attribute received in the response to the first request. --- Thus, the example CreatePermission request must have the PASSWORD-ALGORITHM and also the MESSAGE-INTEGRITY-SHA256, not the MESSAGE-INTEGRITY. In fact, the PASSWORD-ALGORITHMS also would be required because any requests having only the PASSWORD-ALGORITHM without the PASSWORD-ALGORITHMS will be rejected by the server, according to the section 9.2.4 of STUNbis. (Although the section 9.2.3.2 of STUNbis does not explicitly point it out. I wonder it might be a nit of STUNbis.) Likely, the example response must have the MESSAGE-INTEGRITY-SHA256 in place of the MESSAGE-INTEGRITY. These points will apply to all subsequent example diagrams which are involved in authentication. Please note that such a degradation may be regarded as a result of bid-down attack therefore the request will be probably rejected by the server. Best regards, Noriyuki Torii From nobody Wed Jul 10 22:39:56 2019 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 51858120018; Wed, 10 Jul 2019 22:39:54 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Benjamin Kaduk via Datatracker To: "The IESG" Cc: draft-ietf-tram-turnbis@ietf.org, Brandon Williams , tram-chairs@ietf.org, brandon.williams@akamai.com, tram@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.98.3 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Benjamin Kaduk Message-ID: <156282359426.15056.17118634579091500165.idtracker@ietfa.amsl.com> Date: Wed, 10 Jul 2019 22:39:54 -0700 Archived-At: Subject: [tram] Benjamin Kaduk's Discuss on draft-ietf-tram-turnbis-27: (with DISCUSS and COMMENT) X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.29 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, 11 Jul 2019 05:39:55 -0000 Benjamin Kaduk has entered the following ballot position for draft-ietf-tram-turnbis-27: 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-turnbis/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- I support Roman's Discuss. I think I'm confused about whether REQUESTED-ADDRESS-FAMILY and ADDITIONAL-ADDRESS-FAMILY are mutually exclusive. Does sending just the "additional" one secretly mean that you want both v4 and v6? Section 5 I see that the secdir reviewer asked about why it is a "SHOULD" to send SOFTWARE, and only got a response that it is defined in stunbis, but not about why it is recommended. There remain some privacy/security considerations with it, and we should either point to the stunbis security considerations or not recommend using it. (FINGERPRINT is, IIRC, less interesting from a security perspective as it's just about confirming that given traffic is in fact STUN and not something else.) Section 12 Do we need to say anything about backwards compatibility with RFC 5766 peers that use a wider range of channel IDs? Section 12.7 When the server receives an ICMP packet, the server processes it as described in Section 11.5. A Data indication MUST be sent regardless of whether there is a channel bound to the peer that was the destination of the UDP datagram that triggered the reception of the ICMP packet. This MUST seems potentially in conflict with the previous discussion about permissions checks in Section 11.5. Section 20 Looking at the new nonce in the example ("obMatJos2AAABadl7W7PeDU4hKE72jda"), and noting that it starts with the nonce cookie, help me decode the security feature bits. The magic prefix is "obMatJos2" so the capability bits are encoded as "AAAB", which decodes to (hex) 00 00 01. But stunbis says that the bits are ordered from 0 (MSB of first byte) to 23 (LSB of last byte), so this would have bit 23 set, which is in contrast to the registry marking bit 0 as the password-algorithms feature. Where am I messing this up? I'd prefer if the examples showed more usage of MESSAGE-INTEGRITY-SHA256 (especially, any from the server) and fewer MESSAGE-INTEGRITY. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for keeping the diff from RFC 5766 relatively contained! I only reviewed the diff due to time constraints, but in general support reviewing the full document for internal consistency and any remarks that have not aged well, especially with respect to IANA considerations. Section 2 RFC 8174 has an updated version of the BCP 14 boilerplate text. Section 3.1 I appreciate the response to the secdir review, but even the linked stunbis section does not say much about which PKI's trust root is expected to be used. I'm forced to assume the Web PKI but don't have much grounds for that assumption. Section 3.2 The secdir reviewer's comments seem to have some relevance. It seems like even when the third-party authorization mechanism is used, the client is still limited to "the server is authenticated because it gives me the service I asked for", which is not really documented anywhere yet. The long-term password mechanism at least generates an HMAC integrity tag on messages from server to client, which can provide some level of authentication via key confirmation. Section 3.7 If the TURN server carrying out packet translation from IPv4-to-IPv6 cannot get the Don't Fragment (DF) bit in the IPv4 header, it MUST reject the Allocate request with DONT-FRAGMENT attribute. nit: does "cannot get" mean something like "read the value as sent on the wire" (e.g., due to implementation/API limitations)? Section 6 o the relayed transport address or addresses; [...] [...] address. The relayed transport address MUST be unique across all allocations, so it can be used to uniquely identify the allocation. nit: there's maybe a singular/plural mismatch going on here, but I don't have any good ideas. Section 7.1 If the client wishes to obtain one IPv6 and one IPv4 relayed transport address then it includes an ADDITIONAL-ADDRESS-FAMILY attribute in the request. This attribute specifies that the server must allocate both address types. The attribute value in the ADDITIONAL-ADDRESS-FAMILY MUST be set to 0x02 (IPv6 address family). Clients MUST NOT include REQUESTED-ADDRESS-FAMILY and ADDITIONAL- ADDRESS-FAMILY attributes in the same request. [...] This reads like setting REQUESTED-ADDRESS-FAMILY and ADDITIONAL-ADDRESS-FAMILY are mutually exclusive. Is that the correct reading? (Naively, one might expect that the thing named "additional" is applied on top of the base-level request, so I have to ask.) Section 7.2 Why do we only have a SHOULD-level requirement for authentication of Allocate requests where 5766 had MUST? Could we say "may allow unauthenticated requests in order to support [use case] but otherwise MUST require authentication" (with better wording)? I suppose this has probably been discussed ad nauseum already, so feel free to point me at the archives before getting into an actual discussion. 7. If the server does not support the address family requested by the client in REQUESTED-ADDRESS-FAMILY or is disabled by local policy, it MUST generate an Allocate error response, and it MUST include an ERROR-CODE attribute with the 440 (Address Family not Supported) response code. [...] nit: "or is disabled" needs a subject. 9. The server checks if the request contains an ADDITIONAL-ADDRESS- FAMILY attribute. If yes, and the attribute value is 0x01 (IPv4 address family), then the server rejects the request with a 400 (Bad Request) error. Otherwise, the server checks if it can allocate relayed transport addresses of both address types. If the server cannot satisfy the request, then the server rejects What are "both" address types? We only have the ADDITIONAL-ADDRESS-FAMILY (which contains one type) and no REQUESTED-ADDRESS-FAMILY. Section 8.1 When refreshing a dual allocation, the client includes REQUESTED- ADDRESS-FAMILY attribute indicating the address family type that should be refreshed. If no REQUESTED-ADDRESS-FAMILY is included then the request should be treated as applying to all current allocations. The client MUST only include family types it previously allocated and has not yet deleted. [...] I'm a bit confused about "only include family types" plural; I thought there could only be at most one REQUESTED-ADDRESS-FAMILY and that it would only indicate one family type. So how could there be multiple types getting included by the client? Section 11.5 [check that "type and code" is valid in both ICMPv4 and v6] Section 12 Reserved values may be used in the future by other protocols. When the client uses channel binding, it MUST comply with the demultiplexing scheme discussed above. "channel binding" is a term of art in the security world; is this usage intended to roughly mean "channel multiplexing"? (I do see that the subsections are talking about the specific ChannelBind request, so I assume so; I just want to double check.) Section 13 The descriptions below have two parts: a preferred behavior and an alternate behavior. The server SHOULD implement the preferred behavior. Otherwise, the server MUST implement the alternate behavior and MUST NOT do anything else for the reasons detailed in [RFC7915]. [...] RFC 5766 had this split on a per-field basis, but this text suggests that if the preferred behavior is not possible for a given field, then the alternate behavior is used for the entire packet. I note that section 14 does retain the "for a particular field" language for UDP-to-UDP relaying, as do section 15 for TCP-to-UDP relaying and section 16 for UDP-to-TCP relaying. Section 13.2 Is this flow label text consistent with both the inbound and outbound translation directions (specifically, using relayed/peer addresses in the 5-tuple to identify the flow)? If the incoming packet did not include a Fragment header and the outgoing packet size exceeds the outgoing link's MTU, the TURN server drops the outgoing packet and send an ICMP message of type 2 code 0 ("Packet too big") to the sender of the incoming packet. If the packet is being sent to the peer, the TURN server reduces the MTU reported in the ICMP message by 48 bytes to allow room for the overhead of a Data indication. (nit?) "If the packet is being send to the peer" seems to grammatically refer to the outgoing packet that would exceed link MTU, as opposed to the ICMP message being generated. But I think it's supposed to refer to the ICMP message being generated, which has not yet been referred to as a "packet" in this text. Section 13.3 [Same comment about ICMP packet generation/grammar] Section 15 Maybe note that SIP and WebRTC are the primary consumers of TURN? Even if both TCP-AO and UDP authentication would be used between TURN client and server, it would not change the end-to-end security properties of the UDP payload being relayed. [...] I wonder if we even need to say "UDP" in "payload being relayed". Section 16 Fragmentation Preferred Behavior: Any fragmented packets are reassembled in the server and then forwarded to the client over the TCP connection. ICMP messages resulting from the UDP datagrams sent to the peer MUST be forwarded to the client using TURN's mechanism for relevant ICMP types and codes. As in section 12.7, I wonder if this MUST could be seen as overriding other logic for ICMP handling. Section 21.16 I agree with the secdir reviewer that there is at least potential for username and realm to be sensitive. Section 21.4 Do we need references for Teredo and/or 6to4? Section 22 The codepoints for the STUN error codes defined in this specification are listed in Section 19. [IANA is requested to update the reference from [RFC5766] to RFC-to-be for the STUN error codes listed in Section 19.] (I think some of them are from RFC 6156 as well as from 5766.) Section 23 It seems prudent to revisit these listed IAB Considerations for whether the situation has changed in the past ten years (though I don't have any specific points that I would change). Section 25 (nit) are these really "updates" to RFC 6156 so much as incorporating its content wholesale into the core TURN specification? From nobody Wed Jul 10 23:13:01 2019 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 370BD12008B for ; Wed, 10 Jul 2019 23:12:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.999 X-Spam-Level: X-Spam-Status: No, score=-3.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=mcafee.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0r0jcHqzFtpZ for ; Wed, 10 Jul 2019 23:12:50 -0700 (PDT) Received: from us-smtp-delivery-210.mimecast.com (us-smtp-delivery-210.mimecast.com [63.128.21.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 19B9F12009E for ; Wed, 10 Jul 2019 23:12:49 -0700 (PDT) X-NAI-Header: Modified by McAfee Email Gateway (5500) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mcafee.com; s=s_mcafee; t=1562824860; h=From: To:CC:Subject:Thread-Topic:Thread-Index:Date: Message-ID:References:In-Reply-To:Accept-Language: Content-Language:X-MS-Has-Attach:X-MS-TNEF-Correlator: dlp-product:dlp-version:dlp-reaction:authentication-results: x-originating-ip:x-ms-publictraffictype:x-ms-office365-filtering-correlation-id: x-microsoft-antispam:x-ms-traffictypediagnostic: x-ms-exchange-purlcount:x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers:x-forefront-prvs: x-forefront-antispam-report:received-spf:x-ms-exchange-senderadcheck: x-microsoft-antispam-message-info:Content-Type: Content-Transfer-Encoding:MIME-Version:X-MS-Exchange-CrossTenant-Network-Message-Id: X-MS-Exchange-CrossTenant-originalarrivaltime: X-MS-Exchange-CrossTenant-fromentityheader: X-MS-Exchange-CrossTenant-id:X-MS-Exchange-CrossTenant-mailboxtype: X-MS-Exchange-CrossTenant-userprincipalname: X-MS-Exchange-Transport-CrossTenantHeadersStamped: X-OriginatorOrg:X-NAI-Spam-Flag:X-NAI-Spam-Level: X-NAI-Spam-Threshold:X-NAI-Spam-Score:X-NAI-Spam-Version; bh=T5ypUOSrivi6vqhmLaJs+vrfxgbVghW78DJtR4 O4/P0=; b=VtTmzKbnC2VfuWGyNHvgHLs5NexyE7n/4vxApqH7 WKfsh8BOfXlo04j0fRtD8gRdzkeqdLlWCcev9QiAjz6hTZb7ea 5UECz1SseEuvKWn+MgdRqLSg1iiNvh+rhVfxwPeU2DLCrXoyRk tlvhLPcc48PWT7kFG2LqPAXcj5lQXNA= Received: from DNVWSMAILOUT1.mcafee.com (dnvwsmailout1.mcafee.com [161.69.31.173]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-297-kw_ifbO8MLaxbJFUx8i_rQ-1; Thu, 11 Jul 2019 02:11:32 -0400 Received: from DNVEXAPP1N04.corpzone.internalzone.com (unknown [10.44.48.88]) by DNVWSMAILOUT1.mcafee.com with smtp (TLS: TLSv1/SSLv3,256bits,ECDHE-RSA-AES256-SHA384) id 3214_4382_c9919c18_9dda_4204_972c_dd12ab839c89; Thu, 11 Jul 2019 00:00:59 -0600 Received: from DNVEXAPP1N06.corpzone.internalzone.com (10.44.48.90) by DNVEXAPP1N04.corpzone.internalzone.com (10.44.48.88) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Thu, 11 Jul 2019 00:11:29 -0600 Received: from DNVO365EDGE1.corpzone.internalzone.com (10.44.176.66) by DNVEXAPP1N06.corpzone.internalzone.com (10.44.48.90) with Microsoft SMTP Server (TLS) id 15.0.1395.4 via Frontend Transport; Thu, 11 Jul 2019 00:11:29 -0600 Received: from NAM01-BY2-obe.outbound.protection.outlook.com (10.44.176.242) by edge.mcafee.com (10.44.176.66) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Thu, 11 Jul 2019 00:11:29 -0600 Received: from DM5PR16MB1705.namprd16.prod.outlook.com (10.172.44.147) by DM5PR16MB1449.namprd16.prod.outlook.com (10.173.215.8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2052.19; Thu, 11 Jul 2019 06:11:28 +0000 Received: from DM5PR16MB1705.namprd16.prod.outlook.com ([fe80::570:2208:75c2:5f17]) by DM5PR16MB1705.namprd16.prod.outlook.com ([fe80::570:2208:75c2:5f17%8]) with mapi id 15.20.2052.019; Thu, 11 Jul 2019 06:11:28 +0000 From: "Konda, Tirumaleswar Reddy" To: Suresh Krishnan , The IESG CC: "tram-chairs@ietf.org" , "draft-ietf-tram-turnbis@ietf.org" , "tram@ietf.org" , "brandon.williams@akamai.com" Thread-Topic: [tram] Suresh Krishnan's No Objection on draft-ietf-tram-turnbis-27: (with COMMENT) Thread-Index: AQHVNyhl0ttLdPYM5Eq5z2tsfGAIDqbD6e+Q Date: Thu, 11 Jul 2019 06:11:28 +0000 Message-ID: References: <156276743162.15103.11217512835677641225.idtracker@ietfa.amsl.com> In-Reply-To: <156276743162.15103.11217512835677641225.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.3.0.16 dlp-reaction: no-action x-originating-ip: [103.245.47.20] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: f6ea504f-450c-4a62-541b-08d705c69c6a x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:DM5PR16MB1449; x-ms-traffictypediagnostic: DM5PR16MB1449: x-ms-exchange-purlcount: 4 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0095BCF226 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(136003)(346002)(39860400002)(396003)(366004)(376002)(51914003)(189003)(199004)(13464003)(32952001)(54906003)(966005)(3846002)(7736002)(68736007)(8676002)(81166006)(33656002)(110136005)(8936002)(81156014)(2906002)(14454004)(71190400001)(71200400001)(86362001)(305945005)(316002)(229853002)(6116002)(80792005)(74316002)(486006)(256004)(5024004)(53546011)(6506007)(66476007)(66066001)(26005)(66556008)(66446008)(76176011)(76116006)(66946007)(52536014)(11346002)(6306002)(5660300002)(186003)(102836004)(9686003)(53936002)(99286004)(6436002)(25786009)(55016002)(4326008)(7696005)(64756008)(446003)(478600001)(6246003)(476003)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR16MB1449; H:DM5PR16MB1705.namprd16.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: DWzbQAow2Pg7x5mv21yn3TSwjWfj0gtj6iy3jyz2ZN+Zfb3HLB7nviroXybWv6a7lZT7VTRIsMIHcHfPCqyLlLRn8xHLJB8Cwl8pz85bsC3tSKo4NF6JV8WRIvbNQVplz0sQV1YDD2vK7prCol/hzADbpp3FFuwjMSgDv25EFakPYWGstfcKvchPkPjN8a71uPX4YUDDHh7dz7+o8Dh9IcjSpAkkIKbNL+HElUEYvbJDAESEj9NeYleJUJUGsapmF4b/5+EoKGiV/I9Y4n1rGfGzHB6JfZ3eHdGQtiQkZMEwyEoN6eubgcTqheQLRgvlBWesChwr0mVDMsqoD/Ds8r9B0VjWGZhle+qkC1DYGF/nZE47CtwFjFQaYhc4hpHpd2OjpGUnfzaZGpEedrHV/SoxPGg8z8FxjSPM1rFvSXM= MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: f6ea504f-450c-4a62-541b-08d705c69c6a X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Jul 2019 06:11:28.0750 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: TirumaleswarReddy_Konda@McAfee.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR16MB1449 X-OriginatorOrg: mcafee.com X-NAI-Spam-Flag: NO X-NAI-Spam-Level: X-NAI-Spam-Threshold: 15 X-NAI-Spam-Score: 0.3 X-NAI-Spam-Version: 2.3.0.9418 : core <6587> : inlines <7117> : streams <1827015> : uri <2866226> X-MC-Unique: kw_ifbO8MLaxbJFUx8i_rQ-1 X-Mimecast-Spam-Score: 0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [tram] Suresh Krishnan's No Objection on draft-ietf-tram-turnbis-27: (with COMMENT) X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.29 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, 11 Jul 2019 06:12:52 -0000 Hi Suresh, Thanks for the review. Please see inline=20 > -----Original Message----- > From: tram On Behalf Of Suresh Krishnan via > Datatracker > Sent: Wednesday, July 10, 2019 7:34 PM > To: The IESG > Cc: tram-chairs@ietf.org; draft-ietf-tram-turnbis@ietf.org; tram@ietf.org= ; > brandon.williams@akamai.com > Subject: [tram] Suresh Krishnan's No Objection on draft-ietf-tram-turnbis= -27: > (with COMMENT) >=20 > This email originated from outside of the organization. Do not click link= s or > open attachments unless you recognize the sender and know the content is > safe. >=20 > Suresh Krishnan has entered the following ballot position for > draft-ietf-tram-turnbis-27: 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-turnbis/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 >=20 > * Section 3.7 >=20 > I think an informative reference to [draft-ietf-intarea-frag-fragile] wou= ld be > very useful here. It is a BCP that covers this issue in great detail and = has > specific recommendations for different audiences. Sure, updated. >=20 > * Section 13.2 Page 53 >=20 > "If the packet is being sent to the peer" >=20 > The term "the packet" is ambiguous here. This could potentially refer to = the > ICMPv6 packet being sent or the original packet that caused the error. Ca= n > you please clarify which one you mean here? Fixed text for clarity as follows: If the ICMPv4 packet (Destination Unreachable (Type 3) with Code 4) is bein= g sent to the peer, the TURN server SHOULD reduce the MTU reported in the I= CMP message by 48 bytes to allow room for the overhead of a Data indication= .=20 >=20 > * References >=20 > I do have a better citation for the Fragmentation Considered Harmful pape= r if > you want to use it. >=20 > [Kent] Kent, C. and J. Mogul, ""Fragmentation Considered > Harmful", In Proc. SIGCOMM '87 Workshop on Frontiers in > Computer Communications Technology, DOI > 10.1145/55483.55524", August 1987, > WRL-87-3.pdf>. Thanks, Updated. Cheers, -Tiru >=20 >=20 > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram From nobody Thu Jul 11 02:08:04 2019 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 6749D1202B1 for ; Thu, 11 Jul 2019 02:07:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.999 X-Spam-Level: X-Spam-Status: No, score=-3.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=mcafee.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sHDwfsoJTQSf for ; Thu, 11 Jul 2019 02:07:54 -0700 (PDT) Received: from us-smtp-delivery-210.mimecast.com (us-smtp-delivery-210.mimecast.com [63.128.21.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 561011202B5 for ; Thu, 11 Jul 2019 02:07:53 -0700 (PDT) X-NAI-Header: Modified by McAfee Email Gateway (5500) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mcafee.com; s=s_mcafee; t=1562835435; h=From: To:CC:Subject:Thread-Topic:Thread-Index:Date: Message-ID:References:In-Reply-To:Accept-Language: Content-Language:X-MS-Has-Attach:X-MS-TNEF-Correlator: dlp-product:dlp-version:dlp-reaction:authentication-results: x-originating-ip:x-ms-publictraffictype:x-ms-office365-filtering-correlation-id: x-microsoft-antispam:x-ms-traffictypediagnostic: x-ms-exchange-purlcount:x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers:x-forefront-prvs: x-forefront-antispam-report:received-spf:x-ms-exchange-senderadcheck: x-microsoft-antispam-message-info:Content-Type: Content-Transfer-Encoding:MIME-Version:X-MS-Exchange-CrossTenant-Network-Message-Id: X-MS-Exchange-CrossTenant-originalarrivaltime: X-MS-Exchange-CrossTenant-fromentityheader: X-MS-Exchange-CrossTenant-id:X-MS-Exchange-CrossTenant-mailboxtype: X-MS-Exchange-CrossTenant-userprincipalname: X-MS-Exchange-Transport-CrossTenantHeadersStamped: X-OriginatorOrg:X-NAI-Spam-Flag:X-NAI-Spam-Level: X-NAI-Spam-Threshold:X-NAI-Spam-Score:X-NAI-Spam-Version; bh=Lkhn7X2PtBiHoF4EgYlMghCcxDDArPcAhbNMJ+ DroYA=; b=MPrmV1IFfSWWRna98Db3nEW+mIgZ1zaGqfMPlx5f QbQKH++MzLjzyGn9RySL5ZN9ti9yumnr02tLQaCsLjdNMRQWcz K6idxt0cOKO2X5bJsYTnnTkPSzcMFKoYzT+/IUvkcbynoPuue6 IrK4gS5JzmCm7lLEpEJZ04Zq+B3WVKA= Received: from DNVWSMAILOUT1.mcafee.com (dnvwsmailout1.mcafee.com [161.69.31.173]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-110-17kfrR-JNNafawCIyn4vnA-1; Thu, 11 Jul 2019 05:07:48 -0400 Received: from DNVEXAPP1N04.corpzone.internalzone.com (DNVEXAPP1N04.corpzone.internalzone.com [10.44.48.88]) by DNVWSMAILOUT1.mcafee.com with smtp (TLS: TLSv1/SSLv3,256bits,ECDHE-RSA-AES256-SHA384) id 3214_888e_01221dc1_c8f5_44e7_b93f_8b72c43753bd; Thu, 11 Jul 2019 02:57:15 -0600 Received: from DNVEXAPP1N05.corpzone.internalzone.com (10.44.48.89) by DNVEXAPP1N04.corpzone.internalzone.com (10.44.48.88) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Thu, 11 Jul 2019 03:07:32 -0600 Received: from DNVO365EDGE1.corpzone.internalzone.com (10.44.176.66) by DNVEXAPP1N05.corpzone.internalzone.com (10.44.48.89) with Microsoft SMTP Server (TLS) id 15.0.1395.4 via Frontend Transport; Thu, 11 Jul 2019 03:07:32 -0600 Received: from NAM02-SN1-obe.outbound.protection.outlook.com (10.44.176.242) by edge.mcafee.com (10.44.176.66) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Thu, 11 Jul 2019 03:07:31 -0600 Received: from DM5PR16MB1705.namprd16.prod.outlook.com (10.172.44.147) by DM5PR16MB2152.namprd16.prod.outlook.com (52.132.142.13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2052.18; Thu, 11 Jul 2019 09:07:29 +0000 Received: from DM5PR16MB1705.namprd16.prod.outlook.com ([fe80::570:2208:75c2:5f17]) by DM5PR16MB1705.namprd16.prod.outlook.com ([fe80::570:2208:75c2:5f17%8]) with mapi id 15.20.2052.019; Thu, 11 Jul 2019 09:07:29 +0000 From: "Konda, Tirumaleswar Reddy" To: Roman Danyliw , The IESG CC: "tram-chairs@ietf.org" , "draft-ietf-tram-turnbis@ietf.org" , "tram@ietf.org" , "brandon.williams@akamai.com" Thread-Topic: [tram] Roman Danyliw's Discuss on draft-ietf-tram-turnbis-27: (with DISCUSS and COMMENT) Thread-Index: AQHVN3Hb8rvCrm8yiE+tXfblQrByi6bE8P0w Date: Thu, 11 Jul 2019 09:07:29 +0000 Message-ID: References: <156279899179.15443.1948808943181719878.idtracker@ietfa.amsl.com> In-Reply-To: <156279899179.15443.1948808943181719878.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.3.0.16 dlp-reaction: no-action x-originating-ip: [103.245.47.20] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 6e09f599-d9a6-48af-374a-08d705df33b9 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:DM5PR16MB2152; x-ms-traffictypediagnostic: DM5PR16MB2152: x-ms-exchange-purlcount: 4 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0095BCF226 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(396003)(366004)(346002)(39860400002)(136003)(376002)(51914003)(13464003)(189003)(32952001)(199004)(71200400001)(14454004)(81166006)(2906002)(7736002)(74316002)(53936002)(476003)(54906003)(99286004)(305945005)(11346002)(316002)(478600001)(110136005)(66066001)(7696005)(6436002)(33656002)(8936002)(76116006)(8676002)(81156014)(486006)(229853002)(6246003)(14444005)(53546011)(6506007)(102836004)(26005)(76176011)(186003)(5024004)(256004)(80792005)(6116002)(5660300002)(68736007)(966005)(6306002)(446003)(55016002)(9686003)(66556008)(66574012)(66476007)(64756008)(66446008)(4326008)(71190400001)(52536014)(3846002)(86362001)(66946007)(25786009)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR16MB2152; H:DM5PR16MB1705.namprd16.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: uv5MPRgQohvsnOg15WHXtKALhEOks0Wq7cZPUra2gCfbVO0zHmGmAUDqe4xz4iT1rFR8ptdZ1xklggsuPtOGAIjKZL/zGaZXGjOoEVSathieiWmEqeERAnyMxPG7/+8XFo3luihMok0cadKSJyygyAxp8UE0q0OX4V4ojPTNlKWtmi3ymOnARGG7EgrcRXRuB7hbkxj2GYDD+KiJ90C+FCH4UCm1l3IvQTQh+ALy87hnDbhTX9n4fb5xE416VWffQC8fJw9hfdyNvqdC/oxmIxyXnRiQqIf83vvwKNyDKXKGuqmMHm9xxhiH+CvNFJ0zISQMtlEqZUcKLjxkwjoKSmPAL4fi1BpsVqa71hcdIN8IXhXGfFxx64eefcYFCz8+PIPwgNb5uB5eOVW3C9tSr0ik0SOvYAH8hTvXfJwlh/0= MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 6e09f599-d9a6-48af-374a-08d705df33b9 X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Jul 2019 09:07:29.8565 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: TirumaleswarReddy_Konda@McAfee.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR16MB2152 X-OriginatorOrg: mcafee.com X-NAI-Spam-Flag: NO X-NAI-Spam-Level: X-NAI-Spam-Threshold: 15 X-NAI-Spam-Score: 0.3 X-NAI-Spam-Version: 2.3.0.9418 : core <6587> : inlines <7117> : streams <1827027> : uri <2866268> X-MC-Unique: 17kfrR-JNNafawCIyn4vnA-1 X-Mimecast-Spam-Score: 0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Archived-At: Subject: Re: [tram] Roman Danyliw's Discuss on draft-ietf-tram-turnbis-27: (with DISCUSS and COMMENT) X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.29 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, 11 Jul 2019 09:07:58 -0000 SGkgUm9tYW4sDQoNClRoYW5rcyBmb3IgdGhlIHJldmlldy4gUGxlYXNlIHNlZSBpbmxpbmUNCg0K PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiB0cmFtIDx0cmFtLWJvdW5jZXNA aWV0Zi5vcmc+IE9uIEJlaGFsZiBPZiBSb21hbiBEYW55bGl3IHZpYQ0KPiBEYXRhdHJhY2tlcg0K PiBTZW50OiBUaHVyc2RheSwgSnVseSAxMSwgMjAxOSA0OjIwIEFNDQo+IFRvOiBUaGUgSUVTRyA8 aWVzZ0BpZXRmLm9yZz4NCj4gQ2M6IHRyYW0tY2hhaXJzQGlldGYub3JnOyBkcmFmdC1pZXRmLXRy YW0tdHVybmJpc0BpZXRmLm9yZzsgdHJhbUBpZXRmLm9yZzsNCj4gYnJhbmRvbi53aWxsaWFtc0Bh a2FtYWkuY29tDQo+IFN1YmplY3Q6IFt0cmFtXSBSb21hbiBEYW55bGl3J3MgRGlzY3VzcyBvbiBk cmFmdC1pZXRmLXRyYW0tdHVybmJpcy0yNzogKHdpdGgNCj4gRElTQ1VTUyBhbmQgQ09NTUVOVCkN Cj4gDQo+IFRoaXMgZW1haWwgb3JpZ2luYXRlZCBmcm9tIG91dHNpZGUgb2YgdGhlIG9yZ2FuaXph dGlvbi4gRG8gbm90IGNsaWNrIGxpbmtzIG9yDQo+IG9wZW4gYXR0YWNobWVudHMgdW5sZXNzIHlv dSByZWNvZ25pemUgdGhlIHNlbmRlciBhbmQga25vdyB0aGUgY29udGVudCBpcw0KPiBzYWZlLg0K PiANCj4gUm9tYW4gRGFueWxpdyBoYXMgZW50ZXJlZCB0aGUgZm9sbG93aW5nIGJhbGxvdCBwb3Np dGlvbiBmb3INCj4gZHJhZnQtaWV0Zi10cmFtLXR1cm5iaXMtMjc6IERpc2N1c3MNCj4gDQo+IFdo ZW4gcmVzcG9uZGluZywgcGxlYXNlIGtlZXAgdGhlIHN1YmplY3QgbGluZSBpbnRhY3QgYW5kIHJl cGx5IHRvIGFsbCBlbWFpbA0KPiBhZGRyZXNzZXMgaW5jbHVkZWQgaW4gdGhlIFRvIGFuZCBDQyBs aW5lcy4gKEZlZWwgZnJlZSB0byBjdXQgdGhpcyBpbnRyb2R1Y3RvcnkNCj4gcGFyYWdyYXBoLCBo b3dldmVyLikNCj4gDQo+IA0KPiBQbGVhc2UgcmVmZXIgdG8gaHR0cHM6Ly93d3cuaWV0Zi5vcmcv aWVzZy9zdGF0ZW1lbnQvZGlzY3Vzcy1jcml0ZXJpYS5odG1sDQo+IGZvciBtb3JlIGluZm9ybWF0 aW9uIGFib3V0IElFU0cgRElTQ1VTUyBhbmQgQ09NTUVOVCBwb3NpdGlvbnMuDQo+IA0KPiANCj4g VGhlIGRvY3VtZW50LCBhbG9uZyB3aXRoIG90aGVyIGJhbGxvdCBwb3NpdGlvbnMsIGNhbiBiZSBm b3VuZCBoZXJlOg0KPiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRm LXRyYW0tdHVybmJpcy8NCj4gDQo+IA0KPiANCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiBESVNDVVNTOg0K PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tDQo+IA0KPiAoMSkgU2VjdGlvbiAxMi4xLjYuICAoUGVyIHRoZSBiYWNr LWFuZC1mb3J0aCBvbiBDaHJpcyBXb29k4oCZcyBTRUNESVIgcmV2aWV3IOKAkw0KPiB0aGFuayB5 b3UgQ2hyaXMhKSBQZXIg4oCcQ29uZmlkZW50aWFsaXR5IGlzIG9ubHkgYSBzZWNvbmRhcnkgY29u Y2VybiwgYXMgVFVSTg0KPiBjb250cm9sIG1lc3NhZ2VzIGRvIG5vdCBpbmNsdWRlIGluZm9ybWF0 aW9uIHRoYXQgaXMgcGFydGljdWxhcmx5IHNlbnNpdGl2ZeKAnSwNCj4gd291bGRu4oCZdCB0aGUg VVNFUk5BTUUgYW5kIFJFQUxNIHBvdGVudGlhbGx5IGJlIHByaXZhY3kgc2Vuc2l0aXZlPyAgSWYg dGhleQ0KPiBhcmVu4oCZdCBzZW5zaXRpdmUgaW4gYWxsIGNhc2VzIChlLmcuLCB1c2VybmFtZXMg bWlnaHQgYmUgZXBoZW1lcmFsKSwgdGhpcw0KPiBzaG91bGQgYmUgbm90ZWQgYW5kIGNpdGVkLg0K DQpBZ3JlZWQsIGFkZGVkIHRoZSBmb2xsb3dpbmcgcGFyYWdyYXBoOg0KDQogICBJZiB0aGUgVFVS TiBjbGllbnQgYW5kIHNlcnZlciB1c2UgdGhlIFNUVU4gRXh0ZW5zaW9uIGZvciBUaGlyZC1QYXJ0 eQ0KICAgQXV0aG9yaXphdGlvbiBbUkZDNzYzNV0gKGZvciBleGFtcGxlIGl0IGlzIHVzZWQgaW4g V2ViUlRDKSwgdGhlDQogICB1c2VybmFtZSBkb2VzIG5vdCByZXZlYWwgdGhlIHJlYWwgdXNlcidz IGlkZW50aXR5LCB0aGUgVVNFUk5BTUUNCiAgIGF0dHJpYnV0ZSBjYXJyaWVzIGFuIGVwaGVtZXJh bCBhbmQgdW5pcXVlIGtleSBpZGVudGlmaWVyLiAgSWYgdGhlDQogICBUVVJOIGNsaWVudCBhbmQg c2VydmVyIHVzZSB0aGUgU1RVTiBsb25nLXRlcm0gY3JlZGVudGlhbCBtZWNoYW5pc20NCiAgIGFu ZCB0aGUgdXNlcm5hbWUgcmV2ZWFscyB0aGUgcmVhbCB1c2VyJ3MgaWRlbnRpdHksIHRoZSBjbGll bnQgbmVlZHMNCiAgIHRvIHVzZSAoRClUTFMgdHJhbnNwb3J0IGJldHdlZW4gdGhlIGNsaWVudCBh bmQgdGhlIHNlcnZlciBvciB1c2UgdGhlDQogICBVU0VSSEFTSCBhdHRyaWJ1dGUgaW5zdGVhZCBv ZiB0aGUgVVNFUk5BTUUgYXR0cmlidXRlIHRvIGFub255bm1pemUNCiAgIHRoZSB1c2VybmFtZS4N Cg0KICAgSWYgdGhlIFRVUk4gY2xpZW50IGFuZCBzZXJ2ZXIgdXNlIHRoZSBTVFVOIGxvbmctdGVy bSBjcmVkZW50aWFsDQogICBtZWNoYW5pc20gYW5kIHJlYWxtIGluZm9ybWF0aW9uIGlzIHByaXZh Y3kgc2Vuc2l0aXZlLCBUVVJOIGNhbiBiZSBydW4NCiAgIG92ZXIgKEQpVExTLiAgQXMgYSByZW1p bmRlciwgU1RVTiBFeHRlbnNpb24gZm9yIFRoaXJkLVBhcnR5DQogICBBdXRob3JpemF0aW9uIGRv ZXMgbm90IHVzZSByZWFsbS4NCg0KPiANCj4gDQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gQ09NTUVOVDoN Cj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLQ0KPiANCj4gKDIpIFRoaXMgZHJhZnQgcmVsaWVzIG9uIHRoZSBkcmFm dC1pZXRmLXRyYW0tc3R1bmJpc+KAmXMgU1RVTiBQYXNzd29yZCBBbGdvDQo+IFJlZ2lzdHJ5IHdo aWNoIGhhcyBNRDUgYW5kIFNIQS0yNTYuICBTZWN0aW9uIDE2LjEuMSBvZiB0aGF0IGRyYWZ0IGFs cmVhZHkNCj4gZGlzY3Vzc2VzIHRoZSBsaW1pdGF0aW9uIG9mIFNIQS0yNTYgKHdoaWNoIGl0IG1p Z2h0IGJlIHVzZWZ1bCB0byByZWZlcmVuY2UpLg0KPiBOZXZlcnRoZWxlc3MsIGFyZSB0aGVyZSBj YXNlcyB3aGVyZSBNRDUgc2hvdWxkIGJlIHVzZWQgb3ZlciBTSEEtMjU2IGlmDQo+IHRoZXJlIGlz IGEgY2hvaWNlPyAgSXMgdGhlcmUgYSByZWFzb24gbm90IHRvIHJlY29tbWVuZCB0aGF0IGltcGxl bWVudGF0aW9ucw0KPiDigJxTSE9VTEQgTk9UIHVzZSBNRDXigJ0/DQoNClRoZSBvbmx5IHJlYXNv biBkcmFmdC1pZXRmLXRyYW0tc3R1bmJpcyByZXRhaW5lZCBNRDUgaXMgZm9yIGJhY2t3YXJkLWNv bXBhdGliaWxpdHkgKGNsaWVudCB1c2luZyBvbGRlciB2ZXJzaW9uIG9mIFNUVU4gKFJGQzUzODkp KS4gDQoNCj4gDQo+ICgzKSBTZWN0aW9uIDUuIFBlciDigJxUaGUgY2xpZW50IFNIT1VMRCBpbmNs dWRlIHRoZSBTT0ZUV0FSRSDigKbigJ0gYW5kIOKAnFRoZQ0KPiBjbGllbnQgYW5kIHRoZSBzZXJ2 ZXIgTUFZIGluY2x1ZGUgdGhlIEZJTkdFUlBSSU5UIGF0dHJpYnV0ZSDigKbigJ0sIHdoeSBpcyB0 aGUNCj4gc2VuZGluZyBvZiBTT0ZUV0FSRSBub3QgYSDigJxNQVnigJ0gdG9vPw0KDQpUaGlzIHNh bWUgYmVoYXZpb3IgaXMgZGVmaW5lZCBpbiBSRkM1NzY2IGFuZCB0dXJuYmlzIGRvZXMgbm90IG1v ZGlmeSB0aGUgYmVoYXZpb3IsIGFuZCB0byBhZGRyZXNzIHRoZSBjb21tZW50IGZyb20gQ2hyaXMg V29vZCAoU2VjZGlyIHJldmlldykgYWRkZWQgdGhlIGZvbGxvd2luZyBsaW5lIHRvIFNlY3VyaXR5 IENvbnNpZGVyYXRpb25zIHNlY3Rpb246DQoNClNPRlRXQVJFIGF0dHJpYnV0ZSBjYW4gcmV2ZWFs IHRoZSBzcGVjaWZpYyBzb2Z0d2FyZSB2ZXJzaW9uIG9mIHRoZSBUVVJOIGNsaWVudCBhbmQgc2Vy dmVyIHRvIGVhdmVzZHJvcHBlciBhbmQgaXQgbWlnaHQgcG9zc2libHkgYWxsb3cgYXR0YWNrcyBh Z2FpbnN0IHZ1bG5lcmFibGUgc29mdHdhcmUgdGhhdCBpcyBrbm93biB0byBjb250YWluIHNlY3Vy aXR5IGhvbGVzLiBJZiBpdCBpcyBpbXBvcnRhbnQgdG8gcHJldmVudCBhbiBlYXZlc2Ryb3BwZXIg ZnJvbSBsZWFybmluZyB0aGUgc29mdHdhcmUgdmVyc2lvbiwgVFVSTiBjYW4gYmUgcnVuIG92ZXIg KEQpVExTLiANCg0KPiANCj4gKDQpIFNlY3Rpb24gNS4gIChQZXIgdGhlIGJhY2stYW5kLWZvcnRo IG9uIENocmlzIFdvb2TigJlzIFNFQ0RJUiByZXZpZXcpDQo+IFJlY29tbWVuZCBjaXRpbmcgU2Vj dGlvbiA2LjMuMSBvZiBbZHJhZnQtaWV0Zi10cmFtLXN0dW5iaXNdIGFzIHNvdXJjZSBvZiA0MA0K PiBzZWNvbmQgcmVxdWVzdCBidWZmZXIgdGltZW91dA0KDQpEb25lLg0KDQo+IA0KPiAoNSkgU2Vj dGlvbiAyMS40LiAgUGVyIOKAnEl0IGlzIFJFQ09NTUVOREVEIHRoYXQgVFVSTiBzZXJ2ZXJzIG5v dCBhY2NlcHQNCj4gYWxsb2NhdGlvbiBvciBjaGFubmVsIGJpbmRpbmcgcmVxdWVzdHMgZnJvbSBh ZGRyZXNzZXMga25vd24gdG8gYmUNCj4gdHVubmVsZWTigJ0sIEkgY29uY3VyIHdpdGggdGhlIGFk dmljZS4gIEhvdyB3b3VsZCBvbmUgcmVjb2duaXplIHRoYXQgdGhlDQo+IGFkZHJlc3MgaXMgYmVp bmcgdHVubmVsZWQ/DQoNCkJ5IG1hbmFnaW5nIGRyb3AtbGlzdCBvZiB0dW5uZWwgSVAgYWRkcmVz c2VzLCBpdCBpcyB0aGUgc2FtZSB0ZWNobmlxdWUgdXNlZCBieSBzZXZlcmFsIHdlYnNpdGVzIHRv IGJsb2NrIFZQTiBhY2Nlc3MgKHNlZSBodHRwczovL3d3dy5ob3d0b2dlZWsuY29tLzQwMzc3MS93 aHktZG8tc29tZS13ZWJzaXRlcy1ibG9jay12cG5zLykgDQoNCkNoZWVycywNCi1UaXJ1DQoNCj4g DQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K PiB0cmFtIG1haWxpbmcgbGlzdA0KPiB0cmFtQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vdHJhbQ0K From nobody Thu Jul 11 06:39:31 2019 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 5A4451200E0; Thu, 11 Jul 2019 06:39:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=kaloom.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 9IqEk1txDBCG; Thu, 11 Jul 2019 06:39:27 -0700 (PDT) Received: from CAN01-QB1-obe.outbound.protection.outlook.com (mail-eopbgr660098.outbound.protection.outlook.com [40.107.66.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 45068120077; Thu, 11 Jul 2019 06:39:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kaloom.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=MF4XQbBPTJLbf28Khjt7iDjd/0WSbYdWe9FsHY2GEE4=; b=qK6cVVaWgbtTb1ssDf27UCTGST3ocLkK+/h2FArmTlBh9HuHeu9QPFduFfJcOY/eRwn+FSbcQF3Q6qIh30EajSDySAUZiQ2PJpHzXENzvSzYBcnUEE2Dtlov598s1L6aMAkzUWfNl/0E5FlSQng1qW6UNoiwmgkEJLHTEkLhDGI= Received: from YTOPR0101MB1819.CANPRD01.PROD.OUTLOOK.COM (52.132.45.144) by YTOPR0101MB2057.CANPRD01.PROD.OUTLOOK.COM (52.132.49.26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2052.19; Thu, 11 Jul 2019 13:39:25 +0000 Received: from YTOPR0101MB1819.CANPRD01.PROD.OUTLOOK.COM ([fe80::20b6:a749:45f6:12ba]) by YTOPR0101MB1819.CANPRD01.PROD.OUTLOOK.COM ([fe80::20b6:a749:45f6:12ba%3]) with mapi id 15.20.2052.020; Thu, 11 Jul 2019 13:39:24 +0000 From: Suresh Krishnan To: "Konda, Tirumaleswar Reddy" CC: The IESG , "tram-chairs@ietf.org" , "draft-ietf-tram-turnbis@ietf.org" , "tram@ietf.org" , "brandon.williams@akamai.com" Thread-Topic: [tram] Suresh Krishnan's No Objection on draft-ietf-tram-turnbis-27: (with COMMENT) Thread-Index: AQHVNyhl0ttLdPYM5Eq5z2tsfGAIDqbD6e+QgAGD2gA= Date: Thu, 11 Jul 2019 13:39:24 +0000 Message-ID: <11E976B5-6C72-4413-B81C-23D7631118A1@kaloom.com> References: <156276743162.15103.11217512835677641225.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Suresh@kaloom.com; x-originating-ip: [45.19.110.76] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: ebde8735-ffbf-4d47-0180-08d706053036 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(7021145)(8989299)(4534185)(7022145)(4603075)(4627221)(201702281549075)(8990200)(7048125)(7024125)(7027125)(7023125)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:YTOPR0101MB2057; x-ms-traffictypediagnostic: YTOPR0101MB2057: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:6430; x-forefront-prvs: 0095BCF226 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(366004)(39850400004)(376002)(346002)(136003)(189003)(199004)(508600001)(6486002)(229853002)(54896002)(4326008)(53936002)(68736007)(54906003)(236005)(76176011)(6512007)(6436002)(8936002)(53546011)(6506007)(6246003)(102836004)(3846002)(6116002)(6916009)(99286004)(316002)(25786009)(7736002)(71200400001)(476003)(33656002)(80792005)(71190400001)(4744005)(2906002)(5660300002)(81166006)(91956017)(76116006)(36756003)(186003)(2616005)(11346002)(14454004)(66946007)(66556008)(26005)(66446008)(446003)(66476007)(486006)(66066001)(81156014)(8676002)(256004)(64756008)(86362001); DIR:OUT; SFP:1102; SCL:1; SRVR:YTOPR0101MB2057; H:YTOPR0101MB1819.CANPRD01.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: kaloom.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: je90+En7+HVv/3Ap1JWo+TqHnYn2u1NXtFADuu8DaJa9ctgJ03oZZmQGz/Gr7AzcuVgJZrJi24kVbMuxhZRi0DMoArRoDJp2ptdBu1GMj57XAY62v1it2CC4mJhmu161jjpdOoHS2IYPt815DuYVe3Y4VeFXYSd5EYelPww56h3zMIAnqjKdKLkbCTvSOPJfGG8G3viNdTvREeL1RZUeazcpeMoY8x3Co57yhqODfUYZ+q35NGeQ3S1oJVbBmA+ARmqyQGZQIlq+K1aBPVZmtk3yMSTokDs4Vz/eeZEZtbyG1wkGRc6a2VYm7wy2wZe+hvoH1PGseUP2uZSvkbLP1lU2SqRH2tazFiHAWDbS1YZbr5Imzgz8bhgCr5FVBK7RvUm8s/vvMVtASDFy8frxQFMnGQ5m7hycbHsSYe1Dd7A= Content-Type: multipart/alternative; boundary="_000_11E976B56C724413B81C23D7631118A1kaloomcom_" MIME-Version: 1.0 X-OriginatorOrg: kaloom.com X-MS-Exchange-CrossTenant-Network-Message-Id: ebde8735-ffbf-4d47-0180-08d706053036 X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Jul 2019 13:39:24.7964 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 47d58e26-f796-48e8-ac40-1c365c204513 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: Suresh@kaloom.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: YTOPR0101MB2057 Archived-At: Subject: Re: [tram] Suresh Krishnan's No Objection on draft-ietf-tram-turnbis-27: (with COMMENT) X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.29 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, 11 Jul 2019 13:39:30 -0000 --_000_11E976B56C724413B81C23D7631118A1kaloomcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Tiru, Thanks for addressing my comments. Your suggested text changes look good = to me except one. The open point inline. On Jul 11, 2019, at 2:11 AM, Konda, Tirumaleswar Reddy > wrote: * Section 13.2 Page 53 "If the packet is being sent to the peer" The term "the packet" is ambiguous here. This could potentially refer to th= e ICMPv6 packet being sent or the original packet that caused the error. Can you please clarify which one you mean here? Fixed text for clarity as follows: If the ICMPv4 packet (Destination Unreachable (Type 3) with Code 4) is bein= g sent to the peer, the TURN server SHOULD reduce the MTU reported in the I= CMP message by 48 bytes to allow room for the overhead of a Data indication= . This text will not work. It is an ICMPv6 packet that will be sent and not a= n ICMPv4 packet. Can you reword with ICMPv6 Packet Too Big instead. Regards Suresh --_000_11E976B56C724413B81C23D7631118A1kaloomcom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable Hi Tiru,
  Thanks for addressing my comments. Your suggested text changes = look good to me except one. The open point inline.

On Jul 11, 2019, at 2:11 AM, Konda, Tirumaleswar Reddy <= Tirumalesw= arReddy_Konda@McAfee.com> wrote:



* Section 13.2 Page 53

"If the packet is being sent to the peer"

The term "the packet" is ambiguous here. This could potentially r= efer to the
ICMPv6 packet being sent or the original packet that caused the error. Can<= br class=3D""> you please clarify which one you mean here?

Fixed text for clarity as follows:
If the ICMPv4 packet (Destination Unreachable (Type 3) with Code 4) is being = sent to the peer, the TURN server SHOULD reduce the MTU reported in the ICM= P message by 48 bytes to allow room for the overhead of a Data indication.<= span class=3D"Apple-converted-space"> 

This text will not work. It is an ICMPv6 packet that will b= e sent and not an ICMPv4 packet. Can you reword with ICMPv6 Packet Too Big = instead.

Regards
Suresh

--_000_11E976B56C724413B81C23D7631118A1kaloomcom_-- From nobody Thu Jul 11 08:19:32 2019 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 BB6B912004E for ; Thu, 11 Jul 2019 08:19:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.398 X-Spam-Level: X-Spam-Status: No, score=-2.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=mcafee.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R0KO0b_j6g3W for ; Thu, 11 Jul 2019 08:19:19 -0700 (PDT) Received: from us-smtp-delivery-210.mimecast.com (us-smtp-delivery-210.mimecast.com [216.205.24.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 16A741200E6 for ; Thu, 11 Jul 2019 08:19:18 -0700 (PDT) X-NAI-Header: Modified by McAfee Email Gateway (5500) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mcafee.com; s=s_mcafee; t=1562857721; h=From: To:CC:Subject:Thread-Topic:Thread-Index:Date: Message-ID:References:In-Reply-To:Accept-Language: Content-Language:X-MS-Has-Attach:X-MS-TNEF-Correlator: dlp-product:dlp-version:dlp-reaction:authentication-results: x-originating-ip:x-ms-publictraffictype:x-ms-office365-filtering-correlation-id: x-microsoft-antispam:x-ms-traffictypediagnostic: x-ms-exchange-purlcount:x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers:x-forefront-prvs: x-forefront-antispam-report:received-spf:x-ms-exchange-senderadcheck: x-microsoft-antispam-message-info:Content-Type: MIME-Version:X-MS-Exchange-CrossTenant-Network-Message-Id: X-MS-Exchange-CrossTenant-originalarrivaltime: X-MS-Exchange-CrossTenant-fromentityheader: X-MS-Exchange-CrossTenant-id:X-MS-Exchange-CrossTenant-mailboxtype: X-MS-Exchange-CrossTenant-userprincipalname: X-MS-Exchange-Transport-CrossTenantHeadersStamped: X-OriginatorOrg:X-NAI-Spam-Flag:X-NAI-Spam-Level: X-NAI-Spam-Threshold:X-NAI-Spam-Score:X-NAI-Spam-Version; bh=pLuMFjg7HEr2Zo3FGAXagFxogT8WyxBwEob8wK BMNuE=; b=grOPS+lJ4p5CG77x0xal1Sn3/OeIiqBqWViF51s5 AnOHFTM8hP3Qr9D6k9/g2rvmlvZrbpNjseXCTT9Ij9nAWtAHXR 4LXh8C/Tgrx654tGY15ohFgh9vTBwFdne+3T2ouswRypXHq6D2 r4eRtQzuKzyVRLJ5uiFiIralLYCvA3M= Received: from DNVWSMAILOUT1.mcafee.com (dnvwsmailout1.mcafee.com [161.69.31.173]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-297-Dp7S4grmMvujs-jel2gZ5w-1; Thu, 11 Jul 2019 11:19:15 -0400 Received: from DNVEXAPP1N06.corpzone.internalzone.com (unknown [10.44.48.90]) by DNVWSMAILOUT1.mcafee.com with smtp (TLS: TLSv1/SSLv3,256bits,ECDHE-RSA-AES256-SHA384) id 3220_d61f_b7f133ef_26b4_4147_a856_ca2ee358566a; Thu, 11 Jul 2019 09:08:40 -0600 Received: from DNVEXAPP1N05.corpzone.internalzone.com (10.44.48.89) by DNVEXAPP1N06.corpzone.internalzone.com (10.44.48.90) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Thu, 11 Jul 2019 09:19:11 -0600 Received: from DNVO365EDGE1.corpzone.internalzone.com (10.44.176.66) by DNVEXAPP1N05.corpzone.internalzone.com (10.44.48.89) with Microsoft SMTP Server (TLS) id 15.0.1395.4 via Frontend Transport; Thu, 11 Jul 2019 09:19:11 -0600 Received: from NAM05-CO1-obe.outbound.protection.outlook.com (10.44.176.243) by edge.mcafee.com (10.44.176.66) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Thu, 11 Jul 2019 09:19:09 -0600 Received: from DM5PR16MB1705.namprd16.prod.outlook.com (10.172.44.147) by DM5PR16MB1641.namprd16.prod.outlook.com (10.174.177.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2052.20; Thu, 11 Jul 2019 15:19:09 +0000 Received: from DM5PR16MB1705.namprd16.prod.outlook.com ([fe80::570:2208:75c2:5f17]) by DM5PR16MB1705.namprd16.prod.outlook.com ([fe80::570:2208:75c2:5f17%8]) with mapi id 15.20.2052.019; Thu, 11 Jul 2019 15:19:09 +0000 From: "Konda, Tirumaleswar Reddy" To: Suresh Krishnan CC: The IESG , "tram-chairs@ietf.org" , "draft-ietf-tram-turnbis@ietf.org" , "tram@ietf.org" , "brandon.williams@akamai.com" Thread-Topic: [tram] Suresh Krishnan's No Objection on draft-ietf-tram-turnbis-27: (with COMMENT) Thread-Index: AQHVNyhl0ttLdPYM5Eq5z2tsfGAIDqbD6e+QgAGD2gCAABsVwA== Date: Thu, 11 Jul 2019 15:19:09 +0000 Message-ID: References: <156276743162.15103.11217512835677641225.idtracker@ietfa.amsl.com> <11E976B5-6C72-4413-B81C-23D7631118A1@kaloom.com> In-Reply-To: <11E976B5-6C72-4413-B81C-23D7631118A1@kaloom.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.3.0.16 dlp-reaction: no-action x-originating-ip: [49.37.206.28] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 71da5f0f-b50c-4562-2383-08d706131f83 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:DM5PR16MB1641; x-ms-traffictypediagnostic: DM5PR16MB1641: x-ms-exchange-purlcount: 2 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8273; x-forefront-prvs: 0095BCF226 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(136003)(366004)(376002)(396003)(39860400002)(346002)(32952001)(189003)(199004)(9686003)(446003)(476003)(11346002)(7736002)(6246003)(236005)(486006)(25786009)(33656002)(478600001)(229853002)(2906002)(74316002)(3846002)(6306002)(66066001)(54896002)(5024004)(53936002)(55016002)(256004)(790700001)(6116002)(14454004)(8936002)(186003)(81166006)(66556008)(66476007)(81156014)(8676002)(316002)(86362001)(102836004)(26005)(5660300002)(6506007)(80792005)(53546011)(76116006)(71190400001)(68736007)(66946007)(66446008)(64756008)(6436002)(99286004)(54906003)(6916009)(9326002)(4326008)(71200400001)(7696005)(76176011)(52536014)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR16MB1641; H:DM5PR16MB1705.namprd16.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: RX1aEVvC7ezvbRX98UZtpJHoYKjhMlNTlDPTheWCx6KXE24J50jdUlnrkfDwsCBuYvInpAOC1H8zFrPB1VYK7LCq6GNa8pvXIaYhZLfd3S2jkKLwFWaDeHNdhu8INL7cVoQta5SBDGiI79w66QTyw0KC4cVXg5j3nYj2duOaSAUq14v91XQiuMc/RnwGHBiMCRzi9w4WsV6LE7hCSU6/8QckVCDH/tPZoZQJELy+ITvebLqshyCM5MN+l5+tNFFWWXqc5VmdMVRx9EA1CyeLLF9cu6Zdsnkij3ma6HaH820A2xp+jx0aDKBtHonLUOd26i10h09wYRadKJN+A7AkiG7CgT9CUfmRbpyJGGM3m66Ipxsp0tDCNwSgTKBRMZc5Apv45NdI/TZ9vfSW9GladjfaA6vnIg5bGiMS3Fgd3M0= MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 71da5f0f-b50c-4562-2383-08d706131f83 X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Jul 2019 15:19:09.7266 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: TirumaleswarReddy_Konda@McAfee.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR16MB1641 X-OriginatorOrg: mcafee.com X-NAI-Spam-Flag: NO X-NAI-Spam-Level: X-NAI-Spam-Threshold: 15 X-NAI-Spam-Score: 0.2 X-NAI-Spam-Version: 2.3.0.9418 : core <6588> : inlines <7117> : streams <1827052> : uri <2866366> X-MC-Unique: Dp7S4grmMvujs-jel2gZ5w-1 X-Mimecast-Spam-Score: 0 Content-Type: multipart/alternative; boundary="_000_DM5PR16MB1705D35988541D28D84FD13BEAF30DM5PR16MB1705namp_" Archived-At: Subject: Re: [tram] Suresh Krishnan's No Objection on draft-ietf-tram-turnbis-27: (with COMMENT) X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.29 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, 11 Jul 2019 15:19:24 -0000 --_000_DM5PR16MB1705D35988541D28D84FD13BEAF30DM5PR16MB1705namp_ Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 SGkgU3VyZXNoLA0KDQpJIG1vZGlmaWVkIGJvdGggMTMuMiBhbmQgMTMuMyBzZWN0aW9ucy4gVGhl IHRleHQgSSBwcm9wb3NlZCBpcyBmb3IgMTMuMyAoSVB2Ni10by1JUHY0IFRyYW5zbGF0aW9ucyku IEZvciBTZWN0aW9uIDEzLjIgKElQdjYtdG8tSVB2NiBUcmFuc2xhdGlvbnMpIHVzZWQgdGhlIGZv bGxvd2luZyB0ZXh0Og0KSWYgdGhlIElDTVB2NiBwYWNrZXQgKCJQYWNrZXQgdG9vIGJpZyIpIGlz IGJlaW5nIHNlbnQgdG8gdGhlIHBlZXIsIHRoZSBUVVJOIHNlcnZlciByZWR1Y2VzIHRoZSBNVFUg cmVwb3J0ZWQgaW4gdGhlIElDTVAgbWVzc2FnZSBieSA0OCBieXRlcyB0byBhbGxvdyByb29tIGZv ciB0aGUgb3ZlcmhlYWQgb2YgYSBEYXRhIGluZGljYXRpb24uDQoNCkNoZWVycywNCi1UaXJ1DQoN CkZyb206IFN1cmVzaCBLcmlzaG5hbiA8U3VyZXNoQGthbG9vbS5jb20+DQpTZW50OiBUaHVyc2Rh eSwgSnVseSAxMSwgMjAxOSA3OjA5IFBNDQpUbzogS29uZGEsIFRpcnVtYWxlc3dhciBSZWRkeSA8 VGlydW1hbGVzd2FyUmVkZHlfS29uZGFATWNBZmVlLmNvbT4NCkNjOiBUaGUgSUVTRyA8aWVzZ0Bp ZXRmLm9yZz47IHRyYW0tY2hhaXJzQGlldGYub3JnOyBkcmFmdC1pZXRmLXRyYW0tdHVybmJpc0Bp ZXRmLm9yZzsgdHJhbUBpZXRmLm9yZzsgYnJhbmRvbi53aWxsaWFtc0Bha2FtYWkuY29tDQpTdWJq ZWN0OiBSZTogW3RyYW1dIFN1cmVzaCBLcmlzaG5hbidzIE5vIE9iamVjdGlvbiBvbiBkcmFmdC1p ZXRmLXRyYW0tdHVybmJpcy0yNzogKHdpdGggQ09NTUVOVCkNCg0KDQpDQVVUSU9OOiBFeHRlcm5h bCBlbWFpbC4gRG8gbm90IGNsaWNrIGxpbmtzIG9yIG9wZW4gYXR0YWNobWVudHMgdW5sZXNzIHlv dSByZWNvZ25pemUgdGhlIHNlbmRlciBhbmQga25vdyB0aGUgY29udGVudCBpcyBzYWZlLg0KDQpf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KSGkgVGlydSwNCiAgVGhhbmtzIGZvciBh ZGRyZXNzaW5nIG15IGNvbW1lbnRzLiBZb3VyIHN1Z2dlc3RlZCB0ZXh0IGNoYW5nZXMgbG9vayBn b29kIHRvIG1lIGV4Y2VwdCBvbmUuIFRoZSBvcGVuIHBvaW50IGlubGluZS4NCg0KDQpPbiBKdWwg MTEsIDIwMTksIGF0IDI6MTEgQU0sIEtvbmRhLCBUaXJ1bWFsZXN3YXIgUmVkZHkgPFRpcnVtYWxl c3dhclJlZGR5X0tvbmRhQE1jQWZlZS5jb208bWFpbHRvOlRpcnVtYWxlc3dhclJlZGR5X0tvbmRh QE1jQWZlZS5jb20+PiB3cm90ZToNCg0KDQoNCg0KKiBTZWN0aW9uIDEzLjIgUGFnZSA1Mw0KDQoi SWYgdGhlIHBhY2tldCBpcyBiZWluZyBzZW50IHRvIHRoZSBwZWVyIg0KDQpUaGUgdGVybSAidGhl IHBhY2tldCIgaXMgYW1iaWd1b3VzIGhlcmUuIFRoaXMgY291bGQgcG90ZW50aWFsbHkgcmVmZXIg dG8gdGhlDQpJQ01QdjYgcGFja2V0IGJlaW5nIHNlbnQgb3IgdGhlIG9yaWdpbmFsIHBhY2tldCB0 aGF0IGNhdXNlZCB0aGUgZXJyb3IuIENhbg0KeW91IHBsZWFzZSBjbGFyaWZ5IHdoaWNoIG9uZSB5 b3UgbWVhbiBoZXJlPw0KDQpGaXhlZCB0ZXh0IGZvciBjbGFyaXR5IGFzIGZvbGxvd3M6DQpJZiB0 aGUgSUNNUHY0IHBhY2tldCAoRGVzdGluYXRpb24gVW5yZWFjaGFibGUgKFR5cGUgMykgd2l0aCBD b2RlIDQpIGlzIGJlaW5nIHNlbnQgdG8gdGhlIHBlZXIsIHRoZSBUVVJOIHNlcnZlciBTSE9VTEQg cmVkdWNlIHRoZSBNVFUgcmVwb3J0ZWQgaW4gdGhlIElDTVAgbWVzc2FnZSBieSA0OCBieXRlcyB0 byBhbGxvdyByb29tIGZvciB0aGUgb3ZlcmhlYWQgb2YgYSBEYXRhIGluZGljYXRpb24uDQoNClRo aXMgdGV4dCB3aWxsIG5vdCB3b3JrLiBJdCBpcyBhbiBJQ01QdjYgcGFja2V0IHRoYXQgd2lsbCBi ZSBzZW50IGFuZCBub3QgYW4gSUNNUHY0IHBhY2tldC4gQ2FuIHlvdSByZXdvcmQgd2l0aCBJQ01Q djYgUGFja2V0IFRvbyBCaWcgaW5zdGVhZC4NCg0KUmVnYXJkcw0KU3VyZXNoDQoNCg== --_000_DM5PR16MB1705D35988541D28D84FD13BEAF30DM5PR16MB1705namp_ Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OkhlbHZldGljYTsNCglwYW5vc2UtMToyIDExIDYgNCAyIDIgMiAyIDIg NDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0x OjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpEZW5nWGlh bjsNCglwYW5vc2UtMToyIDEgNiAwIDMgMSAxIDEgMSAxO30NCkBmb250LWZhY2UNCgl7Zm9udC1m YW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OiJcQERlbmdYaWFuIjsNCglwYW5vc2UtMToyIDEgNiAwIDMgMSAx IDEgMSAxO30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9y bWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0 Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7 fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJ Y29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bh bi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5tc29ub3JtYWwwLCBsaS5t c29ub3JtYWwwLCBkaXYubXNvbm9ybWFsMA0KCXttc28tc3R5bGUtbmFtZTptc29ub3JtYWw7DQoJ bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjExLjBwdDsN Cglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpzcGFuLmFwcGxlLWNvbnZlcnRl ZC1zcGFjZQ0KCXttc28tc3R5bGUtbmFtZTphcHBsZS1jb252ZXJ0ZWQtc3BhY2U7fQ0Kc3Bhbi5F bWFpbFN0eWxlMjENCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1p bHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVm YXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30N CkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4g MS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9u MTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0 cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1b aWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRt YXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5k aWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1 cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ SGkgU3VyZXNoLDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIG1vZGlmaWVkIGJvdGggMTMuMiBh bmQgMTMuMyBzZWN0aW9ucy4gVGhlIHRleHQgSSBwcm9wb3NlZCBpcyBmb3IgMTMuMyAoSVB2Ni10 by1JUHY0IFRyYW5zbGF0aW9ucykuIEZvciBTZWN0aW9uIDEzLjIgKElQdjYtdG8tSVB2NiBUcmFu c2xhdGlvbnMpIHVzZWQgdGhlIGZvbGxvd2luZyB0ZXh0OjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+SWYgdGhlIElDTVB2NiBwYWNrZXQgKCZxdW90O1BhY2tldCB0b28gYmln JnF1b3Q7KSBpcyBiZWluZyBzZW50IHRvIHRoZSBwZWVyLCB0aGUgVFVSTiBzZXJ2ZXIgcmVkdWNl cyB0aGUgTVRVIHJlcG9ydGVkIGluIHRoZSBJQ01QIG1lc3NhZ2UgYnkgNDggYnl0ZXMgdG8gYWxs b3cgcm9vbSBmb3IgdGhlIG92ZXJoZWFkIG9mIGEgRGF0YSBpbmRpY2F0aW9uLjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5DaGVlcnMsPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij4tVGlydTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVl IDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJv cmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBp biAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPkZyb206PC9iPiBTdXJlc2ggS3Jp c2huYW4gJmx0O1N1cmVzaEBrYWxvb20uY29tJmd0OyA8YnI+DQo8Yj5TZW50OjwvYj4gVGh1cnNk YXksIEp1bHkgMTEsIDIwMTkgNzowOSBQTTxicj4NCjxiPlRvOjwvYj4gS29uZGEsIFRpcnVtYWxl c3dhciBSZWRkeSAmbHQ7VGlydW1hbGVzd2FyUmVkZHlfS29uZGFATWNBZmVlLmNvbSZndDs8YnI+ DQo8Yj5DYzo8L2I+IFRoZSBJRVNHICZsdDtpZXNnQGlldGYub3JnJmd0OzsgdHJhbS1jaGFpcnNA aWV0Zi5vcmc7IGRyYWZ0LWlldGYtdHJhbS10dXJuYmlzQGlldGYub3JnOyB0cmFtQGlldGYub3Jn OyBicmFuZG9uLndpbGxpYW1zQGFrYW1haS5jb208YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFt0 cmFtXSBTdXJlc2ggS3Jpc2huYW4ncyBObyBPYmplY3Rpb24gb24gZHJhZnQtaWV0Zi10cmFtLXR1 cm5iaXMtMjc6ICh3aXRoIENPTU1FTlQpPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHRhYmxl IGNsYXNzPSJNc29Ob3JtYWxUYWJsZSIgYm9yZGVyPSIxIiBjZWxscGFkZGluZz0iMCIgc3R5bGU9 ImJhY2tncm91bmQ6I0YzRkYzMztib3JkZXI6c29saWQgIzlCOUE4NyAxLjVwdCI+DQo8dGJvZHk+ DQo8dHI+DQo8dGQgc3R5bGU9ImJvcmRlcjpub25lO3BhZGRpbmc6Ljc1cHQgLjc1cHQgLjc1cHQg Ljc1cHQiPg0KPHA+PHN0cm9uZz48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojOUI4QjNFIj5DQVVUSU9OPC9zcGFuPjwvc3Ryb25nPjxz cGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiM5QjhCM0UiPjo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPiBFeHRlcm5hbCBlbWFpbC4gRG8gbm90IGNsaWNr IGxpbmtzIG9yIG9wZW4NCiBhdHRhY2htZW50cyB1bmxlc3MgeW91IHJlY29nbml6ZSB0aGUgc2Vu ZGVyIGFuZCBrbm93IHRoZSBjb250ZW50IGlzIHNhZmUuPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250 LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L3RkPg0KPC90cj4NCjwvdGJvZHk+DQo8L3RhYmxlPg0KPGRpdiBjbGFzcz0iTXNvTm9y bWFsIiBhbGlnbj0iY2VudGVyIiBzdHlsZT0idGV4dC1hbGlnbjpjZW50ZXIiPg0KPGhyIHNpemU9 IjIiIHdpZHRoPSIxMDAlIiBhbGlnbj0iY2VudGVyIj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5IaSBUaXJ1LDxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPiZuYnNwOyBUaGFua3MgZm9yIGFkZHJlc3NpbmcgbXkgY29tbWVudHMuIFlvdXIg c3VnZ2VzdGVkIHRleHQgY2hhbmdlcyBsb29rIGdvb2QgdG8gbWUgZXhjZXB0IG9uZS4gVGhlIG9w ZW4gcG9pbnQgaW5saW5lLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHls ZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5PbiBKdWwgMTEsIDIwMTksIGF0IDI6MTEgQU0sIEtvbmRhLCBUaXJ1bWFs ZXN3YXIgUmVkZHkgJmx0OzxhIGhyZWY9Im1haWx0bzpUaXJ1bWFsZXN3YXJSZWRkeV9Lb25kYUBN Y0FmZWUuY29tIj5UaXJ1bWFsZXN3YXJSZWRkeV9Lb25kYUBNY0FmZWUuY29tPC9hPiZndDsgd3Jv dGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2Vy aWYiPjxiciBzdHlsZT0iY2FyZXQtY29sb3I6IHJnYigwLCAwLCAwKTtmb250LXZhcmlhbnQtY2Fw czogbm9ybWFsO3RleHQtYWxpZ246c3RhcnQ7LXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4 O3dvcmQtc3BhY2luZzowcHgiPg0KPGJyPg0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGJsb2Nr cXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48YnI+DQoqIFNlY3Rpb24gMTMuMiBQ YWdlIDUzPGJyPg0KPGJyPg0KJnF1b3Q7SWYgdGhlIHBhY2tldCBpcyBiZWluZyBzZW50IHRvIHRo ZSBwZWVyJnF1b3Q7PGJyPg0KPGJyPg0KVGhlIHRlcm0gJnF1b3Q7dGhlIHBhY2tldCZxdW90OyBp cyBhbWJpZ3VvdXMgaGVyZS4gVGhpcyBjb3VsZCBwb3RlbnRpYWxseSByZWZlciB0byB0aGU8YnI+ DQpJQ01QdjYgcGFja2V0IGJlaW5nIHNlbnQgb3IgdGhlIG9yaWdpbmFsIHBhY2tldCB0aGF0IGNh dXNlZCB0aGUgZXJyb3IuIENhbjxicj4NCnlvdSBwbGVhc2UgY2xhcmlmeSB3aGljaCBvbmUgeW91 IG1lYW4gaGVyZT88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48YnI+DQpGaXhlZCB0ZXh0IGZvciBjbGFy aXR5IGFzIGZvbGxvd3M6PGJyPg0KSWYgdGhlIElDTVB2NCBwYWNrZXQgKERlc3RpbmF0aW9uIFVu cmVhY2hhYmxlIChUeXBlIDMpIHdpdGggQ29kZSA0KSBpcyBiZWluZyBzZW50IHRvIHRoZSBwZWVy LCB0aGUgVFVSTiBzZXJ2ZXIgU0hPVUxEIHJlZHVjZSB0aGUgTVRVIHJlcG9ydGVkIGluIHRoZSBJ Q01QIG1lc3NhZ2UgYnkgNDggYnl0ZXMgdG8gYWxsb3cgcm9vbSBmb3IgdGhlIG92ZXJoZWFkIG9m IGEgRGF0YSBpbmRpY2F0aW9uLjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZu YnNwOzwvc3Bhbj48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4N CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhpcyB0ZXh0IHdpbGwgbm90IHdvcmsuIEl0IGlzIGFu IElDTVB2NiBwYWNrZXQgdGhhdCB3aWxsIGJlIHNlbnQgYW5kIG5vdCBhbiBJQ01QdjQgcGFja2V0 LiBDYW4geW91IHJld29yZCB3aXRoIElDTVB2NiBQYWNrZXQgVG9vIEJpZyBpbnN0ZWFkLjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5SZWdhcmRz PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5TdXJl c2g8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9o dG1sPg0K --_000_DM5PR16MB1705D35988541D28D84FD13BEAF30DM5PR16MB1705namp_-- From nobody Thu Jul 11 08:47:38 2019 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 B3D06120353 for ; Thu, 11 Jul 2019 08:47:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=mcafee.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Ukey14r4RO5 for ; Thu, 11 Jul 2019 08:47:32 -0700 (PDT) Received: from us-smtp-delivery-210.mimecast.com (us-smtp-delivery-210.mimecast.com [216.205.24.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4ABEF120359 for ; Thu, 11 Jul 2019 08:47:32 -0700 (PDT) X-NAI-Header: Modified by McAfee Email Gateway (5500) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mcafee.com; s=s_mcafee; t=1562859410; h=From: To:CC:Subject:Thread-Topic:Thread-Index:Date: Message-ID:References:In-Reply-To:Accept-Language: Content-Language:X-MS-Has-Attach:X-MS-TNEF-Correlator: dlp-product:dlp-version:dlp-reaction:authentication-results: x-originating-ip:x-ms-publictraffictype:x-ms-office365-filtering-correlation-id: x-microsoft-antispam:x-ms-traffictypediagnostic: x-ms-exchange-purlcount:x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers:x-forefront-prvs: x-forefront-antispam-report:received-spf:x-ms-exchange-senderadcheck: x-microsoft-antispam-message-info:Content-Type: Content-Transfer-Encoding:MIME-Version:X-MS-Exchange-CrossTenant-Network-Message-Id: X-MS-Exchange-CrossTenant-originalarrivaltime: X-MS-Exchange-CrossTenant-fromentityheader: X-MS-Exchange-CrossTenant-id:X-MS-Exchange-CrossTenant-mailboxtype: X-MS-Exchange-CrossTenant-userprincipalname: X-MS-Exchange-Transport-CrossTenantHeadersStamped: X-OriginatorOrg:X-NAI-Spam-Flag:X-NAI-Spam-Level: X-NAI-Spam-Threshold:X-NAI-Spam-Score:X-NAI-Spam-Version; bh=7/BVi+53woHBZfwsI8ne/dcxXdqPdew+GMc5jc 58HEg=; b=or6vxD/Snxw5aCQYMpgJ0UQCZswgjDcgdLT3MZbd /gLywnFu+KEDQLN1U+9+EIUhux0szkamoNUGtnzy4fUfeSPFRv tJNZdZvi0ktA623l5s/d1npygYc1cKlLxMYUgL+Ororz/12K8X z0h7/WPye0hbqhYJwSVTFlZlSxqXKSo= Received: from DNVWSMAILOUT1.mcafee.com (dnvwsmailout1.mcafee.com [161.69.31.173]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-15-tyYx_XQNOMGBx9NNw14NFQ-1; Thu, 11 Jul 2019 11:47:25 -0400 Received: from DNVEXAPP1N06.corpzone.internalzone.com (DNVEXAPP1N06.corpzone.internalzone.com [10.44.48.90]) by DNVWSMAILOUT1.mcafee.com with smtp (TLS: TLSv1/SSLv3,256bits,ECDHE-RSA-AES256-SHA384) id 1e7f_4861_404f1205_0f7f_41ad_8c35_e9aa16d2c2d2; Thu, 11 Jul 2019 09:36:50 -0600 Received: from DNVEXAPP1N06.corpzone.internalzone.com (10.44.48.90) by DNVEXAPP1N06.corpzone.internalzone.com (10.44.48.90) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Thu, 11 Jul 2019 09:47:21 -0600 Received: from DNVO365EDGE1.corpzone.internalzone.com (10.44.176.66) by DNVEXAPP1N06.corpzone.internalzone.com (10.44.48.90) with Microsoft SMTP Server (TLS) id 15.0.1395.4 via Frontend Transport; Thu, 11 Jul 2019 09:47:21 -0600 Received: from NAM03-BY2-obe.outbound.protection.outlook.com (10.44.176.240) by edge.mcafee.com (10.44.176.66) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Thu, 11 Jul 2019 09:47:18 -0600 Received: from DM5PR16MB1705.namprd16.prod.outlook.com (10.172.44.147) by DM5PR16MB1721.namprd16.prod.outlook.com (10.172.47.17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2052.19; Thu, 11 Jul 2019 15:47:19 +0000 Received: from DM5PR16MB1705.namprd16.prod.outlook.com ([fe80::570:2208:75c2:5f17]) by DM5PR16MB1705.namprd16.prod.outlook.com ([fe80::570:2208:75c2:5f17%8]) with mapi id 15.20.2052.019; Thu, 11 Jul 2019 15:47:19 +0000 From: "Konda, Tirumaleswar Reddy" To: Benjamin Kaduk , The IESG CC: "tram-chairs@ietf.org" , "draft-ietf-tram-turnbis@ietf.org" , "tram@ietf.org" , "brandon.williams@akamai.com" Thread-Topic: [tram] Benjamin Kaduk's Discuss on draft-ietf-tram-turnbis-27: (with DISCUSS and COMMENT) Thread-Index: AQHVN6sj5hqeZIdQXEa8/G2g6Mwv66bFIQEg Date: Thu, 11 Jul 2019 15:47:19 +0000 Message-ID: References: <156282359426.15056.17118634579091500165.idtracker@ietfa.amsl.com> In-Reply-To: <156282359426.15056.17118634579091500165.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.3.0.16 dlp-reaction: no-action x-originating-ip: [49.37.206.28] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: cb6fdbfe-6a6a-4578-b476-08d706170e88 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:DM5PR16MB1721; x-ms-traffictypediagnostic: DM5PR16MB1721: x-ms-exchange-purlcount: 6 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0095BCF226 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(346002)(366004)(376002)(39860400002)(136003)(396003)(189003)(199004)(54094003)(51914003)(32952001)(52014003)(13464003)(76176011)(71200400001)(3846002)(71190400001)(80792005)(6506007)(478600001)(53546011)(2906002)(186003)(966005)(102836004)(6116002)(33656002)(26005)(4326008)(99286004)(486006)(74316002)(11346002)(229853002)(476003)(7696005)(446003)(6436002)(66476007)(66946007)(110136005)(66556008)(64756008)(66446008)(81166006)(66066001)(316002)(7736002)(81156014)(14444005)(256004)(86362001)(53946003)(14454004)(8676002)(52536014)(30864003)(53936002)(55016002)(6306002)(9686003)(2171002)(5660300002)(6246003)(76116006)(68736007)(8936002)(25786009)(54906003)(305945005)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR16MB1721; H:DM5PR16MB1705.namprd16.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: 4F23BtgDOsNmmDCE0ZMq4xcNzGF/EesE7/saY4ZlGBL7RnoX87IQ22JPfSmUUv9vJwd29pd4UzuHoxdxPYnJQX3bcXYFpgRf+v/qhDwkgSH2XHprDgdDpWfAXpVpMO9hQ6Mnz61v7VxMwLGbJlc2OZMGAFXVWBzgAkWstMamqUtBDROaFhwSuHstv8pLaO8XPH2LL+ULy9BileeOWbfLn1K8RowSQT3dqyKXy6A7pKVowR6nf+Pox+T0A8ddYlenSgAhseygB6f3QgYnq/dNo0z+zLv8XRKB1wHwyTJLMPque81Rdp3xc9Q3XYaQs6OS+q9vVv6Jk5azWO7jfBGih9nu5B9XuirvKftrrYl4aWViQjmM6PkEmlNZY+gbs+nv0R5OtxHXXqSTSvAL0w7PeBtz1Dcs+RhxCDrlpR85/ng= MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: cb6fdbfe-6a6a-4578-b476-08d706170e88 X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Jul 2019 15:47:19.2027 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: TirumaleswarReddy_Konda@McAfee.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR16MB1721 X-OriginatorOrg: mcafee.com X-NAI-Spam-Flag: NO X-NAI-Spam-Level: X-NAI-Spam-Threshold: 15 X-NAI-Spam-Score: 0.3 X-NAI-Spam-Version: 2.3.0.9418 : core <6588> : inlines <7117> : streams <1827054> : uri <2866375> X-MC-Unique: tyYx_XQNOMGBx9NNw14NFQ-1 X-Mimecast-Spam-Score: 0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [tram] Benjamin Kaduk's Discuss on draft-ietf-tram-turnbis-27: (with DISCUSS and COMMENT) X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.29 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, 11 Jul 2019 15:47:37 -0000 Hi Ben, Thanks for the detailed review. Please see inline=20 > -----Original Message----- > From: tram On Behalf Of Benjamin Kaduk via > Datatracker > Sent: Thursday, July 11, 2019 11:10 AM > To: The IESG > Cc: tram-chairs@ietf.org; draft-ietf-tram-turnbis@ietf.org; tram@ietf.org= ; > brandon.williams@akamai.com > Subject: [tram] Benjamin Kaduk's Discuss on draft-ietf-tram-turnbis-27: (= with > DISCUSS and COMMENT) >=20 >=20 >=20 > Benjamin Kaduk has entered the following ballot position for > draft-ietf-tram-turnbis-27: Discuss >=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-turnbis/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- >=20 > I support Roman's Discuss. I have updated the draft to address Roman's Discuss.=20 >=20 > I think I'm confused about whether REQUESTED-ADDRESS-FAMILY and > ADDITIONAL-ADDRESS-FAMILY are mutually exclusive. =20 Yes, both attributes are mutually exclusive. It is discussed in Section 7.1= , Clients MUST NOT include REQUESTED-ADDRESS-FAMILY and ADDITIONAL-ADDRESS-= FAMILY attributes in the same request. > Does sending just the > "additional" one secretly mean that you want both v4 and v6? Yes, ADDITIONAL-ADDRESS-FAMILY is used for allocation of both IPv4 and IPv6= . >=20 > Section 5 >=20 > I see that the secdir reviewer asked about why it is a "SHOULD" to send > SOFTWARE, and only got a response that it is defined in stunbis, but not > about why it is recommended. There remain some privacy/security > considerations with it, and we should either point to the stunbis securit= y > considerations or not recommend using it. (FINGERPRINT is, IIRC, less > interesting from a security perspective as it's just about confirming tha= t given > traffic is in fact STUN and not something else.) This "SHOULD" to send SOFTWARE attribute is defined in RFC5766 (As you may = know, TURN is used in the field for several years) and turnbis does not mod= ify the behavior for backward compatibility, and to address the possible th= reat added the following lines: SOFTWARE attribute can reveal the specific software version of the TURN cli= ent and server to eavesdropper and it might possibly allow attacks against = vulnerable software that is known to contain security holes. If it is impor= tant to prevent an eavesdropper from learning the software version, TURN ca= n be run over (D)TLS. >=20 > Section 12 >=20 > Do we need to say anything about backwards compatibility with RFC 5766 > peers that use a wider range of channel IDs? Yes, added the following line: Note that the channel number range is not backwards compatible with [RFC5766], and cannot be used in environments where such compatibility is required. >=20 > Section 12.7 >=20 > When the server receives an ICMP packet, the server processes it as > described in Section 11.5. A Data indication MUST be sent regardless > of whether there is a channel bound to the peer that was the > destination of the UDP datagram that triggered the reception of the > ICMP packet. >=20 > This MUST seems potentially in conflict with the previous discussion abou= t > permissions checks in Section 11.5. Good catch, removed conflicting text from Section 12.7. >=20 > Section 20 >=20 > Looking at the > new nonce in the example ("obMatJos2AAABadl7W7PeDU4hKE72jda"), and > noting that it starts with the nonce cookie, help me decode the security > feature bits. The magic prefix is "obMatJos2" so the capability bits are > encoded as "AAAB", which decodes to (hex) 00 00 01. But stunbis says tha= t > the bits are ordered from 0 (MSB of first byte) to 23 (LSB of last byte),= so this > would have bit 23 set, which is in contrast to the registry marking bit 0= as the > password-algorithms feature. Where am I messing this up? You are right, replaced with "obMatJos2gAAAadl7W7PeDU4hKE72jda" (hex) 80 00= 00 >=20 > I'd prefer if the examples showed more usage of MESSAGE-INTEGRITY- > SHA256 (especially, any from the server) and fewer MESSAGE-INTEGRITY. Sure, updated examples.=20 >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > Thanks for keeping the diff from RFC 5766 relatively contained! > I only reviewed the diff due to time constraints, but in general support > reviewing the full document for internal consistency and any remarks that > have not aged well, especially with respect to IANA considerations. >=20 > Section 2 >=20 > RFC 8174 has an updated version of the BCP 14 boilerplate text. Fixed.=20 >=20 > Section 3.1 >=20 > I appreciate the response to the secdir review, but even the linked stunb= is > section does not say much about which PKI's trust root is expected to be > used. I'm forced to assume the Web PKI but don't have much grounds for > that assumption. Yes, use pre-populated trust store on the endpoint to validate the certific= ate path.=20 >=20 > Section 3.2 >=20 > The secdir reviewer's comments seem to have some relevance. > It seems like even when the third-party authorization mechanism is used, > the client is still limited to "the server is authenticated because it gi= ves me > the service I asked for", which is not really documented anywhere yet. T= he > long-term password mechanism at least generates an HMAC integrity tag on > messages from server to client, which can provide some level of > authentication via key confirmation. No, STURN third-party authorization provides message integrity for both req= uest and response messages (please see https://tools.ietf.org/html/rfc7635#= section-5). The mac_key to compute the message integrity can change per ca= ll and this mechanism is better than the long-term password mechanism. Note= that WebRTC uses third-party authorization mechanism. >=20 > Section 3.7 >=20 > If the TURN server carrying out > packet translation from IPv4-to-IPv6 cannot get the Don't Fragment > (DF) bit in the IPv4 header, it MUST reject the Allocate request with > DONT-FRAGMENT attribute. >=20 > nit: does "cannot get" mean something like "read the value as sent on the > wire" (e.g., due to implementation/API limitations)? Yes, cannot read the value as sent on wire.=20 >=20 > Section 6 >=20 > o the relayed transport address or addresses; > [...] >=20 > [...] > address. The relayed transport address MUST be unique across all > allocations, so it can be used to uniquely identify the allocation. >=20 > nit: there's maybe a singular/plural mismatch going on here, but I don't = have > any good ideas. >=20 > Section 7.1 >=20 > If the client wishes to obtain one IPv6 and one IPv4 relayed > transport address then it includes an ADDITIONAL-ADDRESS-FAMILY > attribute in the request. This attribute specifies that the server > must allocate both address types. The attribute value in the > ADDITIONAL-ADDRESS-FAMILY MUST be set to 0x02 (IPv6 address family). > Clients MUST NOT include REQUESTED-ADDRESS-FAMILY and ADDITIONAL- > ADDRESS-FAMILY attributes in the same request. [...] >=20 > This reads like setting REQUESTED-ADDRESS-FAMILY and ADDITIONAL- > ADDRESS-FAMILY are mutually exclusive. Is that the correct reading? Yes. > (Naively, one might expect that the thing named "additional" > is applied on top of the base-level request, so I have to ask.) >=20 > Section 7.2 >=20 > Why do we only have a SHOULD-level requirement for authentication of > Allocate requests where 5766 had MUST? Could we say "may allow > unauthenticated requests in order to support [use case] but otherwise > MUST require authentication" (with better wording)? I suppose this has > probably been discussed ad nauseum already, so feel free to point me at t= he > archives before getting into an actual discussion. You missed the next line, it says the authentication of the request is opti= onal to allow TURN servers provided by the local or access network to accept Allocation requests from new and/or guest users in the network who do not necessarily possess long term credentials for STUN authentication and its security implications are discussed in [RFC8155]. The WG spent several cycles discussing the downgrade of a MUST level requir= ement (please see https://tools.ietf.org/html/rfc8155#section-9).=20 >=20 > 7. If the server does not support the address family requested by > the client in REQUESTED-ADDRESS-FAMILY or is disabled by local > policy, it MUST generate an Allocate error response, and it MUST > include an ERROR-CODE attribute with the 440 (Address Family not > Supported) response code. [...] >=20 > nit: "or is disabled" needs a subject. Fixed, updated text as follows: If the server does not support the address family requested by the client i= n REQUESTED-ADDRESS-FAMILY or if the allocation of the requested address fa= mily is disabled by local policy, it MUST generate an Allocate error respon= se, and it MUST include an ERROR-CODE attribute with the 440 (Address Famil= y not Supported) response code. >=20 > 9. The server checks if the request contains an ADDITIONAL-ADDRESS- > FAMILY attribute. If yes, and the attribute value is 0x01 (IPv4 > address family), then the server rejects the request with a 400 > (Bad Request) error. Otherwise, the server checks if it can > allocate relayed transport addresses of both address types. If > the server cannot satisfy the request, then the server rejects >=20 > What are "both" address types? =20 Both IPv4 and IPv6 address families. > We only have the ADDITIONAL-ADDRESS- > FAMILY (which contains one type) and no REQUESTED-ADDRESS-FAMILY. If ADDITIONAL-ADDRESS-FAMILY is used, the server will allocate both IPv4 an= d IPv6 relayed transport addresses.=20 >=20 > Section 8.1 >=20 > When refreshing a dual allocation, the client includes REQUESTED- > ADDRESS-FAMILY attribute indicating the address family type that > should be refreshed. If no REQUESTED-ADDRESS-FAMILY is included then > the request should be treated as applying to all current allocations. > The client MUST only include family types it previously allocated and > has not yet deleted. [...] >=20 > I'm a bit confused about "only include family types" plural; I thought th= ere > could only be at most one REQUESTED-ADDRESS-FAMILY and that it would > only indicate one family type. So how could there be multiple types get= ting > included by the client? Good catch, replaced "types" with "type" >=20 > Section 11.5 >=20 > [check that "type and code" is valid in both ICMPv4 and v6] Yes, it is valid. >=20 > Section 12 >=20 > Reserved values may be used in the future by other protocols. When > the client uses channel binding, it MUST comply with the > demultiplexing scheme discussed above. >=20 > "channel binding" is a term of art in the security world; is this usage i= ntended > to roughly mean "channel multiplexing"? > (I do see that the subsections are talking about the specific ChannelBind > request, so I assume so; I just want to double check.) Yes, a channel binding is created or refreshed using a ChannelBind transac= tion (Please see Section 12.1). >=20 >=20 > Section 13 >=20 > The descriptions below have two parts: a preferred behavior and an > alternate behavior. The server SHOULD implement the preferred > behavior. Otherwise, the server MUST implement the alternate > behavior and MUST NOT do anything else for the reasons detailed in > [RFC7915]. [...] >=20 > RFC 5766 had this split on a per-field basis, but this text suggests that= if the > preferred behavior is not possible for a given field, then the alternate > behavior is used for the entire packet. > I note that section 14 does retain the "for a particular field" language = for > UDP-to-UDP relaying, as do section 15 for TCP-to-UDP relaying and section= 16 > for UDP-to-TCP relaying. Good point, fixed text as follows: Otherwise, if that is not possible for a particular field, the server MUST = implement the alternate behavior and MUST NOT do anything else for the reas= ons detailed in [RFC7915].=20 >=20 > Section 13.2 >=20 > Is this flow label text consistent with both the inbound and outbound > translation directions (specifically, using relayed/peer addresses in the= 5- > tuple to identify the flow)? >=20 > If the incoming packet did not include a Fragment header and the > outgoing packet size exceeds the outgoing link's MTU, the TURN > server drops the outgoing packet and send an ICMP message of type > 2 code 0 ("Packet too big") to the sender of the incoming packet. > If the packet is being sent to the peer, the TURN server reduces > the MTU reported in the ICMP message by 48 bytes to allow room for > the overhead of a Data indication. >=20 > (nit?) "If the packet is being send to the peer" seems to grammatically r= efer > to the outgoing packet that would exceed link MTU, as opposed to the ICMP > message being generated. But I think it's supposed to refer to the ICMP > message being generated, which has not yet been referred to as a "packet" > in this text. Suresh raised the same comment, fixed text as follows: If the ICMPv6 packet ("Packet too big") is being sent to the peer, the TURN= server reduces the MTU reported in the ICMP message by 48 bytes to allow r= oom for the overhead of a Data indication. >=20 > Section 13.3 >=20 > [Same comment about ICMP packet generation/grammar] Fixed text as follows: If the ICMPv4 packet (Destination Unreachable (Type 3) with Code 4) is bein= g sent to the peer, the TURN server SHOULD reduce the MTU reported in the I= CMP message by 48 bytes to allow room for the overhead of a Data indication= . >=20 > Section 15 >=20 > Maybe note that SIP and WebRTC are the primary consumers of TURN? Yes, it is mentioned in several places in the document that WebRTC and SIP = use TURN. >=20 > Even if both > TCP-AO and UDP authentication would be used between TURN client and > server, it would not change the end-to-end security properties of the > UDP payload being relayed. [...] >=20 > I wonder if we even need to say "UDP" in "payload being relayed". Replaced "UDP" with "application" >=20 > Section 16 >=20 > Fragmentation >=20 > Preferred Behavior: Any fragmented packets are reassembled in the > server and then forwarded to the client over the TCP connection. > ICMP messages resulting from the UDP datagrams sent to the peer > MUST be forwarded to the client using TURN's mechanism for > relevant ICMP types and codes. >=20 > As in section 12.7, I wonder if this MUST could be seen as overriding oth= er > logic for ICMP handling. Modified text for clarity as follows: ICMP messages resulting from the UDP datagrams sent to the peer are processed by the server as described in Section 11.5 and forwarded to the client using TURN's mechanism for relevant ICMP types and codes. >=20 > Section 21.16 >=20 > I agree with the secdir reviewer that there is at least potential for use= rname > and realm to be sensitive. I proposed to add the following text: If the TURN client and server use the STUN Extension for Third-Party Authorization [RFC7635] (for example it is used in WebRTC), the username does not reveal the real user's identity, the USERNAME attribute carries an ephemeral and unique key identifier. If the TURN client and server use the STUN long-term credential mechanism and the username reveals the real user's identity, the client needs to use (D)TLS transport between the client and the server or use the USERHASH attribute instead of the USERNAME attribute to anonynmize the username. If the TURN client and server use the STUN long-term credential mechanism and realm information is privacy sensitive, TURN can be run over (D)TLS. As a reminder, STUN Extension for Third-Party Authorization does not use realm. >=20 > Section 21.4 >=20 > Do we need references for Teredo and/or 6to4? https://tools.ietf.org/html/rfc6156 did not add references to Teredo and 6t= o4. >=20 > Section 22 >=20 > The codepoints for the STUN error codes defined in this specification > are listed in Section 19. [IANA is requested to update the reference > from [RFC5766] to RFC-to-be for the STUN error codes listed in > Section 19.] >=20 > (I think some of them are from RFC 6156 as well as from 5766.) Yes, added RFC6156.=20 >=20 > Section 23 >=20 > It seems prudent to revisit these listed IAB Considerations for whether t= he > situation has changed in the past ten years (though I don't have any spec= ific > points that I would change). >=20 > Section 25 >=20 > (nit) are these really "updates" to RFC 6156 so much as incorporating its > content wholesale into the core TURN specification? Yes, several sections in RFC6156 are updated. Cheers, -Tiru >=20 >=20 > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram From nobody Thu Jul 11 15:28:13 2019 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 110901200DB; Thu, 11 Jul 2019 15:27:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=heapingbits.net header.b=KZYhR+SN; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=zHX2Wvpk 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 J4nrfVwvj7AZ; Thu, 11 Jul 2019 15:27:52 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B4EE11200B6; Thu, 11 Jul 2019 15:27:52 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id D443A220BA; Thu, 11 Jul 2019 18:27:51 -0400 (EDT) Received: from imap4 ([10.202.2.54]) by compute6.internal (MEProxy); Thu, 11 Jul 2019 18:27:51 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heapingbits.net; h=mime-version:message-id:in-reply-to:references:date:from:to :cc:subject:content-type:content-transfer-encoding; s=fm1; bh=6V NbfZFwSDaPF+hX8BUwuR4yZ86wlHBpSPfd9ywphSE=; b=KZYhR+SN4p7oJ1zSH2 R8dK0cDnqWxEvGSFwbzL1l5Bl1t4vSyCqB1LDnWu85WCO6ejbcC0Zgow/ts8ro3j Db5Majn3novJrsS/OPNZUwXptt9xMpsMwhZoOlI12nfz5bDhn/QcJNtlPYS+1cws W/2hAVMW1BcyJS0nwBcuEUc8M7R4zCW2UZBZ54SG3X0921HFf7ghCJ6/SnGjMGsj 4Gr3JEk1p73Tvfv0jFLZrF/Vx+yIOUQwGqs5y7wTti/OBOxVwaBKG0aDqQYpT7Cl oErgq+hKPUonxMC91g5saMfG+SFhOzJDdZGyHrd9LDYaDkBp5UcI/hGwH5/TmZj8 +Vcg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=6VNbfZFwSDaPF+hX8BUwuR4yZ86wlHBpSPfd9ywph SE=; b=zHX2WvpkSaKXQdvHnd1PyN/Cx+/1D/GpXB7GAcjVrMCjtCyMA+N8+CE/F 75gOskGHwy8szW24SuwGVQ4waARxBte9U+it5NW8F3d6kaFSkS5E/gT49bSxF994 wlECWUiQqn8n5nYGE+MBpx2DM+o6XB1fZoU5hHI7vdsh7H2FJOLtl8yfLWGuGYrz ujjFZjnTPuRXaDjsdWb273lEElaN5txqHXj8JwGys61vSmW7kFH1zZMyANKv4pdV LljuR0tNhEV5G+yOu/oXg6ucwK2DNm4+VxHBYWr8tJIM0RfG5YeZOz9k5gqWifqy rUwCR5zxIA4d1/9WoGmrLve3BCPpw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduvddrgeelgdduudcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefofgggkfgjfhffhffvufgtgfesthhqredtreerjeenucfhrhhomhepfdevhhhr ihhsthhophhhvghrucghohhougdfuceotggrfieshhgvrghpihhnghgsihhtshdrnhgvth eqnecuffhomhgrihhnpehhthhtphehtdefrhgvshhpohhnshgvtghouggvrghnrghlohhg hiifohhulhgusggvhhgvlhhpfhhulhdrrghtpdhgihhthhhusgdrtghomhdpihgvthhfrd horhhgnecurfgrrhgrmhepmhgrihhlfhhrohhmpegtrgifsehhvggrphhinhhgsghithhs rdhnvghtnecuvehluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 4A5233C00A1; Thu, 11 Jul 2019 18:27:51 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.6-731-g19d3b16-fmstable-20190627v1 Mime-Version: 1.0 Message-Id: <8ba1f7d3-d286-46df-9c13-383340bbf7b5@www.fastmail.com> In-Reply-To: References: <156253133809.549.13521510978566357744@ietfa.amsl.com> <20190709203044.GD24351@kduck.mit.edu> Date: Thu, 11 Jul 2019 15:27:50 -0700 From: "Christopher Wood" To: "Konda, Tirumaleswar Reddy" , "Benjamin Kaduk" Cc: "secdir@ietf.org" , "draft-ietf-tram-turnbis.all@ietf.org" , "ietf@ietf.org" , "tram@ietf.org" Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [tram] Secdir last call review of draft-ietf-tram-turnbis-27 X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.29 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, 11 Jul 2019 22:27:56 -0000 Hi Tiru, On Wed, Jul 10, 2019, at 5:41 AM, Konda, Tirumaleswar Reddy wrote: > Hi Ben, >=20 > Thanks for the review. Please see inline. >=20 > > -----Original Message----- > > From: Benjamin Kaduk > > Sent: Wednesday, July 10, 2019 2:01 AM > > To: Konda, Tirumaleswar Reddy > > Cc: Christopher Wood ; secdir@ietf.org; draft-i= etf- > > tram-turnbis.all@ietf.org; ietf@ietf.org; tram@ietf.org > > Subject: Re: [tram] Secdir last call review of draft-ietf-tram-turnb= is-27 > >=20 > > This email originated from outside of the organization. Do not click= links or > > open attachments unless you recognize the sender and know the conten= t is > > safe. > >=20 > > Chris, thanks for the review. Some more questions/comments inline a= s I > > prepare to ballot on this document... > >=20 > > On Mon, Jul 08, 2019 at 02:18:26PM +0000, Konda, Tirumaleswar Reddy = wrote: > > > Hi Christopher, > > > > > > Thanks for the detailed review. Please see inline > > > > > > > -----Original Message----- > > > > From: tram On Behalf Of Christopher Wood= via > > > > Datatracker > > > > Sent: Monday, July 8, 2019 1:59 AM > > > > To: secdir@ietf.org > > > > Cc: draft-ietf-tram-turnbis.all@ietf.org; ietf@ietf.org; > > > > tram@ietf.org > > > > Subject: [tram] Secdir last call review of > > > > draft-ietf-tram-turnbis-27 > > > > > > > > This email originated from outside of the organization. Do not c= lick > > > > links or open attachments unless you recognize the sender and kn= ow > > > > the content is safe. > > > > > > > > Reviewer: Christopher Wood > > > > Review result: Has Nits > > > > > > > > I have reviewed this document as part of the security directorat= e's > > > > ongoing effort to review all IETF documents being processed by t= he > > > > IESG. These comments were written primarily for the benefit of t= he > > > > security area directors. > > > > Document editors and WG chairs should treat these comments just = like > > > > any other last call comments. > > > > > > > > The summary of the review is: Ready with nits > > > > > > > > Summary: > > > > > > > > In general, the document is well written and clearly founded in > > > > operational experience. The security considerations are thorough= , > > > > providing examples where necessary to highlight important proble= m > > > > areas. It draws a clear line between issues best addressed by > > > > applications outside of TURN, and provides sufficient detail for= > > > > those issues in scope. My comments and questions are, hopefully,= mostly > > nits. > > > > > > > > General comments: > > > > > > > > - TURN server authentication in the case of (D)TLS is > > > > underspecified. Are servers assumed to have WebPKI certificates,= > > > > OOB-trusted raw public keys, or something else? Is there a prefe= rred > > form of authentication? > > > > Relatedly, in > > > > Section 3.2, how do clients authenticate the server? > > > > > > Server certificate validation is discussed in https://tools.ietf.o= rg/html/draft- > > ietf-tram-stunbis-21#section-6.2.3. I have modified the text as fol= lows: > > > > > > If (D)TLS transport is used between the TURN client and the TURN > > > server, the cipher suites, server certificate validation and > > > authentication of TURN server are discussed in Section 6.2.3 of > > > [I-D.ietf-tram-stunbis] > >=20 > > That helps, but it would still be nice to give some indication of wh= at certificate > > PKI(s) are expected to be used. Is anything other than the Web PKI = under > > consideration ? >=20 > No. Please see=20 > https://tools.ietf.org/html/draft-ietf-tram-stunbis-21#section-6.2.3,=20= > It discusses to verify the certificate path and identity of the server= . Perhaps it would be good to explicitly say this in the document? >=20 > >=20 > > > >- Section 3.7: Could > > > > TURN servers not chunk data from stream-oriented transports (TCP= or > > > >TLS) to a preferred MTU size before relaying to peers? > > > > Specifically, there are likely > > > > some cases wherein the server could deal with the client data > > > >messages larger than the recommended 500B limit. On that point, > > > >should servers even accept data larger than this recommended siz= e ? > > > >- > > > > > > Please see > > > https://tools.ietf.org/html/draft-ietf-tram-turnbis-27#section-15 = for > > > TCP-to-UDP relay. If the PMTU is not known, and on legacy or other= wise > > > unusual networks, > > > 500 byte limit for application data is recommended. > > > > > > > Section 3.9: There may be > > > > cases where the TLS connection post TCP connection establishment= > > > > fails. It would therefore seems prudent to not declare victory f= or > > > > one connection over the other until TLS connects, too. - > > > > > > Agreed, Eric (as part of ISEG review) suggested to simplify the te= xt. I have > > updated the text as follows: > > > > > > o For TCP or TLS-over-TCP, the results of the Happy Eyeballs > > > procedure [RFC8305] are used by the TURN client for sending = its > > > TURN messages to the server. > >=20 > > Is the editor's copy available for viewing somewhere? It would be g= ood to > > see this (and other changes) in context. >=20 > Yes, Please see https://github.com/tireddy2/TURNbis=20 Thanks! >=20 > >=20 > > > > Section 3 could benefit from a > > > > subsection on replays and the nonce role. In particular, as late= r > > > > discussed in the security considerations, some of these attacks = are > > > > not new to TURN and should therefore be dealt with by the > > > > application protocol (SRTP). This section might also describe no= nce > > > > rotation policies with more specificity, as this is underspecifi= ed in the > > document. > > > > > > It is discussed in Section 5 in the specification, the server shou= ld expire the > > nonce at least once every hour during the lifetime of the allocation= . > > > > > > >- Section 3 could also benefit from > > > > discussion about cleartext versus encryption transports between > > > >clients and servers. > > > > > > It is discussed in https://tools.ietf.org/html/draft-ietf-tram-tur= nbis- > > 27#section-21.1.6. > >=20 > > There's not much discussion about potential information leakage via= (e.g.) > > USERNAME/USERHASH, and really just a claim that the peer address is = the > > "primary protocol content". +1 to Ben's concern, which echoes my own. > Agreed, added the following paragraph : >=20 > If the TURN client and server use the STUN Extension for Third-Party=20= > Authorization [RFC7635], the username does not reveal the > real user's identity, the USERNAME attribute carries an ephemeral and=20= > unique key identifier, and the key identifier can change per call. > If the TURN client and server use the STUN long-term credential=20 > mechanism and the username reveals the > real user's identity, the client need to either use (D)TLS transport=20= > between the client and the server or use=20 > the USERHASH attribute instead of the USERNAME attribute to anonynmize= =20 > the username. This is an improvement -- thanks! Should use of (D)TLS be mandated ("MUS= T" instead of "need to") when long-term credentials are used? > > > > Encrypting the nonce, username, realm, etc., among other things,= has > > > > obvious benefits. - Why are SOFTWARE and FINGERPRINT attributes > > > > recommended? It seems like clients should be discouraged from > > > > sending these if anything, especially if not used to make alloca= tion > > > > decisions on the server. > > > > > > Username may not be the user identity, Please see > > https://tools.ietf.org/html/rfc7635), It could be an ephemeral and u= nique > > key identifier. Further, username can be anonymized (please see > > https://tools.ietf.org/html/draft-ietf-tram-stunbis-21#section-14.4)= . > > > SOFTWARE and FINGERPRINT attributes are defined in the STUN > > specification, see https://tools.ietf.org/html/draft-ietf-tram-stunb= is-21. I realize they're defined elsewhere. My concern was that this draft seem= s to encourage sending them when perhaps that's not needed, i.e., as is = the case for the SOFTWARE attribute. > >=20 > > These mechanisms are partial mitigations but can still be susceptib= le to cross- > > connection correlation attacks. >=20 > The use of FINGERPRINT is not mandatory, the TURN client and server ma= y=20 > include the FINGERPRINT attribute. Note that ICE=20 > (https://tools.ietf.org/html/rfc8445) mandates the use of FINGERPRINT=20= > attribute. Added the following line for SOFTWARE attribute (TURNbis is= =20 > using the same behavior defined in RFC5766 to use SOFTWARE attribute) = : >=20 > SOFWATE attribute can reveal the specific software version of the TURN= =20 > client and server to eavesdropper and it might possibly allow attacks=20= > against vulnerable software that is known to contain security holes. I= f=20 > it is important to prevent an eavesdropper from learning the software=20= > version, TURN can be run over (D)TLS. I'd replace "holes" with "vulnerabilities," and rewrite=20 "If it is important to prevent an eavesdropper from learning the sof= tware version, TURN can be run over (D)TLS." as follows: "TURN SHOULD be run over (D)TLS to prevent leaking the SOFTWARE attribut= e in clear text." > > > - Section 5: When servers receive data that exceeds an allocation=E2= =80=99s > > > > bandwidth quota, servers silently discard this data. This means > > > > there=E2=80=99s no allocation-based flow control mechanism betwe= en client > > > > and server beyond what=E2=80=99s provided by the transport proto= col, right? > > > > > > Yes, UDP does not include a congestion control mechanism. Right -- it might be good to mention this explicitly. > > > > This seems fine, though > > > > perhaps some discussion of why this design decision was made wou= ld > > > > be helpful. For example, I could imagine explicit signals from > > > > servers to clients that indicate server state would reveal > > > > information about other allocations on the server, which might b= e > > > > problematic. - > > > > > > The errors 486 (Allocation Quota Exceeded) or 508 (Insufficient Ca= pacity) > > do not reveal information of which other users are using the TURN se= rver. Perhaps not which other *users* are using the TURN server, correct. It m= ay leak other information though, and drawing HTTP 503 response code ana= logy would be helpful. > > At least the latter seems to give some indication that many other us= ers are > > using the server at the time (so that it's overloaded), though not = information > > about *which* users that is. >=20 > Yes, similar to 503 HTTP error response. >=20 > >=20 > > > > Section 7.2 suggests that > > > > servers can redirect client allocation requests to other servers= . > > > > Can this create a loop, wherein two TURN servers redirect to one= another? > > > > > > The client detect and stop the loop, it is similar to HTTP redirec= tion. > >=20 > > Where is this specified? >=20 > It is specified in the last paragraph of=20 > https://tools.ietf.org/html/draft-ietf-tram-stunbis-21#section-10=20 Aha -- I missed that. Thanks! Best, Chris From nobody Thu Jul 11 18:30:29 2019 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 8255E120024; Thu, 11 Jul 2019 18:30:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cert.org 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 o_5jX42rbSsx; Thu, 11 Jul 2019 18:30:17 -0700 (PDT) Received: from veto.sei.cmu.edu (veto.sei.cmu.edu [147.72.252.17]) (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 B3EEF120020; Thu, 11 Jul 2019 18:30:17 -0700 (PDT) Received: from korb.sei.cmu.edu (korb.sei.cmu.edu [10.64.21.30]) by veto.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id x6C1UDCZ019915; Thu, 11 Jul 2019 21:30:13 -0400 DKIM-Filter: OpenDKIM Filter v2.11.0 veto.sei.cmu.edu x6C1UDCZ019915 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cert.org; s=yc2bmwvrj62m; t=1562895014; bh=q8yZ/OX4SqmFlLSIL2eKsdLdDYnPKVlTAT8xBXKNa6Y=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=py/iaEHHjiglCXjUAiBLKfbZ0OOHEU3d8TKN0nlRsDJmlCVtlowBEgKcUTWBjVGXa 0CaS7SPgTJEFXWt/0jOhI0nCizdDPsEdDkmD3PPC8EJH7YI+aptwhrOmuOAOLVKs7q WMY5wXigHzqlpkheAXEdAdU8C5q1M3cnOPwkFCrk= Received: from CASSINA.ad.sei.cmu.edu (cassina.ad.sei.cmu.edu [10.64.28.249]) by korb.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id x6C1U9cI017396; Thu, 11 Jul 2019 21:30:09 -0400 Received: from MARCHAND.ad.sei.cmu.edu ([10.64.28.251]) by CASSINA.ad.sei.cmu.edu ([10.64.28.249]) with mapi id 14.03.0439.000; Thu, 11 Jul 2019 21:30:09 -0400 From: Roman Danyliw To: "Konda, Tirumaleswar Reddy" , The IESG CC: "tram-chairs@ietf.org" , "draft-ietf-tram-turnbis@ietf.org" , "tram@ietf.org" , "brandon.williams@akamai.com" Thread-Topic: [tram] Roman Danyliw's Discuss on draft-ietf-tram-turnbis-27: (with DISCUSS and COMMENT) Thread-Index: AQHVN3HNOcpHzxrvaEaIlo9IaIQd0abFZEuAgADMpZA= Date: Fri, 12 Jul 2019 01:30:08 +0000 Message-ID: <359EC4B99E040048A7131E0F4E113AFC01B33CE08D@marchand> References: <156279899179.15443.1948808943181719878.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.22.6] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [tram] Roman Danyliw's Discuss on draft-ietf-tram-turnbis-27: (with DISCUSS and COMMENT) X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.29 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, 12 Jul 2019 01:30:21 -0000 SGkgVGlydSENCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBpZXNnIFtt YWlsdG86aWVzZy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgS29uZGEsIFRpcnVtYWxl c3dhcg0KPiBSZWRkeQ0KPiBTZW50OiBUaHVyc2RheSwgSnVseSAxMSwgMjAxOSA1OjA3IEFNDQo+ IFRvOiBSb21hbiBEYW55bGl3IDxyZGRAY2VydC5vcmc+OyBUaGUgSUVTRyA8aWVzZ0BpZXRmLm9y Zz4NCj4gQ2M6IHRyYW0tY2hhaXJzQGlldGYub3JnOyBkcmFmdC1pZXRmLXRyYW0tdHVybmJpc0Bp ZXRmLm9yZzsgdHJhbUBpZXRmLm9yZzsNCj4gYnJhbmRvbi53aWxsaWFtc0Bha2FtYWkuY29tDQo+ IFN1YmplY3Q6IFJFOiBbdHJhbV0gUm9tYW4gRGFueWxpdydzIERpc2N1c3Mgb24gZHJhZnQtaWV0 Zi10cmFtLXR1cm5iaXMtMjc6DQo+ICh3aXRoIERJU0NVU1MgYW5kIENPTU1FTlQpDQo+IA0KPiBI aSBSb21hbiwNCj4gDQo+IFRoYW5rcyBmb3IgdGhlIHJldmlldy4gUGxlYXNlIHNlZSBpbmxpbmUN Cj4gDQo+ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPiBGcm9tOiB0cmFtIDx0cmFt LWJvdW5jZXNAaWV0Zi5vcmc+IE9uIEJlaGFsZiBPZiBSb21hbiBEYW55bGl3IHZpYQ0KPiA+IERh dGF0cmFja2VyDQo+ID4gU2VudDogVGh1cnNkYXksIEp1bHkgMTEsIDIwMTkgNDoyMCBBTQ0KPiA+ IFRvOiBUaGUgSUVTRyA8aWVzZ0BpZXRmLm9yZz4NCj4gPiBDYzogdHJhbS1jaGFpcnNAaWV0Zi5v cmc7IGRyYWZ0LWlldGYtdHJhbS10dXJuYmlzQGlldGYub3JnOw0KPiA+IHRyYW1AaWV0Zi5vcmc7 IGJyYW5kb24ud2lsbGlhbXNAYWthbWFpLmNvbQ0KPiA+IFN1YmplY3Q6IFt0cmFtXSBSb21hbiBE YW55bGl3J3MgRGlzY3VzcyBvbiBkcmFmdC1pZXRmLXRyYW0tdHVybmJpcy0yNzoNCj4gPiAod2l0 aCBESVNDVVNTIGFuZCBDT01NRU5UKQ0KPiA+DQo+ID4gVGhpcyBlbWFpbCBvcmlnaW5hdGVkIGZy b20gb3V0c2lkZSBvZiB0aGUgb3JnYW5pemF0aW9uLiBEbyBub3QgY2xpY2sNCj4gPiBsaW5rcyBv ciBvcGVuIGF0dGFjaG1lbnRzIHVubGVzcyB5b3UgcmVjb2duaXplIHRoZSBzZW5kZXIgYW5kIGtu b3cgdGhlDQo+ID4gY29udGVudCBpcyBzYWZlLg0KPiA+DQo+ID4gUm9tYW4gRGFueWxpdyBoYXMg ZW50ZXJlZCB0aGUgZm9sbG93aW5nIGJhbGxvdCBwb3NpdGlvbiBmb3INCj4gPiBkcmFmdC1pZXRm LXRyYW0tdHVybmJpcy0yNzogRGlzY3Vzcw0KPiA+DQo+ID4gV2hlbiByZXNwb25kaW5nLCBwbGVh c2Uga2VlcCB0aGUgc3ViamVjdCBsaW5lIGludGFjdCBhbmQgcmVwbHkgdG8gYWxsDQo+ID4gZW1h aWwgYWRkcmVzc2VzIGluY2x1ZGVkIGluIHRoZSBUbyBhbmQgQ0MgbGluZXMuIChGZWVsIGZyZWUg dG8gY3V0DQo+ID4gdGhpcyBpbnRyb2R1Y3RvcnkgcGFyYWdyYXBoLCBob3dldmVyLikNCj4gPg0K PiA+DQo+ID4gUGxlYXNlIHJlZmVyIHRvDQo+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaWVzZy9z dGF0ZW1lbnQvZGlzY3Vzcy1jcml0ZXJpYS5odG1sDQo+ID4gZm9yIG1vcmUgaW5mb3JtYXRpb24g YWJvdXQgSUVTRyBESVNDVVNTIGFuZCBDT01NRU5UIHBvc2l0aW9ucy4NCj4gPg0KPiA+DQo+ID4g VGhlIGRvY3VtZW50LCBhbG9uZyB3aXRoIG90aGVyIGJhbGxvdCBwb3NpdGlvbnMsIGNhbiBiZSBm b3VuZCBoZXJlOg0KPiA+IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWll dGYtdHJhbS10dXJuYmlzLw0KPiA+DQo+ID4NCj4gPg0KPiA+IC0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gPiBE SVNDVVNTOg0KPiA+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gPg0KPiA+ICgxKSBTZWN0aW9uIDEyLjEuNi4g IChQZXIgdGhlIGJhY2stYW5kLWZvcnRoIG9uIENocmlzIFdvb2TigJlzIFNFQ0RJUg0KPiA+IHJl dmlldyDigJMgdGhhbmsgeW91IENocmlzISkgUGVyIOKAnENvbmZpZGVudGlhbGl0eSBpcyBvbmx5 IGEgc2Vjb25kYXJ5DQo+ID4gY29uY2VybiwgYXMgVFVSTiBjb250cm9sIG1lc3NhZ2VzIGRvIG5v dCBpbmNsdWRlIGluZm9ybWF0aW9uIHRoYXQgaXMNCj4gPiBwYXJ0aWN1bGFybHkgc2Vuc2l0aXZl 4oCdLCB3b3VsZG7igJl0IHRoZSBVU0VSTkFNRSBhbmQgUkVBTE0gcG90ZW50aWFsbHkNCj4gPiBi ZSBwcml2YWN5IHNlbnNpdGl2ZT8gIElmIHRoZXkgYXJlbuKAmXQgc2Vuc2l0aXZlIGluIGFsbCBj YXNlcyAoZS5nLiwNCj4gPiB1c2VybmFtZXMgbWlnaHQgYmUgZXBoZW1lcmFsKSwgdGhpcyBzaG91 bGQgYmUgbm90ZWQgYW5kIGNpdGVkLg0KPiANCj4gQWdyZWVkLCBhZGRlZCB0aGUgZm9sbG93aW5n IHBhcmFncmFwaDoNCj4gDQo+ICAgIElmIHRoZSBUVVJOIGNsaWVudCBhbmQgc2VydmVyIHVzZSB0 aGUgU1RVTiBFeHRlbnNpb24gZm9yIFRoaXJkLVBhcnR5DQo+ICAgIEF1dGhvcml6YXRpb24gW1JG Qzc2MzVdIChmb3IgZXhhbXBsZSBpdCBpcyB1c2VkIGluIFdlYlJUQyksIHRoZQ0KPiAgICB1c2Vy bmFtZSBkb2VzIG5vdCByZXZlYWwgdGhlIHJlYWwgdXNlcidzIGlkZW50aXR5LCB0aGUgVVNFUk5B TUUNCj4gICAgYXR0cmlidXRlIGNhcnJpZXMgYW4gZXBoZW1lcmFsIGFuZCB1bmlxdWUga2V5IGlk ZW50aWZpZXIuICBJZiB0aGUNCj4gICAgVFVSTiBjbGllbnQgYW5kIHNlcnZlciB1c2UgdGhlIFNU VU4gbG9uZy10ZXJtIGNyZWRlbnRpYWwgbWVjaGFuaXNtDQo+ICAgIGFuZCB0aGUgdXNlcm5hbWUg cmV2ZWFscyB0aGUgcmVhbCB1c2VyJ3MgaWRlbnRpdHksIHRoZSBjbGllbnQgbmVlZHMNCj4gICAg dG8gdXNlIChEKVRMUyB0cmFuc3BvcnQgYmV0d2VlbiB0aGUgY2xpZW50IGFuZCB0aGUgc2VydmVy IG9yIHVzZSB0aGUNCj4gICAgVVNFUkhBU0ggYXR0cmlidXRlIGluc3RlYWQgb2YgdGhlIFVTRVJO QU1FIGF0dHJpYnV0ZSB0byBhbm9ueW5taXplDQo+ICAgIHRoZSB1c2VybmFtZS4NCj4gDQo+ICAg IElmIHRoZSBUVVJOIGNsaWVudCBhbmQgc2VydmVyIHVzZSB0aGUgU1RVTiBsb25nLXRlcm0gY3Jl ZGVudGlhbA0KPiAgICBtZWNoYW5pc20gYW5kIHJlYWxtIGluZm9ybWF0aW9uIGlzIHByaXZhY3kg c2Vuc2l0aXZlLCBUVVJOIGNhbiBiZSBydW4NCj4gICAgb3ZlciAoRClUTFMuICBBcyBhIHJlbWlu ZGVyLCBTVFVOIEV4dGVuc2lvbiBmb3IgVGhpcmQtUGFydHkNCj4gICAgQXV0aG9yaXphdGlvbiBk b2VzIG5vdCB1c2UgcmVhbG0uDQoNClRoYW5rIHlvdS4gIFRoaXMgdGV4dCB3b3VsZCBhZGRyZXNz IG15IGNvbmNlcm4uDQoNCj4gPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ID4gQ09NTUVOVDoNCj4gPiAtLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tDQo+ID4NCj4gPiAoMikgVGhpcyBkcmFmdCByZWxpZXMgb24gdGhlIGRyYWZ0LWll dGYtdHJhbS1zdHVuYmlz4oCZcyBTVFVOIFBhc3N3b3JkDQo+ID4gQWxnbyBSZWdpc3RyeSB3aGlj aCBoYXMgTUQ1IGFuZCBTSEEtMjU2LiAgU2VjdGlvbiAxNi4xLjEgb2YgdGhhdCBkcmFmdA0KPiA+ IGFscmVhZHkgZGlzY3Vzc2VzIHRoZSBsaW1pdGF0aW9uIG9mIFNIQS0yNTYgKHdoaWNoIGl0IG1p Z2h0IGJlIHVzZWZ1bCB0bw0KPiByZWZlcmVuY2UpLg0KPiA+IE5ldmVydGhlbGVzcywgYXJlIHRo ZXJlIGNhc2VzIHdoZXJlIE1ENSBzaG91bGQgYmUgdXNlZCBvdmVyIFNIQS0yNTYgaWYNCj4gPiB0 aGVyZSBpcyBhIGNob2ljZT8gIElzIHRoZXJlIGEgcmVhc29uIG5vdCB0byByZWNvbW1lbmQgdGhh dA0KPiA+IGltcGxlbWVudGF0aW9ucyDigJxTSE9VTEQgTk9UIHVzZSBNRDXigJ0/DQo+IA0KPiBU aGUgb25seSByZWFzb24gZHJhZnQtaWV0Zi10cmFtLXN0dW5iaXMgcmV0YWluZWQgTUQ1IGlzIGZv ciBiYWNrd2FyZC0NCj4gY29tcGF0aWJpbGl0eSAoY2xpZW50IHVzaW5nIG9sZGVyIHZlcnNpb24g b2YgU1RVTiAoUkZDNTM4OSkpLg0KDQpVbmRlcnN0b29kLiAgQ291bGQgd2Ugc2F5IHNvbWV0aGlu ZyBvbiB0aGUgb3JkZXIgb2YgImlmIGEgY2xpZW50IHN1cHBvcnRzIGJvdGggTUQ1IGFuZCBTSEEt MjU2LCB0aGUgbGF0dGVyIFNIT1VMRCBCRSB1c2VkIj8NCg0KPiA+DQo+ID4gKDMpIFNlY3Rpb24g NS4gUGVyIOKAnFRoZSBjbGllbnQgU0hPVUxEIGluY2x1ZGUgdGhlIFNPRlRXQVJFIOKApuKAnSBh bmQg4oCcVGhlDQo+ID4gY2xpZW50IGFuZCB0aGUgc2VydmVyIE1BWSBpbmNsdWRlIHRoZSBGSU5H RVJQUklOVCBhdHRyaWJ1dGUg4oCm4oCdLCB3aHkgaXMNCj4gPiB0aGUgc2VuZGluZyBvZiBTT0ZU V0FSRSBub3QgYSDigJxNQVnigJ0gdG9vPw0KPiANCj4gVGhpcyBzYW1lIGJlaGF2aW9yIGlzIGRl ZmluZWQgaW4gUkZDNTc2NiBhbmQgdHVybmJpcyBkb2VzIG5vdCBtb2RpZnkgdGhlDQo+IGJlaGF2 aW9yLCBhbmQgdG8gYWRkcmVzcyB0aGUgY29tbWVudCBmcm9tIENocmlzIFdvb2QgKFNlY2RpciBy ZXZpZXcpDQo+IGFkZGVkIHRoZSBmb2xsb3dpbmcgbGluZSB0byBTZWN1cml0eSBDb25zaWRlcmF0 aW9ucyBzZWN0aW9uOg0KPiANCj4gU09GVFdBUkUgYXR0cmlidXRlIGNhbiByZXZlYWwgdGhlIHNw ZWNpZmljIHNvZnR3YXJlIHZlcnNpb24gb2YgdGhlIFRVUk4NCj4gY2xpZW50IGFuZCBzZXJ2ZXIg dG8gZWF2ZXNkcm9wcGVyIGFuZCBpdCBtaWdodCBwb3NzaWJseSBhbGxvdyBhdHRhY2tzIGFnYWlu c3QNCj4gdnVsbmVyYWJsZSBzb2Z0d2FyZSB0aGF0IGlzIGtub3duIHRvIGNvbnRhaW4gc2VjdXJp dHkgaG9sZXMuIElmIGl0IGlzIGltcG9ydGFudA0KPiB0byBwcmV2ZW50IGFuIGVhdmVzZHJvcHBl ciBmcm9tIGxlYXJuaW5nIHRoZSBzb2Z0d2FyZSB2ZXJzaW9uLCBUVVJOIGNhbg0KPiBiZSBydW4g b3ZlciAoRClUTFMuDQoNClVuZGVyc3Rvb2QuICBJIGNhbiBsaXZlIHdpdGggYW4gYXJndW1lbnQg dGhhdCB0dXJuYmlzIHNob3VsZG4ndCBtb2RpZnkgdGhlIGJlaGF2aW9yIGluIHRoaXMgY2FzZSBn aXZlbiB0aGlzIGFkZGl0aW9uYWwgKGhlbHBmdWwpIGxhbmd1YWdlLiAgVGhhbmtzLg0KDQo+ID4N Cj4gPiAoNCkgU2VjdGlvbiA1LiAgKFBlciB0aGUgYmFjay1hbmQtZm9ydGggb24gQ2hyaXMgV29v ZOKAmXMgU0VDRElSIHJldmlldykNCj4gPiBSZWNvbW1lbmQgY2l0aW5nIFNlY3Rpb24gNi4zLjEg b2YgW2RyYWZ0LWlldGYtdHJhbS1zdHVuYmlzXSBhcyBzb3VyY2UNCj4gPiBvZiA0MCBzZWNvbmQg cmVxdWVzdCBidWZmZXIgdGltZW91dA0KPiANCj4gRG9uZS4NCg0KVGhhbmtzLg0KDQo+ID4NCj4g PiAoNSkgU2VjdGlvbiAyMS40LiAgUGVyIOKAnEl0IGlzIFJFQ09NTUVOREVEIHRoYXQgVFVSTiBz ZXJ2ZXJzIG5vdCBhY2NlcHQNCj4gPiBhbGxvY2F0aW9uIG9yIGNoYW5uZWwgYmluZGluZyByZXF1 ZXN0cyBmcm9tIGFkZHJlc3NlcyBrbm93biB0byBiZQ0KPiA+IHR1bm5lbGVk4oCdLCBJIGNvbmN1 ciB3aXRoIHRoZSBhZHZpY2UuICBIb3cgd291bGQgb25lIHJlY29nbml6ZSB0aGF0IHRoZQ0KPiA+ IGFkZHJlc3MgaXMgYmVpbmcgdHVubmVsZWQ/DQo+IA0KPiBCeSBtYW5hZ2luZyBkcm9wLWxpc3Qg b2YgdHVubmVsIElQIGFkZHJlc3NlcywgaXQgaXMgdGhlIHNhbWUgdGVjaG5pcXVlIHVzZWQNCj4g Ynkgc2V2ZXJhbCB3ZWJzaXRlcyB0byBibG9jayBWUE4gYWNjZXNzIChzZWUNCj4gaHR0cHM6Ly93 d3cuaG93dG9nZWVrLmNvbS80MDM3NzEvd2h5LWRvLXNvbWUtd2Vic2l0ZXMtYmxvY2stdnBucy8p DQoNClJpZ2h0LiAgSSBkaWRuJ3Qga25vdyBpZiB0aGVyZSB3YXMgc29tZXRoaW5nIGZhbmNpZXIg SSB3YXMgbWlzc2luZy4NCg0KSSBhcHByZWNpYXRlIHRoZXNlIGNoYW5nZXMgYW5kIGV4cGxhbmF0 aW9ucyENCg0KUm9tYW4NCg0KDQo+IENoZWVycywNCj4gLVRpcnUNCj4gDQo+ID4NCj4gPg0KPiA+ IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4gdHJh bSBtYWlsaW5nIGxpc3QNCj4gPiB0cmFtQGlldGYub3JnDQo+ID4gaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby90cmFtDQo= From nobody Fri Jul 12 02:13:07 2019 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 9A84212032C for ; Fri, 12 Jul 2019 02:13:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.999 X-Spam-Level: X-Spam-Status: No, score=-3.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=mcafee.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j41NyywoGbqt for ; Fri, 12 Jul 2019 02:13:01 -0700 (PDT) Received: from us-smtp-delivery-210.mimecast.com (us-smtp-delivery-210.mimecast.com [63.128.21.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2CFD61202CF for ; Fri, 12 Jul 2019 02:13:01 -0700 (PDT) X-NAI-Header: Modified by McAfee Email Gateway (5500) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mcafee.com; s=s_mcafee; t=1562922138; h=From: To:CC:Subject:Thread-Topic:Thread-Index:Date: Message-ID:References:In-Reply-To:Accept-Language: Content-Language:X-MS-Has-Attach:X-MS-TNEF-Correlator: dlp-product:dlp-version:dlp-reaction:authentication-results: x-originating-ip:x-ms-publictraffictype:x-ms-office365-filtering-correlation-id: x-microsoft-antispam:x-ms-traffictypediagnostic: x-ms-exchange-purlcount:x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers:x-forefront-prvs: x-forefront-antispam-report:received-spf:x-ms-exchange-senderadcheck: x-microsoft-antispam-message-info:Content-Type: Content-Transfer-Encoding:MIME-Version:X-MS-Exchange-CrossTenant-Network-Message-Id: X-MS-Exchange-CrossTenant-originalarrivaltime: X-MS-Exchange-CrossTenant-fromentityheader: X-MS-Exchange-CrossTenant-id:X-MS-Exchange-CrossTenant-mailboxtype: X-MS-Exchange-CrossTenant-userprincipalname: X-MS-Exchange-Transport-CrossTenantHeadersStamped: X-OriginatorOrg:X-NAI-Spam-Flag:X-NAI-Spam-Level: X-NAI-Spam-Threshold:X-NAI-Spam-Score:X-NAI-Spam-Version; bh=FmAcN/5zUJZqq2Y92WIjm7JUzPwVLCcl5dVLrt vCvmU=; b=qWuPYVPWsWrgpXfh2C97/+KFfr8f4vfcrVK7PFwD J8rNpm55BX2VCPhRiqOw+PRv1gCy1MURhGxQ7x6j0nhbt0jOfZ /xJmfyVw2Z2VQlEDTrHG+LvkFB49JJTqaGVa5yv6ryCnlwf4Tg qJxZGT0QQdGi3Poi2i/urEQk5KnywNA= Received: from DNVWSMAILOUT1.mcafee.com (dnvwsmailout1.mcafee.com [161.69.31.173]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-312-bwMDTC1kNtemn6nGG7TNfA-1; Fri, 12 Jul 2019 05:12:54 -0400 Received: from DNVEXAPP1N05.corpzone.internalzone.com (unknown [10.44.48.89]) by DNVWSMAILOUT1.mcafee.com with smtp (TLS: TLSv1/SSLv3,256bits,ECDHE-RSA-AES256-SHA384) id 2f15_b78f_b0027be9_29de_49c6_a73b_b23ad5165d4e; Fri, 12 Jul 2019 03:02:17 -0600 Received: from DNVEXAPP1N06.corpzone.internalzone.com (10.44.48.90) by DNVEXAPP1N05.corpzone.internalzone.com (10.44.48.89) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Fri, 12 Jul 2019 03:12:48 -0600 Received: from DNVO365EDGE1.corpzone.internalzone.com (10.44.176.66) by DNVEXAPP1N06.corpzone.internalzone.com (10.44.48.90) with Microsoft SMTP Server (TLS) id 15.0.1395.4 via Frontend Transport; Fri, 12 Jul 2019 03:12:48 -0600 Received: from NAM04-SN1-obe.outbound.protection.outlook.com (10.44.176.243) by edge.mcafee.com (10.44.176.66) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Fri, 12 Jul 2019 03:12:47 -0600 Received: from DM5PR16MB1705.namprd16.prod.outlook.com (10.172.44.147) by DM5PR16MB1547.namprd16.prod.outlook.com (10.173.209.148) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2052.19; Fri, 12 Jul 2019 09:12:46 +0000 Received: from DM5PR16MB1705.namprd16.prod.outlook.com ([fe80::570:2208:75c2:5f17]) by DM5PR16MB1705.namprd16.prod.outlook.com ([fe80::570:2208:75c2:5f17%8]) with mapi id 15.20.2052.019; Fri, 12 Jul 2019 09:12:46 +0000 From: "Konda, Tirumaleswar Reddy" To: Roman Danyliw , The IESG CC: "tram-chairs@ietf.org" , "draft-ietf-tram-turnbis@ietf.org" , "tram@ietf.org" , "brandon.williams@akamai.com" Thread-Topic: [tram] Roman Danyliw's Discuss on draft-ietf-tram-turnbis-27: (with DISCUSS and COMMENT) Thread-Index: AQHVN3Hb8rvCrm8yiE+tXfblQrByi6bE8P0wgAFCzQCAAHZQIA== Date: Fri, 12 Jul 2019 09:12:45 +0000 Message-ID: References: <156279899179.15443.1948808943181719878.idtracker@ietfa.amsl.com> <359EC4B99E040048A7131E0F4E113AFC01B33CE08D@marchand> In-Reply-To: <359EC4B99E040048A7131E0F4E113AFC01B33CE08D@marchand> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.3.0.16 dlp-reaction: no-action x-originating-ip: [103.245.47.20] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 5e571392-d30a-43fc-a44e-08d706a91a99 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:DM5PR16MB1547; x-ms-traffictypediagnostic: DM5PR16MB1547: x-ms-exchange-purlcount: 4 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 00963989E5 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(366004)(39860400002)(376002)(346002)(136003)(396003)(199004)(189003)(13464003)(32952001)(51914003)(3846002)(6246003)(6116002)(66066001)(478600001)(52536014)(486006)(86362001)(5024004)(6436002)(9686003)(55016002)(256004)(6306002)(14444005)(76116006)(71200400001)(71190400001)(80792005)(53936002)(229853002)(6506007)(446003)(54906003)(74316002)(68736007)(110136005)(66556008)(7696005)(99286004)(316002)(11346002)(66946007)(476003)(66574012)(5660300002)(76176011)(53546011)(102836004)(25786009)(81166006)(26005)(81156014)(186003)(305945005)(33656002)(7736002)(8936002)(8676002)(2906002)(66446008)(966005)(66476007)(64756008)(14454004)(4326008)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR16MB1547; H:DM5PR16MB1705.namprd16.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: 2p2s1xH6NphUjtMl70Ml+j6QDqz/Nb91JV+uof6pza+yBNLyraZ9jsoW8bJ3ha0kbHwWaxTvyL/9EoHcG0Um64l/pRv2HxFMSJHdBRzszKsSs3Ht/YVLrrTlNCe7ExB8iwMHBDRza5sODFNzV92lIIWR58ueqrFsYu8195Pzn254FoUksUrgFx9rHUxSZWxxev1gl1Fm42qeSlb4Xof1XD4dBYJL20RiCHgye587Ya+hZLKO2Yb0lG05Lb4EUu887dMgo4EoDbgM7I3C2KIBrqbm/1xClkk3NxDec9AATugmZ3vM6bjiLOmwOMAurpW0lqm4QdritPUiHf/k3/pabfXnQF4YigXPl9e3Jwb8YYlW4CLFu9OIEcE7emCXIY9ybRFK+5VRKmYEtV/F+deUXbW1Z3obQIwJIFvwkqytU4s= MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 5e571392-d30a-43fc-a44e-08d706a91a99 X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Jul 2019 09:12:45.9779 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: TirumaleswarReddy_Konda@McAfee.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR16MB1547 X-OriginatorOrg: mcafee.com X-NAI-Spam-Flag: NO X-NAI-Spam-Level: X-NAI-Spam-Threshold: 15 X-NAI-Spam-Score: 0.3 X-NAI-Spam-Version: 2.3.0.9418 : core <6588> : inlines <7118> : streams <1827123> : uri <2866671> X-MC-Unique: bwMDTC1kNtemn6nGG7TNfA-1 X-Mimecast-Spam-Score: 0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Archived-At: Subject: Re: [tram] Roman Danyliw's Discuss on draft-ietf-tram-turnbis-27: (with DISCUSS and COMMENT) X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.29 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, 12 Jul 2019 09:13:06 -0000 SGkgUm9tYW4sDQoNClBsZWFzZSBzZWUgaW5saW5lIA0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2Fn ZS0tLS0tDQo+IEZyb206IFJvbWFuIERhbnlsaXcgPHJkZEBjZXJ0Lm9yZz4NCj4gU2VudDogRnJp ZGF5LCBKdWx5IDEyLCAyMDE5IDc6MDAgQU0NCj4gVG86IEtvbmRhLCBUaXJ1bWFsZXN3YXIgUmVk ZHkNCj4gPFRpcnVtYWxlc3dhclJlZGR5X0tvbmRhQE1jQWZlZS5jb20+OyBUaGUgSUVTRyA8aWVz Z0BpZXRmLm9yZz4NCj4gQ2M6IHRyYW0tY2hhaXJzQGlldGYub3JnOyBkcmFmdC1pZXRmLXRyYW0t dHVybmJpc0BpZXRmLm9yZzsgdHJhbUBpZXRmLm9yZzsNCj4gYnJhbmRvbi53aWxsaWFtc0Bha2Ft YWkuY29tDQo+IFN1YmplY3Q6IFJFOiBbdHJhbV0gUm9tYW4gRGFueWxpdydzIERpc2N1c3Mgb24g ZHJhZnQtaWV0Zi10cmFtLXR1cm5iaXMtMjc6DQo+ICh3aXRoIERJU0NVU1MgYW5kIENPTU1FTlQp DQo+IA0KPiBUaGlzIGVtYWlsIG9yaWdpbmF0ZWQgZnJvbSBvdXRzaWRlIG9mIHRoZSBvcmdhbml6 YXRpb24uIERvIG5vdCBjbGljayBsaW5rcyBvcg0KPiBvcGVuIGF0dGFjaG1lbnRzIHVubGVzcyB5 b3UgcmVjb2duaXplIHRoZSBzZW5kZXIgYW5kIGtub3cgdGhlIGNvbnRlbnQgaXMNCj4gc2FmZS4N Cj4gDQo+IEhpIFRpcnUhDQo+IA0KPiA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4g RnJvbTogaWVzZyBbbWFpbHRvOmllc2ctYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEtv bmRhLA0KPiA+IFRpcnVtYWxlc3dhciBSZWRkeQ0KPiA+IFNlbnQ6IFRodXJzZGF5LCBKdWx5IDEx LCAyMDE5IDU6MDcgQU0NCj4gPiBUbzogUm9tYW4gRGFueWxpdyA8cmRkQGNlcnQub3JnPjsgVGhl IElFU0cgPGllc2dAaWV0Zi5vcmc+DQo+ID4gQ2M6IHRyYW0tY2hhaXJzQGlldGYub3JnOyBkcmFm dC1pZXRmLXRyYW0tdHVybmJpc0BpZXRmLm9yZzsNCj4gPiB0cmFtQGlldGYub3JnOyBicmFuZG9u LndpbGxpYW1zQGFrYW1haS5jb20NCj4gPiBTdWJqZWN0OiBSRTogW3RyYW1dIFJvbWFuIERhbnls aXcncyBEaXNjdXNzIG9uIGRyYWZ0LWlldGYtdHJhbS10dXJuYmlzLTI3Og0KPiA+ICh3aXRoIERJ U0NVU1MgYW5kIENPTU1FTlQpDQo+ID4NCj4gPiBIaSBSb21hbiwNCj4gPg0KPiA+IFRoYW5rcyBm b3IgdGhlIHJldmlldy4gUGxlYXNlIHNlZSBpbmxpbmUNCj4gPg0KPiA+ID4gLS0tLS1PcmlnaW5h bCBNZXNzYWdlLS0tLS0NCj4gPiA+IEZyb206IHRyYW0gPHRyYW0tYm91bmNlc0BpZXRmLm9yZz4g T24gQmVoYWxmIE9mIFJvbWFuIERhbnlsaXcgdmlhDQo+ID4gPiBEYXRhdHJhY2tlcg0KPiA+ID4g U2VudDogVGh1cnNkYXksIEp1bHkgMTEsIDIwMTkgNDoyMCBBTQ0KPiA+ID4gVG86IFRoZSBJRVNH IDxpZXNnQGlldGYub3JnPg0KPiA+ID4gQ2M6IHRyYW0tY2hhaXJzQGlldGYub3JnOyBkcmFmdC1p ZXRmLXRyYW0tdHVybmJpc0BpZXRmLm9yZzsNCj4gPiA+IHRyYW1AaWV0Zi5vcmc7IGJyYW5kb24u d2lsbGlhbXNAYWthbWFpLmNvbQ0KPiA+ID4gU3ViamVjdDogW3RyYW1dIFJvbWFuIERhbnlsaXcn cyBEaXNjdXNzIG9uIGRyYWZ0LWlldGYtdHJhbS10dXJuYmlzLTI3Og0KPiA+ID4gKHdpdGggRElT Q1VTUyBhbmQgQ09NTUVOVCkNCj4gPiA+DQo+ID4gPiBUaGlzIGVtYWlsIG9yaWdpbmF0ZWQgZnJv bSBvdXRzaWRlIG9mIHRoZSBvcmdhbml6YXRpb24uIERvIG5vdCBjbGljaw0KPiA+ID4gbGlua3Mg b3Igb3BlbiBhdHRhY2htZW50cyB1bmxlc3MgeW91IHJlY29nbml6ZSB0aGUgc2VuZGVyIGFuZCBr bm93DQo+ID4gPiB0aGUgY29udGVudCBpcyBzYWZlLg0KPiA+ID4NCj4gPiA+IFJvbWFuIERhbnls aXcgaGFzIGVudGVyZWQgdGhlIGZvbGxvd2luZyBiYWxsb3QgcG9zaXRpb24gZm9yDQo+ID4gPiBk cmFmdC1pZXRmLXRyYW0tdHVybmJpcy0yNzogRGlzY3Vzcw0KPiA+ID4NCj4gPiA+IFdoZW4gcmVz cG9uZGluZywgcGxlYXNlIGtlZXAgdGhlIHN1YmplY3QgbGluZSBpbnRhY3QgYW5kIHJlcGx5IHRv DQo+ID4gPiBhbGwgZW1haWwgYWRkcmVzc2VzIGluY2x1ZGVkIGluIHRoZSBUbyBhbmQgQ0MgbGlu ZXMuIChGZWVsIGZyZWUgdG8NCj4gPiA+IGN1dCB0aGlzIGludHJvZHVjdG9yeSBwYXJhZ3JhcGgs IGhvd2V2ZXIuKQ0KPiA+ID4NCj4gPiA+DQo+ID4gPiBQbGVhc2UgcmVmZXIgdG8NCj4gPiA+IGh0 dHBzOi8vd3d3LmlldGYub3JnL2llc2cvc3RhdGVtZW50L2Rpc2N1c3MtY3JpdGVyaWEuaHRtbA0K PiA+ID4gZm9yIG1vcmUgaW5mb3JtYXRpb24gYWJvdXQgSUVTRyBESVNDVVNTIGFuZCBDT01NRU5U IHBvc2l0aW9ucy4NCj4gPiA+DQo+ID4gPg0KPiA+ID4gVGhlIGRvY3VtZW50LCBhbG9uZyB3aXRo IG90aGVyIGJhbGxvdCBwb3NpdGlvbnMsIGNhbiBiZSBmb3VuZCBoZXJlOg0KPiA+ID4gaHR0cHM6 Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi10cmFtLXR1cm5iaXMvDQo+ID4g Pg0KPiA+ID4NCj4gPiA+DQo+ID4gPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiA+ID4gLS0NCj4gPiA+IERJU0NV U1M6DQo+ID4gPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiA+ID4gLS0NCj4gPiA+DQo+ID4gPiAoMSkgU2VjdGlv biAxMi4xLjYuICAoUGVyIHRoZSBiYWNrLWFuZC1mb3J0aCBvbiBDaHJpcyBXb29k4oCZcyBTRUNE SVINCj4gPiA+IHJldmlldyDigJMgdGhhbmsgeW91IENocmlzISkgUGVyIOKAnENvbmZpZGVudGlh bGl0eSBpcyBvbmx5IGEgc2Vjb25kYXJ5DQo+ID4gPiBjb25jZXJuLCBhcyBUVVJOIGNvbnRyb2wg bWVzc2FnZXMgZG8gbm90IGluY2x1ZGUgaW5mb3JtYXRpb24gdGhhdCBpcw0KPiA+ID4gcGFydGlj dWxhcmx5IHNlbnNpdGl2ZeKAnSwgd291bGRu4oCZdCB0aGUgVVNFUk5BTUUgYW5kIFJFQUxNIHBv dGVudGlhbGx5DQo+ID4gPiBiZSBwcml2YWN5IHNlbnNpdGl2ZT8gIElmIHRoZXkgYXJlbuKAmXQg c2Vuc2l0aXZlIGluIGFsbCBjYXNlcyAoZS5nLiwNCj4gPiA+IHVzZXJuYW1lcyBtaWdodCBiZSBl cGhlbWVyYWwpLCB0aGlzIHNob3VsZCBiZSBub3RlZCBhbmQgY2l0ZWQuDQo+ID4NCj4gPiBBZ3Jl ZWQsIGFkZGVkIHRoZSBmb2xsb3dpbmcgcGFyYWdyYXBoOg0KPiA+DQo+ID4gICAgSWYgdGhlIFRV Uk4gY2xpZW50IGFuZCBzZXJ2ZXIgdXNlIHRoZSBTVFVOIEV4dGVuc2lvbiBmb3IgVGhpcmQtUGFy dHkNCj4gPiAgICBBdXRob3JpemF0aW9uIFtSRkM3NjM1XSAoZm9yIGV4YW1wbGUgaXQgaXMgdXNl ZCBpbiBXZWJSVEMpLCB0aGUNCj4gPiAgICB1c2VybmFtZSBkb2VzIG5vdCByZXZlYWwgdGhlIHJl YWwgdXNlcidzIGlkZW50aXR5LCB0aGUgVVNFUk5BTUUNCj4gPiAgICBhdHRyaWJ1dGUgY2Fycmll cyBhbiBlcGhlbWVyYWwgYW5kIHVuaXF1ZSBrZXkgaWRlbnRpZmllci4gIElmIHRoZQ0KPiA+ICAg IFRVUk4gY2xpZW50IGFuZCBzZXJ2ZXIgdXNlIHRoZSBTVFVOIGxvbmctdGVybSBjcmVkZW50aWFs IG1lY2hhbmlzbQ0KPiA+ICAgIGFuZCB0aGUgdXNlcm5hbWUgcmV2ZWFscyB0aGUgcmVhbCB1c2Vy J3MgaWRlbnRpdHksIHRoZSBjbGllbnQgbmVlZHMNCj4gPiAgICB0byB1c2UgKEQpVExTIHRyYW5z cG9ydCBiZXR3ZWVuIHRoZSBjbGllbnQgYW5kIHRoZSBzZXJ2ZXIgb3IgdXNlIHRoZQ0KPiA+ICAg IFVTRVJIQVNIIGF0dHJpYnV0ZSBpbnN0ZWFkIG9mIHRoZSBVU0VSTkFNRSBhdHRyaWJ1dGUgdG8g YW5vbnlubWl6ZQ0KPiA+ICAgIHRoZSB1c2VybmFtZS4NCj4gPg0KPiA+ICAgIElmIHRoZSBUVVJO IGNsaWVudCBhbmQgc2VydmVyIHVzZSB0aGUgU1RVTiBsb25nLXRlcm0gY3JlZGVudGlhbA0KPiA+ ICAgIG1lY2hhbmlzbSBhbmQgcmVhbG0gaW5mb3JtYXRpb24gaXMgcHJpdmFjeSBzZW5zaXRpdmUs IFRVUk4gY2FuIGJlIHJ1bg0KPiA+ICAgIG92ZXIgKEQpVExTLiAgQXMgYSByZW1pbmRlciwgU1RV TiBFeHRlbnNpb24gZm9yIFRoaXJkLVBhcnR5DQo+ID4gICAgQXV0aG9yaXphdGlvbiBkb2VzIG5v dCB1c2UgcmVhbG0uDQo+IA0KPiBUaGFuayB5b3UuICBUaGlzIHRleHQgd291bGQgYWRkcmVzcyBt eSBjb25jZXJuLg0KPiANCj4gPiA+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ID4gPiAtLQ0KPiA+ID4gQ09NTUVO VDoNCj4gPiA+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ID4gPiAtLQ0KPiA+ID4NCj4gPiA+ICgyKSBUaGlzIGRy YWZ0IHJlbGllcyBvbiB0aGUgZHJhZnQtaWV0Zi10cmFtLXN0dW5iaXPigJlzIFNUVU4gUGFzc3dv cmQNCj4gPiA+IEFsZ28gUmVnaXN0cnkgd2hpY2ggaGFzIE1ENSBhbmQgU0hBLTI1Ni4gIFNlY3Rp b24gMTYuMS4xIG9mIHRoYXQNCj4gPiA+IGRyYWZ0IGFscmVhZHkgZGlzY3Vzc2VzIHRoZSBsaW1p dGF0aW9uIG9mIFNIQS0yNTYgKHdoaWNoIGl0IG1pZ2h0IGJlDQo+ID4gPiB1c2VmdWwgdG8NCj4g PiByZWZlcmVuY2UpLg0KPiA+ID4gTmV2ZXJ0aGVsZXNzLCBhcmUgdGhlcmUgY2FzZXMgd2hlcmUg TUQ1IHNob3VsZCBiZSB1c2VkIG92ZXIgU0hBLTI1Ng0KPiA+ID4gaWYgdGhlcmUgaXMgYSBjaG9p Y2U/ICBJcyB0aGVyZSBhIHJlYXNvbiBub3QgdG8gcmVjb21tZW5kIHRoYXQNCj4gPiA+IGltcGxl bWVudGF0aW9ucyDigJxTSE9VTEQgTk9UIHVzZSBNRDXigJ0/DQo+ID4NCj4gPiBUaGUgb25seSBy ZWFzb24gZHJhZnQtaWV0Zi10cmFtLXN0dW5iaXMgcmV0YWluZWQgTUQ1IGlzIGZvciBiYWNrd2Fy ZC0NCj4gPiBjb21wYXRpYmlsaXR5IChjbGllbnQgdXNpbmcgb2xkZXIgdmVyc2lvbiBvZiBTVFVO IChSRkM1Mzg5KSkuDQo+IA0KPiBVbmRlcnN0b29kLiAgQ291bGQgd2Ugc2F5IHNvbWV0aGluZyBv biB0aGUgb3JkZXIgb2YgImlmIGEgY2xpZW50IHN1cHBvcnRzDQo+IGJvdGggTUQ1IGFuZCBTSEEt MjU2LCB0aGUgbGF0dGVyIFNIT1VMRCBCRSB1c2VkIj8NCg0KWWVzLCBtb2RpZmllZCB0aGUgYWJv dmUgdGV4dCBhcyBmb2xsb3dzOg0KDQpOb3RlIHRoYXQgaWYgdGhlIHJlc3BvbnNlIGNvbnRhaW5z IGEgUEFTU1dPUkQtQUxHT1JJVEhNUyBhdHRyaWJ1dGUgYW5kIHRoaXMgYXR0cmlidXRlIGNvbnRh aW5zDQpib3RoIE1ENSBhbmQgU0hBLTI1NiBhbGdvcml0aG1zLCBhbmQgdGhlIGNsaWVudCBhbHNv IHN1cHBvcnRzIGJvdGggdGhlIGFsZ29yaXRobXMsIA0KdGhlIHJlcXVlc3QgTVVTVCBjb250YWlu IGEgUEFTU1dPUkQtQUxHT1JJVEhNIGF0dHJpYnV0ZSB3aXRoIHRoZSBTSEEtMjU2IGFsZ29yaXRo bS4NCg0KQ2hlZXJzLA0KLVRpcnUNCg0KPiANCj4gPiA+DQo+ID4gPiAoMykgU2VjdGlvbiA1LiBQ ZXIg4oCcVGhlIGNsaWVudCBTSE9VTEQgaW5jbHVkZSB0aGUgU09GVFdBUkUg4oCm4oCdIGFuZA0K PiA+ID4g4oCcVGhlIGNsaWVudCBhbmQgdGhlIHNlcnZlciBNQVkgaW5jbHVkZSB0aGUgRklOR0VS UFJJTlQgYXR0cmlidXRlIOKApuKAnSwNCj4gPiA+IHdoeSBpcyB0aGUgc2VuZGluZyBvZiBTT0ZU V0FSRSBub3QgYSDigJxNQVnigJ0gdG9vPw0KPiA+DQo+ID4gVGhpcyBzYW1lIGJlaGF2aW9yIGlz IGRlZmluZWQgaW4gUkZDNTc2NiBhbmQgdHVybmJpcyBkb2VzIG5vdCBtb2RpZnkNCj4gPiB0aGUg YmVoYXZpb3IsIGFuZCB0byBhZGRyZXNzIHRoZSBjb21tZW50IGZyb20gQ2hyaXMgV29vZCAoU2Vj ZGlyDQo+ID4gcmV2aWV3KSBhZGRlZCB0aGUgZm9sbG93aW5nIGxpbmUgdG8gU2VjdXJpdHkgQ29u c2lkZXJhdGlvbnMgc2VjdGlvbjoNCj4gPg0KPiA+IFNPRlRXQVJFIGF0dHJpYnV0ZSBjYW4gcmV2 ZWFsIHRoZSBzcGVjaWZpYyBzb2Z0d2FyZSB2ZXJzaW9uIG9mIHRoZQ0KPiA+IFRVUk4gY2xpZW50 IGFuZCBzZXJ2ZXIgdG8gZWF2ZXNkcm9wcGVyIGFuZCBpdCBtaWdodCBwb3NzaWJseSBhbGxvdw0K PiA+IGF0dGFja3MgYWdhaW5zdCB2dWxuZXJhYmxlIHNvZnR3YXJlIHRoYXQgaXMga25vd24gdG8g Y29udGFpbiBzZWN1cml0eQ0KPiA+IGhvbGVzLiBJZiBpdCBpcyBpbXBvcnRhbnQgdG8gcHJldmVu dCBhbiBlYXZlc2Ryb3BwZXIgZnJvbSBsZWFybmluZyB0aGUNCj4gPiBzb2Z0d2FyZSB2ZXJzaW9u LCBUVVJOIGNhbiBiZSBydW4gb3ZlciAoRClUTFMuDQo+IA0KPiBVbmRlcnN0b29kLiAgSSBjYW4g bGl2ZSB3aXRoIGFuIGFyZ3VtZW50IHRoYXQgdHVybmJpcyBzaG91bGRuJ3QgbW9kaWZ5IHRoZQ0K PiBiZWhhdmlvciBpbiB0aGlzIGNhc2UgZ2l2ZW4gdGhpcyBhZGRpdGlvbmFsIChoZWxwZnVsKSBs YW5ndWFnZS4gIFRoYW5rcy4NCj4gDQo+ID4gPg0KPiA+ID4gKDQpIFNlY3Rpb24gNS4gIChQZXIg dGhlIGJhY2stYW5kLWZvcnRoIG9uIENocmlzIFdvb2TigJlzIFNFQ0RJUg0KPiA+ID4gcmV2aWV3 KSBSZWNvbW1lbmQgY2l0aW5nIFNlY3Rpb24gNi4zLjEgb2YgW2RyYWZ0LWlldGYtdHJhbS1zdHVu YmlzXQ0KPiA+ID4gYXMgc291cmNlIG9mIDQwIHNlY29uZCByZXF1ZXN0IGJ1ZmZlciB0aW1lb3V0 DQo+ID4NCj4gPiBEb25lLg0KPiANCj4gVGhhbmtzLg0KPiANCj4gPiA+DQo+ID4gPiAoNSkgU2Vj dGlvbiAyMS40LiAgUGVyIOKAnEl0IGlzIFJFQ09NTUVOREVEIHRoYXQgVFVSTiBzZXJ2ZXJzIG5v dA0KPiA+ID4gYWNjZXB0IGFsbG9jYXRpb24gb3IgY2hhbm5lbCBiaW5kaW5nIHJlcXVlc3RzIGZy b20gYWRkcmVzc2VzIGtub3duDQo+ID4gPiB0byBiZSB0dW5uZWxlZOKAnSwgSSBjb25jdXIgd2l0 aCB0aGUgYWR2aWNlLiAgSG93IHdvdWxkIG9uZSByZWNvZ25pemUNCj4gPiA+IHRoYXQgdGhlIGFk ZHJlc3MgaXMgYmVpbmcgdHVubmVsZWQ/DQo+ID4NCj4gPiBCeSBtYW5hZ2luZyBkcm9wLWxpc3Qg b2YgdHVubmVsIElQIGFkZHJlc3NlcywgaXQgaXMgdGhlIHNhbWUgdGVjaG5pcXVlDQo+ID4gdXNl ZCBieSBzZXZlcmFsIHdlYnNpdGVzIHRvIGJsb2NrIFZQTiBhY2Nlc3MgKHNlZQ0KPiA+IGh0dHBz Oi8vd3d3Lmhvd3RvZ2Vlay5jb20vNDAzNzcxL3doeS1kby1zb21lLXdlYnNpdGVzLWJsb2NrLQ0K PiB2cG5zLykNCj4gDQo+IFJpZ2h0LiAgSSBkaWRuJ3Qga25vdyBpZiB0aGVyZSB3YXMgc29tZXRo aW5nIGZhbmNpZXIgSSB3YXMgbWlzc2luZy4NCj4gDQo+IEkgYXBwcmVjaWF0ZSB0aGVzZSBjaGFu Z2VzIGFuZCBleHBsYW5hdGlvbnMhDQo+IA0KPiBSb21hbg0KPiANCj4gDQo+ID4gQ2hlZXJzLA0K PiA+IC1UaXJ1DQo+ID4NCj4gPiA+DQo+ID4gPg0KPiA+ID4gX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPiA+IHRyYW0gbWFpbGluZyBsaXN0DQo+ID4g PiB0cmFtQGlldGYub3JnDQo+ID4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL3RyYW0NCg== From nobody Fri Jul 12 06:01:34 2019 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 A6292120045 for ; Fri, 12 Jul 2019 06:01:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.999 X-Spam-Level: X-Spam-Status: No, score=-3.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=mcafee.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OwyEqUDDs1eO for ; Fri, 12 Jul 2019 06:01:29 -0700 (PDT) Received: from us-smtp-delivery-210.mimecast.com (us-smtp-delivery-210.mimecast.com [63.128.21.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3CD961200C5 for ; Fri, 12 Jul 2019 06:01:29 -0700 (PDT) X-NAI-Header: Modified by McAfee Email Gateway (5500) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mcafee.com; s=s_mcafee; t=1562935841; h=ARC-Seal: ARC-Message-Signature:ARC-Authentication-Results: From:To:CC:Subject:Thread-Topic:Thread-Index: Date:Message-ID:References:In-Reply-To:Accept-Language: Content-Language:X-MS-Has-Attach:X-MS-TNEF-Correlator: dlp-product:dlp-version:dlp-reaction:authentication-results: x-originating-ip:x-ms-publictraffictype:x-ms-office365-filtering-correlation-id: x-microsoft-antispam:x-ms-traffictypediagnostic: x-ms-exchange-purlcount:x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers:x-forefront-prvs: x-forefront-antispam-report:received-spf:x-ms-exchange-senderadcheck: x-microsoft-antispam-message-info:Content-Type: Content-Transfer-Encoding:MIME-Version:X-MS-Exchange-CrossTenant-Network-Message-Id: X-MS-Exchange-CrossTenant-originalarrivaltime: X-MS-Exchange-CrossTenant-fromentityheader: X-MS-Exchange-CrossTenant-id:X-MS-Exchange-CrossTenant-mailboxtype: X-MS-Exchange-CrossTenant-userprincipalname: X-MS-Exchange-Transport-CrossTenantHeadersStamped: X-OriginatorOrg:X-NAI-Spam-Flag:X-NAI-Spam-Level: X-NAI-Spam-Threshold:X-NAI-Spam-Score:X-NAI-Spam-Version; bh=loBSUN30EadwAboQoVxqgjpMSNyPGG78/RC94I vKELo=; b=EBlhtQ1hZ1sUvxmd0vvaIODPlu32ES+hGdGOkM14 cZf48qGBR6vcD3Ax5M25ZTrII1lt1v0AjyjaGoCOSQ0Lj0OrMY JY7Fvbc1NcFqT/mk8ac7vafRpCpa+yWKDWfVxYO59HtOPQvwGz hozm+yvW1LkbGq2Q1yKt9JbQUUG2g6s= Received: from DNVWSMAILOUT1.mcafee.com (dnvwsmailout1.mcafee.com [161.69.31.173]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-70-VQsFFgDgPT2XiOObIEL_6w-1; Fri, 12 Jul 2019 09:01:18 -0400 Received: from DNVEXAPP1N05.corpzone.internalzone.com (unknown [10.44.48.89]) by DNVWSMAILOUT1.mcafee.com with smtp (TLS: TLSv1/SSLv3,256bits,ECDHE-RSA-AES256-SHA384) id 2f15_6c24_326978ac_545f_48e8_ada6_573df227ceb2; Fri, 12 Jul 2019 06:50:40 -0600 Received: from DNVEXAPP1N05.corpzone.internalzone.com (10.44.48.89) by DNVEXAPP1N05.corpzone.internalzone.com (10.44.48.89) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Fri, 12 Jul 2019 07:01:15 -0600 Received: from DNVO365EDGE1.corpzone.internalzone.com (10.44.176.66) by DNVEXAPP1N05.corpzone.internalzone.com (10.44.48.89) with Microsoft SMTP Server (TLS) id 15.0.1395.4 via Frontend Transport; Fri, 12 Jul 2019 07:01:15 -0600 Received: from NAM01-BY2-obe.outbound.protection.outlook.com (10.44.176.243) by edge.mcafee.com (10.44.176.66) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Fri, 12 Jul 2019 07:01:11 -0600 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=K4v8yQDlb8VeVhGs+J7RQ/pu+2BGHPMHDhfP1ChdKYVLhMRlt3uJ5cpNLPxJULbmQP9Z3ZXEHufRouo0H2sa8EpZiMBtkRnjOZKLjBW5AgUFvZCDGoZZx52XNgw1VWi2nkDLvSeUiPXvpuPZYrizX+ov4q1Jn1r8aq5gRjQyesYAlRdN8lSe8EQhczXcmdvIWPUPAwiYay/b2rNeXrFWrTK+FJdg9SedvN1OwOVdstJUg4EuKIX+0fCcBHO7HeNZZcjxLL3pQ+zu+eHy9rAGL/lbtTP9IWEOnrI7bwK4teC4Yigm/Sa3PknZgZWIfaa0m62xtYnRQKgUZhAc4RnTmw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=loBSUN30EadwAboQoVxqgjpMSNyPGG78/RC94IvKELo=; b=oFW6x0x6FRtApaAPtcYJqhYqJ2RBe8FRyZgEBSEl/Nep5juBQFIpnWrvPMWMsIDv0Mm8PMprheQXawJ4YLLzX4yLBqFS7jyLpf8x98mes9ZmlKQukMdRj0xWCWFENUbndjWh7hoqzVx/kUgDKcWMCH05y4vGsE8yJVQ2WN6SEhjLnV99LzQfc5Zlt6zgAttXYocTA7a/jTyIvQX7J3TDO7OL7ql2+Qy8wZHZSTQ9oayHikWTNm2iF88NhS5Vp0e1WxHonYurmSBZlEEWtOhLUDrzQFDOhXmca50Jl5QSU4DeutNx9xVpX5XShr/uilGxXCSuVydqRdKtono7rg9IrA== ARC-Authentication-Results: i=1; mx.microsoft.com 1;spf=pass smtp.mailfrom=mcafee.com;dmarc=pass action=none header.from=mcafee.com;dkim=pass header.d=mcafee.com;arc=none Received: from DM5PR16MB1705.namprd16.prod.outlook.com (10.172.44.147) by DM5PR16MB1801.namprd16.prod.outlook.com (10.174.176.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2073.10; Fri, 12 Jul 2019 13:01:10 +0000 Received: from DM5PR16MB1705.namprd16.prod.outlook.com ([fe80::570:2208:75c2:5f17]) by DM5PR16MB1705.namprd16.prod.outlook.com ([fe80::570:2208:75c2:5f17%8]) with mapi id 15.20.2052.019; Fri, 12 Jul 2019 13:01:10 +0000 From: "Konda, Tirumaleswar Reddy" To: Christopher Wood , Benjamin Kaduk CC: "secdir@ietf.org" , "draft-ietf-tram-turnbis.all@ietf.org" , "ietf@ietf.org" , "tram@ietf.org" Thread-Topic: [tram] Secdir last call review of draft-ietf-tram-turnbis-27 Thread-Index: AQHVNQMAJeymFhPVnEO1ky4wx5pqrabAcMBwgAJPmICAAKIlAIACozsAgAC0umA= Date: Fri, 12 Jul 2019 13:01:09 +0000 Message-ID: References: <156253133809.549.13521510978566357744@ietfa.amsl.com> <20190709203044.GD24351@kduck.mit.edu> <8ba1f7d3-d286-46df-9c13-383340bbf7b5@www.fastmail.com> In-Reply-To: <8ba1f7d3-d286-46df-9c13-383340bbf7b5@www.fastmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.3.0.16 dlp-reaction: no-action x-originating-ip: [49.37.206.28] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: db3655d5-e213-4cb1-3014-08d706c902cc x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:DM5PR16MB1801; x-ms-traffictypediagnostic: DM5PR16MB1801: x-ms-exchange-purlcount: 10 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 00963989E5 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(376002)(366004)(136003)(396003)(39860400002)(346002)(51914003)(13464003)(189003)(52014003)(199004)(32952001)(52536014)(102836004)(316002)(6246003)(6116002)(6506007)(66556008)(53546011)(186003)(64756008)(26005)(7696005)(99286004)(66946007)(66446008)(30864003)(76176011)(110136005)(3846002)(76116006)(66476007)(54906003)(86362001)(5660300002)(66066001)(2906002)(9686003)(11346002)(966005)(446003)(71190400001)(53936002)(81166006)(6436002)(80792005)(81156014)(6306002)(55016002)(476003)(305945005)(486006)(74316002)(229853002)(7736002)(71200400001)(8936002)(256004)(33656002)(14454004)(4326008)(68736007)(5024004)(14444005)(478600001)(8676002)(25786009)(2171002)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR16MB1801; H:DM5PR16MB1705.namprd16.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: hZUhB3pSEX5RS8k7gGUvl9GYRSxwh3+hGaMNxkq6qlQkxeiuuPP2IOeYsZ8Usrte9QhFL89OWNEGKuOzj1KZ4facZdcd/tO+h9N5j67s5RyC1BziCy3yMn62+UKRltYny4kLSLnuo9INLilpQ8fQfwXh+n6OoUDrW/jij6oOp5KgyUCvK5dPwE013ZjRm4AUkLqgREkq1qR+sRhkrfMNObcWroDcn6PLUNsWCMJoSdzruUx06zxacxFqkCKQp2qXXHqHAtIaWpIPqzUsJ6cvz+igI1a7WFCt/rqhurc0AXIga7WGX+95uXc6APrXlPZQ87+aCaqRoDizvoRvRojfEjhvovDLcW1GFzEGjuJ8Y/g8SD9VoWdI7V5hVC3nSIdAWk0obd3tEZ83kxb+Lt2ZfCzo8+ZnFxXF+craWXjrlrk= MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: db3655d5-e213-4cb1-3014-08d706c902cc X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Jul 2019 13:01:10.0132 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: TirumaleswarReddy_Konda@McAfee.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR16MB1801 X-OriginatorOrg: mcafee.com X-NAI-Spam-Flag: NO X-NAI-Spam-Level: X-NAI-Spam-Threshold: 15 X-NAI-Spam-Score: 0.1 X-NAI-Spam-Version: 2.3.0.9418 : core <6589> : inlines <7118> : streams <1827138> : uri <2866735> X-MC-Unique: VQsFFgDgPT2XiOObIEL_6w-1 X-Mimecast-Spam-Score: 0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Archived-At: Subject: Re: [tram] Secdir last call review of draft-ietf-tram-turnbis-27 X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.29 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, 12 Jul 2019 13:01:34 -0000 SGkgQ2hyaXMsDQoNClBsZWFzZSBzZWUgaW5saW5lIA0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2Fn ZS0tLS0tDQo+IEZyb206IENocmlzdG9waGVyIFdvb2QgPGNhd0BoZWFwaW5nYml0cy5uZXQ+DQo+ IFNlbnQ6IEZyaWRheSwgSnVseSAxMiwgMjAxOSAzOjU4IEFNDQo+IFRvOiBLb25kYSwgVGlydW1h bGVzd2FyIFJlZGR5DQo+IDxUaXJ1bWFsZXN3YXJSZWRkeV9Lb25kYUBNY0FmZWUuY29tPjsgQmVu amFtaW4gS2FkdWsNCj4gPGthZHVrQG1pdC5lZHU+DQo+IENjOiBzZWNkaXJAaWV0Zi5vcmc7IGRy YWZ0LWlldGYtdHJhbS10dXJuYmlzLmFsbEBpZXRmLm9yZzsgaWV0ZkBpZXRmLm9yZzsNCj4gdHJh bUBpZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTogW3RyYW1dIFNlY2RpciBsYXN0IGNhbGwgcmV2aWV3 IG9mIGRyYWZ0LWlldGYtdHJhbS10dXJuYmlzLTI3DQo+IA0KPiBUaGlzIGVtYWlsIG9yaWdpbmF0 ZWQgZnJvbSBvdXRzaWRlIG9mIHRoZSBvcmdhbml6YXRpb24uIERvIG5vdCBjbGljayBsaW5rcyBv cg0KPiBvcGVuIGF0dGFjaG1lbnRzIHVubGVzcyB5b3UgcmVjb2duaXplIHRoZSBzZW5kZXIgYW5k IGtub3cgdGhlIGNvbnRlbnQgaXMNCj4gc2FmZS4NCj4gDQo+IEhpIFRpcnUsDQo+IA0KPiBPbiBX ZWQsIEp1bCAxMCwgMjAxOSwgYXQgNTo0MSBBTSwgS29uZGEsIFRpcnVtYWxlc3dhciBSZWRkeSB3 cm90ZToNCj4gPiBIaSBCZW4sDQo+ID4NCj4gPiBUaGFua3MgZm9yIHRoZSByZXZpZXcuIFBsZWFz ZSBzZWUgaW5saW5lLg0KPiA+DQo+ID4gPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+ ID4gRnJvbTogQmVuamFtaW4gS2FkdWsgPGthZHVrQG1pdC5lZHU+DQo+ID4gPiBTZW50OiBXZWRu ZXNkYXksIEp1bHkgMTAsIDIwMTkgMjowMSBBTQ0KPiA+ID4gVG86IEtvbmRhLCBUaXJ1bWFsZXN3 YXIgUmVkZHkNCj4gPFRpcnVtYWxlc3dhclJlZGR5X0tvbmRhQE1jQWZlZS5jb20+DQo+ID4gPiBD YzogQ2hyaXN0b3BoZXIgV29vZCA8Y2F3QGhlYXBpbmdiaXRzLm5ldD47IHNlY2RpckBpZXRmLm9y ZzsNCj4gPiA+IGRyYWZ0LWlldGYtIHRyYW0tdHVybmJpcy5hbGxAaWV0Zi5vcmc7IGlldGZAaWV0 Zi5vcmc7IHRyYW1AaWV0Zi5vcmcNCj4gPiA+IFN1YmplY3Q6IFJlOiBbdHJhbV0gU2VjZGlyIGxh c3QgY2FsbCByZXZpZXcgb2YNCj4gPiA+IGRyYWZ0LWlldGYtdHJhbS10dXJuYmlzLTI3DQo+ID4g Pg0KPiA+ID4gVGhpcyBlbWFpbCBvcmlnaW5hdGVkIGZyb20gb3V0c2lkZSBvZiB0aGUgb3JnYW5p emF0aW9uLiBEbyBub3QgY2xpY2sNCj4gPiA+IGxpbmtzIG9yIG9wZW4gYXR0YWNobWVudHMgdW5s ZXNzIHlvdSByZWNvZ25pemUgdGhlIHNlbmRlciBhbmQga25vdw0KPiA+ID4gdGhlIGNvbnRlbnQg aXMgc2FmZS4NCj4gPiA+DQo+ID4gPiBDaHJpcywgdGhhbmtzIGZvciB0aGUgcmV2aWV3LiAgU29t ZSBtb3JlIHF1ZXN0aW9ucy9jb21tZW50cyBpbmxpbmUNCj4gPiA+IGFzIEkgcHJlcGFyZSB0byBi YWxsb3Qgb24gdGhpcyBkb2N1bWVudC4uLg0KPiA+ID4NCj4gPiA+IE9uIE1vbiwgSnVsIDA4LCAy MDE5IGF0IDAyOjE4OjI2UE0gKzAwMDAsIEtvbmRhLCBUaXJ1bWFsZXN3YXIgUmVkZHkNCj4gd3Jv dGU6DQo+ID4gPiA+IEhpIENocmlzdG9waGVyLA0KPiA+ID4gPg0KPiA+ID4gPiBUaGFua3MgZm9y IHRoZSBkZXRhaWxlZCByZXZpZXcuIFBsZWFzZSBzZWUgaW5saW5lDQo+ID4gPiA+DQo+ID4gPiA+ ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPiA+ID4gPiBGcm9tOiB0cmFtIDx0cmFt LWJvdW5jZXNAaWV0Zi5vcmc+IE9uIEJlaGFsZiBPZiBDaHJpc3RvcGhlcg0KPiBXb29kDQo+ID4g PiA+ID4gdmlhIERhdGF0cmFja2VyDQo+ID4gPiA+ID4gU2VudDogTW9uZGF5LCBKdWx5IDgsIDIw MTkgMTo1OSBBTQ0KPiA+ID4gPiA+IFRvOiBzZWNkaXJAaWV0Zi5vcmcNCj4gPiA+ID4gPiBDYzog ZHJhZnQtaWV0Zi10cmFtLXR1cm5iaXMuYWxsQGlldGYub3JnOyBpZXRmQGlldGYub3JnOw0KPiA+ ID4gPiA+IHRyYW1AaWV0Zi5vcmcNCj4gPiA+ID4gPiBTdWJqZWN0OiBbdHJhbV0gU2VjZGlyIGxh c3QgY2FsbCByZXZpZXcgb2YNCj4gPiA+ID4gPiBkcmFmdC1pZXRmLXRyYW0tdHVybmJpcy0yNw0K PiA+ID4gPiA+DQo+ID4gPiA+ID4gVGhpcyBlbWFpbCBvcmlnaW5hdGVkIGZyb20gb3V0c2lkZSBv ZiB0aGUgb3JnYW5pemF0aW9uLiBEbyBub3QNCj4gPiA+ID4gPiBjbGljayBsaW5rcyBvciBvcGVu IGF0dGFjaG1lbnRzIHVubGVzcyB5b3UgcmVjb2duaXplIHRoZSBzZW5kZXINCj4gPiA+ID4gPiBh bmQga25vdyB0aGUgY29udGVudCBpcyBzYWZlLg0KPiA+ID4gPiA+DQo+ID4gPiA+ID4gUmV2aWV3 ZXI6IENocmlzdG9waGVyIFdvb2QNCj4gPiA+ID4gPiBSZXZpZXcgcmVzdWx0OiBIYXMgTml0cw0K PiA+ID4gPiA+DQo+ID4gPiA+ID4gSSBoYXZlIHJldmlld2VkIHRoaXMgZG9jdW1lbnQgYXMgcGFy dCBvZiB0aGUgc2VjdXJpdHkNCj4gPiA+ID4gPiBkaXJlY3RvcmF0ZSdzIG9uZ29pbmcgZWZmb3J0 IHRvIHJldmlldyBhbGwgSUVURiBkb2N1bWVudHMgYmVpbmcNCj4gPiA+ID4gPiBwcm9jZXNzZWQg YnkgdGhlIElFU0cuIFRoZXNlIGNvbW1lbnRzIHdlcmUgd3JpdHRlbiBwcmltYXJpbHkgZm9yDQo+ ID4gPiA+ID4gdGhlIGJlbmVmaXQgb2YgdGhlIHNlY3VyaXR5IGFyZWEgZGlyZWN0b3JzLg0KPiA+ ID4gPiA+IERvY3VtZW50IGVkaXRvcnMgYW5kIFdHIGNoYWlycyBzaG91bGQgdHJlYXQgdGhlc2Ug Y29tbWVudHMganVzdA0KPiA+ID4gPiA+IGxpa2UgYW55IG90aGVyIGxhc3QgY2FsbCBjb21tZW50 cy4NCj4gPiA+ID4gPg0KPiA+ID4gPiA+IFRoZSBzdW1tYXJ5IG9mIHRoZSByZXZpZXcgaXM6IFJl YWR5IHdpdGggbml0cw0KPiA+ID4gPiA+DQo+ID4gPiA+ID4gU3VtbWFyeToNCj4gPiA+ID4gPg0K PiA+ID4gPiA+IEluIGdlbmVyYWwsIHRoZSBkb2N1bWVudCBpcyB3ZWxsIHdyaXR0ZW4gYW5kIGNs ZWFybHkgZm91bmRlZCBpbg0KPiA+ID4gPiA+IG9wZXJhdGlvbmFsIGV4cGVyaWVuY2UuIFRoZSBz ZWN1cml0eSBjb25zaWRlcmF0aW9ucyBhcmUNCj4gPiA+ID4gPiB0aG9yb3VnaCwgcHJvdmlkaW5n IGV4YW1wbGVzIHdoZXJlIG5lY2Vzc2FyeSB0byBoaWdobGlnaHQNCj4gPiA+ID4gPiBpbXBvcnRh bnQgcHJvYmxlbSBhcmVhcy4gSXQgZHJhd3MgYSBjbGVhciBsaW5lIGJldHdlZW4gaXNzdWVzDQo+ ID4gPiA+ID4gYmVzdCBhZGRyZXNzZWQgYnkgYXBwbGljYXRpb25zIG91dHNpZGUgb2YgVFVSTiwg YW5kIHByb3ZpZGVzDQo+ID4gPiA+ID4gc3VmZmljaWVudCBkZXRhaWwgZm9yIHRob3NlIGlzc3Vl cyBpbiBzY29wZS4gTXkgY29tbWVudHMgYW5kDQo+ID4gPiA+ID4gcXVlc3Rpb25zIGFyZSwgaG9w ZWZ1bGx5LCBtb3N0bHkNCj4gPiA+IG5pdHMuDQo+ID4gPiA+ID4NCj4gPiA+ID4gPiBHZW5lcmFs IGNvbW1lbnRzOg0KPiA+ID4gPiA+DQo+ID4gPiA+ID4gLSBUVVJOIHNlcnZlciBhdXRoZW50aWNh dGlvbiBpbiB0aGUgY2FzZSBvZiAoRClUTFMgaXMNCj4gPiA+ID4gPiB1bmRlcnNwZWNpZmllZC4g QXJlIHNlcnZlcnMgYXNzdW1lZCB0byBoYXZlIFdlYlBLSSBjZXJ0aWZpY2F0ZXMsDQo+ID4gPiA+ ID4gT09CLXRydXN0ZWQgcmF3IHB1YmxpYyBrZXlzLCBvciBzb21ldGhpbmcgZWxzZT8gSXMgdGhl cmUgYQ0KPiA+ID4gPiA+IHByZWZlcnJlZA0KPiA+ID4gZm9ybSBvZiBhdXRoZW50aWNhdGlvbj8N Cj4gPiA+ID4gPiBSZWxhdGVkbHksIGluDQo+ID4gPiA+ID4gU2VjdGlvbiAzLjIsIGhvdyBkbyBj bGllbnRzIGF1dGhlbnRpY2F0ZSB0aGUgc2VydmVyPw0KPiA+ID4gPg0KPiA+ID4gPiBTZXJ2ZXIg Y2VydGlmaWNhdGUgdmFsaWRhdGlvbiBpcyBkaXNjdXNzZWQgaW4NCj4gPiA+ID4gaHR0cHM6Ly90 b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LQ0KPiA+ID4gaWV0Zi10cmFtLXN0dW5iaXMtMjEjc2Vj dGlvbi02LjIuMy4gIEkgaGF2ZSBtb2RpZmllZCB0aGUgdGV4dCBhcyBmb2xsb3dzOg0KPiA+ID4g Pg0KPiA+ID4gPiBJZiAoRClUTFMgdHJhbnNwb3J0IGlzIHVzZWQgYmV0d2VlbiB0aGUgVFVSTiBj bGllbnQgYW5kIHRoZSBUVVJODQo+ID4gPiA+IHNlcnZlciwgdGhlIGNpcGhlciBzdWl0ZXMsIHNl cnZlciBjZXJ0aWZpY2F0ZSB2YWxpZGF0aW9uIGFuZA0KPiA+ID4gPiBhdXRoZW50aWNhdGlvbiBv ZiBUVVJOIHNlcnZlciBhcmUgZGlzY3Vzc2VkIGluIFNlY3Rpb24gNi4yLjMgb2YNCj4gPiA+ID4g W0ktRC5pZXRmLXRyYW0tc3R1bmJpc10NCj4gPiA+DQo+ID4gPiBUaGF0IGhlbHBzLCBidXQgaXQg d291bGQgc3RpbGwgYmUgbmljZSB0byBnaXZlIHNvbWUgaW5kaWNhdGlvbiBvZg0KPiA+ID4gd2hh dCBjZXJ0aWZpY2F0ZQ0KPiA+ID4gUEtJKHMpIGFyZSBleHBlY3RlZCB0byBiZSB1c2VkLiAgSXMg YW55dGhpbmcgb3RoZXIgdGhhbiB0aGUgV2ViIFBLSQ0KPiA+ID4gdW5kZXIgY29uc2lkZXJhdGlv biA/DQo+ID4NCj4gPiBOby4gUGxlYXNlIHNlZQ0KPiA+IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcv aHRtbC9kcmFmdC1pZXRmLXRyYW0tc3R1bmJpcy0yMSNzZWN0aW9uLTYuMi4zLA0KPiA+IEl0IGRp c2N1c3NlcyB0byB2ZXJpZnkgdGhlIGNlcnRpZmljYXRlIHBhdGggYW5kIGlkZW50aXR5IG9mIHRo ZSBzZXJ2ZXIuDQo+IA0KPiBQZXJoYXBzIGl0IHdvdWxkIGJlIGdvb2QgdG8gZXhwbGljaXRseSBz YXkgdGhpcyBpbiB0aGUgZG9jdW1lbnQ/DQoNCkkgYWRkZWQgdGhlIGZvbGxvd2luZyBsaW5lOg0K DQpJZiAoRClUTFMgdHJhbnNwb3J0IGlzIHVzZWQgYmV0d2VlbiB0aGUgVFVSTiBjbGllbnQgYW5k IHRoZSBUVVJOIA0Kc2VydmVyLCB0aGUgY2lwaGVyIHN1aXRlcywgc2VydmVyIGNlcnRpZmljYXRl IHZhbGlkYXRpb24gYW5kIA0KYXV0aGVudGljYXRpb24gb2YgVFVSTiBzZXJ2ZXIgYXJlIGRpc2N1 c3NlZCBpbiBTZWN0aW9uIDYuMi4zIG9mIA0KW0ktRC5pZXRmLXRyYW0tc3R1bmJpc10uDQoNCj4g DQo+ID4NCj4gPiA+DQo+ID4gPiA+ID4tIFNlY3Rpb24gMy43OiBDb3VsZA0KPiA+ID4gPiA+IFRV Uk4gc2VydmVycyBub3QgY2h1bmsgZGF0YSBmcm9tIHN0cmVhbS1vcmllbnRlZCB0cmFuc3BvcnRz IChUQ1ANCj4gPiA+ID4gPm9yDQo+ID4gPiA+ID5UTFMpICB0byBhIHByZWZlcnJlZCBNVFUgc2l6 ZSBiZWZvcmUgcmVsYXlpbmcgdG8gcGVlcnM/DQo+ID4gPiA+ID4gU3BlY2lmaWNhbGx5LCB0aGVy ZSBhcmUgbGlrZWx5DQo+ID4gPiA+ID4gc29tZSBjYXNlcyB3aGVyZWluIHRoZSBzZXJ2ZXIgY291 bGQgZGVhbCB3aXRoIHRoZSBjbGllbnQgZGF0YQ0KPiA+ID4gPiA+bWVzc2FnZXMgIGxhcmdlciB0 aGFuIHRoZSByZWNvbW1lbmRlZCA1MDBCIGxpbWl0LiBPbiB0aGF0IHBvaW50LA0KPiA+ID4gPiA+ c2hvdWxkIHNlcnZlcnMgZXZlbiAgYWNjZXB0IGRhdGEgbGFyZ2VyIHRoYW4gdGhpcyByZWNvbW1l bmRlZCBzaXplID8NCj4gPiA+ID4gPi0NCj4gPiA+ID4NCj4gPiA+ID4gUGxlYXNlIHNlZQ0KPiA+ ID4gPiBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi10cmFtLXR1cm5iaXMt Mjcjc2VjdGlvbi0xNQ0KPiA+ID4gPiBmb3IgVENQLXRvLVVEUCByZWxheS4gSWYgdGhlIFBNVFUg aXMgbm90IGtub3duLCBhbmQgb24gbGVnYWN5IG9yDQo+ID4gPiA+IG90aGVyd2lzZSB1bnVzdWFs IG5ldHdvcmtzLA0KPiA+ID4gPiA1MDAgYnl0ZSBsaW1pdCBmb3IgYXBwbGljYXRpb24gZGF0YSBp cyByZWNvbW1lbmRlZC4NCj4gPiA+ID4NCj4gPiA+ID4gPiBTZWN0aW9uIDMuOTogVGhlcmUgbWF5 IGJlDQo+ID4gPiA+ID4gY2FzZXMgd2hlcmUgdGhlIFRMUyBjb25uZWN0aW9uIHBvc3QgVENQIGNv bm5lY3Rpb24gZXN0YWJsaXNobWVudA0KPiA+ID4gPiA+IGZhaWxzLiBJdCB3b3VsZCB0aGVyZWZv cmUgc2VlbXMgcHJ1ZGVudCB0byBub3QgZGVjbGFyZSB2aWN0b3J5DQo+ID4gPiA+ID4gZm9yIG9u ZSBjb25uZWN0aW9uIG92ZXIgdGhlIG90aGVyIHVudGlsIFRMUyBjb25uZWN0cywgdG9vLiAtDQo+ ID4gPiA+DQo+ID4gPiA+IEFncmVlZCwgRXJpYyAoYXMgcGFydCBvZiBJU0VHIHJldmlldykgc3Vn Z2VzdGVkIHRvIHNpbXBsaWZ5IHRoZQ0KPiA+ID4gPiB0ZXh0LiBJIGhhdmUNCj4gPiA+IHVwZGF0 ZWQgdGhlIHRleHQgYXMgZm9sbG93czoNCj4gPiA+ID4NCj4gPiA+ID4gICAgbyAgRm9yIFRDUCBv ciBUTFMtb3Zlci1UQ1AsIHRoZSByZXN1bHRzIG9mIHRoZSBIYXBweSBFeWViYWxscw0KPiA+ID4g PiAgICAgICBwcm9jZWR1cmUgW1JGQzgzMDVdIGFyZSB1c2VkIGJ5IHRoZSBUVVJOIGNsaWVudCBm b3Igc2VuZGluZyBpdHMNCj4gPiA+ID4gICAgICAgVFVSTiBtZXNzYWdlcyB0byB0aGUgc2VydmVy Lg0KPiA+ID4NCj4gPiA+IElzIHRoZSBlZGl0b3IncyBjb3B5IGF2YWlsYWJsZSBmb3Igdmlld2lu ZyBzb21ld2hlcmU/ICBJdCB3b3VsZCBiZQ0KPiA+ID4gZ29vZCB0byBzZWUgdGhpcyAoYW5kIG90 aGVyIGNoYW5nZXMpIGluIGNvbnRleHQuDQo+ID4NCj4gPiBZZXMsIFBsZWFzZSBzZWUgaHR0cHM6 Ly9naXRodWIuY29tL3RpcmVkZHkyL1RVUk5iaXMNCj4gDQo+IFRoYW5rcyENCj4gDQo+ID4NCj4g PiA+DQo+ID4gPiA+ID4gU2VjdGlvbiAzIGNvdWxkIGJlbmVmaXQgZnJvbSBhDQo+ID4gPiA+ID4g c3Vic2VjdGlvbiBvbiByZXBsYXlzIGFuZCB0aGUgbm9uY2Ugcm9sZS4gSW4gcGFydGljdWxhciwg YXMNCj4gPiA+ID4gPiBsYXRlciBkaXNjdXNzZWQgaW4gdGhlIHNlY3VyaXR5IGNvbnNpZGVyYXRp b25zLCBzb21lIG9mIHRoZXNlDQo+ID4gPiA+ID4gYXR0YWNrcyBhcmUgbm90IG5ldyB0byBUVVJO IGFuZCBzaG91bGQgdGhlcmVmb3JlIGJlIGRlYWx0IHdpdGgNCj4gPiA+ID4gPiBieSB0aGUgYXBw bGljYXRpb24gcHJvdG9jb2wgKFNSVFApLiBUaGlzIHNlY3Rpb24gbWlnaHQgYWxzbw0KPiA+ID4g PiA+IGRlc2NyaWJlIG5vbmNlIHJvdGF0aW9uIHBvbGljaWVzIHdpdGggbW9yZSBzcGVjaWZpY2l0 eSwgYXMgdGhpcw0KPiA+ID4gPiA+IGlzIHVuZGVyc3BlY2lmaWVkIGluIHRoZQ0KPiA+ID4gZG9j dW1lbnQuDQo+ID4gPiA+DQo+ID4gPiA+IEl0IGlzIGRpc2N1c3NlZCBpbiBTZWN0aW9uIDUgaW4g dGhlIHNwZWNpZmljYXRpb24sIHRoZSBzZXJ2ZXINCj4gPiA+ID4gc2hvdWxkIGV4cGlyZSB0aGUN Cj4gPiA+IG5vbmNlIGF0IGxlYXN0IG9uY2UgZXZlcnkgaG91ciBkdXJpbmcgdGhlIGxpZmV0aW1l IG9mIHRoZSBhbGxvY2F0aW9uLg0KPiA+ID4gPg0KPiA+ID4gPiA+LSBTZWN0aW9uIDMgY291bGQg YWxzbyBiZW5lZml0IGZyb20gIGRpc2N1c3Npb24gYWJvdXQgY2xlYXJ0ZXh0DQo+ID4gPiA+ID52 ZXJzdXMgZW5jcnlwdGlvbiB0cmFuc3BvcnRzIGJldHdlZW4gY2xpZW50cyBhbmQgIHNlcnZlcnMu DQo+ID4gPiA+DQo+ID4gPiA+IEl0IGlzIGRpc2N1c3NlZCBpbg0KPiA+ID4gPiBodHRwczovL3Rv b2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi10cmFtLXR1cm5iaXMtDQo+ID4gPiAyNyNzZWN0 aW9uLTIxLjEuNi4NCj4gPiA+DQo+ID4gPiBUaGVyZSdzIG5vdCBtdWNoIGRpc2N1c3Npb24gYWJv dXQgcG90ZW50aWFsIGluZm9ybWF0aW9uICBsZWFrYWdlIHZpYQ0KPiA+ID4gKGUuZy4pIFVTRVJO QU1FL1VTRVJIQVNILCBhbmQgcmVhbGx5IGp1c3QgYSBjbGFpbSB0aGF0IHRoZSBwZWVyDQo+ID4g PiBhZGRyZXNzIGlzIHRoZSAicHJpbWFyeSBwcm90b2NvbCBjb250ZW50Ii4NCj4gDQo+ICsxIHRv IEJlbidzIGNvbmNlcm4sIHdoaWNoIGVjaG9lcyBteSBvd24uDQo+IA0KPiA+IEFncmVlZCwgYWRk ZWQgdGhlIGZvbGxvd2luZyBwYXJhZ3JhcGggOg0KPiA+DQo+ID4gSWYgdGhlIFRVUk4gY2xpZW50 IGFuZCBzZXJ2ZXIgdXNlIHRoZSBTVFVOIEV4dGVuc2lvbiBmb3IgVGhpcmQtUGFydHkNCj4gPiBB dXRob3JpemF0aW9uIFtSRkM3NjM1XSwgdGhlIHVzZXJuYW1lIGRvZXMgbm90IHJldmVhbCB0aGUg cmVhbCB1c2VyJ3MNCj4gPiBpZGVudGl0eSwgdGhlIFVTRVJOQU1FIGF0dHJpYnV0ZSBjYXJyaWVz IGFuIGVwaGVtZXJhbCBhbmQgdW5pcXVlIGtleQ0KPiA+IGlkZW50aWZpZXIsIGFuZCB0aGUga2V5 IGlkZW50aWZpZXIgY2FuIGNoYW5nZSBwZXIgY2FsbC4NCj4gPiBJZiB0aGUgVFVSTiBjbGllbnQg YW5kIHNlcnZlciB1c2UgdGhlIFNUVU4gbG9uZy10ZXJtIGNyZWRlbnRpYWwNCj4gPiBtZWNoYW5p c20gYW5kIHRoZSB1c2VybmFtZSByZXZlYWxzIHRoZSByZWFsIHVzZXIncyBpZGVudGl0eSwgdGhl DQo+ID4gY2xpZW50IG5lZWQgdG8gZWl0aGVyIHVzZSAoRClUTFMgdHJhbnNwb3J0IGJldHdlZW4g dGhlIGNsaWVudCBhbmQgdGhlDQo+ID4gc2VydmVyIG9yIHVzZSB0aGUgVVNFUkhBU0ggYXR0cmli dXRlIGluc3RlYWQgb2YgdGhlIFVTRVJOQU1FIGF0dHJpYnV0ZQ0KPiA+IHRvIGFub255bm1pemUg dGhlIHVzZXJuYW1lLg0KPiANCj4gVGhpcyBpcyBhbiBpbXByb3ZlbWVudCAtLSB0aGFua3MhIFNo b3VsZCB1c2Ugb2YgKEQpVExTIGJlIG1hbmRhdGVkDQo+ICgiTVVTVCIgaW5zdGVhZCBvZiAibmVl ZCB0byIpIHdoZW4gbG9uZy10ZXJtIGNyZWRlbnRpYWxzIGFyZSB1c2VkPw0KDQpJIHRoaW5rIHlv dSBtZWFuIChEKVRMUyBvciBVU0VSSEFTSCBtdXN0IGJlIHVzZWQsIHVwZGF0ZWQgdGhlIGxpbmUg YXMgZm9sbG93czoNCg0KSWYgdGhlIFRVUk4gY2xpZW50IGFuZCBzZXJ2ZXIgdXNlIHRoZSBTVFVO IGxvbmctdGVybSBjcmVkZW50aWFsIG1lY2hhbmlzbSBhbmQgdGhlIHVzZXJuYW1lIHJldmVhbHMg dGhlIHJlYWwgdXNlcidzIGlkZW50aXR5LCB0aGUgY2xpZW50IE1VU1QgZWl0aGVyIHVzZSB0aGUg VVNFUkhBU0ggYXR0cmlidXRlIGluc3RlYWQgb2YgdGhlIFVTRVJOQU1FIGF0dHJpYnV0ZSB0byBh bm9ueW5taXplIHRoZSB1c2VybmFtZSBvciB1c2UgDQooRClUTFMgdHJhbnNwb3J0IGJldHdlZW4g dGhlIGNsaWVudCBhbmQgdGhlIHNlcnZlci4NCg0KPiANCj4gPiA+ID4gPiBFbmNyeXB0aW5nIHRo ZSBub25jZSwgdXNlcm5hbWUsIHJlYWxtLCBldGMuLCBhbW9uZyBvdGhlciB0aGluZ3MsDQo+ID4g PiA+ID4gaGFzIG9idmlvdXMgYmVuZWZpdHMuIC0gV2h5IGFyZSBTT0ZUV0FSRSBhbmQgRklOR0VS UFJJTlQNCj4gPiA+ID4gPiBhdHRyaWJ1dGVzIHJlY29tbWVuZGVkPyAgSXQgc2VlbXMgbGlrZSBj bGllbnRzIHNob3VsZCBiZQ0KPiA+ID4gPiA+IGRpc2NvdXJhZ2VkIGZyb20gc2VuZGluZyB0aGVz ZSBpZiBhbnl0aGluZywgZXNwZWNpYWxseSBpZiBub3QNCj4gPiA+ID4gPiB1c2VkIHRvIG1ha2Ug YWxsb2NhdGlvbiBkZWNpc2lvbnMgb24gdGhlIHNlcnZlci4NCj4gPiA+ID4NCj4gPiA+ID4gVXNl cm5hbWUgbWF5IG5vdCBiZSB0aGUgdXNlciBpZGVudGl0eSwgUGxlYXNlIHNlZQ0KPiA+ID4gaHR0 cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzc2MzUpLCBJdCBjb3VsZCBiZSBhbiBlcGhlbWVy YWwgYW5kDQo+ID4gPiB1bmlxdWUga2V5IGlkZW50aWZpZXIuIEZ1cnRoZXIsIHVzZXJuYW1lIGNh biBiZSBhbm9ueW1pemVkIChwbGVhc2UNCj4gPiA+IHNlZSBodHRwczovL3Rvb2xzLmlldGYub3Jn L2h0bWwvZHJhZnQtaWV0Zi10cmFtLXN0dW5iaXMtMjEjc2VjdGlvbi0xNC40KS4NCj4gPiA+ID4g U09GVFdBUkUgYW5kIEZJTkdFUlBSSU5UIGF0dHJpYnV0ZXMgYXJlIGRlZmluZWQgaW4gdGhlIFNU VU4NCj4gPiA+IHNwZWNpZmljYXRpb24sIHNlZSBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwv ZHJhZnQtaWV0Zi10cmFtLXN0dW5iaXMtMjEuDQo+IA0KPiBJIHJlYWxpemUgdGhleSdyZSBkZWZp bmVkIGVsc2V3aGVyZS4gTXkgY29uY2VybiB3YXMgdGhhdCB0aGlzIGRyYWZ0IHNlZW1zIHRvDQo+ IGVuY291cmFnZSBzZW5kaW5nIHRoZW0gd2hlbiBwZXJoYXBzIHRoYXQncyBub3QgbmVlZGVkLCBp LmUuLCBhcyBpcyB0aGUgY2FzZQ0KPiBmb3IgdGhlIFNPRlRXQVJFIGF0dHJpYnV0ZS4NCg0KVGhp cyAiU0hPVUxEIiB0byBzZW5kIFNPRlRXQVJFIGF0dHJpYnV0ZSBpcyBkZWZpbmVkIGluIFJGQzU3 NjYgKEFzIHlvdSBtYXkga25vdywgVFVSTiBpcyB1c2VkIGluIHRoZSBmaWVsZCBmb3Igc2V2ZXJh bCB5ZWFycykgYW5kIHR1cm5iaXMgZG9lcyBub3QgbW9kaWZ5IHRoZSBiZWhhdmlvciBmb3IgYmFj a3dhcmQgY29tcGF0aWJpbGl0eS4gVGhlIHVzZSBvZiBGSU5HRVJQUklOVCBpcyBub3QgbWFuZGF0 b3J5LCB0aGUgZHJhZnQgc2F5cyB0aGUgVFVSTiBjbGllbnQgYW5kIHNlcnZlciBtYXkgaW5jbHVk ZSB0aGUgRklOR0VSUFJJTlQgYXR0cmlidXRlLiAgDQoNCj4gDQo+ID4gPg0KPiA+ID4gVGhlc2Ug bWVjaGFuaXNtcyAgYXJlIHBhcnRpYWwgbWl0aWdhdGlvbnMgYnV0IGNhbiBzdGlsbCBiZQ0KPiA+ ID4gc3VzY2VwdGlibGUgdG8gY3Jvc3MtIGNvbm5lY3Rpb24gY29ycmVsYXRpb24gYXR0YWNrcy4N Cj4gPg0KPiA+IFRoZSB1c2Ugb2YgRklOR0VSUFJJTlQgaXMgbm90IG1hbmRhdG9yeSwgdGhlIFRV Uk4gY2xpZW50IGFuZCBzZXJ2ZXINCj4gPiBtYXkgaW5jbHVkZSB0aGUgRklOR0VSUFJJTlQgYXR0 cmlidXRlLiAgTm90ZSB0aGF0IElDRQ0KPiA+IChodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwv cmZjODQ0NSkgbWFuZGF0ZXMgdGhlIHVzZSBvZiBGSU5HRVJQUklOVA0KPiA+IGF0dHJpYnV0ZS4g QWRkZWQgdGhlIGZvbGxvd2luZyBsaW5lIGZvciBTT0ZUV0FSRSBhdHRyaWJ1dGUgKFRVUk5iaXMg aXMNCj4gPiB1c2luZyB0aGUgc2FtZSBiZWhhdmlvciBkZWZpbmVkIGluIFJGQzU3NjYgdG8gdXNl IFNPRlRXQVJFIGF0dHJpYnV0ZSkgIDoNCj4gPg0KPiA+IFNPRldBVEUgYXR0cmlidXRlIGNhbiBy ZXZlYWwgdGhlIHNwZWNpZmljIHNvZnR3YXJlIHZlcnNpb24gb2YgdGhlIFRVUk4NCj4gPiBjbGll bnQgYW5kIHNlcnZlciB0byBlYXZlc2Ryb3BwZXIgYW5kIGl0IG1pZ2h0IHBvc3NpYmx5IGFsbG93 IGF0dGFja3MNCj4gPiBhZ2FpbnN0IHZ1bG5lcmFibGUgc29mdHdhcmUgdGhhdCBpcyBrbm93biB0 byBjb250YWluIHNlY3VyaXR5IGhvbGVzLg0KPiA+IElmIGl0IGlzIGltcG9ydGFudCB0byBwcmV2 ZW50IGFuIGVhdmVzZHJvcHBlciBmcm9tIGxlYXJuaW5nIHRoZQ0KPiA+IHNvZnR3YXJlIHZlcnNp b24sIFRVUk4gY2FuIGJlIHJ1biBvdmVyIChEKVRMUy4NCj4gDQo+IEknZCByZXBsYWNlICJob2xl cyIgd2l0aCAidnVsbmVyYWJpbGl0aWVzLCIgYW5kIHJld3JpdGUNCg0KRG9uZS4NCg0KPiANCj4g ICAgIklmICBpdCBpcyBpbXBvcnRhbnQgdG8gcHJldmVudCBhbiBlYXZlc2Ryb3BwZXIgZnJvbSBs ZWFybmluZyB0aGUgc29mdHdhcmUNCj4gdmVyc2lvbiwgVFVSTiBjYW4gYmUgcnVuIG92ZXIgKEQp VExTLiINCj4gDQo+IGFzIGZvbGxvd3M6DQo+IA0KPiAiVFVSTiBTSE9VTEQgYmUgcnVuIG92ZXIg KEQpVExTIHRvIHByZXZlbnQgbGVha2luZyB0aGUgU09GVFdBUkUNCj4gYXR0cmlidXRlIGluIGNs ZWFyIHRleHQuIg0KDQpXZSB3YW50IHRvIGF2b2lkIGRvdWJsZSBlbmNyeXB0aW9uIG9mIGFwcGxp Y2F0aW9uIGRhdGEsIGFuZCBTT0ZUV0FSRSBhdHRyaWJ1dGUgaGFzIGJlZW4gc2VudCBpbiBjbGVh ciB0ZXh0IGFsbCB0aGVzZSB5ZWFycyBpbiB0aGUgZmllbGQsIGFuZCBubyBhdHRhY2sgaGFzIGJl ZW4gZGV0ZWN0ZWQgYmFzZWQgb24gU09GVFdBUkUgZmllbGQuIEkgY2FuIHJldmlzZSB0aGUgdGV4 dCBhcyBmb2xsb3dzOg0KSWYgdGhlIHNvZnR3YXJlIHZlcnNpb24gaXMga25vd24gdG8gY29udGFp biBzZWN1cml0eSB2dWxuZXJhYmlsaXRpZXMsIFRVUk4gU0hPVUxEIGJlIHJ1biBvdmVyIChEKVRM UyB0byBwcmV2ZW50IGxlYWtpbmcgdGhlIFNPRlRXQVJFIGF0dHJpYnV0ZSBpbiBjbGVhciB0ZXh0 Lg0KDQo+IA0KPiA+ID4gPiAtIFNlY3Rpb24gNTogV2hlbiBzZXJ2ZXJzIHJlY2VpdmUgZGF0YSB0 aGF0IGV4Y2VlZHMgYW4NCj4gPiA+ID4gYWxsb2NhdGlvbuKAmXMNCj4gPiA+ID4gPiBiYW5kd2lk dGggcXVvdGEsIHNlcnZlcnMgc2lsZW50bHkgZGlzY2FyZCB0aGlzIGRhdGEuIFRoaXMgbWVhbnMN Cj4gPiA+ID4gPiB0aGVyZeKAmXMgbm8gYWxsb2NhdGlvbi1iYXNlZCBmbG93IGNvbnRyb2wgbWVj aGFuaXNtIGJldHdlZW4NCj4gPiA+ID4gPiBjbGllbnQgYW5kIHNlcnZlciBiZXlvbmQgd2hhdOKA mXMgcHJvdmlkZWQgYnkgdGhlIHRyYW5zcG9ydCBwcm90b2NvbCwNCj4gcmlnaHQ/DQo+ID4gPiA+ DQo+ID4gPiA+IFllcywgVURQIGRvZXMgbm90IGluY2x1ZGUgYSBjb25nZXN0aW9uIGNvbnRyb2wg bWVjaGFuaXNtLg0KPiANCj4gUmlnaHQgLS0gaXQgbWlnaHQgYmUgZ29vZCB0byBtZW50aW9uIHRo aXMgZXhwbGljaXRseS4NCg0KVXBkYXRlZC4NCg0KPiANCj4gPiA+ID4gPiBUaGlzIHNlZW1zIGZp bmUsIHRob3VnaA0KPiA+ID4gPiA+IHBlcmhhcHMgc29tZSBkaXNjdXNzaW9uIG9mIHdoeSB0aGlz IGRlc2lnbiBkZWNpc2lvbiB3YXMgbWFkZQ0KPiA+ID4gPiA+IHdvdWxkIGJlIGhlbHBmdWwuIEZv ciBleGFtcGxlLCBJIGNvdWxkIGltYWdpbmUgZXhwbGljaXQgc2lnbmFscw0KPiA+ID4gPiA+IGZy b20gc2VydmVycyB0byBjbGllbnRzIHRoYXQgaW5kaWNhdGUgc2VydmVyIHN0YXRlIHdvdWxkIHJl dmVhbA0KPiA+ID4gPiA+IGluZm9ybWF0aW9uIGFib3V0IG90aGVyIGFsbG9jYXRpb25zIG9uIHRo ZSBzZXJ2ZXIsIHdoaWNoIG1pZ2h0DQo+ID4gPiA+ID4gYmUgcHJvYmxlbWF0aWMuIC0NCj4gPiA+ ID4NCj4gPiA+ID4gVGhlIGVycm9ycyA0ODYgKEFsbG9jYXRpb24gUXVvdGEgRXhjZWVkZWQpIG9y IDUwOCAoSW5zdWZmaWNpZW50DQo+ID4gPiA+IENhcGFjaXR5KQ0KPiA+ID4gZG8gbm90IHJldmVh bCBpbmZvcm1hdGlvbiBvZiB3aGljaCBvdGhlciB1c2VycyBhcmUgdXNpbmcgdGhlIFRVUk4gc2Vy dmVyLg0KPiANCj4gUGVyaGFwcyBub3Qgd2hpY2ggb3RoZXIgKnVzZXJzKiBhcmUgdXNpbmcgdGhl IFRVUk4gc2VydmVyLCBjb3JyZWN0LiBJdCBtYXkNCj4gbGVhayBvdGhlciBpbmZvcm1hdGlvbiB0 aG91Z2gsIGFuZCBkcmF3aW5nIEhUVFAgNTAzIHJlc3BvbnNlIGNvZGUgYW5hbG9neQ0KPiB3b3Vs ZCBiZSBoZWxwZnVsLg0KDQpBZGRlZCB0aGUgZm9sbG93aW5nIGxpbmU6DQpOb3RlIHRoYXQgdGhl IGVycm9yIGNvZGUgdmFsdWVzIDQ4NiBhbmQgNTA4IGluZGljYXRlIHRvIGEgZWF2ZXNkcm9wcGVy IGFuZCB0aGUgY2xpZW50IHRoYXQgc2V2ZXJhbCBvdGhlciB1c2VycyBhcmUgdXNpbmcgdGhlIHNl cnZlciBhdCB0aGlzIHRpbWUsIHNpbWlsYXIgdG8gdGhhdCBvZiB0aGUgSFRUUCBlcnJvciByZXNw b25zZSBjb2RlIDUwMywgYnV0IGRvZXMgbm90IHJldmVhbCBhbnkgaW5mb3JtYXRpb24gYWJvdXQg dGhlIHVzZXJzIHVzaW5nIHRoZSBUVVJOIHNlcnZlci4NCg0KQ2hlZXJzLA0KLVRpcnUNCg0KPiAN Cj4gPiA+IEF0IGxlYXN0IHRoZSBsYXR0ZXIgc2VlbXMgdG8gZ2l2ZSBzb21lIGluZGljYXRpb24g dGhhdCBtYW55IG90aGVyDQo+ID4gPiB1c2VycyBhcmUgdXNpbmcgdGhlIHNlcnZlciBhdCB0aGUg IHRpbWUgKHNvIHRoYXQgaXQncyBvdmVybG9hZGVkKSwNCj4gPiA+IHRob3VnaCBub3QgaW5mb3Jt YXRpb24gYWJvdXQgKndoaWNoKiB1c2VycyB0aGF0IGlzLg0KPiA+DQo+ID4gWWVzLCBzaW1pbGFy IHRvIDUwMyBIVFRQIGVycm9yIHJlc3BvbnNlLg0KPiA+DQo+ID4gPg0KPiA+ID4gPiA+IFNlY3Rp b24gNy4yIHN1Z2dlc3RzIHRoYXQNCj4gPiA+ID4gPiBzZXJ2ZXJzIGNhbiByZWRpcmVjdCBjbGll bnQgYWxsb2NhdGlvbiByZXF1ZXN0cyB0byBvdGhlciBzZXJ2ZXJzLg0KPiA+ID4gPiA+IENhbiB0 aGlzIGNyZWF0ZSBhIGxvb3AsIHdoZXJlaW4gdHdvIFRVUk4gc2VydmVycyByZWRpcmVjdCB0byBv bmUNCj4gYW5vdGhlcj8NCj4gPiA+ID4NCj4gPiA+ID4gVGhlIGNsaWVudCBkZXRlY3QgYW5kIHN0 b3AgdGhlIGxvb3AsIGl0IGlzIHNpbWlsYXIgdG8gSFRUUCByZWRpcmVjdGlvbi4NCj4gPiA+DQo+ ID4gPiBXaGVyZSBpcyB0aGlzIHNwZWNpZmllZD8NCj4gPg0KPiA+IEl0IGlzIHNwZWNpZmllZCBp biB0aGUgbGFzdCBwYXJhZ3JhcGggb2YNCj4gPiBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwv ZHJhZnQtaWV0Zi10cmFtLXN0dW5iaXMtMjEjc2VjdGlvbi0xMA0KPiANCj4gQWhhIC0tIEkgbWlz c2VkIHRoYXQuIFRoYW5rcyENCj4gDQo+IEJlc3QsDQo+IENocmlzDQo= From nobody Fri Jul 12 18:49:34 2019 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 A763112006A; Fri, 12 Jul 2019 18:49:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LoYkE14w9WKW; Fri, 12 Jul 2019 18:49:13 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 60D0B12000E; Fri, 12 Jul 2019 18:49:12 -0700 (PDT) Received: from mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x6D1n2WO019102 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 12 Jul 2019 21:49:05 -0400 Date: Fri, 12 Jul 2019 20:49:02 -0500 From: Benjamin Kaduk To: "Konda, Tirumaleswar Reddy" Cc: Christopher Wood , "secdir@ietf.org" , "draft-ietf-tram-turnbis.all@ietf.org" , "ietf@ietf.org" , "tram@ietf.org" Message-ID: <20190713014901.GQ16418@mit.edu> References: <156253133809.549.13521510978566357744@ietfa.amsl.com> <20190709203044.GD24351@kduck.mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [tram] Secdir last call review of draft-ietf-tram-turnbis-27 X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Jul 2019 01:49:17 -0000 Hi Tiru, Thanks for all the updates, including further downthread with Chris. Just a couple notes inline... On Wed, Jul 10, 2019 at 12:40:37PM +0000, Konda, Tirumaleswar Reddy wrote: > Hi Ben, > > Thanks for the review. Please see inline. > > > -----Original Message----- > > From: Benjamin Kaduk > > Sent: Wednesday, July 10, 2019 2:01 AM > > To: Konda, Tirumaleswar Reddy > > Cc: Christopher Wood ; secdir@ietf.org; draft-ietf- > > tram-turnbis.all@ietf.org; ietf@ietf.org; tram@ietf.org > > Subject: Re: [tram] Secdir last call review of draft-ietf-tram-turnbis-27 > > > > This email originated from outside of the organization. Do not click links or > > open attachments unless you recognize the sender and know the content is > > safe. > > > > Chris, thanks for the review. Some more questions/comments inline as I > > prepare to ballot on this document... > > > > On Mon, Jul 08, 2019 at 02:18:26PM +0000, Konda, Tirumaleswar Reddy wrote: > > > Hi Christopher, > > > > > > Thanks for the detailed review. Please see inline > > > > > > > -----Original Message----- > > > > From: tram On Behalf Of Christopher Wood via > > > > Datatracker > > > > Sent: Monday, July 8, 2019 1:59 AM > > > > To: secdir@ietf.org > > > > Cc: draft-ietf-tram-turnbis.all@ietf.org; ietf@ietf.org; > > > > tram@ietf.org > > > > Subject: [tram] Secdir last call review of > > > > draft-ietf-tram-turnbis-27 > > > > > > > > This email originated from outside of the organization. Do not click > > > > links or open attachments unless you recognize the sender and know > > > > the content is safe. > > > > > > > > Reviewer: Christopher Wood > > > > Review result: Has Nits > > > > > > > > I have reviewed this document as part of the security directorate's > > > > ongoing effort to review all IETF documents being processed by the > > > > IESG. These comments were written primarily for the benefit of the > > > > security area directors. > > > > Document editors and WG chairs should treat these comments just like > > > > any other last call comments. > > > > > > > > The summary of the review is: Ready with nits > > > > > > > > Summary: > > > > > > > > In general, the document is well written and clearly founded in > > > > operational experience. The security considerations are thorough, > > > > providing examples where necessary to highlight important problem > > > > areas. It draws a clear line between issues best addressed by > > > > applications outside of TURN, and provides sufficient detail for > > > > those issues in scope. My comments and questions are, hopefully, mostly > > nits. > > > > > > > > General comments: > > > > > > > > - TURN server authentication in the case of (D)TLS is > > > > underspecified. Are servers assumed to have WebPKI certificates, > > > > OOB-trusted raw public keys, or something else? Is there a preferred > > form of authentication? > > > > Relatedly, in > > > > Section 3.2, how do clients authenticate the server? > > > > > > Server certificate validation is discussed in https://tools.ietf.org/html/draft- > > ietf-tram-stunbis-21#section-6.2.3. I have modified the text as follows: > > > > > > If (D)TLS transport is used between the TURN client and the TURN > > > server, the cipher suites, server certificate validation and > > > authentication of TURN server are discussed in Section 6.2.3 of > > > [I-D.ietf-tram-stunbis] > > > > That helps, but it would still be nice to give some indication of what certificate > > PKI(s) are expected to be used. Is anything other than the Web PKI under > > consideration ? > > No. Please see https://tools.ietf.org/html/draft-ietf-tram-stunbis-21#section-6.2.3, It discusses to verify the certificate path and identity of the server. > > > > > > >- Section 3.7: Could > > > > TURN servers not chunk data from stream-oriented transports (TCP or > > > >TLS) to a preferred MTU size before relaying to peers? > > > > Specifically, there are likely > > > > some cases wherein the server could deal with the client data > > > >messages larger than the recommended 500B limit. On that point, > > > >should servers even accept data larger than this recommended size ? > > > >- > > > > > > Please see > > > https://tools.ietf.org/html/draft-ietf-tram-turnbis-27#section-15 for > > > TCP-to-UDP relay. If the PMTU is not known, and on legacy or otherwise > > > unusual networks, > > > 500 byte limit for application data is recommended. > > > > > > > Section 3.9: There may be > > > > cases where the TLS connection post TCP connection establishment > > > > fails. It would therefore seems prudent to not declare victory for > > > > one connection over the other until TLS connects, too. - > > > > > > Agreed, Eric (as part of ISEG review) suggested to simplify the text. I have > > updated the text as follows: > > > > > > o For TCP or TLS-over-TCP, the results of the Happy Eyeballs > > > procedure [RFC8305] are used by the TURN client for sending its > > > TURN messages to the server. > > > > Is the editor's copy available for viewing somewhere? It would be good to > > see this (and other changes) in context. > > Yes, Please see https://github.com/tireddy2/TURNbis > > > > > > > Section 3 could benefit from a > > > > subsection on replays and the nonce role. In particular, as later > > > > discussed in the security considerations, some of these attacks are > > > > not new to TURN and should therefore be dealt with by the > > > > application protocol (SRTP). This section might also describe nonce > > > > rotation policies with more specificity, as this is underspecified in the > > document. > > > > > > It is discussed in Section 5 in the specification, the server should expire the > > nonce at least once every hour during the lifetime of the allocation. > > > > > > >- Section 3 could also benefit from > > > > discussion about cleartext versus encryption transports between > > > >clients and servers. > > > > > > It is discussed in https://tools.ietf.org/html/draft-ietf-tram-turnbis- > > 27#section-21.1.6. > > > > There's not much discussion about potential information leakage via (e.g.) > > USERNAME/USERHASH, and really just a claim that the peer address is the > > "primary protocol content". > > Agreed, added the following paragraph : > > If the TURN client and server use the STUN Extension for Third-Party Authorization [RFC7635], the username does not reveal the > real user's identity, the USERNAME attribute carries an ephemeral and unique key identifier, and the key identifier can change per call. > If the TURN client and server use the STUN long-term credential mechanism and the username reveals the > real user's identity, the client need to either use (D)TLS transport between the client and the server or use > the USERHASH attribute instead of the USERNAME attribute to anonynmize the username. > > > > > > > Encrypting the nonce, username, realm, etc., among other things, has > > > > obvious benefits. - Why are SOFTWARE and FINGERPRINT attributes > > > > recommended? It seems like clients should be discouraged from > > > > sending these if anything, especially if not used to make allocation > > > > decisions on the server. > > > > > > Username may not be the user identity, Please see > > https://tools.ietf.org/html/rfc7635), It could be an ephemeral and unique > > key identifier. Further, username can be anonymized (please see > > https://tools.ietf.org/html/draft-ietf-tram-stunbis-21#section-14.4). > > > SOFTWARE and FINGERPRINT attributes are defined in the STUN > > specification, see https://tools.ietf.org/html/draft-ietf-tram-stunbis-21. > > > > These mechanisms are partial mitigations but can still be susceptible to cross- > > connection correlation attacks. > > The use of FINGERPRINT is not mandatory, the TURN client and server may include the FINGERPRINT attribute. Note that ICE (https://tools.ietf.org/html/rfc8445) mandates the use of FINGERPRINT attribute. Added the following line for SOFTWARE attribute (TURNbis is using the same behavior defined in RFC5766 to use SOFTWARE attribute) : > > SOFWATE attribute can reveal the specific software version of the TURN client and server to eavesdropper and it might possibly allow attacks against vulnerable software that is known to contain security holes. If it is important to prevent an eavesdropper from learning the software version, TURN can be run over (D)TLS. The later suggestion was: % We want to avoid double encryption of application data, and SOFTWARE attribute has % been sent in clear text all these years in the field, and no attack has been % detected based on SOFTWARE field. I can revise the text as follows: % If the software version is known to contain security vulnerabilities, TURN SHOULD be % run over (D)TLS to prevent leaking the SOFTWARE attribute in clear text. I think some of the concern is over the risk of so-called "zero-day" exploits, where the attacker knows of a version-specific flaw but the defenders do not (and have zero days notice to protect against it). Such a concern would suggest to avoid sending SOFTWARE over enencrypted transport regardless of the state of known vulnerabilities, but in the end it is a matter of local policy. > > > > > > - Section 5: When servers receive data that exceeds an allocation’s > > > > bandwidth quota, servers silently discard this data. This means > > > > there’s no allocation-based flow control mechanism between client > > > > and server beyond what’s provided by the transport protocol, right? > > > > > > Yes, UDP does not include a congestion control mechanism. > > > > > > > This seems fine, though > > > > perhaps some discussion of why this design decision was made would > > > > be helpful. For example, I could imagine explicit signals from > > > > servers to clients that indicate server state would reveal > > > > information about other allocations on the server, which might be > > > > problematic. - > > > > > > The errors 486 (Allocation Quota Exceeded) or 508 (Insufficient Capacity) > > do not reveal information of which other users are using the TURN server. > > > > At least the latter seems to give some indication that many other users are > > using the server at the time (so that it's overloaded), though not information > > about *which* users that is. > > Yes, similar to 503 HTTP error response. > > > > > > > Section 7.2 suggests that > > > > servers can redirect client allocation requests to other servers. > > > > Can this create a loop, wherein two TURN servers redirect to one another? > > > > > > The client detect and stop the loop, it is similar to HTTP redirection. > > > > Where is this specified? > > It is specified in the last paragraph of https://tools.ietf.org/html/draft-ietf-tram-stunbis-21#section-10 > > > If the client has been redirected to a > server to which it has already sent this request within the last five > minutes, it MUST ignore the redirection and consider the transaction > to have failed. This prevents infinite ping-ponging between servers > in case of redirection loops. > Thanks for the pointer; as you saw in my ballot position I was quite pressed for time this week and only was able to look at the diff. -Ben From nobody Fri Jul 12 19:14:50 2019 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 6DC8C120074; Fri, 12 Jul 2019 19:14:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EAI4UjyZod10; Fri, 12 Jul 2019 19:14:38 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 2FD6F12000E; Fri, 12 Jul 2019 19:14:37 -0700 (PDT) Received: from mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x6D2EUVU028185 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 12 Jul 2019 22:14:33 -0400 Date: Fri, 12 Jul 2019 21:14:30 -0500 From: Benjamin Kaduk To: "Konda, Tirumaleswar Reddy" Cc: The IESG , "tram-chairs@ietf.org" , "draft-ietf-tram-turnbis@ietf.org" , "tram@ietf.org" , "brandon.williams@akamai.com" Message-ID: <20190713021429.GR16418@mit.edu> References: <156282359426.15056.17118634579091500165.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [tram] Benjamin Kaduk's Discuss on draft-ietf-tram-turnbis-27: (with DISCUSS and COMMENT) X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Jul 2019 02:14:42 -0000 Hi Tiru, On Thu, Jul 11, 2019 at 03:47:19PM +0000, Konda, Tirumaleswar Reddy wrote: > Hi Ben, > > Thanks for the detailed review. Please see inline Sorry to have made you deduplicate with the reviews that had already come in -- I wrote this text fairly early (on just the diff) with intent to return and tidy up, but ran out of time and had to just submit what I had. > > -----Original Message----- > > From: tram On Behalf Of Benjamin Kaduk via > > Datatracker > > Sent: Thursday, July 11, 2019 11:10 AM > > To: The IESG > > Cc: tram-chairs@ietf.org; draft-ietf-tram-turnbis@ietf.org; tram@ietf.org; > > brandon.williams@akamai.com > > Subject: [tram] Benjamin Kaduk's Discuss on draft-ietf-tram-turnbis-27: (with > > DISCUSS and COMMENT) > > > > > > > > Benjamin Kaduk has entered the following ballot position for > > draft-ietf-tram-turnbis-27: 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-turnbis/ > > > > > > > > ---------------------------------------------------------------------- > > DISCUSS: > > ---------------------------------------------------------------------- > > > > I support Roman's Discuss. > > I have updated the draft to address Roman's Discuss. > > > > > I think I'm confused about whether REQUESTED-ADDRESS-FAMILY and > > ADDITIONAL-ADDRESS-FAMILY are mutually exclusive. > > Yes, both attributes are mutually exclusive. It is discussed in Section 7.1, Clients MUST NOT include REQUESTED-ADDRESS-FAMILY and ADDITIONAL-ADDRESS-FAMILY attributes in the same request. Okay. This seems weird to me and I wouldn't object if some very blunt text was added early on about "when both IPv4 and IPv6 are desired, the ADDITIONAL-ADDRESS-FAMILY attribute alone serves to request both address types; otherwise the single REQUESTED-ADDRESS-FAMILY attribute suffices", but this point clearly is not Discuss-worthy. > > Does sending just the > > "additional" one secretly mean that you want both v4 and v6? > > Yes, ADDITIONAL-ADDRESS-FAMILY is used for allocation of both IPv4 and IPv6. > > > > > Section 5 > > > > I see that the secdir reviewer asked about why it is a "SHOULD" to send > > SOFTWARE, and only got a response that it is defined in stunbis, but not > > about why it is recommended. There remain some privacy/security > > considerations with it, and we should either point to the stunbis security > > considerations or not recommend using it. (FINGERPRINT is, IIRC, less > > interesting from a security perspective as it's just about confirming that given > > traffic is in fact STUN and not something else.) > > This "SHOULD" to send SOFTWARE attribute is defined in RFC5766 (As you may know, TURN is used in the field for several years) and turnbis does not modify the behavior for backward compatibility, and to address the possible threat added the following lines: > > SOFTWARE attribute can reveal the specific software version of the TURN client and server to eavesdropper and it might possibly allow attacks against vulnerable software that is known to contain security holes. If it is important to prevent an eavesdropper from learning the software version, TURN can be run over (D)TLS. (let's keep this on the secdir thread) > > > > Section 12 > > > > Do we need to say anything about backwards compatibility with RFC 5766 > > peers that use a wider range of channel IDs? > > Yes, added the following line: > Note that the channel number range is not backwards compatible with > [RFC5766], and cannot be used in environments where such > compatibility is required. I see now that Adam also raised this topic, and I'd like to hear his thoughts on this proposed text. Since we normally don't make breaking changes in "bis" documents, I'd also like to hear a bit more about what knoweldge we have (if any) about implementations that might be affected and are not affected. > > > > Section 12.7 > > > > When the server receives an ICMP packet, the server processes it as > > described in Section 11.5. A Data indication MUST be sent regardless > > of whether there is a channel bound to the peer that was the > > destination of the UDP datagram that triggered the reception of the > > ICMP packet. > > > > This MUST seems potentially in conflict with the previous discussion about > > permissions checks in Section 11.5. > > Good catch, removed conflicting text from Section 12.7. > > > > > Section 20 > > > > Looking at the > > new nonce in the example ("obMatJos2AAABadl7W7PeDU4hKE72jda"), and > > noting that it starts with the nonce cookie, help me decode the security > > feature bits. The magic prefix is "obMatJos2" so the capability bits are > > encoded as "AAAB", which decodes to (hex) 00 00 01. But stunbis says that > > the bits are ordered from 0 (MSB of first byte) to 23 (LSB of last byte), so this > > would have bit 23 set, which is in contrast to the registry marking bit 0 as the > > password-algorithms feature. Where am I messing this up? > > You are right, replaced with "obMatJos2gAAAadl7W7PeDU4hKE72jda" (hex) 80 00 00 It's reassuring to know that I wasn't missing something obvious; thanks! > > > > I'd prefer if the examples showed more usage of MESSAGE-INTEGRITY- > > SHA256 (especially, any from the server) and fewer MESSAGE-INTEGRITY. > > Sure, updated examples. > > > > > > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > > Thanks for keeping the diff from RFC 5766 relatively contained! > > I only reviewed the diff due to time constraints, but in general support > > reviewing the full document for internal consistency and any remarks that > > have not aged well, especially with respect to IANA considerations. > > > > Section 2 > > > > RFC 8174 has an updated version of the BCP 14 boilerplate text. > > Fixed. > > > > > Section 3.1 > > > > I appreciate the response to the secdir review, but even the linked stunbis > > section does not say much about which PKI's trust root is expected to be > > used. I'm forced to assume the Web PKI but don't have much grounds for > > that assumption. > > Yes, use pre-populated trust store on the endpoint to validate the certificate path. > > > > > Section 3.2 > > > > The secdir reviewer's comments seem to have some relevance. > > It seems like even when the third-party authorization mechanism is used, > > the client is still limited to "the server is authenticated because it gives me > > the service I asked for", which is not really documented anywhere yet. The > > long-term password mechanism at least generates an HMAC integrity tag on > > messages from server to client, which can provide some level of > > authentication via key confirmation. > > No, STURN third-party authorization provides message integrity for both request and response messages (please see https://tools.ietf.org/html/rfc7635#section-5). The mac_key to compute the message integrity can change per call and this mechanism is better than the long-term password mechanism. Note that WebRTC uses third-party authorization mechanism. Ah, that's reassuring to learn. Sorry for the confusion. > > > > Section 3.7 > > > > If the TURN server carrying out > > packet translation from IPv4-to-IPv6 cannot get the Don't Fragment > > (DF) bit in the IPv4 header, it MUST reject the Allocate request with > > DONT-FRAGMENT attribute. > > > > nit: does "cannot get" mean something like "read the value as sent on the > > wire" (e.g., due to implementation/API limitations)? > > Yes, cannot read the value as sent on wire. I'd suggest "is unable to access the state of", but that's entirely editorial and at your discretion. > > > > Section 6 > > > > o the relayed transport address or addresses; > > [...] > > > > [...] > > address. The relayed transport address MUST be unique across all > > allocations, so it can be used to uniquely identify the allocation. > > > > nit: there's maybe a singular/plural mismatch going on here, but I don't have > > any good ideas. > > > > Section 7.1 > > > > If the client wishes to obtain one IPv6 and one IPv4 relayed > > transport address then it includes an ADDITIONAL-ADDRESS-FAMILY > > attribute in the request. This attribute specifies that the server > > must allocate both address types. The attribute value in the > > ADDITIONAL-ADDRESS-FAMILY MUST be set to 0x02 (IPv6 address family). > > Clients MUST NOT include REQUESTED-ADDRESS-FAMILY and ADDITIONAL- > > ADDRESS-FAMILY attributes in the same request. [...] > > > > This reads like setting REQUESTED-ADDRESS-FAMILY and ADDITIONAL- > > ADDRESS-FAMILY are mutually exclusive. Is that the correct reading? > > Yes. > > > (Naively, one might expect that the thing named "additional" > > is applied on top of the base-level request, so I have to ask.) > > > > Section 7.2 > > > > Why do we only have a SHOULD-level requirement for authentication of > > Allocate requests where 5766 had MUST? Could we say "may allow > > unauthenticated requests in order to support [use case] but otherwise > > MUST require authentication" (with better wording)? I suppose this has > > probably been discussed ad nauseum already, so feel free to point me at the > > archives before getting into an actual discussion. > > You missed the next line, it says the authentication of the request is optional to allow TURN > servers provided by the local or access network to accept > Allocation requests from new and/or guest users in the network > who do not necessarily possess long term credentials for STUN > authentication and its security implications are discussed in > [RFC8155]. I saw the next line; the current formulation also allows non-use of authentication in other situations, which is why I suggested an alternate wording. > The WG spent several cycles discussing the downgrade of a MUST level requirement (please see https://tools.ietf.org/html/rfc8155#section-9). To be clear, I do not object to removing the MUST for the local-use case; I'm concerned with the wording of the text that, as written, also weakens the requirement for all other cases. > > > > 7. If the server does not support the address family requested by > > the client in REQUESTED-ADDRESS-FAMILY or is disabled by local > > policy, it MUST generate an Allocate error response, and it MUST > > include an ERROR-CODE attribute with the 440 (Address Family not > > Supported) response code. [...] > > > > nit: "or is disabled" needs a subject. > > Fixed, updated text as follows: > If the server does not support the address family requested by the client in REQUESTED-ADDRESS-FAMILY or if the allocation of the requested address family is disabled by local policy, it MUST generate an Allocate error response, and it MUST include an ERROR-CODE attribute with the 440 (Address Family not Supported) response code. Thanks > > 9. The server checks if the request contains an ADDITIONAL-ADDRESS- > > FAMILY attribute. If yes, and the attribute value is 0x01 (IPv4 > > address family), then the server rejects the request with a 400 > > (Bad Request) error. Otherwise, the server checks if it can > > allocate relayed transport addresses of both address types. If > > the server cannot satisfy the request, then the server rejects > > > > What are "both" address types? > > Both IPv4 and IPv6 address families. I guess once I realize that "ADDITIONAL-ADDRESS-FAMILY" is just code for "IPv4 and IPv6" with no other options, this doesn't look as unclear. > > We only have the ADDITIONAL-ADDRESS- > > FAMILY (which contains one type) and no REQUESTED-ADDRESS-FAMILY. > > If ADDITIONAL-ADDRESS-FAMILY is used, the server will allocate both IPv4 and IPv6 relayed transport addresses. > > > > > Section 8.1 > > > > When refreshing a dual allocation, the client includes REQUESTED- > > ADDRESS-FAMILY attribute indicating the address family type that > > should be refreshed. If no REQUESTED-ADDRESS-FAMILY is included then > > the request should be treated as applying to all current allocations. > > The client MUST only include family types it previously allocated and > > has not yet deleted. [...] > > > > I'm a bit confused about "only include family types" plural; I thought there > > could only be at most one REQUESTED-ADDRESS-FAMILY and that it would > > only indicate one family type. So how could there be multiple types getting > > included by the client? > > Good catch, replaced "types" with "type" (It needs a definite article, then for "only include the family type") > > > > Section 11.5 > > > > [check that "type and code" is valid in both ICMPv4 and v6] > > Yes, it is valid. Sorry; that was supposed to be a note to myself! But yes, luckily for me this is not the point of difference between ICMPv4 and ICMPv6 that I was vaguely remembering. > > > > Section 12 > > > > Reserved values may be used in the future by other protocols. When > > the client uses channel binding, it MUST comply with the > > demultiplexing scheme discussed above. > > > > "channel binding" is a term of art in the security world; is this usage intended > > to roughly mean "channel multiplexing"? > > (I do see that the subsections are talking about the specific ChannelBind > > request, so I assume so; I just want to double check.) > > Yes, a channel binding is created or refreshed using a ChannelBind transaction (Please see Section 12.1). Great. Well, not great that there's a collision of jargon, but it's way too late to do anything about, now. > > > > > > Section 13 > > > > The descriptions below have two parts: a preferred behavior and an > > alternate behavior. The server SHOULD implement the preferred > > behavior. Otherwise, the server MUST implement the alternate > > behavior and MUST NOT do anything else for the reasons detailed in > > [RFC7915]. [...] > > > > RFC 5766 had this split on a per-field basis, but this text suggests that if the > > preferred behavior is not possible for a given field, then the alternate > > behavior is used for the entire packet. > > I note that section 14 does retain the "for a particular field" language for > > UDP-to-UDP relaying, as do section 15 for TCP-to-UDP relaying and section 16 > > for UDP-to-TCP relaying. > > Good point, fixed text as follows: > Otherwise, if that is not possible for a particular field, the server MUST implement the alternate behavior and MUST NOT do anything else for the reasons detailed in [RFC7915]. > > > > > Section 13.2 > > > > Is this flow label text consistent with both the inbound and outbound > > translation directions (specifically, using relayed/peer addresses in the 5- > > tuple to identify the flow)? > > > > If the incoming packet did not include a Fragment header and the > > outgoing packet size exceeds the outgoing link's MTU, the TURN > > server drops the outgoing packet and send an ICMP message of type > > 2 code 0 ("Packet too big") to the sender of the incoming packet. > > If the packet is being sent to the peer, the TURN server reduces > > the MTU reported in the ICMP message by 48 bytes to allow room for > > the overhead of a Data indication. > > > > (nit?) "If the packet is being send to the peer" seems to grammatically refer > > to the outgoing packet that would exceed link MTU, as opposed to the ICMP > > message being generated. But I think it's supposed to refer to the ICMP > > message being generated, which has not yet been referred to as a "packet" > > in this text. > > Suresh raised the same comment, fixed text as follows: > If the ICMPv6 packet ("Packet too big") is being sent to the peer, the TURN server reduces the MTU reported in the ICMP message by 48 bytes to allow room for the overhead of a Data indication. Great; t hanks > > > > Section 13.3 > > > > [Same comment about ICMP packet generation/grammar] > > Fixed text as follows: > If the ICMPv4 packet (Destination Unreachable (Type 3) with Code 4) is being sent to the peer, the TURN server SHOULD reduce the MTU reported in the ICMP message by 48 bytes to allow room for the overhead of a Data indication. > > > > > Section 15 > > > > Maybe note that SIP and WebRTC are the primary consumers of TURN? > > Yes, it is mentioned in several places in the document that WebRTC and SIP use TURN. Okay; my fault for only looking at the diff, probably. > > > > Even if both > > TCP-AO and UDP authentication would be used between TURN client and > > server, it would not change the end-to-end security properties of the > > UDP payload being relayed. [...] > > > > I wonder if we even need to say "UDP" in "payload being relayed". > > Replaced "UDP" with "application" > > > > > Section 16 > > > > Fragmentation > > > > Preferred Behavior: Any fragmented packets are reassembled in the > > server and then forwarded to the client over the TCP connection. > > ICMP messages resulting from the UDP datagrams sent to the peer > > MUST be forwarded to the client using TURN's mechanism for > > relevant ICMP types and codes. > > > > As in section 12.7, I wonder if this MUST could be seen as overriding other > > logic for ICMP handling. > > Modified text for clarity as follows: > > ICMP messages resulting from the UDP datagrams sent to the peer > are processed by the server as described in Section 11.5 and > forwarded to the client using TURN's mechanism for relevant ICMP > types and codes. Thanks > > > > Section 21.16 > > > > I agree with the secdir reviewer that there is at least potential for username > > and realm to be sensitive. > > I proposed to add the following text: > > If the TURN client and server use the STUN Extension for Third-Party > Authorization [RFC7635] (for example it is used in WebRTC), the > username does not reveal the real user's identity, the USERNAME > attribute carries an ephemeral and unique key identifier. If the > TURN client and server use the STUN long-term credential mechanism > and the username reveals the real user's identity, the client needs > to use (D)TLS transport between the client and the server or use the > USERHASH attribute instead of the USERNAME attribute to anonynmize > the username. > > If the TURN client and server use the STUN long-term credential > mechanism and realm information is privacy sensitive, TURN can be run > over (D)TLS. As a reminder, STUN Extension for Third-Party > Authorization does not use realm. Excellent; thank you! > > > > Section 21.4 > > > > Do we need references for Teredo and/or 6to4? > > https://tools.ietf.org/html/rfc6156 did not add references to Teredo and 6to4. Okay; just wanted to check. > > > > Section 22 > > > > The codepoints for the STUN error codes defined in this specification > > are listed in Section 19. [IANA is requested to update the reference > > from [RFC5766] to RFC-to-be for the STUN error codes listed in > > Section 19.] > > > > (I think some of them are from RFC 6156 as well as from 5766.) > > Yes, added RFC6156. > > > > > Section 23 > > > > It seems prudent to revisit these listed IAB Considerations for whether the > > situation has changed in the past ten years (though I don't have any specific > > points that I would change). > > > > Section 25 > > > > (nit) are these really "updates" to RFC 6156 so much as incorporating its > > content wholesale into the core TURN specification? > > Yes, several sections in RFC6156 are updated. Okay, thanks. -Ben From nobody Fri Jul 12 23:12:22 2019 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 D9D0C12008F for ; Fri, 12 Jul 2019 23:12:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4 X-Spam-Level: X-Spam-Status: No, score=-4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=mcafee.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BSSRQrtoR7YJ for ; Fri, 12 Jul 2019 23:12:17 -0700 (PDT) Received: from us-smtp-delivery-210.mimecast.com (us-smtp-delivery-210.mimecast.com [63.128.21.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 34E25120024 for ; Fri, 12 Jul 2019 23:12:17 -0700 (PDT) X-NAI-Header: Modified by McAfee Email Gateway (5500) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mcafee.com; s=s_mcafee; t=1562997622; h=ARC-Seal: ARC-Message-Signature:ARC-Authentication-Results: From:To:CC:Subject:Thread-Topic:Thread-Index: Date:Message-ID:References:In-Reply-To:Accept-Language: Content-Language:X-MS-Has-Attach:X-MS-TNEF-Correlator: dlp-product:dlp-version:dlp-reaction:authentication-results: x-originating-ip:x-ms-publictraffictype:x-ms-office365-filtering-correlation-id: x-microsoft-antispam:x-ms-traffictypediagnostic: x-ms-exchange-purlcount:x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers:x-forefront-prvs: x-forefront-antispam-report:received-spf:x-ms-exchange-senderadcheck: x-microsoft-antispam-message-info:Content-Type: Content-Transfer-Encoding:MIME-Version:X-MS-Exchange-CrossTenant-Network-Message-Id: X-MS-Exchange-CrossTenant-originalarrivaltime: X-MS-Exchange-CrossTenant-fromentityheader: X-MS-Exchange-CrossTenant-id:X-MS-Exchange-CrossTenant-mailboxtype: X-MS-Exchange-CrossTenant-userprincipalname: X-MS-Exchange-Transport-CrossTenantHeadersStamped: X-OriginatorOrg:X-NAI-Spam-Flag:X-NAI-Spam-Level: X-NAI-Spam-Threshold:X-NAI-Spam-Score:X-NAI-Spam-Version; bh=DBHC5C/tnsCy+AnHEk/WjYi6LIAFWQzAjESOxJ 0XUF0=; b=gMnjGGe5xrttDOGG0EIcvFKbYR3X3RVYKCHovs6r nuZZsiTAqC76DY6LxAQoeHrXrCCpxbSermPWyYt2Cdp+M2LEjj m6wXiO4jcQPJ1Gw94wFR1GVIsZbkqzaZeIsZf3otRo7d3wxB6T WUTHp5BQ6SVAVv8c9uzVqmYM7bDwqLU= Received: from DNVWSMAILOUT1.mcafee.com (dnvwsmailout1.mcafee.com [161.69.31.173]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-289-YOTrHg2EPRO11j827Av29w-1; Sat, 13 Jul 2019 02:11:02 -0400 Received: from DNVEXAPP1N06.corpzone.internalzone.com (unknown [10.44.48.90]) by DNVWSMAILOUT1.mcafee.com with smtp (TLS: TLSv1/SSLv3,256bits,ECDHE-RSA-AES256-SHA384) id 6c32_2583_bd69741e_aa02_44cb_8e79_4c7ec2213b94; Sat, 13 Jul 2019 00:00:20 -0600 Received: from DNVEXAPP1N04.corpzone.internalzone.com (10.44.48.88) by DNVEXAPP1N06.corpzone.internalzone.com (10.44.48.90) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Sat, 13 Jul 2019 00:10:58 -0600 Received: from DNVO365EDGE1.corpzone.internalzone.com (10.44.176.66) by DNVEXAPP1N04.corpzone.internalzone.com (10.44.48.88) with Microsoft SMTP Server (TLS) id 15.0.1395.4 via Frontend Transport; Sat, 13 Jul 2019 00:10:58 -0600 Received: from NAM03-CO1-obe.outbound.protection.outlook.com (10.44.176.241) by edge.mcafee.com (10.44.176.66) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Sat, 13 Jul 2019 00:10:58 -0600 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=CQJRQtPhw+HuCRkB5bMg1zCqeyqFJ+cZmm7qnv83lFYGbU/AiuZAB7jLbymbKtG4vT/ANv5wCDRXeaHdJZsA0i05yDjKduQxB5ku3Fw5RsihjxqoJ9SDiPjD62vZu2ozcAn/FTWhdU3T07PjOUK+iXcY7wC5tSKj4BVxVbSnTbKSj6OBgQzmVSQGo0JkyI4USYVLezcmSzTraD17OIubGOZBjuAeEV3aJuvzdiiD1y46NkfrrlKq138b4YsD8usnHTGzASxTcNNMH8gz4EkCZJ1Ncxb7Ob5ewq2K51bDDZBwTJd6jR5MS4UyEwWlwIgaezNW6ZoKG7A7Gn0C6Ut/wQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=DBHC5C/tnsCy+AnHEk/WjYi6LIAFWQzAjESOxJ0XUF0=; b=GWfoJa5GMhzqnKHS7b0atKQnKoU7DvYOK+dcdnD1rVdCiVKn0pdmws/6YeLmSWHhg8OrR2c7Z5GRsymiGMj8k4+g+CD8oVa8qxNyoLqQ7H7D/s/xTs1y9LkV6vbGcykDgTi4/fLEttjhhgr6jpwMpCUg8qAl43wthlzx2rTlIGWYEi/pgqOyGTHApNaXySBUuHjEZyU+zvHhHkAKSm1RgBK1QTy0R2Zqt4t2rvAciRHe+FKuxCIMBB8dait9b3NFiVvKIxQ7f4GJoeai0dLYWOtDiH2AMSEA38qBLL39l54FSV8PEVg3bgq7H/yKB82mGULVy6GmD2+orXdzNUuPQQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1;spf=pass smtp.mailfrom=mcafee.com;dmarc=pass action=none header.from=mcafee.com;dkim=pass header.d=mcafee.com;arc=none Received: from DM5PR16MB1705.namprd16.prod.outlook.com (10.172.44.147) by DM5PR16MB2325.namprd16.prod.outlook.com (52.132.142.152) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2073.10; Sat, 13 Jul 2019 06:10:55 +0000 Received: from DM5PR16MB1705.namprd16.prod.outlook.com ([fe80::570:2208:75c2:5f17]) by DM5PR16MB1705.namprd16.prod.outlook.com ([fe80::570:2208:75c2:5f17%8]) with mapi id 15.20.2052.022; Sat, 13 Jul 2019 06:10:55 +0000 From: "Konda, Tirumaleswar Reddy" To: Benjamin Kaduk CC: The IESG , "tram-chairs@ietf.org" , "draft-ietf-tram-turnbis@ietf.org" , "tram@ietf.org" , "brandon.williams@akamai.com" Thread-Topic: [tram] Benjamin Kaduk's Discuss on draft-ietf-tram-turnbis-27: (with DISCUSS and COMMENT) Thread-Index: AQHVN6sj5hqeZIdQXEa8/G2g6Mwv66bFIQEggAKxEACAAC4dEA== Date: Sat, 13 Jul 2019 06:10:55 +0000 Message-ID: References: <156282359426.15056.17118634579091500165.idtracker@ietfa.amsl.com> <20190713021429.GR16418@mit.edu> In-Reply-To: <20190713021429.GR16418@mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.3.0.16 dlp-reaction: no-action x-originating-ip: [49.37.206.28] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 01b5fca7-47f2-4091-4873-08d70758dd9a x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:DM5PR16MB2325; x-ms-traffictypediagnostic: DM5PR16MB2325: x-ms-exchange-purlcount: 6 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 00979FCB3A x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(376002)(396003)(39860400002)(366004)(136003)(346002)(13464003)(51914003)(32952001)(189003)(199004)(54094003)(66066001)(6506007)(305945005)(7736002)(53546011)(68736007)(33656002)(5024004)(8676002)(186003)(81156014)(256004)(316002)(102836004)(26005)(478600001)(966005)(81166006)(14444005)(25786009)(11346002)(6436002)(52536014)(5660300002)(446003)(54906003)(6116002)(80792005)(66446008)(229853002)(14454004)(3846002)(66476007)(64756008)(53946003)(66946007)(66556008)(7696005)(76116006)(6246003)(6916009)(76176011)(8936002)(9686003)(74316002)(4326008)(86362001)(6306002)(2906002)(476003)(30864003)(71190400001)(71200400001)(99286004)(486006)(53936002)(55016002)(2171002)(85282002)(579004); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR16MB2325; H:DM5PR16MB1705.namprd16.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: EcuSImko1w3P2Bza1gTsyxcKJHkUnBBfsAI5fVZFNwNC7GACuvyXLyPGp4DI5o8/sodOUkHUw65sABvMtBBMH3xEHmxv1VcZ4rm/ppsOIAHcMfcqB92NGqKhew+Vjblk5MRonGTBDQq/5ICOPZV9khxGgYUVUdOgJRO30B542LNxL392eRWziKxzaz+lj0CzDwPsEsesUlPz38dDJQok+ZDrxjTofWuLDRfuqw+bIeUP1NEW8jYfYCv+bdW0g94nbLTmSSWl1KpiGcF/w718u8CvJw8axJSy0jpuJf6h2a0PCm9PdVX3aOQGsHxfSZwkxD5sTkfSYuPI/9JwUV12nzGEpM5r6d0WJN8gluuZ5r8JZInLEoSIKOpm2sj9UQ4yRhHdLIgFxRpGjqSDCvLuBqwc3cCltKQeTiwEx14pmuI= MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 01b5fca7-47f2-4091-4873-08d70758dd9a X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Jul 2019 06:10:55.0925 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: TirumaleswarReddy_Konda@McAfee.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR16MB2325 X-OriginatorOrg: mcafee.com X-NAI-Spam-Flag: NO X-NAI-Spam-Level: X-NAI-Spam-Threshold: 15 X-NAI-Spam-Score: 0.3 X-NAI-Spam-Version: 2.3.0.9418 : core <6589> : inlines <7119> : streams <1827206> : uri <2867002> X-MC-Unique: YOTrHg2EPRO11j827Av29w-1 X-Mimecast-Spam-Score: 0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [tram] Benjamin Kaduk's Discuss on draft-ietf-tram-turnbis-27: (with DISCUSS and COMMENT) X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Jul 2019 06:12:21 -0000 Hi Ben, Please see inline > -----Original Message----- > From: Benjamin Kaduk > Sent: Saturday, July 13, 2019 7:45 AM > To: Konda, Tirumaleswar Reddy > Cc: The IESG ; tram-chairs@ietf.org; draft-ietf-tram- > turnbis@ietf.org; tram@ietf.org; brandon.williams@akamai.com > Subject: Re: [tram] Benjamin Kaduk's Discuss on draft-ietf-tram-turnbis-2= 7: > (with DISCUSS and COMMENT) >=20 > This email originated from outside of the organization. Do not click link= s or > open attachments unless you recognize the sender and know the content is > safe. >=20 > Hi Tiru, >=20 > On Thu, Jul 11, 2019 at 03:47:19PM +0000, Konda, Tirumaleswar Reddy wrote= : > > Hi Ben, > > > > Thanks for the detailed review. Please see inline >=20 > Sorry to have made you deduplicate with the reviews that had already come > in -- I wrote this text fairly early (on just the diff) with intent to re= turn and > tidy up, but ran out of time and had to just submit what I had. No problem, the review helped to improve the draft.=20 >=20 > > > -----Original Message----- > > > From: tram On Behalf Of Benjamin Kaduk via > > > Datatracker > > > Sent: Thursday, July 11, 2019 11:10 AM > > > To: The IESG > > > Cc: tram-chairs@ietf.org; draft-ietf-tram-turnbis@ietf.org; > > > tram@ietf.org; brandon.williams@akamai.com > > > Subject: [tram] Benjamin Kaduk's Discuss on > > > draft-ietf-tram-turnbis-27: (with DISCUSS and COMMENT) > > > > > > > > > > > > Benjamin Kaduk has entered the following ballot position for > > > draft-ietf-tram-turnbis-27: 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-turnbis/ > > > > > > > > > > > > -------------------------------------------------------------------- > > > -- > > > DISCUSS: > > > -------------------------------------------------------------------- > > > -- > > > > > > I support Roman's Discuss. > > > > I have updated the draft to address Roman's Discuss. > > > > > > > > I think I'm confused about whether REQUESTED-ADDRESS-FAMILY and > > > ADDITIONAL-ADDRESS-FAMILY are mutually exclusive. > > > > Yes, both attributes are mutually exclusive. It is discussed in Section= 7.1, > Clients MUST NOT include REQUESTED-ADDRESS-FAMILY and ADDITIONAL- > ADDRESS-FAMILY attributes in the same request. >=20 > Okay. This seems weird to me and I wouldn't object if some very blunt t= ext > was added early on about "when both IPv4 and IPv6 are desired, the > ADDITIONAL-ADDRESS-FAMILY attribute alone serves to request both > address types; otherwise the single REQUESTED-ADDRESS-FAMILY attribute > suffices", but this point clearly is not Discuss-worthy. This point is already covered in Section 5 (General Behavior) as follows: TURN, as defined in this specification, supports both IPv4 and IPv6. IPv6 s= upport in TURN includes IPv4-to-IPv6, IPv6-to-IPv6, and IPv6-to-IPv4 relayi= ng. The REQUESTED-ADDRESS-FAMILY attribute allows a client to explicitly re= quest the address type the TURN server will allocate (e.g., an IPv4-only no= de may request the TURN server to allocate an IPv6 address). The ADDITIONAL= -ADDRESS-FAMILY attribute allows a client to request the server to allocate= one IPv4 and one IPv6 relay address in a single Allocate request. This sav= es local ports on the client and reduces the number of messages sent betwee= n the client and the TURN server. >=20 > > > Does sending just the > > > "additional" one secretly mean that you want both v4 and v6? > > > > Yes, ADDITIONAL-ADDRESS-FAMILY is used for allocation of both IPv4 and > IPv6. > > > > > > > > Section 5 > > > > > > I see that the secdir reviewer asked about why it is a "SHOULD" to > > > send SOFTWARE, and only got a response that it is defined in > > > stunbis, but not about why it is recommended. There remain some > > > privacy/security considerations with it, and we should either point > > > to the stunbis security considerations or not recommend using it. > > > (FINGERPRINT is, IIRC, less interesting from a security perspective > > > as it's just about confirming that given traffic is in fact STUN and > > > not something else.) > > > > This "SHOULD" to send SOFTWARE attribute is defined in RFC5766 (As you > may know, TURN is used in the field for several years) and turnbis does n= ot > modify the behavior for backward compatibility, and to address the possib= le > threat added the following lines: > > > > SOFTWARE attribute can reveal the specific software version of the TURN > client and server to eavesdropper and it might possibly allow attacks aga= inst > vulnerable software that is known to contain security holes. If it is imp= ortant > to prevent an eavesdropper from learning the software version, TURN can > be run over (D)TLS. >=20 > (let's keep this on the secdir thread) Okay.=20 >=20 > > > > > > Section 12 > > > > > > Do we need to say anything about backwards compatibility with RFC > > > 5766 peers that use a wider range of channel IDs? > > > > Yes, added the following line: > > Note that the channel number range is not backwards compatible with > > [RFC5766], and cannot be used in environments where such compatibility > > is required. >=20 > I see now that Adam also raised this topic, and I'd like to hear his thou= ghts on > this proposed text. Since we normally don't make breaking changes in "bi= s" > documents, I'd also like to hear a bit more about what knoweldge we have = (if > any) about implementations that might be affected and are not affected. Update to the TURN channel number range is done in https://tools.ietf.org/h= tml/rfc7983#section-9.3 to distinguish multiplexed protocols, and the range= is updated in turnbis to align with RFC7983 .=20 >=20 > > > > > > Section 12.7 > > > > > > When the server receives an ICMP packet, the server processes it a= s > > > described in Section 11.5. A Data indication MUST be sent regardl= ess > > > of whether there is a channel bound to the peer that was the > > > destination of the UDP datagram that triggered the reception of th= e > > > ICMP packet. > > > > > > This MUST seems potentially in conflict with the previous discussion > > > about permissions checks in Section 11.5. > > > > Good catch, removed conflicting text from Section 12.7. > > > > > > > > Section 20 > > > > > > Looking at the > > > new nonce in the example ("obMatJos2AAABadl7W7PeDU4hKE72jda"), > and > > > noting that it starts with the nonce cookie, help me decode the > > > security feature bits. The magic prefix is "obMatJos2" so the > > > capability bits are encoded as "AAAB", which decodes to (hex) 00 00 > > > 01. But stunbis says that the bits are ordered from 0 (MSB of first > > > byte) to 23 (LSB of last byte), so this would have bit 23 set, which > > > is in contrast to the registry marking bit 0 as the password-algorith= ms > feature. Where am I messing this up? > > > > You are right, replaced with "obMatJos2gAAAadl7W7PeDU4hKE72jda" (hex) > > 80 00 00 >=20 > It's reassuring to know that I wasn't missing something obvious; thanks! Thanks for catching it :) >=20 > > > > > > I'd prefer if the examples showed more usage of MESSAGE-INTEGRITY- > > > SHA256 (especially, any from the server) and fewer MESSAGE-INTEGRITY. > > > > Sure, updated examples. > > > > > > > > > > > -------------------------------------------------------------------- > > > -- > > > COMMENT: > > > -------------------------------------------------------------------- > > > -- > > > > > > Thanks for keeping the diff from RFC 5766 relatively contained! > > > I only reviewed the diff due to time constraints, but in general > > > support reviewing the full document for internal consistency and any > > > remarks that have not aged well, especially with respect to IANA > considerations. > > > > > > Section 2 > > > > > > RFC 8174 has an updated version of the BCP 14 boilerplate text. > > > > Fixed. > > > > > > > > Section 3.1 > > > > > > I appreciate the response to the secdir review, but even the linked > > > stunbis section does not say much about which PKI's trust root is > > > expected to be used. I'm forced to assume the Web PKI but don't > > > have much grounds for that assumption. > > > > Yes, use pre-populated trust store on the endpoint to validate the > certificate path. > > > > > > > > Section 3.2 > > > > > > The secdir reviewer's comments seem to have some relevance. > > > It seems like even when the third-party authorization mechanism is > > > used, the client is still limited to "the server is authenticated > > > because it gives me the service I asked for", which is not really > > > documented anywhere yet. The long-term password mechanism at least > > > generates an HMAC integrity tag on messages from server to client, > > > which can provide some level of authentication via key confirmation. > > > > No, STURN third-party authorization provides message integrity for both > request and response messages (please see > https://tools.ietf.org/html/rfc7635#section-5). The mac_key to compute t= he > message integrity can change per call and this mechanism is better than t= he > long-term password mechanism. Note that WebRTC uses third-party > authorization mechanism. >=20 > Ah, that's reassuring to learn. Sorry for the confusion. >=20 > > > > > > Section 3.7 > > > > > > If the TURN server carrying ou= t > > > packet translation from IPv4-to-IPv6 cannot get the Don't Fragment > > > (DF) bit in the IPv4 header, it MUST reject the Allocate request w= ith > > > DONT-FRAGMENT attribute. > > > > > > nit: does "cannot get" mean something like "read the value as sent > > > on the wire" (e.g., due to implementation/API limitations)? > > > > Yes, cannot read the value as sent on wire. >=20 > I'd suggest "is unable to access the state of", but that's entirely edit= orial and > at your discretion. Thanks, updated. >=20 > > > > > > Section 6 > > > > > > o the relayed transport address or addresses; > > > [...] > > > > > > [...] > > > address. The relayed transport address MUST be unique across all > > > allocations, so it can be used to uniquely identify the allocation= . > > > > > > nit: there's maybe a singular/plural mismatch going on here, but I > > > don't have any good ideas. > > > > > > Section 7.1 > > > > > > If the client wishes to obtain one IPv6 and one IPv4 relayed > > > transport address then it includes an ADDITIONAL-ADDRESS-FAMILY > > > attribute in the request. This attribute specifies that the serve= r > > > must allocate both address types. The attribute value in the > > > ADDITIONAL-ADDRESS-FAMILY MUST be set to 0x02 (IPv6 address > family). > > > Clients MUST NOT include REQUESTED-ADDRESS-FAMILY and > ADDITIONAL- > > > ADDRESS-FAMILY attributes in the same request. [...] > > > > > > This reads like setting REQUESTED-ADDRESS-FAMILY and ADDITIONAL- > > > ADDRESS-FAMILY are mutually exclusive. Is that the correct reading? > > > > Yes. > > > > > (Naively, one might expect that the thing named "additional" > > > is applied on top of the base-level request, so I have to ask.) > > > > > > Section 7.2 > > > > > > Why do we only have a SHOULD-level requirement for authentication of > > > Allocate requests where 5766 had MUST? Could we say "may allow > > > unauthenticated requests in order to support [use case] but > > > otherwise MUST require authentication" (with better wording)? I > > > suppose this has probably been discussed ad nauseum already, so feel > > > free to point me at the archives before getting into an actual discus= sion. > > > > You missed the next line, it says the authentication of the request is > > optional to allow TURN servers provided by the local or access network > > to accept Allocation requests from new and/or guest users in the > > network who do not necessarily possess long term credentials for STUN > > authentication and its security implications are discussed in > > [RFC8155]. >=20 > I saw the next line; the current formulation also allows non-use of > authentication in other situations, which is why I suggested an alternat= e > wording. >=20 > > The WG spent several cycles discussing the downgrade of a MUST level > requirement (please see https://tools.ietf.org/html/rfc8155#section-9). >=20 > To be clear, I do not object to removing the MUST for the local-use case;= I'm > concerned with the wording of the text that, as written, also weakens the > requirement for all other cases. Got it, updated step as follows: 1. The TURN server provided by the local or access network MAY allow unauthenticated request in order to accept Allocation requests from new and/or guest users in the network who do not necessarily possess long term credentials for STUN authentication and its security implications are discussed in [RFC8155]. Otherwise, the server MUST require that the request be authenticated. If the request is authenticated, the authentication MUST be done either using the long-term credential mechanism of [I-D.ietf-tram-stunbis] or the STUN Extension for Third-Party Authorization [RFC7635] unless the client and server agree to use another mechanism through some procedure outside the scope of this document. >=20 > > > > > > 7. If the server does not support the address family requested b= y > > > the client in REQUESTED-ADDRESS-FAMILY or is disabled by loca= l > > > policy, it MUST generate an Allocate error response, and it M= UST > > > include an ERROR-CODE attribute with the 440 (Address Family = not > > > Supported) response code. [...] > > > > > > nit: "or is disabled" needs a subject. > > > > Fixed, updated text as follows: > > If the server does not support the address family requested by the clie= nt in > REQUESTED-ADDRESS-FAMILY or if the allocation of the requested address > family is disabled by local policy, it MUST generate an Allocate error re= sponse, > and it MUST include an ERROR-CODE attribute with the 440 (Address Family > not Supported) response code. >=20 > Thanks >=20 > > > 9. The server checks if the request contains an ADDITIONAL-ADDRE= SS- > > > FAMILY attribute. If yes, and the attribute value is 0x01 (I= Pv4 > > > address family), then the server rejects the request with a 4= 00 > > > (Bad Request) error. Otherwise, the server checks if it can > > > allocate relayed transport addresses of both address types. = If > > > the server cannot satisfy the request, then the server > > > rejects > > > > > > What are "both" address types? > > > > Both IPv4 and IPv6 address families. >=20 > I guess once I realize that "ADDITIONAL-ADDRESS-FAMILY" is just code for > "IPv4 and IPv6" with no other options, this doesn't look as unclear. >=20 > > > We only have the ADDITIONAL-ADDRESS- FAMILY (which contains one > > > type) and no REQUESTED-ADDRESS-FAMILY. > > > > If ADDITIONAL-ADDRESS-FAMILY is used, the server will allocate both IPv= 4 > and IPv6 relayed transport addresses. > > > > > > > > Section 8.1 > > > > > > When refreshing a dual allocation, the client includes REQUESTED- > > > ADDRESS-FAMILY attribute indicating the address family type that > > > should be refreshed. If no REQUESTED-ADDRESS-FAMILY is included > then > > > the request should be treated as applying to all current allocatio= ns. > > > The client MUST only include family types it previously allocated = and > > > has not yet deleted. [...] > > > > > > I'm a bit confused about "only include family types" plural; I > > > thought there could only be at most one REQUESTED-ADDRESS-FAMILY > and > > > that it would only indicate one family type. So how could there be > > > multiple types getting included by the client? > > > > Good catch, replaced "types" with "type" >=20 > (It needs a definite article, then for "only include the family type") Done.=20 Cheers, -Tiru >=20 > > > > > > Section 11.5 > > > > > > [check that "type and code" is valid in both ICMPv4 and v6] > > > > Yes, it is valid. >=20 > Sorry; that was supposed to be a note to myself! > But yes, luckily for me this is not the point of difference between ICMPv= 4 > and ICMPv6 that I was vaguely remembering. >=20 > > > > > > Section 12 > > > > > > Reserved values may be used in the future by other protocols. Whe= n > > > the client uses channel binding, it MUST comply with the > > > demultiplexing scheme discussed above. > > > > > > "channel binding" is a term of art in the security world; is this > > > usage intended to roughly mean "channel multiplexing"? > > > (I do see that the subsections are talking about the specific > > > ChannelBind request, so I assume so; I just want to double check.) > > > > Yes, a channel binding is created or refreshed using a ChannelBind > transaction (Please see Section 12.1). >=20 > Great. Well, not great that there's a collision of jargon, but it's way = too late to > do anything about, now. >=20 > > > > > > > > > Section 13 > > > > > > The descriptions below have two parts: a preferred behavior and an > > > alternate behavior. The server SHOULD implement the preferred > > > behavior. Otherwise, the server MUST implement the alternate > > > behavior and MUST NOT do anything else for the reasons detailed in > > > [RFC7915]. [...] > > > > > > RFC 5766 had this split on a per-field basis, but this text suggests > > > that if the preferred behavior is not possible for a given field, > > > then the alternate behavior is used for the entire packet. > > > I note that section 14 does retain the "for a particular field" > > > language for UDP-to-UDP relaying, as do section 15 for TCP-to-UDP > > > relaying and section 16 for UDP-to-TCP relaying. > > > > Good point, fixed text as follows: > > Otherwise, if that is not possible for a particular field, the server M= UST > implement the alternate behavior and MUST NOT do anything else for the > reasons detailed in [RFC7915]. > > > > > > > > Section 13.2 > > > > > > Is this flow label text consistent with both the inbound and > > > outbound translation directions (specifically, using relayed/peer > > > addresses in the 5- tuple to identify the flow)? > > > > > > If the incoming packet did not include a Fragment header and th= e > > > outgoing packet size exceeds the outgoing link's MTU, the TURN > > > server drops the outgoing packet and send an ICMP message of ty= pe > > > 2 code 0 ("Packet too big") to the sender of the incoming packe= t. > > > If the packet is being sent to the peer, the TURN server reduc= es > > > the MTU reported in the ICMP message by 48 bytes to allow room = for > > > the overhead of a Data indication. > > > > > > (nit?) "If the packet is being send to the peer" seems to > > > grammatically refer to the outgoing packet that would exceed link > > > MTU, as opposed to the ICMP message being generated. But I think > > > it's supposed to refer to the ICMP message being generated, which has > not yet been referred to as a "packet" > > > in this text. > > > > Suresh raised the same comment, fixed text as follows: > > If the ICMPv6 packet ("Packet too big") is being sent to the peer, the = TURN > server reduces the MTU reported in the ICMP message by 48 bytes to allow > room for the overhead of a Data indication. >=20 > Great; t hanks >=20 > > > > > > Section 13.3 > > > > > > [Same comment about ICMP packet generation/grammar] > > > > Fixed text as follows: > > If the ICMPv4 packet (Destination Unreachable (Type 3) with Code 4) is > being sent to the peer, the TURN server SHOULD reduce the MTU reported > in the ICMP message by 48 bytes to allow room for the overhead of a Data > indication. > > > > > > > > Section 15 > > > > > > Maybe note that SIP and WebRTC are the primary consumers of TURN? > > > > Yes, it is mentioned in several places in the document that WebRTC and = SIP > use TURN. >=20 > Okay; my fault for only looking at the diff, probably. >=20 > > > > > > Even if both > > > TCP-AO and UDP authentication would be used between TURN client > and > > > server, it would not change the end-to-end security properties of = the > > > UDP payload being relayed. [...] > > > > > > I wonder if we even need to say "UDP" in "payload being relayed". > > > > Replaced "UDP" with "application" > > > > > > > > Section 16 > > > > > > Fragmentation > > > > > > Preferred Behavior: Any fragmented packets are reassembled in t= he > > > server and then forwarded to the client over the TCP connection= . > > > ICMP messages resulting from the UDP datagrams sent to the peer > > > MUST be forwarded to the client using TURN's mechanism for > > > relevant ICMP types and codes. > > > > > > As in section 12.7, I wonder if this MUST could be seen as > > > overriding other logic for ICMP handling. > > > > Modified text for clarity as follows: > > > > ICMP messages resulting from the UDP datagrams sent to the peer are > > processed by the server as described in Section 11.5 and forwarded to > > the client using TURN's mechanism for relevant ICMP types and codes. >=20 > Thanks >=20 > > > > > > Section 21.16 > > > > > > I agree with the secdir reviewer that there is at least potential > > > for username and realm to be sensitive. > > > > I proposed to add the following text: > > > > If the TURN client and server use the STUN Extension for Third-Party > > Authorization [RFC7635] (for example it is used in WebRTC), the > > username does not reveal the real user's identity, the USERNAME > > attribute carries an ephemeral and unique key identifier. If the > > TURN client and server use the STUN long-term credential mechanism > > and the username reveals the real user's identity, the client needs > > to use (D)TLS transport between the client and the server or use the > > USERHASH attribute instead of the USERNAME attribute to anonynmize > > the username. > > > > If the TURN client and server use the STUN long-term credential > > mechanism and realm information is privacy sensitive, TURN can be ru= n > > over (D)TLS. As a reminder, STUN Extension for Third-Party > > Authorization does not use realm. >=20 > Excellent; thank you! >=20 > > > > > > Section 21.4 > > > > > > Do we need references for Teredo and/or 6to4? > > > > https://tools.ietf.org/html/rfc6156 did not add references to Teredo an= d > 6to4. >=20 > Okay; just wanted to check. >=20 > > > > > > Section 22 > > > > > > The codepoints for the STUN error codes defined in this specificat= ion > > > are listed in Section 19. [IANA is requested to update the refere= nce > > > from [RFC5766] to RFC-to-be for the STUN error codes listed in > > > Section 19.] > > > > > > (I think some of them are from RFC 6156 as well as from 5766.) > > > > Yes, added RFC6156. > > > > > > > > Section 23 > > > > > > It seems prudent to revisit these listed IAB Considerations for > > > whether the situation has changed in the past ten years (though I > > > don't have any specific points that I would change). > > > > > > Section 25 > > > > > > (nit) are these really "updates" to RFC 6156 so much as > > > incorporating its content wholesale into the core TURN specification? > > > > Yes, several sections in RFC6156 are updated. >=20 > Okay, thanks. >=20 > -Ben From nobody Fri Jul 12 23:34:26 2019 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 ACEC21200BA for ; Fri, 12 Jul 2019 23:34:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4 X-Spam-Level: X-Spam-Status: No, score=-4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=mcafee.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uzDPjFTIDcwY for ; Fri, 12 Jul 2019 23:34:20 -0700 (PDT) Received: from us-smtp-delivery-210.mimecast.com (us-smtp-delivery-210.mimecast.com [63.128.21.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 11E2112008F for ; Fri, 12 Jul 2019 23:34:19 -0700 (PDT) X-NAI-Header: Modified by McAfee Email Gateway (5500) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mcafee.com; s=s_mcafee; t=1562999012; h=ARC-Seal: ARC-Message-Signature:ARC-Authentication-Results: From:To:CC:Subject:Thread-Topic:Thread-Index: Date:Message-ID:References:In-Reply-To:Accept-Language: Content-Language:X-MS-Has-Attach:X-MS-TNEF-Correlator: dlp-product:dlp-version:dlp-reaction:authentication-results: x-originating-ip:x-ms-publictraffictype:x-ms-office365-filtering-correlation-id: x-microsoft-antispam:x-ms-traffictypediagnostic: x-ms-exchange-purlcount:x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers:x-forefront-prvs: x-forefront-antispam-report:received-spf:x-ms-exchange-senderadcheck: x-microsoft-antispam-message-info:Content-Type: Content-Transfer-Encoding:MIME-Version:X-MS-Exchange-CrossTenant-Network-Message-Id: X-MS-Exchange-CrossTenant-originalarrivaltime: X-MS-Exchange-CrossTenant-fromentityheader: X-MS-Exchange-CrossTenant-id:X-MS-Exchange-CrossTenant-mailboxtype: X-MS-Exchange-CrossTenant-userprincipalname: X-MS-Exchange-Transport-CrossTenantHeadersStamped: X-OriginatorOrg:X-NAI-Spam-Flag:X-NAI-Spam-Level: X-NAI-Spam-Threshold:X-NAI-Spam-Score:X-NAI-Spam-Version; bh=HdHIBLUvxV9nBwHx9il9njs1v1KMliJoOD6aSk JnyRs=; b=oK29Fhqcgr7+eWrAvP7JXj6Xdpufr7qxmGOMT3OQ O07Hgg6OBBry7NizRcLGR5insLZKiBGb97pHE0VBoTEJ1bf5hM Y5bWSXHeKuwYRDT90YJ1i6u2f2VjkG1QxTp2XicOKhnxkL7mVh /hvVEAy0sjZ2mP3esZVyWp6i6XtpnkU= Received: from DNVWSMAILOUT1.mcafee.com (dnvwsmailout1.mcafee.com [161.69.31.173]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-64-f9efpBi6MVS1ut7ZN3N54A-1; Sat, 13 Jul 2019 02:34:11 -0400 Received: from DNVEXAPP1N06.corpzone.internalzone.com (DNVEXAPP1N06.corpzone.internalzone.com [10.44.48.90]) by DNVWSMAILOUT1.mcafee.com with smtp (TLS: TLSv1/SSLv3,256bits,ECDHE-RSA-AES256-SHA384) id 6c32_3f4c_f84f959d_71c3_41ce_bc1b_9db7e5c5de58; Sat, 13 Jul 2019 00:23:30 -0600 Received: from DNVEXAPP1N05.corpzone.internalzone.com (10.44.48.89) by DNVEXAPP1N06.corpzone.internalzone.com (10.44.48.90) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Sat, 13 Jul 2019 00:34:07 -0600 Received: from DNVO365EDGE1.corpzone.internalzone.com (10.44.176.66) by DNVEXAPP1N05.corpzone.internalzone.com (10.44.48.89) with Microsoft SMTP Server (TLS) id 15.0.1395.4 via Frontend Transport; Sat, 13 Jul 2019 00:34:06 -0600 Received: from NAM03-CO1-obe.outbound.protection.outlook.com (10.44.176.240) by edge.mcafee.com (10.44.176.66) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Sat, 13 Jul 2019 00:34:06 -0600 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=EXw85X756G8NCkL76pr70n1cFh5ej4kQcFFUXS0d+L5ZOunudwJn09OS8dY6HG6A8KF4mo+HEcsKtItzTEBK7bZJQB0i0qQ5KhwzhWCzKrB+hFn2bO/QngtTmJr2DNkiZLw/LYc4Vr8jVYn53JXBkZKdnkjccuQcj4URuAEJNDLL/I807vFN4vji1MLIeuoKIm9bhMDbTOUFGDoDIt47WDvju/fZAv9uM+DYwKfkhB0ys/CenumcyoI/t0d1nh+noIsX2RDvHkIiI5JyQc2L5NI1LyWYe+WRltS6xVB9oSgO7i2P2qYYJV8be65eLOwnMEUuTAKY31nK3DgecpIKUw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=HdHIBLUvxV9nBwHx9il9njs1v1KMliJoOD6aSkJnyRs=; b=EIN+TWcgw3lYylIyNMR5x2FV8XUq+L5k4Vvqp0bgKbv4JwqdCKvR0LgLFeNq/qvXyGr9mgiuenbP7G/qzkZuB6zAHJ1mG9njfI57Nj2hYeO4E+1XlkfD7Y2dlM21LYpY1sfsLd5W1TAvz+5XwhIcIwPZULMu8XcgUWWZZ6heWDUnTQa/IiJXscPRRZxMZ3NuCRt8hRPagjpjHzR2E1dCFsPfO+GbVnd/5eey0CWZADmIis9fRDImaVk3Tz2pW3IkoSf13lzzpp502CcoqCKH+tRl36O9Rp9q/7b36nuZsb2DMybKsCV0Paq+TfW3BUUTjdlDseJ0+sQoLsThW4oPpg== ARC-Authentication-Results: i=1; mx.microsoft.com 1;spf=pass smtp.mailfrom=mcafee.com;dmarc=pass action=none header.from=mcafee.com;dkim=pass header.d=mcafee.com;arc=none Received: from DM5PR16MB1705.namprd16.prod.outlook.com (10.172.44.147) by DM5SPR00MB110.namprd16.prod.outlook.com (10.174.247.150) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2073.14; Sat, 13 Jul 2019 06:34:03 +0000 Received: from DM5PR16MB1705.namprd16.prod.outlook.com ([fe80::570:2208:75c2:5f17]) by DM5PR16MB1705.namprd16.prod.outlook.com ([fe80::570:2208:75c2:5f17%8]) with mapi id 15.20.2052.022; Sat, 13 Jul 2019 06:34:03 +0000 From: "Konda, Tirumaleswar Reddy" To: Benjamin Kaduk CC: Christopher Wood , "secdir@ietf.org" , "draft-ietf-tram-turnbis.all@ietf.org" , "ietf@ietf.org" , "tram@ietf.org" Thread-Topic: [tram] Secdir last call review of draft-ietf-tram-turnbis-27 Thread-Index: AQHVNQMAJeymFhPVnEO1ky4wx5pqrabAcMBwgAJPmICAAKIlAIAEbccAgABJSTA= Date: Sat, 13 Jul 2019 06:34:03 +0000 Message-ID: References: <156253133809.549.13521510978566357744@ietfa.amsl.com> <20190709203044.GD24351@kduck.mit.edu> <20190713014901.GQ16418@mit.edu> In-Reply-To: <20190713014901.GQ16418@mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.3.0.16 dlp-reaction: no-action x-originating-ip: [49.37.206.28] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 283f07b6-b761-4696-6c1b-08d7075c1936 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600148)(711020)(4605104)(1401327)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7193020); SRVR:DM5SPR00MB110; x-ms-traffictypediagnostic: DM5SPR00MB110: x-ms-exchange-purlcount: 10 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 00979FCB3A x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(366004)(376002)(346002)(396003)(136003)(39860400002)(13464003)(32952001)(199004)(189003)(51914003)(6246003)(55016002)(7736002)(2171002)(6306002)(9686003)(305945005)(66066001)(81156014)(81166006)(5024004)(53936002)(53546011)(74316002)(33656002)(256004)(14444005)(54906003)(30864003)(478600001)(3846002)(476003)(486006)(102836004)(6506007)(25786009)(99286004)(7696005)(8936002)(11346002)(6116002)(76176011)(2906002)(5660300002)(6436002)(68736007)(66946007)(229853002)(316002)(86362001)(52536014)(8676002)(186003)(80792005)(4326008)(446003)(6916009)(966005)(66556008)(66446008)(76116006)(71200400001)(71190400001)(64756008)(66476007)(14454004)(26005)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5SPR00MB110; H:DM5PR16MB1705.namprd16.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: fP6KleNox3jXAqkgTODruftalyd/njDKzBh9tSWHLoUWm+Hbu92F5BcyBQ704zg3R58t+5e748r51E60Esq4O3khvmhh40+hqbH9PlPmSGz9U94Zpj3o6TiWD43wUYGTk5QWmLo/IDWIuuLXwevOg8WZdnPlGt6xLGGZ0l21KN4t5LrS7Q0FFX9GwgYkhVbiRyLKyTMEt8F75LVF/4UDOHDzn2vGJBlU1RJw4PDOt0miRLEOe0f3w5EJmdAqxuBRuQrl3GpF5ESs6oaUS5PgKmTxs2wTi9C5WrqHpnN9rpPnYEtgMP4hEhIlh8krO8uwlpBL5JWWDryd9WNgNbe/RdSAYRudPcWx0/gSfC1O1gJvzTuXsArUMij7SJ/oHHfl4bu6kRPjx59xDQCF1z4uDBx1dhZ7FkEsTzLFfhw44n4= MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 283f07b6-b761-4696-6c1b-08d7075c1936 X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Jul 2019 06:34:03.5795 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: TirumaleswarReddy_Konda@McAfee.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5SPR00MB110 X-OriginatorOrg: mcafee.com X-NAI-Spam-Flag: NO X-NAI-Spam-Level: X-NAI-Spam-Threshold: 15 X-NAI-Spam-Score: 0.1 X-NAI-Spam-Version: 2.3.0.9418 : core <6589> : inlines <7119> : streams <1827208> : uri <2867009> X-MC-Unique: f9efpBi6MVS1ut7ZN3N54A-1 X-Mimecast-Spam-Score: 0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Archived-At: Subject: Re: [tram] Secdir last call review of draft-ietf-tram-turnbis-27 X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Jul 2019 06:34:26 -0000 SGkgQmVuLA0KDQpQbGVhc2Ugc2VlIGlubGluZQ0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t LS0tDQo+IEZyb206IEJlbmphbWluIEthZHVrIDxrYWR1a0BtaXQuZWR1Pg0KPiBTZW50OiBTYXR1 cmRheSwgSnVseSAxMywgMjAxOSA3OjE5IEFNDQo+IFRvOiBLb25kYSwgVGlydW1hbGVzd2FyIFJl ZGR5IDxUaXJ1bWFsZXN3YXJSZWRkeV9Lb25kYUBNY0FmZWUuY29tPg0KPiBDYzogQ2hyaXN0b3Bo ZXIgV29vZCA8Y2F3QGhlYXBpbmdiaXRzLm5ldD47IHNlY2RpckBpZXRmLm9yZzsgZHJhZnQtaWV0 Zi0NCj4gdHJhbS10dXJuYmlzLmFsbEBpZXRmLm9yZzsgaWV0ZkBpZXRmLm9yZzsgdHJhbUBpZXRm Lm9yZw0KPiBTdWJqZWN0OiBSZTogW3RyYW1dIFNlY2RpciBsYXN0IGNhbGwgcmV2aWV3IG9mIGRy YWZ0LWlldGYtdHJhbS10dXJuYmlzLTI3DQo+IA0KPiBUaGlzIGVtYWlsIG9yaWdpbmF0ZWQgZnJv bSBvdXRzaWRlIG9mIHRoZSBvcmdhbml6YXRpb24uIERvIG5vdCBjbGljayBsaW5rcyBvcg0KPiBv cGVuIGF0dGFjaG1lbnRzIHVubGVzcyB5b3UgcmVjb2duaXplIHRoZSBzZW5kZXIgYW5kIGtub3cg dGhlIGNvbnRlbnQgaXMNCj4gc2FmZS4NCj4gDQo+IEhpIFRpcnUsDQo+IA0KPiBUaGFua3MgZm9y IGFsbCB0aGUgdXBkYXRlcywgaW5jbHVkaW5nIGZ1cnRoZXIgZG93bnRocmVhZCB3aXRoIENocmlz Lg0KPiBKdXN0IGEgY291cGxlIG5vdGVzIGlubGluZS4uLg0KPiANCj4gT24gV2VkLCBKdWwgMTAs IDIwMTkgYXQgMTI6NDA6MzdQTSArMDAwMCwgS29uZGEsIFRpcnVtYWxlc3dhciBSZWRkeSB3cm90 ZToNCj4gPiBIaSBCZW4sDQo+ID4NCj4gPiBUaGFua3MgZm9yIHRoZSByZXZpZXcuIFBsZWFzZSBz ZWUgaW5saW5lLg0KPiA+DQo+ID4gPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+ID4g RnJvbTogQmVuamFtaW4gS2FkdWsgPGthZHVrQG1pdC5lZHU+DQo+ID4gPiBTZW50OiBXZWRuZXNk YXksIEp1bHkgMTAsIDIwMTkgMjowMSBBTQ0KPiA+ID4gVG86IEtvbmRhLCBUaXJ1bWFsZXN3YXIg UmVkZHkNCj4gPFRpcnVtYWxlc3dhclJlZGR5X0tvbmRhQE1jQWZlZS5jb20+DQo+ID4gPiBDYzog Q2hyaXN0b3BoZXIgV29vZCA8Y2F3QGhlYXBpbmdiaXRzLm5ldD47IHNlY2RpckBpZXRmLm9yZzsN Cj4gPiA+IGRyYWZ0LWlldGYtIHRyYW0tdHVybmJpcy5hbGxAaWV0Zi5vcmc7IGlldGZAaWV0Zi5v cmc7IHRyYW1AaWV0Zi5vcmcNCj4gPiA+IFN1YmplY3Q6IFJlOiBbdHJhbV0gU2VjZGlyIGxhc3Qg Y2FsbCByZXZpZXcgb2YNCj4gPiA+IGRyYWZ0LWlldGYtdHJhbS10dXJuYmlzLTI3DQo+ID4gPg0K PiA+ID4gVGhpcyBlbWFpbCBvcmlnaW5hdGVkIGZyb20gb3V0c2lkZSBvZiB0aGUgb3JnYW5pemF0 aW9uLiBEbyBub3QgY2xpY2sNCj4gPiA+IGxpbmtzIG9yIG9wZW4gYXR0YWNobWVudHMgdW5sZXNz IHlvdSByZWNvZ25pemUgdGhlIHNlbmRlciBhbmQga25vdw0KPiA+ID4gdGhlIGNvbnRlbnQgaXMg c2FmZS4NCj4gPiA+DQo+ID4gPiBDaHJpcywgdGhhbmtzIGZvciB0aGUgcmV2aWV3LiAgU29tZSBt b3JlIHF1ZXN0aW9ucy9jb21tZW50cyBpbmxpbmUNCj4gPiA+IGFzIEkgcHJlcGFyZSB0byBiYWxs b3Qgb24gdGhpcyBkb2N1bWVudC4uLg0KPiA+ID4NCj4gPiA+IE9uIE1vbiwgSnVsIDA4LCAyMDE5 IGF0IDAyOjE4OjI2UE0gKzAwMDAsIEtvbmRhLCBUaXJ1bWFsZXN3YXIgUmVkZHkNCj4gd3JvdGU6 DQo+ID4gPiA+IEhpIENocmlzdG9waGVyLA0KPiA+ID4gPg0KPiA+ID4gPiBUaGFua3MgZm9yIHRo ZSBkZXRhaWxlZCByZXZpZXcuIFBsZWFzZSBzZWUgaW5saW5lDQo+ID4gPiA+DQo+ID4gPiA+ID4g LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPiA+ID4gPiBGcm9tOiB0cmFtIDx0cmFtLWJv dW5jZXNAaWV0Zi5vcmc+IE9uIEJlaGFsZiBPZiBDaHJpc3RvcGhlcg0KPiBXb29kDQo+ID4gPiA+ ID4gdmlhIERhdGF0cmFja2VyDQo+ID4gPiA+ID4gU2VudDogTW9uZGF5LCBKdWx5IDgsIDIwMTkg MTo1OSBBTQ0KPiA+ID4gPiA+IFRvOiBzZWNkaXJAaWV0Zi5vcmcNCj4gPiA+ID4gPiBDYzogZHJh ZnQtaWV0Zi10cmFtLXR1cm5iaXMuYWxsQGlldGYub3JnOyBpZXRmQGlldGYub3JnOw0KPiA+ID4g PiA+IHRyYW1AaWV0Zi5vcmcNCj4gPiA+ID4gPiBTdWJqZWN0OiBbdHJhbV0gU2VjZGlyIGxhc3Qg Y2FsbCByZXZpZXcgb2YNCj4gPiA+ID4gPiBkcmFmdC1pZXRmLXRyYW0tdHVybmJpcy0yNw0KPiA+ ID4gPiA+DQo+ID4gPiA+ID4gVGhpcyBlbWFpbCBvcmlnaW5hdGVkIGZyb20gb3V0c2lkZSBvZiB0 aGUgb3JnYW5pemF0aW9uLiBEbyBub3QNCj4gPiA+ID4gPiBjbGljayBsaW5rcyBvciBvcGVuIGF0 dGFjaG1lbnRzIHVubGVzcyB5b3UgcmVjb2duaXplIHRoZSBzZW5kZXINCj4gPiA+ID4gPiBhbmQg a25vdyB0aGUgY29udGVudCBpcyBzYWZlLg0KPiA+ID4gPiA+DQo+ID4gPiA+ID4gUmV2aWV3ZXI6 IENocmlzdG9waGVyIFdvb2QNCj4gPiA+ID4gPiBSZXZpZXcgcmVzdWx0OiBIYXMgTml0cw0KPiA+ ID4gPiA+DQo+ID4gPiA+ID4gSSBoYXZlIHJldmlld2VkIHRoaXMgZG9jdW1lbnQgYXMgcGFydCBv ZiB0aGUgc2VjdXJpdHkNCj4gPiA+ID4gPiBkaXJlY3RvcmF0ZSdzIG9uZ29pbmcgZWZmb3J0IHRv IHJldmlldyBhbGwgSUVURiBkb2N1bWVudHMgYmVpbmcNCj4gPiA+ID4gPiBwcm9jZXNzZWQgYnkg dGhlIElFU0cuIFRoZXNlIGNvbW1lbnRzIHdlcmUgd3JpdHRlbiBwcmltYXJpbHkgZm9yDQo+ID4g PiA+ID4gdGhlIGJlbmVmaXQgb2YgdGhlIHNlY3VyaXR5IGFyZWEgZGlyZWN0b3JzLg0KPiA+ID4g PiA+IERvY3VtZW50IGVkaXRvcnMgYW5kIFdHIGNoYWlycyBzaG91bGQgdHJlYXQgdGhlc2UgY29t bWVudHMganVzdA0KPiA+ID4gPiA+IGxpa2UgYW55IG90aGVyIGxhc3QgY2FsbCBjb21tZW50cy4N Cj4gPiA+ID4gPg0KPiA+ID4gPiA+IFRoZSBzdW1tYXJ5IG9mIHRoZSByZXZpZXcgaXM6IFJlYWR5 IHdpdGggbml0cw0KPiA+ID4gPiA+DQo+ID4gPiA+ID4gU3VtbWFyeToNCj4gPiA+ID4gPg0KPiA+ ID4gPiA+IEluIGdlbmVyYWwsIHRoZSBkb2N1bWVudCBpcyB3ZWxsIHdyaXR0ZW4gYW5kIGNsZWFy bHkgZm91bmRlZCBpbg0KPiA+ID4gPiA+IG9wZXJhdGlvbmFsIGV4cGVyaWVuY2UuIFRoZSBzZWN1 cml0eSBjb25zaWRlcmF0aW9ucyBhcmUNCj4gPiA+ID4gPiB0aG9yb3VnaCwgcHJvdmlkaW5nIGV4 YW1wbGVzIHdoZXJlIG5lY2Vzc2FyeSB0byBoaWdobGlnaHQNCj4gPiA+ID4gPiBpbXBvcnRhbnQg cHJvYmxlbSBhcmVhcy4gSXQgZHJhd3MgYSBjbGVhciBsaW5lIGJldHdlZW4gaXNzdWVzDQo+ID4g PiA+ID4gYmVzdCBhZGRyZXNzZWQgYnkgYXBwbGljYXRpb25zIG91dHNpZGUgb2YgVFVSTiwgYW5k IHByb3ZpZGVzDQo+ID4gPiA+ID4gc3VmZmljaWVudCBkZXRhaWwgZm9yIHRob3NlIGlzc3VlcyBp biBzY29wZS4gTXkgY29tbWVudHMgYW5kDQo+ID4gPiA+ID4gcXVlc3Rpb25zIGFyZSwgaG9wZWZ1 bGx5LCBtb3N0bHkNCj4gPiA+IG5pdHMuDQo+ID4gPiA+ID4NCj4gPiA+ID4gPiBHZW5lcmFsIGNv bW1lbnRzOg0KPiA+ID4gPiA+DQo+ID4gPiA+ID4gLSBUVVJOIHNlcnZlciBhdXRoZW50aWNhdGlv biBpbiB0aGUgY2FzZSBvZiAoRClUTFMgaXMNCj4gPiA+ID4gPiB1bmRlcnNwZWNpZmllZC4gQXJl IHNlcnZlcnMgYXNzdW1lZCB0byBoYXZlIFdlYlBLSSBjZXJ0aWZpY2F0ZXMsDQo+ID4gPiA+ID4g T09CLXRydXN0ZWQgcmF3IHB1YmxpYyBrZXlzLCBvciBzb21ldGhpbmcgZWxzZT8gSXMgdGhlcmUg YQ0KPiA+ID4gPiA+IHByZWZlcnJlZA0KPiA+ID4gZm9ybSBvZiBhdXRoZW50aWNhdGlvbj8NCj4g PiA+ID4gPiBSZWxhdGVkbHksIGluDQo+ID4gPiA+ID4gU2VjdGlvbiAzLjIsIGhvdyBkbyBjbGll bnRzIGF1dGhlbnRpY2F0ZSB0aGUgc2VydmVyPw0KPiA+ID4gPg0KPiA+ID4gPiBTZXJ2ZXIgY2Vy dGlmaWNhdGUgdmFsaWRhdGlvbiBpcyBkaXNjdXNzZWQgaW4NCj4gPiA+ID4gaHR0cHM6Ly90b29s cy5pZXRmLm9yZy9odG1sL2RyYWZ0LQ0KPiA+ID4gaWV0Zi10cmFtLXN0dW5iaXMtMjEjc2VjdGlv bi02LjIuMy4gIEkgaGF2ZSBtb2RpZmllZCB0aGUgdGV4dCBhcyBmb2xsb3dzOg0KPiA+ID4gPg0K PiA+ID4gPiBJZiAoRClUTFMgdHJhbnNwb3J0IGlzIHVzZWQgYmV0d2VlbiB0aGUgVFVSTiBjbGll bnQgYW5kIHRoZSBUVVJODQo+ID4gPiA+IHNlcnZlciwgdGhlIGNpcGhlciBzdWl0ZXMsIHNlcnZl ciBjZXJ0aWZpY2F0ZSB2YWxpZGF0aW9uIGFuZA0KPiA+ID4gPiBhdXRoZW50aWNhdGlvbiBvZiBU VVJOIHNlcnZlciBhcmUgZGlzY3Vzc2VkIGluIFNlY3Rpb24gNi4yLjMgb2YNCj4gPiA+ID4gW0kt RC5pZXRmLXRyYW0tc3R1bmJpc10NCj4gPiA+DQo+ID4gPiBUaGF0IGhlbHBzLCBidXQgaXQgd291 bGQgc3RpbGwgYmUgbmljZSB0byBnaXZlIHNvbWUgaW5kaWNhdGlvbiBvZg0KPiA+ID4gd2hhdCBj ZXJ0aWZpY2F0ZQ0KPiA+ID4gUEtJKHMpIGFyZSBleHBlY3RlZCB0byBiZSB1c2VkLiAgSXMgYW55 dGhpbmcgb3RoZXIgdGhhbiB0aGUgV2ViIFBLSQ0KPiA+ID4gdW5kZXIgY29uc2lkZXJhdGlvbiA/ DQo+ID4NCj4gPiBOby4gUGxlYXNlIHNlZSBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJh ZnQtaWV0Zi10cmFtLXN0dW5iaXMtDQo+IDIxI3NlY3Rpb24tNi4yLjMsIEl0IGRpc2N1c3NlcyB0 byB2ZXJpZnkgdGhlIGNlcnRpZmljYXRlIHBhdGggYW5kIGlkZW50aXR5IG9mIHRoZQ0KPiBzZXJ2 ZXIuDQo+ID4NCj4gPiA+DQo+ID4gPiA+ID4tIFNlY3Rpb24gMy43OiBDb3VsZA0KPiA+ID4gPiA+ IFRVUk4gc2VydmVycyBub3QgY2h1bmsgZGF0YSBmcm9tIHN0cmVhbS1vcmllbnRlZCB0cmFuc3Bv cnRzIChUQ1ANCj4gPiA+ID4gPm9yDQo+ID4gPiA+ID5UTFMpICB0byBhIHByZWZlcnJlZCBNVFUg c2l6ZSBiZWZvcmUgcmVsYXlpbmcgdG8gcGVlcnM/DQo+ID4gPiA+ID4gU3BlY2lmaWNhbGx5LCB0 aGVyZSBhcmUgbGlrZWx5DQo+ID4gPiA+ID4gc29tZSBjYXNlcyB3aGVyZWluIHRoZSBzZXJ2ZXIg Y291bGQgZGVhbCB3aXRoIHRoZSBjbGllbnQgZGF0YQ0KPiA+ID4gPiA+bWVzc2FnZXMgIGxhcmdl ciB0aGFuIHRoZSByZWNvbW1lbmRlZCA1MDBCIGxpbWl0LiBPbiB0aGF0IHBvaW50LA0KPiA+ID4g PiA+c2hvdWxkIHNlcnZlcnMgZXZlbiAgYWNjZXB0IGRhdGEgbGFyZ2VyIHRoYW4gdGhpcyByZWNv bW1lbmRlZCBzaXplID8NCj4gPiA+ID4gPi0NCj4gPiA+ID4NCj4gPiA+ID4gUGxlYXNlIHNlZQ0K PiA+ID4gPiBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi10cmFtLXR1cm5i aXMtMjcjc2VjdGlvbi0xNQ0KPiA+ID4gPiBmb3IgVENQLXRvLVVEUCByZWxheS4gSWYgdGhlIFBN VFUgaXMgbm90IGtub3duLCBhbmQgb24gbGVnYWN5IG9yDQo+ID4gPiA+IG90aGVyd2lzZSB1bnVz dWFsIG5ldHdvcmtzLA0KPiA+ID4gPiA1MDAgYnl0ZSBsaW1pdCBmb3IgYXBwbGljYXRpb24gZGF0 YSBpcyByZWNvbW1lbmRlZC4NCj4gPiA+ID4NCj4gPiA+ID4gPiBTZWN0aW9uIDMuOTogVGhlcmUg bWF5IGJlDQo+ID4gPiA+ID4gY2FzZXMgd2hlcmUgdGhlIFRMUyBjb25uZWN0aW9uIHBvc3QgVENQ IGNvbm5lY3Rpb24gZXN0YWJsaXNobWVudA0KPiA+ID4gPiA+IGZhaWxzLiBJdCB3b3VsZCB0aGVy ZWZvcmUgc2VlbXMgcHJ1ZGVudCB0byBub3QgZGVjbGFyZSB2aWN0b3J5DQo+ID4gPiA+ID4gZm9y IG9uZSBjb25uZWN0aW9uIG92ZXIgdGhlIG90aGVyIHVudGlsIFRMUyBjb25uZWN0cywgdG9vLiAt DQo+ID4gPiA+DQo+ID4gPiA+IEFncmVlZCwgRXJpYyAoYXMgcGFydCBvZiBJU0VHIHJldmlldykg c3VnZ2VzdGVkIHRvIHNpbXBsaWZ5IHRoZQ0KPiA+ID4gPiB0ZXh0LiBJIGhhdmUNCj4gPiA+IHVw ZGF0ZWQgdGhlIHRleHQgYXMgZm9sbG93czoNCj4gPiA+ID4NCj4gPiA+ID4gICAgbyAgRm9yIFRD UCBvciBUTFMtb3Zlci1UQ1AsIHRoZSByZXN1bHRzIG9mIHRoZSBIYXBweSBFeWViYWxscw0KPiA+ ID4gPiAgICAgICBwcm9jZWR1cmUgW1JGQzgzMDVdIGFyZSB1c2VkIGJ5IHRoZSBUVVJOIGNsaWVu dCBmb3Igc2VuZGluZyBpdHMNCj4gPiA+ID4gICAgICAgVFVSTiBtZXNzYWdlcyB0byB0aGUgc2Vy dmVyLg0KPiA+ID4NCj4gPiA+IElzIHRoZSBlZGl0b3IncyBjb3B5IGF2YWlsYWJsZSBmb3Igdmll d2luZyBzb21ld2hlcmU/ICBJdCB3b3VsZCBiZQ0KPiA+ID4gZ29vZCB0byBzZWUgdGhpcyAoYW5k IG90aGVyIGNoYW5nZXMpIGluIGNvbnRleHQuDQo+ID4NCj4gPiBZZXMsIFBsZWFzZSBzZWUgaHR0 cHM6Ly9naXRodWIuY29tL3RpcmVkZHkyL1RVUk5iaXMNCj4gPg0KPiA+ID4NCj4gPiA+ID4gPiBT ZWN0aW9uIDMgY291bGQgYmVuZWZpdCBmcm9tIGENCj4gPiA+ID4gPiBzdWJzZWN0aW9uIG9uIHJl cGxheXMgYW5kIHRoZSBub25jZSByb2xlLiBJbiBwYXJ0aWN1bGFyLCBhcw0KPiA+ID4gPiA+IGxh dGVyIGRpc2N1c3NlZCBpbiB0aGUgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMsIHNvbWUgb2YgdGhl c2UNCj4gPiA+ID4gPiBhdHRhY2tzIGFyZSBub3QgbmV3IHRvIFRVUk4gYW5kIHNob3VsZCB0aGVy ZWZvcmUgYmUgZGVhbHQgd2l0aA0KPiA+ID4gPiA+IGJ5IHRoZSBhcHBsaWNhdGlvbiBwcm90b2Nv bCAoU1JUUCkuIFRoaXMgc2VjdGlvbiBtaWdodCBhbHNvDQo+ID4gPiA+ID4gZGVzY3JpYmUgbm9u Y2Ugcm90YXRpb24gcG9saWNpZXMgd2l0aCBtb3JlIHNwZWNpZmljaXR5LCBhcyB0aGlzDQo+ID4g PiA+ID4gaXMgdW5kZXJzcGVjaWZpZWQgaW4gdGhlDQo+ID4gPiBkb2N1bWVudC4NCj4gPiA+ID4N Cj4gPiA+ID4gSXQgaXMgZGlzY3Vzc2VkIGluIFNlY3Rpb24gNSBpbiB0aGUgc3BlY2lmaWNhdGlv biwgdGhlIHNlcnZlcg0KPiA+ID4gPiBzaG91bGQgZXhwaXJlIHRoZQ0KPiA+ID4gbm9uY2UgYXQg bGVhc3Qgb25jZSBldmVyeSBob3VyIGR1cmluZyB0aGUgbGlmZXRpbWUgb2YgdGhlIGFsbG9jYXRp b24uDQo+ID4gPiA+DQo+ID4gPiA+ID4tIFNlY3Rpb24gMyBjb3VsZCBhbHNvIGJlbmVmaXQgZnJv bSAgZGlzY3Vzc2lvbiBhYm91dCBjbGVhcnRleHQNCj4gPiA+ID4gPnZlcnN1cyBlbmNyeXB0aW9u IHRyYW5zcG9ydHMgYmV0d2VlbiBjbGllbnRzIGFuZCAgc2VydmVycy4NCj4gPiA+ID4NCj4gPiA+ ID4gSXQgaXMgZGlzY3Vzc2VkIGluDQo+ID4gPiA+IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRt bC9kcmFmdC1pZXRmLXRyYW0tdHVybmJpcy0NCj4gPiA+IDI3I3NlY3Rpb24tMjEuMS42Lg0KPiA+ ID4NCj4gPiA+IFRoZXJlJ3Mgbm90IG11Y2ggZGlzY3Vzc2lvbiBhYm91dCBwb3RlbnRpYWwgaW5m b3JtYXRpb24gIGxlYWthZ2UgdmlhDQo+ID4gPiAoZS5nLikgVVNFUk5BTUUvVVNFUkhBU0gsIGFu ZCByZWFsbHkganVzdCBhIGNsYWltIHRoYXQgdGhlIHBlZXINCj4gPiA+IGFkZHJlc3MgaXMgdGhl ICJwcmltYXJ5IHByb3RvY29sIGNvbnRlbnQiLg0KPiA+DQo+ID4gQWdyZWVkLCBhZGRlZCB0aGUg Zm9sbG93aW5nIHBhcmFncmFwaCA6DQo+ID4NCj4gPiBJZiB0aGUgVFVSTiBjbGllbnQgYW5kIHNl cnZlciB1c2UgdGhlIFNUVU4gRXh0ZW5zaW9uIGZvciBUaGlyZC1QYXJ0eQ0KPiA+IEF1dGhvcml6 YXRpb24gW1JGQzc2MzVdLCB0aGUgdXNlcm5hbWUgZG9lcyBub3QgcmV2ZWFsIHRoZSByZWFsIHVz ZXIncw0KPiBpZGVudGl0eSwgdGhlIFVTRVJOQU1FIGF0dHJpYnV0ZSBjYXJyaWVzIGFuIGVwaGVt ZXJhbCBhbmQgdW5pcXVlIGtleQ0KPiBpZGVudGlmaWVyLCBhbmQgdGhlIGtleSBpZGVudGlmaWVy IGNhbiBjaGFuZ2UgcGVyIGNhbGwuDQo+ID4gSWYgdGhlIFRVUk4gY2xpZW50IGFuZCBzZXJ2ZXIg dXNlIHRoZSBTVFVOIGxvbmctdGVybSBjcmVkZW50aWFsDQo+ID4gbWVjaGFuaXNtIGFuZCB0aGUg dXNlcm5hbWUgcmV2ZWFscyB0aGUgcmVhbCB1c2VyJ3MgaWRlbnRpdHksIHRoZQ0KPiA+IGNsaWVu dCBuZWVkIHRvIGVpdGhlciB1c2UgKEQpVExTIHRyYW5zcG9ydCBiZXR3ZWVuIHRoZSBjbGllbnQg YW5kIHRoZQ0KPiBzZXJ2ZXIgb3IgdXNlIHRoZSBVU0VSSEFTSCBhdHRyaWJ1dGUgaW5zdGVhZCBv ZiB0aGUgVVNFUk5BTUUgYXR0cmlidXRlIHRvDQo+IGFub255bm1pemUgdGhlIHVzZXJuYW1lLg0K PiA+DQo+ID4gPg0KPiA+ID4gPiA+IEVuY3J5cHRpbmcgdGhlIG5vbmNlLCB1c2VybmFtZSwgcmVh bG0sIGV0Yy4sIGFtb25nIG90aGVyIHRoaW5ncywNCj4gPiA+ID4gPiBoYXMgb2J2aW91cyBiZW5l Zml0cy4gLSBXaHkgYXJlIFNPRlRXQVJFIGFuZCBGSU5HRVJQUklOVA0KPiA+ID4gPiA+IGF0dHJp YnV0ZXMgcmVjb21tZW5kZWQ/ICBJdCBzZWVtcyBsaWtlIGNsaWVudHMgc2hvdWxkIGJlDQo+ID4g PiA+ID4gZGlzY291cmFnZWQgZnJvbSBzZW5kaW5nIHRoZXNlIGlmIGFueXRoaW5nLCBlc3BlY2lh bGx5IGlmIG5vdA0KPiA+ID4gPiA+IHVzZWQgdG8gbWFrZSBhbGxvY2F0aW9uIGRlY2lzaW9ucyBv biB0aGUgc2VydmVyLg0KPiA+ID4gPg0KPiA+ID4gPiBVc2VybmFtZSBtYXkgbm90IGJlIHRoZSB1 c2VyIGlkZW50aXR5LCBQbGVhc2Ugc2VlDQo+ID4gPiBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0 bWwvcmZjNzYzNSksIEl0IGNvdWxkIGJlIGFuIGVwaGVtZXJhbCBhbmQNCj4gPiA+IHVuaXF1ZSBr ZXkgaWRlbnRpZmllci4gRnVydGhlciwgdXNlcm5hbWUgY2FuIGJlIGFub255bWl6ZWQgKHBsZWFz ZQ0KPiA+ID4gc2VlIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXRyYW0t c3R1bmJpcy0yMSNzZWN0aW9uLTE0LjQpLg0KPiA+ID4gPiBTT0ZUV0FSRSBhbmQgRklOR0VSUFJJ TlQgYXR0cmlidXRlcyBhcmUgZGVmaW5lZCBpbiB0aGUgU1RVTg0KPiA+ID4gc3BlY2lmaWNhdGlv biwgc2VlIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXRyYW0tc3R1bmJp cy0yMS4NCj4gPiA+DQo+ID4gPiBUaGVzZSBtZWNoYW5pc21zICBhcmUgcGFydGlhbCBtaXRpZ2F0 aW9ucyBidXQgY2FuIHN0aWxsIGJlDQo+ID4gPiBzdXNjZXB0aWJsZSB0byBjcm9zcy0gY29ubmVj dGlvbiBjb3JyZWxhdGlvbiBhdHRhY2tzLg0KPiA+DQo+ID4gVGhlIHVzZSBvZiBGSU5HRVJQUklO VCBpcyBub3QgbWFuZGF0b3J5LCB0aGUgVFVSTiBjbGllbnQgYW5kIHNlcnZlciBtYXkNCj4gaW5j bHVkZSB0aGUgRklOR0VSUFJJTlQgYXR0cmlidXRlLiAgTm90ZSB0aGF0IElDRQ0KPiAoaHR0cHM6 Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzg0NDUpIG1hbmRhdGVzIHRoZSB1c2Ugb2YgRklOR0VS UFJJTlQNCj4gYXR0cmlidXRlLiBBZGRlZCB0aGUgZm9sbG93aW5nIGxpbmUgZm9yIFNPRlRXQVJF IGF0dHJpYnV0ZSAoVFVSTmJpcyBpcyB1c2luZw0KPiB0aGUgc2FtZSBiZWhhdmlvciBkZWZpbmVk IGluIFJGQzU3NjYgdG8gdXNlIFNPRlRXQVJFIGF0dHJpYnV0ZSkgIDoNCj4gPg0KPiA+IFNPRldB VEUgYXR0cmlidXRlIGNhbiByZXZlYWwgdGhlIHNwZWNpZmljIHNvZnR3YXJlIHZlcnNpb24gb2Yg dGhlIFRVUk4NCj4gY2xpZW50IGFuZCBzZXJ2ZXIgdG8gZWF2ZXNkcm9wcGVyIGFuZCBpdCBtaWdo dCBwb3NzaWJseSBhbGxvdyBhdHRhY2tzIGFnYWluc3QNCj4gdnVsbmVyYWJsZSBzb2Z0d2FyZSB0 aGF0IGlzIGtub3duIHRvIGNvbnRhaW4gc2VjdXJpdHkgaG9sZXMuIElmIGl0IGlzIGltcG9ydGFu dA0KPiB0byBwcmV2ZW50IGFuIGVhdmVzZHJvcHBlciBmcm9tIGxlYXJuaW5nIHRoZSBzb2Z0d2Fy ZSB2ZXJzaW9uLCBUVVJOIGNhbg0KPiBiZSBydW4gb3ZlciAoRClUTFMuDQo+IA0KPiBUaGUgbGF0 ZXIgc3VnZ2VzdGlvbiB3YXM6DQo+IA0KPiAlIFdlIHdhbnQgdG8gYXZvaWQgZG91YmxlIGVuY3J5 cHRpb24gb2YgYXBwbGljYXRpb24gZGF0YSwgYW5kIFNPRlRXQVJFDQo+IGF0dHJpYnV0ZSBoYXMN Cj4gJSBiZWVuIHNlbnQgaW4gY2xlYXIgdGV4dCBhbGwgdGhlc2UgeWVhcnMgaW4gdGhlIGZpZWxk LCBhbmQgbm8gYXR0YWNrIGhhcyBiZWVuDQo+ICUgZGV0ZWN0ZWQgYmFzZWQgb24gU09GVFdBUkUg ZmllbGQuIEkgY2FuIHJldmlzZSB0aGUgdGV4dCBhcyBmb2xsb3dzOg0KPiAlIElmIHRoZSBzb2Z0 d2FyZSB2ZXJzaW9uIGlzIGtub3duIHRvIGNvbnRhaW4gc2VjdXJpdHkgdnVsbmVyYWJpbGl0aWVz LCBUVVJODQo+IFNIT1VMRCBiZSAlIHJ1biBvdmVyIChEKVRMUyB0byBwcmV2ZW50IGxlYWtpbmcg dGhlIFNPRlRXQVJFIGF0dHJpYnV0ZSBpbg0KPiBjbGVhciB0ZXh0Lg0KPiANCj4gSSB0aGluayBz b21lIG9mIHRoZSBjb25jZXJuIGlzIG92ZXIgdGhlIHJpc2sgb2Ygc28tY2FsbGVkICJ6ZXJvLWRh eSINCj4gZXhwbG9pdHMsIHdoZXJlIHRoZSBhdHRhY2tlciBrbm93cyBvZiBhIHZlcnNpb24tc3Bl Y2lmaWMgZmxhdyBidXQgdGhlDQo+IGRlZmVuZGVycyBkbyBub3QgKGFuZCBoYXZlIHplcm8gZGF5 cyBub3RpY2UgdG8gcHJvdGVjdCBhZ2FpbnN0IGl0KS4gIFN1Y2ggYQ0KPiBjb25jZXJuIHdvdWxk IHN1Z2dlc3QgdG8gYXZvaWQgc2VuZGluZyBTT0ZUV0FSRSBvdmVyIGVuZW5jcnlwdGVkDQo+IHRy YW5zcG9ydCByZWdhcmRsZXNzIG9mIHRoZSBzdGF0ZSBvZiBrbm93biB2dWxuZXJhYmlsaXRpZXMs IGJ1dCBpbiB0aGUgZW5kIGl0IGlzDQo+IGEgbWF0dGVyIG9mIGxvY2FsIHBvbGljeS4NCg0KQWdy ZWVkLCBmaXhpbmcgYW5kIHJlbGVhc2luZyBhIHBhdGNoIHdpbGwgdGFrZSBzb21lIHRpbWUgYW5k IG1lYW53aGlsZSB0aGUgcG9saWN5IGNhbiBiZSBtb2RpZmllZCB0byB1c2UgdGVtcG9yYXJpbHkg dXNlIChEKVRMUy4gIEkgY2FuIGFkZCB0aGUgZm9sbG93aW5nIHRleHQ6DQpJZiB6ZXJvLWRheSB2 dWxuZXJhYmlsaXRpZXMgYXJlIGRldGVjdGVkIGluIHRoZSBzb2Z0d2FyZSB2ZXJzaW9uLCB0aGUg ZW5kcG9pbnQgcG9saWN5IGNhbiBiZSBtb2RpZmllZCB0byBtYW5kYXRlIHRoZSB1c2Ugb2YgKEQp VExTIHRpbGwgdGhlIHBhdGNoIGlzIGluIHBsYWNlIHRvIGZpeCB0aGUgZmxhdy4NCg0KPiANCj4g DQo+ID4NCj4gPiA+DQo+ID4gPiA+IC0gU2VjdGlvbiA1OiBXaGVuIHNlcnZlcnMgcmVjZWl2ZSBk YXRhIHRoYXQgZXhjZWVkcyBhbg0KPiA+ID4gPiBhbGxvY2F0aW9u4oCZcw0KPiA+ID4gPiA+IGJh bmR3aWR0aCBxdW90YSwgc2VydmVycyBzaWxlbnRseSBkaXNjYXJkIHRoaXMgZGF0YS4gVGhpcyBt ZWFucw0KPiA+ID4gPiA+IHRoZXJl4oCZcyBubyBhbGxvY2F0aW9uLWJhc2VkIGZsb3cgY29udHJv bCBtZWNoYW5pc20gYmV0d2Vlbg0KPiA+ID4gPiA+IGNsaWVudCBhbmQgc2VydmVyIGJleW9uZCB3 aGF04oCZcyBwcm92aWRlZCBieSB0aGUgdHJhbnNwb3J0IHByb3RvY29sLA0KPiByaWdodD8NCj4g PiA+ID4NCj4gPiA+ID4gWWVzLCBVRFAgZG9lcyBub3QgaW5jbHVkZSBhIGNvbmdlc3Rpb24gY29u dHJvbCBtZWNoYW5pc20uDQo+ID4gPiA+DQo+ID4gPiA+ID4gVGhpcyBzZWVtcyBmaW5lLCB0aG91 Z2gNCj4gPiA+ID4gPiBwZXJoYXBzIHNvbWUgZGlzY3Vzc2lvbiBvZiB3aHkgdGhpcyBkZXNpZ24g ZGVjaXNpb24gd2FzIG1hZGUNCj4gPiA+ID4gPiB3b3VsZCBiZSBoZWxwZnVsLiBGb3IgZXhhbXBs ZSwgSSBjb3VsZCBpbWFnaW5lIGV4cGxpY2l0IHNpZ25hbHMNCj4gPiA+ID4gPiBmcm9tIHNlcnZl cnMgdG8gY2xpZW50cyB0aGF0IGluZGljYXRlIHNlcnZlciBzdGF0ZSB3b3VsZCByZXZlYWwNCj4g PiA+ID4gPiBpbmZvcm1hdGlvbiBhYm91dCBvdGhlciBhbGxvY2F0aW9ucyBvbiB0aGUgc2VydmVy LCB3aGljaCBtaWdodA0KPiA+ID4gPiA+IGJlIHByb2JsZW1hdGljLiAtDQo+ID4gPiA+DQo+ID4g PiA+IFRoZSBlcnJvcnMgNDg2IChBbGxvY2F0aW9uIFF1b3RhIEV4Y2VlZGVkKSBvciA1MDggKElu c3VmZmljaWVudA0KPiA+ID4gPiBDYXBhY2l0eSkNCj4gPiA+IGRvIG5vdCByZXZlYWwgaW5mb3Jt YXRpb24gb2Ygd2hpY2ggb3RoZXIgdXNlcnMgYXJlIHVzaW5nIHRoZSBUVVJOIHNlcnZlci4NCj4g PiA+DQo+ID4gPiBBdCBsZWFzdCB0aGUgbGF0dGVyIHNlZW1zIHRvIGdpdmUgc29tZSBpbmRpY2F0 aW9uIHRoYXQgbWFueSBvdGhlcg0KPiA+ID4gdXNlcnMgYXJlIHVzaW5nIHRoZSBzZXJ2ZXIgYXQg dGhlICB0aW1lIChzbyB0aGF0IGl0J3Mgb3ZlcmxvYWRlZCksDQo+ID4gPiB0aG91Z2ggbm90IGlu Zm9ybWF0aW9uIGFib3V0ICp3aGljaCogdXNlcnMgdGhhdCBpcy4NCj4gPg0KPiA+IFllcywgc2lt aWxhciB0byA1MDMgSFRUUCBlcnJvciByZXNwb25zZS4NCj4gPg0KPiA+ID4NCj4gPiA+ID4gPiBT ZWN0aW9uIDcuMiBzdWdnZXN0cyB0aGF0DQo+ID4gPiA+ID4gc2VydmVycyBjYW4gcmVkaXJlY3Qg Y2xpZW50IGFsbG9jYXRpb24gcmVxdWVzdHMgdG8gb3RoZXIgc2VydmVycy4NCj4gPiA+ID4gPiBD YW4gdGhpcyBjcmVhdGUgYSBsb29wLCB3aGVyZWluIHR3byBUVVJOIHNlcnZlcnMgcmVkaXJlY3Qg dG8gb25lDQo+IGFub3RoZXI/DQo+ID4gPiA+DQo+ID4gPiA+IFRoZSBjbGllbnQgZGV0ZWN0IGFu ZCBzdG9wIHRoZSBsb29wLCBpdCBpcyBzaW1pbGFyIHRvIEhUVFAgcmVkaXJlY3Rpb24uDQo+ID4g Pg0KPiA+ID4gV2hlcmUgaXMgdGhpcyBzcGVjaWZpZWQ/DQo+ID4NCj4gPiBJdCBpcyBzcGVjaWZp ZWQgaW4gdGhlIGxhc3QgcGFyYWdyYXBoIG9mDQo+ID4gaHR0cHM6Ly90b29scy5pZXRmLm9yZy9o dG1sL2RyYWZ0LWlldGYtdHJhbS1zdHVuYmlzLTIxI3NlY3Rpb24tMTANCj4gPg0KPiA+IDxzbmlw Pg0KPiA+IElmIHRoZSBjbGllbnQgaGFzIGJlZW4gcmVkaXJlY3RlZCB0byBhIHNlcnZlciB0byB3 aGljaCBpdCBoYXMgYWxyZWFkeQ0KPiA+IHNlbnQgdGhpcyByZXF1ZXN0IHdpdGhpbiB0aGUgbGFz dCBmaXZlIG1pbnV0ZXMsIGl0IE1VU1QgaWdub3JlIHRoZQ0KPiA+IHJlZGlyZWN0aW9uIGFuZCBj b25zaWRlciB0aGUgdHJhbnNhY3Rpb24gdG8gaGF2ZSBmYWlsZWQuICBUaGlzDQo+ID4gcHJldmVu dHMgaW5maW5pdGUgcGluZy1wb25naW5nIGJldHdlZW4gc2VydmVycyBpbiBjYXNlIG9mIHJlZGly ZWN0aW9uDQo+ID4gbG9vcHMuDQo+ID4gPC9zbmlwPg0KPiANCj4gVGhhbmtzIGZvciB0aGUgcG9p bnRlcjsgYXMgeW91IHNhdyBpbiBteSBiYWxsb3QgcG9zaXRpb24gSSB3YXMgcXVpdGUgcHJlc3Nl ZA0KPiBmb3IgdGltZSB0aGlzIHdlZWsgYW5kIG9ubHkgd2FzIGFibGUgdG8gbG9vayBhdCB0aGUg ZGlmZi4NCg0KTm8gcHJvYmxlbSwgdGhhbmtzIGZvciBoZWxwLg0KDQpDaGVlcnMsDQotVGlydQ0K DQo+IA0KPiAtQmVuDQoNCg== From nobody Sun Jul 14 23:33:12 2019 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 C46AB1200B8 for ; Sun, 14 Jul 2019 23:33:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4 X-Spam-Level: X-Spam-Status: No, score=-4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=mcafee.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 34j5qdPY2UqX for ; Sun, 14 Jul 2019 23:33:03 -0700 (PDT) Received: from us-smtp-delivery-210.mimecast.com (us-smtp-delivery-210.mimecast.com [63.128.21.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A0F541200B9 for ; Sun, 14 Jul 2019 23:33:01 -0700 (PDT) X-NAI-Header: Modified by McAfee Email Gateway (5500) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mcafee.com; s=s_mcafee; t=1563171635; h=ARC-Seal: ARC-Message-Signature:ARC-Authentication-Results: From:To:CC:Subject:Thread-Topic:Thread-Index: Date:Message-ID:References:In-Reply-To:Accept-Language: Content-Language:X-MS-Has-Attach:X-MS-TNEF-Correlator: dlp-product:dlp-version:dlp-reaction:authentication-results: x-originating-ip:x-ms-publictraffictype:x-ms-office365-filtering-correlation-id: x-microsoft-antispam:x-ms-traffictypediagnostic: x-ms-exchange-purlcount:x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers:x-forefront-prvs: x-forefront-antispam-report:received-spf:x-ms-exchange-senderadcheck: x-microsoft-antispam-message-info:Content-Type: Content-Transfer-Encoding:MIME-Version:X-MS-Exchange-CrossTenant-Network-Message-Id: X-MS-Exchange-CrossTenant-originalarrivaltime: X-MS-Exchange-CrossTenant-fromentityheader: X-MS-Exchange-CrossTenant-id:X-MS-Exchange-CrossTenant-mailboxtype: X-MS-Exchange-CrossTenant-userprincipalname: X-MS-Exchange-Transport-CrossTenantHeadersStamped: X-OriginatorOrg:X-NAI-Spam-Flag:X-NAI-Spam-Level: X-NAI-Spam-Threshold:X-NAI-Spam-Score:X-NAI-Spam-Version; bh=bHK5ML+noDpF6hAUmJln7Pwwf5QC0cQs5yBcjw IJCC4=; b=c4c32M0u42ceeSVLO158XLThUzNn6nnzsziJTcrA yewRal7jgCoqyWOxalM+gJ8XDS936yjoMvrJjFg1wEONGG770X CHIe0wiFf556suKsV3r/jhCv9hL0EdiH06+fhs8wu1yHIrt8De YNGwDKzPc1aNxJrXhhkJdZc8cJkPKJE= Received: from DNVWSMAILOUT1.mcafee.com (dnvwsmailout1.mcafee.com [161.69.31.173]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-339-m9Q_bAKJOWq4OzOd0FCufg-1; Mon, 15 Jul 2019 02:31:23 -0400 Received: from DNVEXAPP1N05.corpzone.internalzone.com (unknown [10.44.48.89]) by DNVWSMAILOUT1.mcafee.com with smtp (TLS: TLSv1/SSLv3,256bits,ECDHE-RSA-AES256-SHA384) id 6809_17fc_a3547743_c57a_45ba_b7f0_0069ba2d9e52; Mon, 15 Jul 2019 00:20:34 -0600 Received: from DNVEXAPP1N05.corpzone.internalzone.com (10.44.48.89) by DNVEXAPP1N05.corpzone.internalzone.com (10.44.48.89) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Mon, 15 Jul 2019 00:31:03 -0600 Received: from DNVO365EDGE1.corpzone.internalzone.com (10.44.176.66) by DNVEXAPP1N05.corpzone.internalzone.com (10.44.48.89) with Microsoft SMTP Server (TLS) id 15.0.1395.4 via Frontend Transport; Mon, 15 Jul 2019 00:31:03 -0600 Received: from NAM03-BY2-obe.outbound.protection.outlook.com (10.44.176.240) by edge.mcafee.com (10.44.176.66) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Mon, 15 Jul 2019 00:31:02 -0600 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=oTn8yfZjthX6Rh68Um7Nmj52SEo4DGEAPoGEm0zWr36Q3tjbPSFzCVWhuLjpDTtyFpmOE2t+5nc7SCvu3ddMpN5b9wIkYwSuPB3xuBJcS1IQ99Vnj8VpXvUoasVBQ1wCgwnlRHZgKQGJYWX5nb711V6JVZZKA5rHsgZZ5rW8yzWFGbTD0NVGU9DA1kw4pyErnNQnDyUDjSJCEyFEHeWN4P5N1SENHKaDubHRBfEXIoO6o6PuiDb+K4kisWbODIj4sv4PuFJxtU4wKKklyG8OzqHAjSKyYHB/oxyOyG/GHyirc6pBhFnL/KLTYiOMmhl1ulwgp27rkjoCk8OIf+GP4A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=bHK5ML+noDpF6hAUmJln7Pwwf5QC0cQs5yBcjwIJCC4=; b=i0eqs1VK2OJ8UuisZj4dXLGjbmN/T/1NoICMZz68AoPGfBjBwqZyJ5kI24cU6Zil0xhGv371IPfm2ijsnZzhDBNIPZfbXrPpkDxZiUn0M0k9nfbLa1slp0jNF7Jt8sA+BUZVgftgynRvKDX3hBbqdYSahcMMxS5Kn6UBvBTjW8Hs6aaQ8CluAo0B7Eec8OTbRiDVIOM4W+2K3VZzdg+npmy/7H6DCXZWGRn6UJB0vfKJVO9ZI9Vh73tEKeLtu7HteS8fFxVAZax1p4ahZAlSIvpO9pKJ9KA99Ql2xsCw+r2L5hPmLx/el3jKIsu54Dime+2yQe0zahEm+wYLQcVVmA== ARC-Authentication-Results: i=1; mx.microsoft.com 1;spf=pass smtp.mailfrom=mcafee.com;dmarc=pass action=none header.from=mcafee.com;dkim=pass header.d=mcafee.com;arc=none Received: from DM5PR16MB1705.namprd16.prod.outlook.com (10.172.44.147) by DM5PR16MB2405.namprd16.prod.outlook.com (52.132.143.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2073.14; Mon, 15 Jul 2019 06:31:01 +0000 Received: from DM5PR16MB1705.namprd16.prod.outlook.com ([fe80::570:2208:75c2:5f17]) by DM5PR16MB1705.namprd16.prod.outlook.com ([fe80::570:2208:75c2:5f17%8]) with mapi id 15.20.2073.012; Mon, 15 Jul 2019 06:31:01 +0000 From: "Konda, Tirumaleswar Reddy" To: =?utf-8?B?TWlyamEgS8O8aGxld2luZA==?= , The IESG CC: "tram-chairs@ietf.org" , "draft-ietf-tram-turnbis@ietf.org" , "tram@ietf.org" , "brandon.williams@akamai.com" Thread-Topic: =?utf-8?B?W3RyYW1dIE1pcmphIEvDvGhsZXdpbmQncyBEaXNjdXNzIG9uIGRyYWZ0LWll?= =?utf-8?Q?tf-tram-turnbis-27:_(with_DISCUSS_and_COMMENT)?= Thread-Index: AQHVNzftWkN2G8olS0aOBDqJ1prLPKbG+S0g Date: Mon, 15 Jul 2019 06:31:00 +0000 Message-ID: References: <156277411459.15353.13243689830942672102.idtracker@ietfa.amsl.com> In-Reply-To: <156277411459.15353.13243689830942672102.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.3.0.16 dlp-reaction: no-action x-originating-ip: [103.245.47.20] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 4380a40a-5ef7-4f87-c176-08d708ee0126 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600148)(711020)(4605104)(1401327)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7193020); SRVR:DM5PR16MB2405; x-ms-traffictypediagnostic: DM5PR16MB2405: x-ms-exchange-purlcount: 5 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 00997889E7 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(376002)(346002)(136003)(366004)(39860400002)(396003)(189003)(199004)(51914003)(76094002)(32952001)(13464003)(71190400001)(3846002)(71200400001)(6116002)(33656002)(80792005)(55016002)(446003)(6306002)(6246003)(8936002)(81156014)(6436002)(81166006)(9686003)(256004)(53936002)(14444005)(86362001)(229853002)(5024004)(66574012)(7736002)(305945005)(74316002)(186003)(26005)(2906002)(6506007)(52536014)(102836004)(76176011)(53546011)(66066001)(25786009)(54906003)(966005)(5660300002)(99286004)(316002)(68736007)(110136005)(4326008)(76116006)(14454004)(478600001)(476003)(11346002)(66476007)(66946007)(7696005)(66556008)(66446008)(64756008)(224303003)(486006)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR16MB2405; H:DM5PR16MB1705.namprd16.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: 8qTsa5FY3zsD9pYYgpKQZ6icb/y+xM8ze01ntb8fWHcHtAylJJIANlOFcejpqNqqMd5hl+/77DEp+e+QY87K0w1dSW59xh0FCYmNh5RFSMmwby/KcgaieEIYit/OLVTTh+Y5oHSPQeW7p20yZfmqZRhb3t9g1V1roYTpeFFk5Z3wRfKXduTHoHHrYLUFvklWmj2XlrA4T3qmzqW6wNm6v5DNFKGB0qNmJ7rcPxStvP6zDuorGL9x9zaECZyrnxYcm3OgX/i7DwKbgs8OmVA5v+JmQPgoin0uFGUIoTTRUXkb2Cu9ce+LkjhmmRdtL0cHi2tdYuI4ps6Ji+tOk5Ek5xJmLm/1o7FCvoctw+ooE5njuqDVvuHCtBWGy1rpY7ave2z+YSCTWyAmykgkyuNTN3++MHBTgrGiJ+FNhVOJdBY= MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 4380a40a-5ef7-4f87-c176-08d708ee0126 X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Jul 2019 06:31:00.9889 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: TirumaleswarReddy_Konda@McAfee.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR16MB2405 X-OriginatorOrg: mcafee.com X-NAI-Spam-Flag: NO X-NAI-Spam-Level: X-NAI-Spam-Threshold: 15 X-NAI-Spam-Score: 0.2 X-NAI-Spam-Version: 2.3.0.9418 : core <6589> : inlines <7119> : streams <1827399> : uri <2867733> X-MC-Unique: m9Q_bAKJOWq4OzOd0FCufg-1 X-Mimecast-Spam-Score: 0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Archived-At: Subject: Re: [tram] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf-?= =?utf-8?q?tram-turnbis-27=3A_=28with_DISCUSS_and_COMMENT=29?= X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.29 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, 15 Jul 2019 06:33:05 -0000 SGkgTWlyamEsDQoNClRoYW5rcyBmb3IgdGhlIHJldmlldy4gUGxlYXNlIHNlZSBpbmxpbmUNCg0K PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiB0cmFtIDx0cmFtLWJvdW5jZXNA aWV0Zi5vcmc+IE9uIEJlaGFsZiBPZiBNaXJqYSBLw7xobGV3aW5kIHZpYQ0KPiBEYXRhdHJhY2tl cg0KPiBTZW50OiBXZWRuZXNkYXksIEp1bHkgMTAsIDIwMTkgOToyNSBQTQ0KPiBUbzogVGhlIElF U0cgPGllc2dAaWV0Zi5vcmc+DQo+IENjOiB0cmFtLWNoYWlyc0BpZXRmLm9yZzsgZHJhZnQtaWV0 Zi10cmFtLXR1cm5iaXNAaWV0Zi5vcmc7IHRyYW1AaWV0Zi5vcmc7DQo+IGJyYW5kb24ud2lsbGlh bXNAYWthbWFpLmNvbQ0KPiBTdWJqZWN0OiBbdHJhbV0gTWlyamEgS8O8aGxld2luZCdzIERpc2N1 c3Mgb24gZHJhZnQtaWV0Zi10cmFtLXR1cm5iaXMtMjc6ICh3aXRoDQo+IERJU0NVU1MgYW5kIENP TU1FTlQpDQo+IA0KPiBUaGlzIGVtYWlsIG9yaWdpbmF0ZWQgZnJvbSBvdXRzaWRlIG9mIHRoZSBv cmdhbml6YXRpb24uIERvIG5vdCBjbGljayBsaW5rcyBvcg0KPiBvcGVuIGF0dGFjaG1lbnRzIHVu bGVzcyB5b3UgcmVjb2duaXplIHRoZSBzZW5kZXIgYW5kIGtub3cgdGhlIGNvbnRlbnQgaXMNCj4g c2FmZS4NCj4gDQo+IE1pcmphIEvDvGhsZXdpbmQgaGFzIGVudGVyZWQgdGhlIGZvbGxvd2luZyBi YWxsb3QgcG9zaXRpb24gZm9yDQo+IGRyYWZ0LWlldGYtdHJhbS10dXJuYmlzLTI3OiBEaXNjdXNz DQo+IA0KPiBXaGVuIHJlc3BvbmRpbmcsIHBsZWFzZSBrZWVwIHRoZSBzdWJqZWN0IGxpbmUgaW50 YWN0IGFuZCByZXBseSB0byBhbGwgZW1haWwNCj4gYWRkcmVzc2VzIGluY2x1ZGVkIGluIHRoZSBU byBhbmQgQ0MgbGluZXMuIChGZWVsIGZyZWUgdG8gY3V0IHRoaXMgaW50cm9kdWN0b3J5DQo+IHBh cmFncmFwaCwgaG93ZXZlci4pDQo+IA0KPiANCj4gUGxlYXNlIHJlZmVyIHRvIGh0dHBzOi8vd3d3 LmlldGYub3JnL2llc2cvc3RhdGVtZW50L2Rpc2N1c3MtY3JpdGVyaWEuaHRtbA0KPiBmb3IgbW9y ZSBpbmZvcm1hdGlvbiBhYm91dCBJRVNHIERJU0NVU1MgYW5kIENPTU1FTlQgcG9zaXRpb25zLg0K PiANCj4gDQo+IFRoZSBkb2N1bWVudCwgYWxvbmcgd2l0aCBvdGhlciBiYWxsb3QgcG9zaXRpb25z LCBjYW4gYmUgZm91bmQgaGVyZToNCj4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2Mv ZHJhZnQtaWV0Zi10cmFtLXR1cm5iaXMvDQo+IA0KPiANCj4gDQo+IC0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4g RElTQ1VTUzoNCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiANCj4gT25lIHF1aWNrIGRpc2N1c3Npb24gd2hp Y2ggcHJvYmFibHkgaXMgb25seSBhbiBvdmVyc2lnaHQgYW5kIHRoZXJlZm9yZQ0KPiBzaG91bGQg YmUgZWFzeSBnb3QgZml4Og0KPiANCj4gSSdtIGJpdCBjb25mdXNlZCBhYm91dCB0aGUgcmVxdWly ZW1lbnQgb24gdXNpbmcgYXV0aGVudGljYXRpb24uIFRoaXMgZHJhZnQNCj4gc2F5cyBpbiBzZWN0 aW9uIDUgKGFzIFJGQzU3NjYgZG9lcyk6DQo+IA0KPiAiVGhlIHNlcnZlciBNVVNUIGRlbWFuZCB0 aGF0IGFsbCByZXF1ZXN0cw0KPiAgICBmcm9tIHRoZSBjbGllbnQgYmUgYXV0aGVudGljYXRlZCB1 c2luZyB0aGlzIG1lY2hhbmlzbSwgb3IgdGhhdCBhDQo+ICAgIGVxdWFsbHkgc3Ryb25nIG9yIHN0 cm9uZ2VyIG1lY2hhbmlzbSBmb3IgY2xpZW50IGF1dGhlbnRpY2F0aW9uIGlzDQo+ICAgIHVzZWQu Ig0KPiANCj4gSG93ZXZlciwgUkZDIDgxNTUgd2hpY2ggaXMgZXZlbiBub3cgY2l0ZWQgaW4gdGhp cyBkcmFmdCwgdXBkYXRlcyBSRkM1NzY2DQo+IGFuZCByZWxheGVzIHRoaXMgcmVxdWlyZW1lbnQu IExhdGVyIGluIHRoZSBzZWN0aW9uIDcuMi4gdGhpcyBkcmFmdCBzYXlzOg0KPiANCj4gIlRoZSBz ZXJ2ZXIgU0hPVUxEIHJlcXVpcmUgdGhhdCB0aGUgcmVxdWVzdCBiZSBhdXRoZW50aWNhdGVkLiIN Cj4gDQo+IEkgYXNzdW1lIHRoZSByZXF1aXJlbWVudCBpbiBzZWN0aW9uIDUgaXMgYW4gb3ZlcnNp Z2h0Pw0KDQpZZXMsIHJlbW92ZWQgdGhlIHJlcXVpcmVtZW50IGluIFNlY3Rpb24gNS4NCg0KPiAN Cj4gSSBhbHNvIHJlY29tbWVuZCB0byBvbmx5IHNwZWNpZnkgdGhpcyByZXF1aXJlbWVudCBub3Jt YXRpdmVseSBpbiBvbmUgcGxhY2UuDQoNCkRvbmUsIHVwZGF0ZWQgc3RlcCAxIGluIFNlY3Rpb24g NSB0byBhZGRyZXNzIHRoZSBjb21tZW50IGZyb20gQmVuIGFzIGZvbGxvd3M6DQoNCiAgIDEuICAg VGhlIFRVUk4gc2VydmVyIHByb3ZpZGVkIGJ5IHRoZSBsb2NhbCBvciBhY2Nlc3MgbmV0d29yayBN QVkNCiAgICAgICAgYWxsb3cgdW5hdXRoZW50aWNhdGVkIHJlcXVlc3QgaW4gb3JkZXIgdG8gYWNj ZXB0IEFsbG9jYXRpb24NCiAgICAgICAgcmVxdWVzdHMgZnJvbSBuZXcgYW5kL29yIGd1ZXN0IHVz ZXJzIGluIHRoZSBuZXR3b3JrIHdobyBkbyBub3QNCiAgICAgICAgbmVjZXNzYXJpbHkgcG9zc2Vz cyBsb25nIHRlcm0gY3JlZGVudGlhbHMgZm9yIFNUVU4NCiAgICAgICAgYXV0aGVudGljYXRpb24g YW5kIGl0cyBzZWN1cml0eSBpbXBsaWNhdGlvbnMgYXJlIGRpc2N1c3NlZCBpbg0KICAgICAgICBb UkZDODE1NV0uICBPdGhlcndpc2UsIHRoZSBzZXJ2ZXIgTVVTVCByZXF1aXJlIHRoYXQgdGhlIHJl cXVlc3QNCiAgICAgICAgYmUgYXV0aGVudGljYXRlZC4gIElmIHRoZSByZXF1ZXN0IGlzIGF1dGhl bnRpY2F0ZWQsIHRoZQ0KICAgICAgICBhdXRoZW50aWNhdGlvbiBNVVNUIGJlIGRvbmUgZWl0aGVy IHVzaW5nIHRoZSBsb25nLXRlcm0NCiAgICAgICAgY3JlZGVudGlhbCBtZWNoYW5pc20gb2YgW0kt RC5pZXRmLXRyYW0tc3R1bmJpc10gb3IgdGhlIFNUVU4NCiAgICAgICAgRXh0ZW5zaW9uIGZvciBU aGlyZC1QYXJ0eSBBdXRob3JpemF0aW9uIFtSRkM3NjM1XSB1bmxlc3MgdGhlDQogICAgICAgIGNs aWVudCBhbmQgc2VydmVyIGFncmVlIHRvIHVzZSBhbm90aGVyIG1lY2hhbmlzbSB0aHJvdWdoIHNv bWUNCiAgICAgICAgcHJvY2VkdXJlIG91dHNpZGUgdGhlIHNjb3BlIG9mIHRoaXMgZG9jdW1lbnQu DQoNCj4gDQo+IA0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IENPTU1FTlQ6DQo+IC0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0N Cj4gDQo+IFNvbWUgb3RoZXIgdGVjaG5pY2FsIGNvbW1lbnRzL3F1ZXN0aW9uczoNCj4gDQo+IDEp IFNlYyAzLjc6DQo+ICJvciB1c2UgVURQIGZyYWdtZW50YXRpb24gW0ktRC5pZXRmLXRzdndnLXVk cC1vcHRpb25zXS4iDQo+IEkgYmVsaWV2ZSB0aGUgcG9zc2liaWxpdHkgdG8gdXNlIFVEUCBmcmFn bWVudGF0aW9uIHdhcyBicm91Z2h0IHVwIGJ5IHRoZQ0KPiBUU1YtQVJUIHJldmlldyAoVGhhbmtz IEpvZSEpLiBIb3dldmVyLCBJIHdvdWxkIGxpa2UgdG8gbWVudGlvbiB0aGF0IHRoaXMgY2FuDQo+ IG9ubHkgYmUgdXNlZCBpZiBzdXBwb3J0ZWQgYnkgYm90aCBlbmRwb2ludHMgYW5kIHRoYXQgc2hv dWxkIHByb2JhYmx5IGFsc28NCj4gYmUgcmVtYXJrZWQgaGVyZS4gVGhlIG5leHQgc2VudGVuY2Ug aW4gdGhlIGRyYWZ0IGluZGljYXRlZCB0aGlzIGJ5IHNheWluZw0KPiAidW50aWwgVURQIGZyYWdt ZW50YXRpb24gc3VwcG9ydCBpcyBhdmFpbGFibGUiLCBob3dldmVyLCB0aGlzIGFjdHVhbGx5IHNl ZW0NCj4gdG8gYmUgZWRpdG9yaWFsbHkgYSBiaXQgbWlzcGxhY2VkIHRoZXJlIGFuZCBjb3VsZCBl eHBsYWluIG1vcmUuIFNlZSBhbHNvIHRoaXMNCj4gdGV4dCBpbg0KPiBkcmFmdC1pZXRmLXRzdndn LXVkcC1vcHRpb25zOg0KPiANCj4gIkZSQUcgbmVlZHMgdG8gYmUgdXNlZCB3aXRoIGV4dHJlbWUg Y2FyZSBiZWNhdXNlIGl0IHdpbGwgcHJlc2VudA0KPiAgICBpbmNvcnJlY3QgZGF0YWdyYW0gYm91 bmRhcmllcyB0byBhIGxlZ2FjeSByZWNlaXZlciwgdW5sZXNzIGVuY29kZWQNCj4gICAgYXMgTElU RSBkYXRhIChzZWUgU2VjdGlvbiA1LjgpLiINCj4gDQo+IEFsc28gbm90ZSB0aGF0IGRyYWZ0LWll dGYtdHN2d2ctdWRwLW9wdGlvbnMgaXMgc3RpbGwgdW5kZXIgZGV2ZWxvcG1lbnQgYW5kDQo+IHdl IGRvbid0IGhhdmUgbXVjaCBkZXBsb3ltZW50IGV4cGVyaWVuY2Ugd2l0aCBpdCB5ZXQuDQoNClll cywgSm9lIHN1Z2dlc3QgdGhlIGFib3ZlIGNoYW5nZS4gSSBoYXZlIGFkZGVkIHRoZSBmb2xsb3dp bmcgbGluZToNCk5vdGUgdGhhdCB0aGUgVURQIGZyYWdtZW50YXRpb24gb3B0aW9uIG5lZWRzIHRv IGJlIHN1cHBvcnRlZCBieSBib3RoIGVuZHBvaW50cywgYW5kIGF0IHRoZSB0aW1lIG9mIHdyaXRp bmcgb2YgdGhpcyBkb2N1bWVudCwgVURQIGZyYWdtZW50YXRpb24gc3VwcG9ydCBpcyB1bmRlciBk aXNjdXNzaW9uIGFuZCBpcyBub3QgZGVwbG95ZWQuDQoNCj4gDQo+IEFuZCBmdXJ0aGVyLCBpbiB0 aGUgc2FtZSBzZWN0aW9uLiBUaGVyZSBpcyBhbHNvIGRyYWZ0LWlldGYtdHN2d2ctZGF0YWdyYW0t DQo+IHBscG10dWQgb24gIlBhY2tldGl6YXRpb24gTGF5ZXIgUGF0aCBNVFUgRGlzY292ZXJ5IGZv ciBEYXRhZ3JhbQ0KPiBUcmFuc3BvcnRzIi4gUGxlYXNlIGFsc28gYmUgYXdhcmUgdGhhdCB0aGVy ZSBpcyBhbiBleHRlbnNpdmUgVFNWLUFSVCBmb3INCj4gZHJhZnQtaWV0Zi10cmFtLXN0dW4tcG10 dWQuIEJvdGggbWlnaHQgaW1wYWN0IHRoZSBmaW5hbCBjb250ZW50IG9mIHRoaXMNCj4gc2VjdGlv bi4NCg0KVGhlIGRyYWZ0IGRvZXMgbm90IHJlZmVyIHRvIGRyYWZ0LWlldGYtdHN2d2ctZGF0YWdy YW0tIHBscG10dWQuIA0KDQo+IA0KPiAyKSBzZWMgMTEuNToNCj4gIldoZW4gdGhlIHNlcnZlciBy ZWNlaXZlcyBhbiBJQ01QIHBhY2tldCwgdGhlIHNlcnZlciB2ZXJpZmllcyB0aGF0IHRoZQ0KPiAg ICB0eXBlIGlzIGVpdGhlciAzIG9yIDExIGZvciBhbiBJQ01QdjQgW1JGQzA3OTJdIHBhY2tldCBv ciBlaXRoZXIgMSwgMiwNCj4gICAgb3IgMyBmb3IgYW4gSUNNUHY2IFtSRkM0NDQzXSBwYWNrZXQu Ig0KPiBSZXN0cmljdGluZyB0byBhIHNldCBvZiBrbm93biB0eXBlcywgZG9lc24ndCBzZWVtIHRv IHN1cHBvcnQgZnV0dXJlDQo+IGV4dGVuc2liaWxpdHkgdmVyeSB3ZWxsLi4uDQoNCkdvb2QgcG9p bnQsIGFkZGVkIHRoZSBmb2xsb3dpbmcgbGluZXM6DQpOZXcgSUNNUCB0eXBlcyBvciBjb2RlcyBj YW4gYmUgZGVmaW5lZCBpbiBmdXR1cmUgc3BlY2lmaWNhdGlvbnMuIElmIHRoZSBzZXJ2ZXIgcmVj ZWl2ZXMgYW4gSUNNUCBlcnJvciBwYWNrZXQsIGFuZCB0aGUgbmV3IHR5cGUgb3IgY29kZSBmaWVs ZCBjYW4gaGVscCB0aGUgY2xpZW50IHRvIG1ha2UgdXNlIG9mIHRoZSBJQ01QIGVycm9yIG5vdGlm aWNhdGlvbiBhbmQgZ2VuZXJhdGUgZmVlZGJhY2sgdG8gdGhlIGFwcGxpY2F0aW9uIGxheWVyLCB0 aGUgc2VydmVyIHNlbmRzIHRoZSBEYXRhIGluZGljYXRpb24gd2l0aCBhbiBJQ01QIGF0dHJpYnV0 ZSBjb252ZXlpbmcgdGhlIG5ldyBJQ01QIHR5cGUgb3IgY29kZS4NCg0KPiANCj4gMykgc2VjIDEy LjU6DQo+ICJPdmVyIFRDUCBhbmQgVExTLW92ZXItVENQLCB0aGUgQ2hhbm5lbERhdGEgbWVzc2Fn ZSBNVVNUIGJlIHBhZGRlZCB0bw0KPiAgICBhIG11bHRpcGxlIG9mIGZvdXIgYnl0ZXMgaW4gb3Jk ZXIgdG8gZW5zdXJlIHRoZSBhbGlnbm1lbnQgb2YNCj4gICAgc3Vic2VxdWVudCBtZXNzYWdlcy4i DQo+IE5vdCBleGFjdGx5IHN1cmUgd2h5IHRoaXMgaXMgdXNlZnVsLi4uPyBJcyB0aGlzIHRvIGFs aWduIHdpdGggU1RVTiBhbmQgdGhlcmVmb3JlDQo+IG1ha2UgcHJvY2Vzc2luZyBzb21laG93IGVh c2llcj8gSXMgdGhhdCByZWFsbHkgbmVlZGVkLiBBbmQgZXhjZXB0aW9uDQo+IHNob3VsZCBiZSBl YXN5IHRvIGltcGxlbWVudCBhbmQgc2hvdWxkIHNhdmUgc29tZSBieXRlcyB3aGljaCBpcyB0aGUg YXMgSQ0KPiB1bmRlcnN0b29kIGl0IHRoZSB3aG9sZSBwdXJwb3NlIG9mIGNoYW5uZWxzLCBubz8N Cg0KVGhpcyBiZWhhdmlvciBpcyBub3QgbmV3LCBpdCBpcyBkZWZpbmVkIGFuZCBkZXBsb3llZCBp biBUVVJOIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM1NzY2I3NlY3Rpb24tMTEuNSAN Cg0KPiANCj4gNCkgMTIuNjoNCj4gIk5vdGUgdGhhdCBpZg0KPiAgICB0aGUgTGVuZ3RoIGZpZWxk IGluIHRoZSBDaGFubmVsRGF0YSBtZXNzYWdlIGlzIDAsIHRoZW4gdGhlcmUgd2lsbCBiZQ0KPiAg ICBubyBkYXRhIGluIHRoZSBVRFAgZGF0YWdyYW0sIGJ1dCB0aGUgVURQIGRhdGFncmFtIGlzIHN0 aWxsIGZvcm1lZCBhbmQNCj4gICAgc2VudC4iDQo+IENhbiB5b3UgbWF5YmUgYWRkIHNvbWUgbW9y ZSB0ZXh0IGFuZCBleHBsYWluIHdoeSB0aGlzIGlzIHVzZWZ1bD8NCg0KU3VyZSwgYWRkZWQgcmVm ZXJlbmNlIHRvIFNlY3Rpb24gNC4xIGluIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM2 MjYzIA0KDQo+IA0KPiA1KSBzZWMgMTU6DQo+IFJGQzY4MjQgd2lsbCBzb29uIGJlIG9ic29sZXRl ZCBieSBkcmFmdC1pZXRmLW1wdGNwLXJmYzY4MjRiaXMgYW5kIHBsZWFzZQ0KPiBzL1RDUCBtdWx0 aS1wYXRoL011bHRpcGF0aCBUQ1AvLg0KDQpUaGFua3MsIHVwZGF0ZWQuDQoNCj4gDQo+IDYpIEp1 c3QgYSB0aG91Z2h0IGxvb2tpbmcgYXQgc2VjdGlvbiAxNCBhbmQgMTY6IEl0IGNvdWxkIGhhdmUg YmVlbiBuaWNlIHRvDQo+IHByb3ZpZGUgYW4gRUNOIGZlZWRiYWNrIGZpZWxkIGZyb20gdGhlIHNl cnZlciB0byB0aGUgY2xpZW50IGluIGNhc2UgYSBFQ04NCj4gbWFya2VkIHBhY2tldCBpcyByZWNl aXZlZCBmcm9tIHRoZSBwZWVyLi4uIGhvd2V2ZXIsIEkgZ3Vlc3MgdGhhdCBmdXR1cmUNCj4gd29y ayBhdCB0aGlzIHBvaW50IGluIHRoZSBwcm9jZXNzLi4uDQo+IA0KPiA3KSBzZWMgMTguMTM6IE1h eWJlIEkgbWlzc2VkIHRoaXMgYmVjYXVzZSBJIHJldmlld2VkIHRoaXMgZG9jIG92ZXIgMyBkYXlz LCBidXQNCj4gaXMgb25seSB0aGUgSUNNUCBBdHRyaWJ1dGUgc2VuZCB0byB0aGUgY2xpZW50IG9y IGlzIHRoZSBhY3R1YWwgSUNNUCBwYWNrZXRzIG9yDQo+IGFzIG11Y2ggYXMgcG9zc2libGUgb2Yg dGhhdCBwYWNrZXQgaW5jbHVkZXMgYXMgd2VsbD8NCg0KWWVzLCBvbmx5IHRoZSBJQ01QIGF0dHJp YnV0ZSBpcyBzZW50IHRvIHRoZSBjbGllbnQuDQoNCj4gDQo+IDgpIHNlYyAyMzoNCj4gIlJlc3Bv bnNlOiBUVVJOIHdpbGwgbm8gbG9uZ2VyIGJlIG5lZWRlZCBvbmNlIHRoZXJlIGFyZSBubyBsb25n ZXIgYW55DQo+ICAgIE5BVHMuICBVbmZvcnR1bmF0ZWx5LCBhcyBvZiB0aGUgZGF0ZSBvZiBwdWJs aWNhdGlvbiBvZiB0aGlzIGRvY3VtZW50LA0KPiAgICBpdCBubyBsb25nZXIgc2VlbXMgdmVyeSBs aWtlbHkgdGhhdCBOQVRzIHdpbGwgZ28gYXdheSBhbnkgdGltZSBzb29uLg0KPiAgICBIb3dldmVy LCB0aGUgbmVlZCBmb3IgVFVSTiB3aWxsIGFsc28gZGVjcmVhc2UgYXMgdGhlIG51bWJlciBvZiBO QVRzDQo+ICAgIHdpdGggdGhlIG1hcHBpbmcgcHJvcGVydHkgb2YgRW5kcG9pbnQtSW5kZXBlbmRl bnQgTWFwcGluZyBbUkZDNDc4N10NCj4gICAgaW5jcmVhc2VzLiINCj4gWWVzLi4uIHNvIHlvdSBk b24ndCB0aGluayB0aGF0IElQdjYgd2lsbCBiZSBhbnkgaGVscCBoZXJlPw0KDQpZZXMsIElQdjYg d2lsbCBub3QgaGVscCBpbiBzb21lIHNjZW5hcmlvcywgdXBkYXRlZCBJbnRyb2R1Y3Rpb24gdG8g bGlzdCB0aGVtLg0KDQogICBJbiBtYW55IGVudGVycHJpc2UgbmV0d29ya3MsIGRpcmVjdCBVRFAg dHJhbnNtaXNzaW9ucyBhcmUgbm90DQogICBwZXJtaXR0ZWQgYmV0d2VlbiBjbGllbnRzIG9uIHRo ZSBpbnRlcm5hbCBuZXR3b3JrcyBhbmQgZXh0ZXJuYWwgSVANCiAgIGFkZHJlc3Nlcy4gIFRvIHBl cm1pdCBtZWRpYSBzZXNzaW9ucyBpbiBzdWNoIGEgc2l0dWF0aW9uIHRvIHVzZSBVRFANCiAgIGFu ZCB0byBhdm9pZCBmb3JjaW5nIHRoZSBtZWRpYSBzZXNzaW9ucyB0aHJvdWdoIFRDUCwgRW50ZXJw cmlzZQ0KICAgRmlyZXdhbGwgY2FuIGJlIGNvbmZpZ3VyZWQgdG8gYWxsb3cgVURQIHRyYWZmaWMg cmVsYXllZCB0aHJvdWdoIGFuDQogICBFbnRlcnByaXNlIHJlbGF5IHNlcnZlci4gIFRoaXMgc2Nl bmFyaW8gaXMgcmVxdWlyZWQgdG8gYmUgc3VwcG9ydGVkDQogICBieSB0aGUgV2ViUlRDIHJlcXVp cmVtZW50cyAoU2VjdGlvbiAyLjMuNS4xIGluIFtSRkM3NDc4XSkuICBJbg0KICAgYWRkaXRpb24s IGluIGEgU0lQIG9yIFdlYlJUQyBjYWxsLCBpZiB0aGUgdXNlciB3YW50cyBJUCBsb2NhdGlvbg0K ICAgcHJpdmFjeSBmcm9tIHRoZSBwZWVyIHRoZW4gdGhlIGNsaWVudCBjYW4gc2VsZWN0IGEgcmVs YXkgc2VydmVyDQogICBvZmZlcmluZyBJUCBsb2NhdGlvbiBwcml2YWN5IGFuZCBvbmx5IGNvbnZl eSB0aGUgcmVsYXllZCBjYW5kaWRhdGVzDQogICB0byB0aGUgcGVlciBmb3IgSUNFIGNvbm5lY3Rp dml0eSBjaGVja3MgKHNlZSBTZWN0aW9uIDQuMi40IGluDQogICBbSS1ELmlldGYtcnRjd2ViLXNl Y3VyaXR5XSkuIA0KDQo+IA0KPiBFZGl0b3JpYWwgY29tbWVudHM6DQo+IA0KPiAxKSBTZWMgNjoN Cj4gIlRoZSByZWxheWVkIHRyYW5zcG9ydCBhZGRyZXNzIE1VU1QgYmUgdW5pcXVlIGFjcm9zcyBh bGwNCj4gICAgYWxsb2NhdGlvbnMsIHNvIGl0IGNhbiBiZSB1c2VkIHRvIHVuaXF1ZWx5IGlkZW50 aWZ5IHRoZSBhbGxvY2F0aW9uLg0KPiANCj4gICAgQm90aCB0aGUgcmVsYXllZCB0cmFuc3BvcnQg YWRkcmVzcyBhbmQgdGhlIDUtdHVwbGUgTVVTVCBiZSB1bmlxdWUNCj4gICAgYWNyb3NzIGFsbCBh bGxvY2F0aW9ucywgc28gZWl0aGVyIG9uZSBjYW4gYmUgdXNlZCB0byB1bmlxdWVseQ0KPiAgICBp ZGVudGlmeSB0aGUgYWxsb2NhdGlvbiwgWy4uLl0iDQo+IFRoZXNlIHR3byBzZW50ZW5jZXMgc2Vl bSBxdWl0ZSByZWR1bmRhbnQuIFRoZSBmaXJzdCBvbmUgd2FzIGFkZGVkIGluIHRoaXMNCj4gZHJh ZnQuIFRoZSBzZWNvbmQgb25lIHdhcyBhbHJlYWR5IHRoZXJlIGluIFJGQzU3NjYuDQoNClRoYW5r cywgcmVtb3ZlZCB0aGUgc2Vjb25kIHNlbnRlbmNlLiANCg0KPiANCj4gMikgc2VjIDcuMToNCj4g IlNpbmNlIHRoaXMgc3BlY2lmaWNhdGlvbiBvbmx5DQo+ICAgIGFsbG93cyBVRFAgYmV0d2VlbiB0 aGUgc2VydmVyIGFuZCB0aGUgcGVlcnMsIGl0IGlzIFJFQ09NTUVOREVEIHRoYXQNCj4gWy4uLl0i DQo+IFdvcmRpbmdzICgib25seSBhbGxvd3MiKSBzZWVtcyB3ZWlyZCB0byBtZSBnaXZlbiB1c2Ug b2Ygb3RoZXIgcHJvcG9zYWxzIGlzDQo+IGF0IGxlYXN0IHRvIHNvbWUgZXh0ZW5kIGRpc2N1c3Nl ZC4NCg0KVGhlIHNwZWNpZmljYXRpb24gZG9lcyBub3QgYWxsb3cgYW55IG90aGVyIHByb3RvY29s IG90aGVyIHRoYW4gVURQIGJldHdlZW4gdGhlIHNlcnZlciBhbmQgcGVlcnMgKEFzIHlvdSBrbm93 LCBVRFAgaXMgdGhlIHByZWZlcnJlZCB0cmFuc3BvcnQgZm9yIG1lZGlhIHN0cmVhbXMpLg0KDQo+ IA0KPiBOaXRzOg0KPiBzZWMgNy4xLjogcy90aGUgY2xpZW50IHBpY2sgYSBjdXJyZW50bHkgdW51 c2VkIHRyYW5zcG9ydCBhZGRyZXNzL3RoZSBjbGllbnQNCj4gcGlja3MgYSBjdXJyZW50bHkgdW51 c2VkIHRyYW5zcG9ydCBhZGRyZXNzLw0KDQpGaXhlZC4NCg0KQ2hlZXJzLA0KLVRpcnUNCj4gDQo+ IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiB0 cmFtIG1haWxpbmcgbGlzdA0KPiB0cmFtQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vdHJhbQ0K From nobody Mon Jul 15 07:10:32 2019 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 B9FFE120125; Mon, 15 Jul 2019 07:10:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.5 X-Spam-Level: X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, 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 header.b=fjeVvHtv; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=rjNoRkQw 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 6uVE4v-puWBD; Mon, 15 Jul 2019 07:10:21 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9410912011B; Mon, 15 Jul 2019 07:10:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10345; q=dns/txt; s=iport; t=1563199820; x=1564409420; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=aMCvXtoou84XFiZBAJ06EV5tCmstYoYdlJWgb2KOQyY=; b=fjeVvHtvN7Abv36KTj/z4QJ/FQeAWpX82d5ZdqRgIwYNFTPn4Dj2i1Nj kSnmZQeh1dSGWzqzE8BmAJ6uBr6HdSLfaC0dCEdaEMfivO17Yfq4sedvI CDLB/9y9XDPYsumiVq2fSjV0sw9ZOaSCPFzBu3i01/iGk5zsuw7xHNZ39 w=; IronPort-PHdr: =?us-ascii?q?9a23=3Aq+GsBxUoEtxhF/5tnRvCQzQYL0bV8LGuZFwc94?= =?us-ascii?q?YnhrRSc6+q45XlOgnF6O5wiEPSA9yJ8OpK3uzRta2oGXcN55qMqjgjSNRNTF?= =?us-ascii?q?dE7KdehAk8GIiAAEz/IuTtank0EctLTkVk81mwMFNeH4D1YFiB6nA=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BeAADziCxd/5ldJa1bChwBAQEEAQE?= =?us-ascii?q?HBAEBgVMHAQELAYEUL1ADalUgBAsoCoQSg0cDhFKJe4I2kx+EVYEugSQDVAk?= =?us-ascii?q?BAQEMAQEjCgIBAYRAAheCTiM0CQ4BAwEBBAEBAgEFbYU8AQuFSwIBAxIRHQE?= =?us-ascii?q?BNwEPAgEIQgICAjAlAgQOJ4MAAYEdTQMdAQIMn14CgTiIYHGBMoJ5AQEFgUZ?= =?us-ascii?q?Bgn0YghMDBoE0AYteF4FAP4E4DBOCTD6CYQIBAgGBMhVDgl0ygiaMJoIjL4R?= =?us-ascii?q?+lnEJAoIZhliNNBuCLYcljjiNNYdIkAgCBAIEBQIOAQEFgVA4gT8RCHAVZQG?= =?us-ascii?q?CQYJBg3GFFIU/cgGBKI1hAYEgAQE?= X-IronPort-AV: E=Sophos;i="5.63,493,1557187200"; d="scan'208,217";a="596828637" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 15 Jul 2019 14:10:07 +0000 Received: from XCH-ALN-017.cisco.com (xch-aln-017.cisco.com [173.36.7.27]) by rcdn-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id x6FEA2g9006453 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 15 Jul 2019 14:10:06 GMT Received: from xhs-rtp-002.cisco.com (64.101.210.229) by XCH-ALN-017.cisco.com (173.36.7.27) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 15 Jul 2019 09:10:02 -0500 Received: from xhs-aln-002.cisco.com (173.37.135.119) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 15 Jul 2019 10:10:01 -0400 Received: from NAM04-CO1-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Mon, 15 Jul 2019 09:10:01 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=klaPrczeRKpHis0QYZ23ajZu91jCVHKFxPxVTgyHQheCdXFHsRiXli8otBOxCho+xi1S0E/VKj1jDUJW4BNGFzJd7+yNhQQFmfc8HIJqkgjJOo4uOknoeB70cttZW2IZlfuJVYlFPecx9t5G07XaFEJtP8kilNtzNGvuXdDe7cs01jrukwd/qeKk62KkNVQBGMrgC/ZLxffiUBsqZRzq/ayjfCrbyDcCh74QDHkucqG84lf9hrjcw+LKZoGSiZCoVDS5KBcWg1rV4IvXanYW++B6p6TOcAWwsfEW3BRk4+nJXq1u9kjO1SEksiP63FtR1nEUe/rAMOlkMJLRfyqDPA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=aMCvXtoou84XFiZBAJ06EV5tCmstYoYdlJWgb2KOQyY=; b=Av1Aeh63Z9KAm18gxh0NaM181Ls4EqU+MPusj2/LprHMFm8AoaOAtA3gQi3QtNIMsohI+Ugg+UCTTyVDeb2AcymlXyFW4H/1o0gn1pGokSzY5dbhWfG6+W5I7eoTxzpAMrRnk8d0Fe8Wk6NiAf5XjwMMKB+JBjIrl0Spz35lazKfIATigCopocVadxKkrukgWYrJVQq/kU0Ky0z3gldaKseRyiQeDTinsj3HY47+Mgb91q/fY5fBm8jqMkb7KerZxC7WXWYimCQP07vUfu2hVY1HKvH7fxTAxUVIcmUfbMsBJDwb0U9JKqPCfVIaSHILWE0t7AyYWsfsahMLLvTghQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1;spf=pass smtp.mailfrom=cisco.com;dmarc=pass action=none header.from=cisco.com;dkim=pass header.d=cisco.com;arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=aMCvXtoou84XFiZBAJ06EV5tCmstYoYdlJWgb2KOQyY=; b=rjNoRkQwsoe4g4A8jmy2Iywhq/rqif9L/5e+5mK5Fr1jiq/b5VojPmP6eL8UsIraeX8/67lPN1n2i+J50acwjeC6PhedhhR3pPVu8zgGqWQYkgyfs4o9Jkz3EmWJ0ae1OUPAHay0xYbu3V/r9VBabgroesbn3LkP2EMWBk/eh/M= Received: from SN6PR11MB2800.namprd11.prod.outlook.com (52.135.93.15) by SN6PR11MB2768.namprd11.prod.outlook.com (52.135.92.155) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2073.14; Mon, 15 Jul 2019 14:10:00 +0000 Received: from SN6PR11MB2800.namprd11.prod.outlook.com ([fe80::897:7870:e0c6:b2aa]) by SN6PR11MB2800.namprd11.prod.outlook.com ([fe80::897:7870:e0c6:b2aa%5]) with mapi id 15.20.2073.012; Mon, 15 Jul 2019 14:10:00 +0000 From: "Felipe Garrido (fegarrid)" To: "iesg@ietf.org" CC: "draft-ietf-tram-stun-pmtud@ietf.org" , "gonzalo.camarillo@ericsson.com" , "tasveren@rbbn.com" , "tram-chairs@ietf.org" , "tram@ietf.org" Thread-Topic: Suresh Krishnan's Discuss on draft-ietf-tram-stun-pmtud-10: (with DISCUSS) Thread-Index: AQHVCZsIClB3Gn2i3EeQegUBxsHF5KbBIgfSgALRVAA= Date: Mon, 15 Jul 2019 14:09:59 +0000 Message-ID: References: <153793486460.13063.13186763367840598004.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1a.0.190609 authentication-results: spf=none (sender IP is ) smtp.mailfrom=fegarrid@cisco.com; x-originating-ip: [173.38.117.73] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 14116810-ef0c-4af6-66a8-08d7092e1fa9 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:SN6PR11MB2768; x-ms-traffictypediagnostic: SN6PR11MB2768: x-ms-exchange-purlcount: 4 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 00997889E7 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(366004)(376002)(346002)(396003)(39860400002)(136003)(189003)(199004)(6116002)(3846002)(186003)(66066001)(9326002)(26005)(71190400001)(71200400001)(36756003)(2501003)(4326008)(606006)(14444005)(256004)(2351001)(486006)(91956017)(76116006)(8936002)(66446008)(66946007)(66476007)(66556008)(64756008)(1730700003)(81166006)(81156014)(5660300002)(68736007)(66574012)(14454004)(236005)(2616005)(11346002)(6246003)(53936002)(229853002)(446003)(6916009)(7736002)(6486002)(966005)(99286004)(25786009)(316002)(58126008)(2906002)(33656002)(21615005)(54906003)(8676002)(478600001)(54896002)(476003)(6512007)(6306002)(6436002)(5640700003)(6506007)(76176011)(102836004)(86362001); DIR:OUT; SFP:1101; SCL:1; SRVR:SN6PR11MB2768; H:SN6PR11MB2800.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: 6mYmH8ga4zzhCg9AsGyt0oooq2lr2WDMNrY/dlYhwaunRfcS/nF5N6hQMnXQT0Z6l16ALxMrIGCh4Lf4HoQ3DFoIQpxYJ8GVhfuVJ11XsTkSlm/t+WpSn2XQCoCoG5ibQ2AGKL5jPQdRXk5ihYVG4s7ory77F9YOlR4ay6JIYoeohYZhaqWQ9mRz0ur669WLIemnLPoI4dmbu9sdfA8jkrAQBE/DeYawGUVRxGLSn879LyCgs3M70DfzQr12lPpWOXiUaGJYV/n6L09Cgmrm+S7Kgywo4hSGUiHyLlcaMFySyBuhfD+FgZxMFBCnU9Zff+v82WX3ep7omGUcSB0v0lr2w11k4y/h0gabHhPysLSOUXz7FSb4SoAQ9o0f4vHlg+MbFMxmOI7vPyXm/DWuo428boRAkZKhTiUTLXrPpic= Content-Type: multipart/alternative; boundary="_000_FBC4199B0D0A4969A2BD60ACF5272FDEciscocom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 14116810-ef0c-4af6-66a8-08d7092e1fa9 X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Jul 2019 14:09:59.9686 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: fegarrid@cisco.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN6PR11MB2768 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.27, xch-aln-017.cisco.com X-Outbound-Node: rcdn-core-2.cisco.com Archived-At: Subject: Re: [tram] Suresh Krishnan's Discuss on draft-ietf-tram-stun-pmtud-10: (with DISCUSS) X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.29 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, 15 Jul 2019 14:10:23 -0000 --_000_FBC4199B0D0A4969A2BD60ACF5272FDEciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgU3VyZXNoLA0KDQpEb2VzIHRoZSBmb2xsb3dpbmcgbGFuZ3VhZ2Ugc2F0aXNmeSB5b3VyIERp c2N1c3M/IFNpbWlsYXIgcmVmZXJlbmNlcyB0byBJUHY2IHBhY2tldHMgd291bGQgYmUgYWRkZWQg dG8gdGhlIG90aGVyIHNlY3Rpb25zLg0KDQpUaGFua3MsDQotRmVsaXBlDQoNCjQuMS4gIFNpbXBs ZSBQcm9iaW5nIE1lY2hhbmlzbQ0KDQogICBUaGUgU2ltcGxlIFByb2JpbmcgbWVjaGFuaXNtIGlz IGltcGxlbWVudGVkIGJ5IHNlbmRpbmcgYSBQcm9iZQ0KICAgUmVxdWVzdCB3aXRoIGEgUEFERElO RyBbUkZDNTc4MF0gYXR0cmlidXRlIG92ZXIgVURQIHdpdGggdGhlIERGIGJpdA0KICAgc2V0IGlu IHRoZSBJUCBoZWFkZXIgZm9yIElQdjQgcGFja2V0cyBhbmQgSVB2NiBwYWNrZXRzIHdpdGhvdXQN CiAgIHRoZSBGcmFnbWVudCBIZWFkZXIgaW5jbHVkZWQuICBBIHJvdXRlciBvbiB0aGUgcGF0aCB0 byB0aGUgc2VydmVyIGNhbg0KICByZWplY3QgdGhpcyByZXF1ZXN0IHdpdGggYW4gSUNNUCBtZXNz YWdlIG9yIGRyb3AgaXQuDQoNCjQuMi4yLiAgUmVjZWl2aW5nIGFuIElDTVAgUGFja2V0DQoNCiAg IElmIGFuIElDTVAgcGFja2V0ICJGcmFnbWVudGF0aW9uIG5lZWRlZCIgb3IgIlBhY2tldCBUb28g QmlnIiBpcyByZWNlaXZlZCB0aGVuIHRoaXMgaXMNCiAgIGludGVycHJldGVkIGFzIGEgUHJvYmUg RmFpbHVyZSwgYXMgZGVmaW5lZCBpbiBbUkZDNDgyMV0gU2VjdGlvbiA3LjUuDQoNClN1cmVzaCBL cmlzaG5hbiBoYXMgZW50ZXJlZCB0aGUgZm9sbG93aW5nIGJhbGxvdCBwb3NpdGlvbiBmb3INCmRy YWZ0LWlldGYtdHJhbS1zdHVuLXBtdHVkLTEwOiBEaXNjdXNzDQoNCg0KDQpQbGVhc2UgcmVmZXIg dG8gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaWVzZy9zdGF0ZW1lbnQvZGlzY3Vzcy1jcml0ZXJpYS5o dG1sDQpmb3IgbW9yZSBpbmZvcm1hdGlvbiBhYm91dCBJRVNHIERJU0NVU1MgYW5kIENPTU1FTlQg cG9zaXRpb25zLg0KDQoNClRoZSBkb2N1bWVudCwgYWxvbmcgd2l0aCBvdGhlciBiYWxsb3QgcG9z aXRpb25zLCBjYW4gYmUgZm91bmQgaGVyZToNCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcv ZG9jL2RyYWZ0LWlldGYtdHJhbS1zdHVuLXBtdHVkLw0KDQoNCg0KLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KRElT Q1VTUzoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KU2VjdGlvbiA0LjEueCBhbmQgNC4yLngNCg0KUGxlYXNl IHNwZWNpZnkgaG93IHRoaXMgc2ltcGxlIHByb2JpbmcgbWVjaGFuaXNtIHdpbGwgd29yayB3aXRo IElQdjYuIEl0DQpzaG91bGRuJ3QgYmUgdG9vIGRpZmZpY3VsdCB0byBkbyAoY2xlYW51cCByZWZl cmVuY2VzIHRvIHRoZSBERiBiaXQsIHVzZSBUeXBlIDINCiJQYWNrZXQgVG9vIEJpZyIgdG8gaWRl bnRpZnkgZmFpbHVyZXMgZXRjLikuIFNpbWlsYXIgdHJlYXRtZW50IHdpbGwgYmUgcmVxdWlyZWQN CmZvciB0aGUgY29tcGxldGUgcHJvYmluZyBtZWNoYW5pc20gYXMgd2VsbC4NCg0KDQoNCg0K --_000_FBC4199B0D0A4969A2BD60ACF5272FDEciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1z b0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJw bGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25v cm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltYXJn aW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21z by1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlm Ow0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6 ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7 c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRp di5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT4NCjwvaGVh ZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYg Y2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+SGkgU3VyZXNoLCA8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBw dDtjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPkRvZXMg dGhlIGZvbGxvd2luZyBsYW5ndWFnZSBzYXRpc2Z5IHlvdXIgRGlzY3Vzcz8gU2ltaWxhciByZWZl cmVuY2VzIHRvIElQdjYgcGFja2V0cyB3b3VsZCBiZSBhZGRlZCB0byB0aGUgb3RoZXIgc2VjdGlv bnMuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4w cHQ7Y29sb3I6YmxhY2siPlRoYW5rcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+LUZl bGlwZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBw dDtjb2xvcjpibGFjayI+NC4xLiZuYnNwOyBTaW1wbGUgUHJvYmluZyBNZWNoYW5pc208bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEyLjBwdDtjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6Ymxh Y2siPiZuYnNwOyZuYnNwOyBUaGUgU2ltcGxlIFByb2JpbmcgbWVjaGFuaXNtIGlzIGltcGxlbWVu dGVkIGJ5IHNlbmRpbmcgYSBQcm9iZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj4mbmJz cDsmbmJzcDsgUmVxdWVzdCB3aXRoIGEgUEFERElORyBbUkZDNTc4MF0gYXR0cmlidXRlIG92ZXIg VURQIHdpdGggdGhlIERGIGJpdDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj4mbmJzcDsm bmJzcDsgc2V0IGluIHRoZSBJUCBoZWFkZXIgZm9yIElQdjQgcGFja2V0cyBhbmQgSVB2NiBwYWNr ZXRzIHdpdGhvdXQNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsm bmJzcDt0aGUgRnJhZ21lbnQgSGVhZGVyIGluY2x1ZGVkLiZuYnNwOyBBIHJvdXRlciBvbiB0aGUg cGF0aCB0byB0aGUgc2VydmVyIGNhbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj4mbmJz cDsmbmJzcDtyZWplY3QgdGhpcyByZXF1ZXN0IHdpdGggYW4gSUNNUCBtZXNzYWdlIG9yIGRyb3Ag aXQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0 O2NvbG9yOmJsYWNrIj40LjIuMi4mbmJzcDsgUmVjZWl2aW5nIGFuIElDTVAgUGFja2V0PG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJs YWNrIj4mbmJzcDsmbmJzcDsgSWYgYW4gSUNNUCBwYWNrZXQgJnF1b3Q7RnJhZ21lbnRhdGlvbiBu ZWVkZWQmcXVvdDsgb3IgJnF1b3Q7UGFja2V0IFRvbyBCaWcmcXVvdDsgaXMgcmVjZWl2ZWQgdGhl biB0aGlzIGlzPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyBpbnRl cnByZXRlZCBhcyBhIFByb2JlIEZhaWx1cmUsIGFzIGRlZmluZWQgaW4gW1JGQzQ4MjFdIFNlY3Rp b24gNy41LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6Ymxh Y2siPlN1cmVzaCBLcmlzaG5hbiBoYXMgZW50ZXJlZCB0aGUgZm9sbG93aW5nIGJhbGxvdCBwb3Np dGlvbiBmb3I8YnI+DQpkcmFmdC1pZXRmLXRyYW0tc3R1bi1wbXR1ZC0xMDogRGlzY3Vzczxicj4N Cjxicj4NCjxicj4NCjxicj4NClBsZWFzZSByZWZlciB0byA8L3NwYW4+PGEgaHJlZj0iaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvaWVzZy9zdGF0ZW1lbnQvZGlzY3Vzcy1jcml0ZXJpYS5odG1sIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvaWVzZy9zdGF0 ZW1lbnQvZGlzY3Vzcy1jcml0ZXJpYS5odG1sPC9zcGFuPjwvYT48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEyLjBwdDtjb2xvcjpibGFjayI+PGJyPg0KZm9yIG1vcmUgaW5mb3JtYXRpb24gYWJvdXQg SUVTRyBESVNDVVNTIGFuZCBDT01NRU5UIHBvc2l0aW9ucy48YnI+DQo8YnI+DQo8YnI+DQpUaGUg ZG9jdW1lbnQsIGFsb25nIHdpdGggb3RoZXIgYmFsbG90IHBvc2l0aW9ucywgY2FuIGJlIGZvdW5k IGhlcmU6PGJyPg0KPC9zcGFuPjxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcv ZG9jL2RyYWZ0LWlldGYtdHJhbS1zdHVuLXBtdHVkLyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox Mi4wcHQiPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtdHJhbS1z dHVuLXBtdHVkLzwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6 YmxhY2siPjxicj4NCjxicj4NCjxicj4NCjxicj4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08YnI+DQpESVNDVVNT Ojxicj4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS08YnI+DQo8YnI+DQpTZWN0aW9uIDQuMS54IGFuZCA0LjIueDxi cj4NCjxicj4NClBsZWFzZSBzcGVjaWZ5IGhvdyB0aGlzIHNpbXBsZSBwcm9iaW5nIG1lY2hhbmlz bSB3aWxsIHdvcmsgd2l0aCBJUHY2LiBJdDxicj4NCnNob3VsZG4ndCBiZSB0b28gZGlmZmljdWx0 IHRvIGRvIChjbGVhbnVwIHJlZmVyZW5jZXMgdG8gdGhlIERGIGJpdCwgdXNlIFR5cGUgMjxicj4N CiZxdW90O1BhY2tldCBUb28gQmlnJnF1b3Q7IHRvIGlkZW50aWZ5IGZhaWx1cmVzIGV0Yy4pLiBT aW1pbGFyIHRyZWF0bWVudCB3aWxsIGJlIHJlcXVpcmVkPGJyPg0KZm9yIHRoZSBjb21wbGV0ZSBw cm9iaW5nIG1lY2hhbmlzbSBhcyB3ZWxsLjxicj4NCjxicj4NCjxicj4NCjxicj4NCjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_FBC4199B0D0A4969A2BD60ACF5272FDEciscocom_-- From nobody Mon Jul 15 23:17:49 2019 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 EB922120073 for ; Mon, 15 Jul 2019 23:17:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.999 X-Spam-Level: X-Spam-Status: No, score=-3.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=mcafee.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GFUEsapqYgN8 for ; Mon, 15 Jul 2019 23:17:45 -0700 (PDT) Received: from us-smtp-delivery-210.mimecast.com (us-smtp-delivery-210.mimecast.com [63.128.21.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D3D48120020 for ; Mon, 15 Jul 2019 23:17:44 -0700 (PDT) X-NAI-Header: Modified by McAfee Email Gateway (5500) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mcafee.com; s=s_mcafee; t=1563257209; h=ARC-Seal: ARC-Message-Signature:ARC-Authentication-Results: From:To:Subject:Thread-Topic:Thread-Index: Date:Message-ID:References:In-Reply-To:Accept-Language: Content-Language:X-MS-Has-Attach:X-MS-TNEF-Correlator: dlp-product:dlp-version:dlp-reaction:authentication-results: x-originating-ip:x-ms-publictraffictype:x-ms-office365-filtering-correlation-id: x-microsoft-antispam:x-ms-traffictypediagnostic: x-ms-exchange-purlcount:x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers:x-forefront-prvs: x-forefront-antispam-report:received-spf:x-ms-exchange-senderadcheck: x-microsoft-antispam-message-info:Content-Type: Content-Transfer-Encoding:MIME-Version:X-MS-Exchange-CrossTenant-Network-Message-Id: X-MS-Exchange-CrossTenant-originalarrivaltime: X-MS-Exchange-CrossTenant-fromentityheader: X-MS-Exchange-CrossTenant-id:X-MS-Exchange-CrossTenant-mailboxtype: X-MS-Exchange-CrossTenant-userprincipalname: X-MS-Exchange-Transport-CrossTenantHeadersStamped: X-OriginatorOrg:X-NAI-Spam-Flag:X-NAI-Spam-Level: X-NAI-Spam-Threshold:X-NAI-Spam-Score:X-NAI-Spam-Version; bh=FzbHR+mo8WVHKGYYbpyWCSyPrj00+27ChyfxN6 Weppw=; b=OpmKdwESqwxUvKPsJZGty62jgwPFNDP5cKtH671o 5W/RSZGXSP2LxvNpLMG4x5gotnlG1L2NuumszdwWJ1NrjvEeY7 tccr6zffNg1IHqs6u6+jOAwkkyudsf327usCf5fYlHukhOGnDT VrgOsH6CIu8nFySbTS/dX7u4zjdW2l8= Received: from DNVWSMAILOUT1.mcafee.com (dnvwsmailout1.mcafee.com [161.69.31.173]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-46-AIoOFgJgOrivtXSS2F-qpA-1; Tue, 16 Jul 2019 02:17:39 -0400 Received: from DNVEXAPP1N06.corpzone.internalzone.com (unknown [10.44.48.90]) by DNVWSMAILOUT1.mcafee.com with smtp (TLS: TLSv1/SSLv3,256bits,ECDHE-RSA-AES256-SHA384) id 2aa4_4ec7_8fe089d3_0b6b_4792_a433_54ccfee4f1ec; Tue, 16 Jul 2019 00:06:48 -0600 Received: from DNVEXAPP1N04.corpzone.internalzone.com (10.44.48.88) by DNVEXAPP1N06.corpzone.internalzone.com (10.44.48.90) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Tue, 16 Jul 2019 00:17:34 -0600 Received: from DNVO365EDGE2.corpzone.internalzone.com (10.44.176.74) by DNVEXAPP1N04.corpzone.internalzone.com (10.44.48.88) with Microsoft SMTP Server (TLS) id 15.0.1395.4 via Frontend Transport; Tue, 16 Jul 2019 00:17:34 -0600 Received: from NAM02-CY1-obe.outbound.protection.outlook.com (10.44.176.243) by edge.mcafee.com (10.44.176.74) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Tue, 16 Jul 2019 00:17:34 -0600 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=MVF7o2R/GQeF9p8j+flqq8BjqT8Bcsd4S+yCQeJgxiNvWLniYKCy8kumP5TI8O05IKisMtZLXodMF3wUx91vF3S8rgmvJwHQGFeN/gWx6LKASq9qNLZXcpEkhUm4y6wk73Ecyq+JsgYkYBBPBvqrzAzBh/V0+rjzjjTostMdSJCPJJ0Y7abEALcDGGggAcnB/J5GFEwbEMT2hdKfbUOiYFwfxP7hJ1Kh9btwiNV6Wpn+BA6Qi1QK91MT3Hi9IoiUaUHWvFaQG5lsN6UsmZtzn6kBclzPlmLqM7MCHOKk/oVzAjoODigreuv0qcTeAwzbkL35jM9ODSmzyYY60WpPGA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=FzbHR+mo8WVHKGYYbpyWCSyPrj00+27ChyfxN6Weppw=; b=CNRxi7hDpjgS5ZtMJls7B4CQ5Yr9TaAU3u8ivlm9XI4Rh+13XySqu8qAXMMBcafXgsCWuJLZSTgCg691BEiTH3Za6NNLuZgjwUOIllubyDw3sN7IulCmHmyxfUQFYMWtmfSWu9V4yZl8rCzYViXwfoJougztOdc0DijyphRGhN0WlPbE6CN9Hn67rnA/guKqFEpHKyeB6UrR4nRaFqELB5Xxzo+uZQS4enx/+OEQyKUyy52pJuZ6vypM/9n2xkgZtd9UlzzXFjKRlJuGDeovYARcBdU3KDGDBpHN+N/h3q4bz8mutScj4tpGQNCa+3abBHxrmmcWVOj8l+TNhEK0Jw== ARC-Authentication-Results: i=1; mx.microsoft.com 1;spf=pass smtp.mailfrom=mcafee.com;dmarc=pass action=none header.from=mcafee.com;dkim=pass header.d=mcafee.com;arc=none Received: from DM5PR16MB1705.namprd16.prod.outlook.com (10.172.44.147) by DM5PR16MB1804.namprd16.prod.outlook.com (10.172.44.148) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2073.10; Tue, 16 Jul 2019 06:17:32 +0000 Received: from DM5PR16MB1705.namprd16.prod.outlook.com ([fe80::570:2208:75c2:5f17]) by DM5PR16MB1705.namprd16.prod.outlook.com ([fe80::570:2208:75c2:5f17%8]) with mapi id 15.20.2073.012; Tue, 16 Jul 2019 06:17:32 +0000 From: "Konda, Tirumaleswar Reddy" To: Noriyuki Torii , "tram@ietf.org" Thread-Topic: [tram] some more nits in draft-ietf-tram-turnbis-27 Thread-Index: AQHVN6ofh2Ycokq7FUGkLsu3UcGxaabL1VNA Date: Tue, 16 Jul 2019 06:17:32 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.3.0.16 dlp-reaction: no-action x-originating-ip: [103.245.47.20] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: f73483a3-5a76-4af5-3f9e-08d709b549c3 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600148)(711020)(4605104)(1401327)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7193020); SRVR:DM5PR16MB1804; x-ms-traffictypediagnostic: DM5PR16MB1804: x-ms-exchange-purlcount: 1 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-forefront-prvs: 0100732B76 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(396003)(366004)(136003)(39860400002)(346002)(376002)(32952001)(13464003)(189003)(199004)(76176011)(6506007)(53546011)(6306002)(66066001)(52536014)(6436002)(7696005)(86362001)(2501003)(2906002)(99286004)(55016002)(25786009)(7736002)(80792005)(68736007)(66556008)(486006)(9686003)(64756008)(102836004)(5660300002)(71200400001)(476003)(478600001)(66446008)(66946007)(71190400001)(76116006)(66476007)(8676002)(229853002)(305945005)(11346002)(53936002)(14454004)(446003)(966005)(3846002)(6116002)(110136005)(26005)(74316002)(81156014)(316002)(6246003)(19627235002)(81166006)(8936002)(5024004)(14444005)(256004)(186003)(33656002)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR16MB1804; H:DM5PR16MB1705.namprd16.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: cFxrTemEr6+zrhKFfd1nMcLRdcvHuookFipQbxXfeG6CGMOe+UiAH+VvE8Wmk4Q9Bk+diNLsZQACrMzDC8HtUxqhS9awbe7oiUFipF2bp0wfgC6WxyG1vT0r+La8W3cREUHYCF9FNpuzbCEUhxGw5DBIdS21ALUeFRx8WCZThlqePtid4NqVthEoTFrNQHulKA4WBkNHOyHtxtDdAM3l16BulPRHCGkZ/c9Oqb1Ve8/1pfpuxZ6rlbKhfA7bgJuB6x97Yydqrx5Vm+TZ39bE139AugEyg4DO/7FNc4MaUFdKwqk9FwZDCMVqYfV+BsDNwAXZbO1RW7G5skM8/XY0XpKt9aveYcw8rFSDGgNHXnX/WtQ7lnlQLbJZX5KxgGS1clp1JTfgDvSEgFzX55PnqS9BQGujbXQX9z8kAl68wD4= MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: f73483a3-5a76-4af5-3f9e-08d709b549c3 X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Jul 2019 06:17:32.4635 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: TirumaleswarReddy_Konda@McAfee.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR16MB1804 X-OriginatorOrg: mcafee.com X-NAI-Spam-Flag: NO X-NAI-Spam-Level: X-NAI-Spam-Threshold: 15 X-NAI-Spam-Score: 0.1 X-NAI-Spam-Version: 2.3.0.9418 : core <6590> : inlines <7120> : streams <1827494> : uri <2868104> X-MC-Unique: AIoOFgJgOrivtXSS2F-qpA-1 X-Mimecast-Spam-Score: 0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [tram] some more nits in draft-ietf-tram-turnbis-27 X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.29 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, 16 Jul 2019 06:17:48 -0000 > -----Original Message----- > From: tram On Behalf Of Noriyuki Torii > Sent: Thursday, July 11, 2019 11:03 AM > To: tram@ietf.org > Subject: [tram] some more nits in draft-ietf-tram-turnbis-27 >=20 > This email originated from outside of the organization. Do not click link= s or > open attachments unless you recognize the sender and know the content is > safe. >=20 > To whom it may concern, >=20 > I found some more points in draft-ietf-tram-turnbis-27, in addition to my > previos mail. > So I would like to report here. Hope this may help for improvements. >=20 > in page 67 >=20 > TURN TURN Peer Peer > client server A B > | | | | > |--- Allocate request -------------->| | | > | Transaction-Id=3D0xA56250D3F17ABE679422DE85 | | > | SOFTWARE=3D"Example client, version 1.03" | | > | LIFETIME=3D3600 (1 hour) | | | > | REQUESTED-TRANSPORT=3D17 (UDP) | | | > | DONT-FRAGMENT | | | > | | | | > |<-- Allocate error response --------| | | > | Transaction-Id=3D0xA56250D3F17ABE679422DE85 | | > | SOFTWARE=3D"Example server, version 1.17" | | > | ERROR-CODE=3D401 (Unauthorized) | | | > | REALM=3D"example.com" | | | > | NONCE=3D"obMatJos2AAABadl7W7PeDU4hKE72jda" | | > | PASSWORD-ALGORITHMS=3DMD5 and SHA256 | | > | | | | > |--- Allocate request -------------->| | | > | Transaction-Id=3D0xC271E932AD7446A32C234492 | | > | SOFTWARE=3D"Example client 1.03" | | | > | LIFETIME=3D3600 (1 hour) | | | > | REQUESTED-TRANSPORT=3D17 (UDP) | | | > | DONT-FRAGMENT | | | > | USERNAME=3D"George" | | | > | REALM=3D"example.com" | | | > | NONCE=3D"obMatJos2AAABadl7W7PeDU4hKE72jda" | | > | PASSWORD-ALGORITHMS=3DMD5 and SHA256 | | > | PASSWORD-ALGORITHM=3DSHA256 | | | > | MESSAGE-INTEGRITY=3D... | | | > | MESSAGE-INTEGRITY-SHA256=3D... | | | > | | | | > |<-- Allocate success response ------| | | > | Transaction-Id=3D0xC271E932AD7446A32C234492 | | > | SOFTWARE=3D"Example server, version 1.17" | | > | LIFETIME=3D1200 (20 minutes) | | | > | XOR-RELAYED-ADDRESS=3D192.0.2.15:50000 | | > | XOR-MAPPED-ADDRESS=3D192.0.2.1:7000 | | > | MESSAGE-INTEGRITY=3D... | | | >=20 > Above example shows the server's final response includes MESSAGE- > INTEGRITY. > But the section 9.2.4 of STUNbis says > --- > If these checks pass, the server continues to process the request. > Any response generated by the server MUST include MESSAGE-INTEGRITY- > SHA256 attribute, computed using the username and password utilized > to authenticate the request, unless the request was processed as > though PASSWORD-ALGORITHM was MD5 (because the request contained > neither PASSWORD-ALGORITHMS nor PASSWORD-ALGORITHM). In that > case > the MESSAGE-INTEGRITY attribute MUST be used instead of the MESSAGE- > INTEGRITY-SHA256 attribute. > --- > So, the final response in this diagram must include the MESSAGE-INTEGRITY= - > SHA256, not the MESSAGE-INTEGRITY. > > >=20 > in page 71 (and subsequent diagrams ...) >=20 > TURN TURN Peer Peer > client server A B > |--- CreatePermission request ------>| | | > | Transaction-Id=3D0xE5913A8F460956CA277D3319 | | > | XOR-PEER-ADDRESS=3D192.0.2.150:0 | | | > | USERNAME=3D"George" | | | > | REALM=3D"example.com" | | | > | NONCE=3D"obMatJos2AAABadl7W7PeDU4hKE72jda" | | > | MESSAGE-INTEGRITY=3D... | | | > | | | | > |<-- CreatePermission success resp.--| | | > | Transaction-Id=3D0xE5913A8F460956CA277D3319 | | > | MESSAGE-INTEGRITY=3D... | | | >=20 > The MESSAGE-INTEGRITY is utilized here nevertheless the > MESSAGE-INTEGRITY-SHA256 should be chosen in previous Allocate example. > As a result, the authentication strength is degraded. >=20 > Section 9.2.3.2 of STUNbis says > --- > The client SHOULD > cache the username, password, realm, and nonce for subsequent > communications with the server. When the client sends a subsequent > request, it MUST include either the USERNAME or USERHASH, REALM, > NONCE, and PASSWORD-ALGORITHM attributes with these cached values. > It MUST include a MESSAGE-INTEGRITY attribute or a MESSAGE-INTEGRITY- > SHA256 attribute, computed as described in Section 14.5 and > Section 14.6 using the cached password. The choice between the two > attributes depends on the attribute received in the response to the > first request. > --- > Thus, the example CreatePermission request must have the PASSWORD- > ALGORITHM and also the MESSAGE-INTEGRITY-SHA256, not the MESSAGE- > INTEGRITY. > In fact, the PASSWORD-ALGORITHMS also would be required because any > requests having only the PASSWORD-ALGORITHM without the PASSWORD- > ALGORITHMS will be rejected by the server, according to the section 9.2.4= of > STUNbis. > (Although the section 9.2.3.2 of STUNbis does not explicitly point it ou= t. > I wonder it might be a nit of STUNbis.) Yes, it looks like a nit in STUNbis. > Likely, the example response must > have the MESSAGE-INTEGRITY-SHA256 in place of the MESSAGE-INTEGRITY. Thanks, Ben (ISEG review) raised the same comment. It will be fixed in the = next revision, PASSWORD-ALGORITHMS, PASSWORD-ALGORITHM and MESSAGE-INTEGRIT= Y-SHA256 is used in all requests=20 starting from Allocate success response.=20 Cheers, -Tiru >=20 > These points will apply to all subsequent example diagrams which are > involved in authentication. >=20 > Please note that such a degradation may be regarded as a result of bid-do= wn > attack therefore the request will be probably rejected by the server. >=20 > Best regards, >=20 > Noriyuki Torii >=20 > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram From nobody Tue Jul 16 09:25:23 2019 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 E914E1208B4; Tue, 16 Jul 2019 09:25:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23iRkvyYCfeB; Tue, 16 Jul 2019 09:25:12 -0700 (PDT) Received: from mail-pf1-x433.google.com (mail-pf1-x433.google.com [IPv6:2607:f8b0:4864:20::433]) (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 F14171208B2; Tue, 16 Jul 2019 09:25:04 -0700 (PDT) Received: by mail-pf1-x433.google.com with SMTP id c73so9346217pfb.13; Tue, 16 Jul 2019 09:25:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=2D929abQO/y2GSuUYwc+tjtJb/eq4RenPL6tkw4KKU8=; b=CPJwlJqipydWwotbdFwOg7pBk0o4vuCZwIpXLgnkxUThB3CgJYRqeby6zG7u2ztT0F 91aTyupydbDc5XxI0vtZ/4jCY/0VyuY8YCMhT3kpPKNn0gPsMGvfo1dm7Jht3pof4nQC VBdI21PVxbbzBSO7pei6+DkDdpjfBMHM6BLD0dp79hj10j9X4qcPFWwpJjA6cEKnh67E oNSygvZZTQgf4JH6SS1+AUgUGPXToeMV2ik5ffcj7h1mUwOoNrQf8Gaz6kY2hoaD1qXO WJAHjqw2C/9SvTZA0J5Xf1RvI7MAJr6wsr3RE0o2coJqgF9oXwDKcq9Iw66BvWC7W11X LZFw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=2D929abQO/y2GSuUYwc+tjtJb/eq4RenPL6tkw4KKU8=; b=MPJ1oOOjFqBlq9fJXd3T+dpTdXpzmuEN3vvLN+Kf9yX8S5+vDHbXWqic1hsUY8ayh9 sJhKq2urnL435y5NHsooks3ZQ9DW0UdC/DkTiow9xklA7bAHv2Pl593e7ug2dpAShVlO xRtRbhVkGUNDGjr6PIYGmVFdBQjUKCR5bXD1dgY+Ro6X/Wrvg7tWtjNXcTlYQVHLQQn0 8l1loI5tetp42PUorQ3pIeIx2YZSZnBDfMh87kk1YMixXeYY+j7IZSuFBFUVBzZsUKmW Fzmwwt41OD7DuU60xj+enXUZuM1P71NHC8GOKJbU6JsRy6tMBF2EdX/qVawBboNkWzFk xx5Q== X-Gm-Message-State: APjAAAVPVt6MOjSA3cnW0ifCLC6TQfumz+gLuCXX5AKjvR6vK8aUQPUI ioYAYoalqyGfj2x2wN6wcnE= X-Google-Smtp-Source: APXvYqz1PmiHd8GK/2QMNDXRcvVtY1GG9jo19wTKHWymWTTvBaG/MBQkh7wrOpiHdN3taBfjnh5H1Q== X-Received: by 2002:a17:90a:23ce:: with SMTP id g72mr6606114pje.77.1563294304355; Tue, 16 Jul 2019 09:25:04 -0700 (PDT) Received: from sjcldanwi.lan ([75.111.84.113]) by smtp.gmail.com with ESMTPSA id 135sm20505839pfb.137.2019.07.16.09.25.02 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 16 Jul 2019 09:25:03 -0700 (PDT) From: Dan Wing Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_04756B26-C0D0-406E-A2A6-0C7A18F4E31F" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Tue, 16 Jul 2019 09:25:01 -0700 In-Reply-To: Cc: "iesg@ietf.org" , "tram-chairs@ietf.org" , "gonzalo.camarillo@ericsson.com" , "tasveren@rbbn.com" , "tram@ietf.org" To: "Felipe Garrido (fegarrid)" , "draft-ietf-tram-stun-pmtud@ietf.org" References: <153793486460.13063.13186763367840598004.idtracker@ietfa.amsl.com> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [tram] Suresh Krishnan's Discuss on draft-ietf-tram-stun-pmtud-10: (with DISCUSS) X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.29 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, 16 Jul 2019 16:25:15 -0000 --Apple-Mail=_04756B26-C0D0-406E-A2A6-0C7A18F4E31F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Jul 15, 2019, at 7:09 AM, Felipe Garrido (fegarrid) = wrote: >=20 > Hi Suresh,=20 > =20 > Does the following language satisfy your Discuss? Similar references = to IPv6 packets would be added to the other sections. > =20 > Thanks, > -Felipe > =20 > 4.1. Simple Probing Mechanism > =20 > The Simple Probing mechanism is implemented by sending a Probe > Request with a PADDING [RFC5780] attribute over UDP with the DF bit > set in the IP header for IPv4 packets and IPv6 packets without > the Fragment Header included. A router on the path to the server = can > reject this request with an ICMP message or drop it. The router could also forward the 'request' (actually, it's just an IP = packet as far as the router is concerned, it isn't a "request"), so = three things can happen to that packet. Separately, we all know some routers are configured to strip DF bits = (that is, set to zro), and some routers are configured to fragment even = if DF=3D1. Is there implementation guidance we can give to assist = detecting such behavior and learning the real underlying MTU, or should = we ignore that routers do this and would interfere with the MTU learned = by STUN-PMTUD? -d > =20 > 4.2.2. Receiving an ICMP Packet > =20 > If an ICMP packet "Fragmentation needed" or "Packet Too Big" is = received then this is > interpreted as a Probe Failure, as defined in [RFC4821] Section = 7.5. > =20 > Suresh Krishnan has entered the following ballot position for > draft-ietf-tram-stun-pmtud-10: Discuss >=20 >=20 >=20 > Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html = > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-tram-stun-pmtud/ = >=20 >=20 >=20 > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- >=20 > Section 4.1.x and 4.2.x >=20 > Please specify how this simple probing mechanism will work with IPv6. = It > shouldn't be too difficult to do (cleanup references to the DF bit, = use Type 2 > "Packet Too Big" to identify failures etc.). Similar treatment will be = required > for the complete probing mechanism as well. >=20 >=20 >=20 >=20 > =20 > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram = --Apple-Mail=_04756B26-C0D0-406E-A2A6-0C7A18F4E31F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii On = Jul 15, 2019, at 7:09 AM, Felipe Garrido (fegarrid) <fegarrid@cisco.com> = wrote:

Hi Suresh, 
 
Does the = following language satisfy your Discuss? Similar references to IPv6 = packets would be added to the other sections.
 
Thanks,
-Felipe
 
4.1.  Simple = Probing Mechanism
 
   The = Simple Probing mechanism is implemented by sending a Probe
   Request with a = PADDING [RFC5780] attribute over UDP with the DF bit
   set in the IP header = for IPv4 packets and IPv6 packets without
   the Fragment = Header included.  A router on the path to the server can
  reject this request = with an ICMP message or drop = it.

The router could also forward the 'request' = (actually, it's just an IP packet as far as the router is concerned, it = isn't a "request"), so three things can happen to that = packet.


Separately, we all know some routers are = configured to strip DF bits (that is, set to zro), and some routers are = configured to fragment even if DF=3D1.  Is there implementation = guidance we can give to assist detecting such behavior and learning the = real underlying MTU, or should we ignore that routers do this and would = interfere with the MTU learned by STUN-PMTUD?

-d


 
4.2.2.  = Receiving an ICMP Packet
 
   If = an ICMP packet "Fragmentation needed" or "Packet Too Big" is received = then this is
   = interpreted as a Probe Failure, as defined in [RFC4821] Section 7.5.
 

Suresh Krishnan has entered the following ballot position = for
draft-ietf-tram-stun-pmtud-10: Discuss


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


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



---------------------------------------------------------------= -------
DISCUSS:
---------------------------------------------------------------= -------

Section 4.1.x and 4.2.x

Please specify how this simple probing = mechanism will work with IPv6. It
shouldn't be too = difficult to do (cleanup references to the DF bit, use Type 2
"Packet Too Big" to identify failures etc.). Similar = treatment will be required
for the complete probing = mechanism as well.



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

= --Apple-Mail=_04756B26-C0D0-406E-A2A6-0C7A18F4E31F-- From nobody Wed Jul 17 05:35:11 2019 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 D3E841200F8 for ; Wed, 17 Jul 2019 05:35:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.999 X-Spam-Level: X-Spam-Status: No, score=-3.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=mcafee.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MIf1v9W2O-cH for ; Wed, 17 Jul 2019 05:35:07 -0700 (PDT) Received: from us-smtp-delivery-210.mimecast.com (us-smtp-delivery-210.mimecast.com [63.128.21.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 678631200C3 for ; Wed, 17 Jul 2019 05:35:07 -0700 (PDT) X-NAI-Header: Modified by McAfee Email Gateway (5500) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mcafee.com; s=s_mcafee; t=1563366183; h=ARC-Seal: ARC-Message-Signature:ARC-Authentication-Results: From:To:CC:Subject:Thread-Topic:Thread-Index: Date:Message-ID:References:In-Reply-To:Accept-Language: Content-Language:X-MS-Has-Attach:X-MS-TNEF-Correlator: dlp-product:dlp-version:dlp-reaction:authentication-results: x-originating-ip:x-ms-publictraffictype:x-ms-office365-filtering-correlation-id: x-microsoft-antispam:x-ms-traffictypediagnostic: x-ms-exchange-purlcount:x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers:x-forefront-prvs: x-forefront-antispam-report:received-spf:x-ms-exchange-senderadcheck: x-microsoft-antispam-message-info:Content-Type: Content-Transfer-Encoding:MIME-Version:X-MS-Exchange-CrossTenant-Network-Message-Id: X-MS-Exchange-CrossTenant-originalarrivaltime: X-MS-Exchange-CrossTenant-fromentityheader: X-MS-Exchange-CrossTenant-id:X-MS-Exchange-CrossTenant-mailboxtype: X-MS-Exchange-CrossTenant-userprincipalname: X-MS-Exchange-Transport-CrossTenantHeadersStamped: X-OriginatorOrg:X-NAI-Spam-Flag:X-NAI-Spam-Level: X-NAI-Spam-Threshold:X-NAI-Spam-Score:X-NAI-Spam-Version; bh=GhsnymRqJFfS0GIcbX+wpYHX4sN/qheiN08AZ7 0cTGk=; b=Ye3QtsrhZxmOX9sRG3ZYJ0HaXvF/mKU+pSQ4v+yv d5CqLpbuC6zI/hx/2gGACyI2RaY6KvS29pSl/Q6kQbATzNBgk9 RbSm+YbHbTEUt35p4XqOr5rkr+ERY2eR2vY2Eg6yUxvhBOdxY9 NxPq4x4VaDdbF5zckFcJABDAdmSfpSA= Received: from DNVWSMAILOUT1.mcafee.com (dnvwsmailout1.mcafee.com [161.69.31.173]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-240-gQv7uSNoMkOQfHHWRRZopw-1; Wed, 17 Jul 2019 08:33:58 -0400 Received: from DNVEXAPP1N05.corpzone.internalzone.com (DNVEXAPP1N05.corpzone.internalzone.com [10.44.48.89]) by DNVWSMAILOUT1.mcafee.com with smtp (TLS: TLSv1/SSLv3,256bits,ECDHE-RSA-AES256-SHA384) id 6bf8_3ece_d7748641_a5b6_4a22_bc16_548554a78815; Wed, 17 Jul 2019 06:23:02 -0600 Received: from DNVEXAPP1N06.corpzone.internalzone.com (10.44.48.90) by DNVEXAPP1N05.corpzone.internalzone.com (10.44.48.89) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Wed, 17 Jul 2019 06:33:40 -0600 Received: from DNVO365EDGE1.corpzone.internalzone.com (10.44.176.66) by DNVEXAPP1N06.corpzone.internalzone.com (10.44.48.90) with Microsoft SMTP Server (TLS) id 15.0.1395.4 via Frontend Transport; Wed, 17 Jul 2019 06:33:40 -0600 Received: from NAM03-DM3-obe.outbound.protection.outlook.com (10.44.176.242) by edge.mcafee.com (10.44.176.66) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Wed, 17 Jul 2019 06:33:38 -0600 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Nrnl5c/6YKGRBHm/h6Dfp081noWZdMJQf/miCKRMqmyTeBxdIVlmySqDOLCRI4svIsuIMbsUlP60p3ds9rYOu+JiZ3eX1saMNFduYwiUWAtClTnZZBMl3Nj7jMwkI94ZQ5YEOYiNbgZUVaG4ya6zkbFkbOR3fY2WVhxAoJvipeDfGYhctLMq5hlyBNrgFtGrgg6U6p64YrmsgbfRmSwLuAAgfW7Afm7zPy/Bp8hynuhSl0zFhHUosspxb+0pMeC3UHYRrwrV0SfYMHDgMm9T10LeMoJw5c7LwofOeY5d1Xyk7ZZDTobIhVLUKGZxM4Eq2+rdNohGIUB1lVbuI8nAkA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=GhsnymRqJFfS0GIcbX+wpYHX4sN/qheiN08AZ70cTGk=; b=Qb/0B5ClgLPOp9upB49sLKkrriJNhfL0hhUNb+SidXttPn1riTVCcU+sr0cpiBka8cgmFjFMh3lKnh9tYw0VJcv6eKpKM74CSnrpgt+vT2YGYifycUJCYDqVNjG+LKnE9YxXU6ioENM+F9qRahtPzm2cU+AHNZvIAIq3yRrrwK/1iC9YWBBsUZoOf8YcjuBIIp/SgNdhDEAoffJZAGZu1Hv2wjHFRrGMgN0edXQ7bEt8t8oq0h8CZ2Ru8bC+3alYLD24P+Y8HqTN9d8WmFtE0MHPvJGovjDvfJGtqvVo7FZWTJyAG2ZdhTxGdng3+yIUigE3dC+om9TGT87gIAbT9A== ARC-Authentication-Results: i=1; mx.microsoft.com 1;spf=pass smtp.mailfrom=mcafee.com;dmarc=pass action=none header.from=mcafee.com;dkim=pass header.d=mcafee.com;arc=none Received: from DM5PR16MB1705.namprd16.prod.outlook.com (10.172.44.147) by DM5PR16MB1578.namprd16.prod.outlook.com (10.173.211.12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2073.14; Wed, 17 Jul 2019 12:33:37 +0000 Received: from DM5PR16MB1705.namprd16.prod.outlook.com ([fe80::570:2208:75c2:5f17]) by DM5PR16MB1705.namprd16.prod.outlook.com ([fe80::570:2208:75c2:5f17%8]) with mapi id 15.20.2073.012; Wed, 17 Jul 2019 12:33:37 +0000 From: "Konda, Tirumaleswar Reddy" To: Roman Danyliw , The IESG CC: "tram-chairs@ietf.org" , "draft-ietf-tram-turnbis@ietf.org" , "tram@ietf.org" , "brandon.williams@akamai.com" Thread-Topic: [tram] Roman Danyliw's Discuss on draft-ietf-tram-turnbis-27: (with DISCUSS and COMMENT) Thread-Index: AQHVN3Hb8rvCrm8yiE+tXfblQrByi6bE8P0wgAFCzQCAAHZQIIAH6ZqQ Date: Wed, 17 Jul 2019 12:33:37 +0000 Message-ID: References: <156279899179.15443.1948808943181719878.idtracker@ietfa.amsl.com> <359EC4B99E040048A7131E0F4E113AFC01B33CE08D@marchand> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.3.0.16 dlp-reaction: no-action x-originating-ip: [49.37.206.28] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: a6b1f1e6-cd0d-4452-2e43-08d70ab2fdfc x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:DM5PR16MB1578; x-ms-traffictypediagnostic: DM5PR16MB1578: x-ms-exchange-purlcount: 5 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 01018CB5B3 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(346002)(366004)(376002)(39860400002)(396003)(136003)(32952001)(199004)(189003)(51914003)(13464003)(71190400001)(80792005)(186003)(305945005)(52536014)(71200400001)(229853002)(4326008)(3846002)(33656002)(7736002)(6116002)(25786009)(11346002)(476003)(478600001)(966005)(74316002)(446003)(5660300002)(66574012)(256004)(5024004)(14444005)(2906002)(81156014)(8936002)(81166006)(14454004)(9686003)(6306002)(7696005)(68736007)(66066001)(55016002)(6436002)(110136005)(54906003)(86362001)(26005)(6506007)(53546011)(102836004)(6246003)(8676002)(99286004)(486006)(66556008)(76116006)(316002)(53936002)(64756008)(66476007)(66946007)(76176011)(66446008)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR16MB1578; H:DM5PR16MB1705.namprd16.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: K9A3BZS9m0OK8X/Og9CrQzB5I1UYK1auVCuyJxHP8Gk1Te8Q+1MJGiw6ggSMkwoE7kcnsayxaKi3RVBwaa3sphkrdr3DJJ8VoNzddu0X77ZdLuqTN3AaLkqLKt/kkGFC27X/qe5ZdSy/exCv3XwMHvvrDtQidiXqD8wk+Mpa2weeRKk2peu1k/d0gXA1tvcvZIedYChtaATTqwmkXOiAzV9G4aBewGG1Nsw2RdIa6Ss5fDC4JgixwZWyYcbx+jPEnVXVuj8pAiHPL0c+eoNkEwPmSn+YZ9NofelGsXtJZqZQfzpDwQja9FIAMXZ+iiCMSsTtPNCW40Dq/qpxXX9N0xQZ6yjItwQ4f/ZmsMH+XR+mCZeCaFxcF59SDG48AV/IHms4ufx8Yu9a7Ohetq7yB0Xyh7p5XbvG5lDpvp53yNY= MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: a6b1f1e6-cd0d-4452-2e43-08d70ab2fdfc X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Jul 2019 12:33:37.7062 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: TirumaleswarReddy_Konda@McAfee.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR16MB1578 X-OriginatorOrg: mcafee.com X-NAI-Spam-Flag: NO X-NAI-Spam-Level: X-NAI-Spam-Threshold: 15 X-NAI-Spam-Score: 0.3 X-NAI-Spam-Version: 2.3.0.9418 : core <6591> : inlines <7120> : streams <1827614> : uri <2868588> X-MC-Unique: gQv7uSNoMkOQfHHWRRZopw-1 X-Mimecast-Spam-Score: 0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Archived-At: Subject: Re: [tram] Roman Danyliw's Discuss on draft-ietf-tram-turnbis-27: (with DISCUSS and COMMENT) X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.29 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 Jul 2019 12:35:10 -0000 SGkgUm9tYW4sDQoNCkkgaGF2ZSB1cGRhdGVkIHRoZSBkcmFmdCB0byBhZGRyZXNzIHlvdXIgRGlz Y3VzcyBhbmQgY29tbWVudHMgKHNlZSBodHRwczovL2dpdGh1Yi5jb20vdGlyZWRkeTIvVFVSTmJp cy9ibG9iL21hc3Rlci9EaWZmJTIwJTIwZHJhZnQtaWV0Zi10cmFtLXR1cm5iaXMtMjcudHh0JTIw LSUyMGRyYWZ0LWlldGYtdHJhbS10dXJuYmlzLTI4LnBkZikuIA0KUGxlYXNlIGhhdmUgYSBsb29r Lg0KDQpDaGVlcnMsDQotVGlydQ0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZy b206IEtvbmRhLCBUaXJ1bWFsZXN3YXIgUmVkZHkNCj4gU2VudDogRnJpZGF5LCBKdWx5IDEyLCAy MDE5IDI6NDMgUE0NCj4gVG86IFJvbWFuIERhbnlsaXcgPHJkZEBjZXJ0Lm9yZz47IFRoZSBJRVNH IDxpZXNnQGlldGYub3JnPg0KPiBDYzogdHJhbS1jaGFpcnNAaWV0Zi5vcmc7IGRyYWZ0LWlldGYt dHJhbS10dXJuYmlzQGlldGYub3JnOyB0cmFtQGlldGYub3JnOw0KPiBicmFuZG9uLndpbGxpYW1z QGFrYW1haS5jb20NCj4gU3ViamVjdDogUkU6IFt0cmFtXSBSb21hbiBEYW55bGl3J3MgRGlzY3Vz cyBvbiBkcmFmdC1pZXRmLXRyYW0tdHVybmJpcy0yNzoNCj4gKHdpdGggRElTQ1VTUyBhbmQgQ09N TUVOVCkNCj4gDQo+IEhpIFJvbWFuLA0KPiANCj4gUGxlYXNlIHNlZSBpbmxpbmUNCj4gDQo+ID4g LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPiBGcm9tOiBSb21hbiBEYW55bGl3IDxyZGRA Y2VydC5vcmc+DQo+ID4gU2VudDogRnJpZGF5LCBKdWx5IDEyLCAyMDE5IDc6MDAgQU0NCj4gPiBU bzogS29uZGEsIFRpcnVtYWxlc3dhciBSZWRkeQ0KPiA+IDxUaXJ1bWFsZXN3YXJSZWRkeV9Lb25k YUBNY0FmZWUuY29tPjsgVGhlIElFU0cgPGllc2dAaWV0Zi5vcmc+DQo+ID4gQ2M6IHRyYW0tY2hh aXJzQGlldGYub3JnOyBkcmFmdC1pZXRmLXRyYW0tdHVybmJpc0BpZXRmLm9yZzsNCj4gPiB0cmFt QGlldGYub3JnOyBicmFuZG9uLndpbGxpYW1zQGFrYW1haS5jb20NCj4gPiBTdWJqZWN0OiBSRTog W3RyYW1dIFJvbWFuIERhbnlsaXcncyBEaXNjdXNzIG9uIGRyYWZ0LWlldGYtdHJhbS10dXJuYmlz LTI3Og0KPiA+ICh3aXRoIERJU0NVU1MgYW5kIENPTU1FTlQpDQo+ID4NCj4gPiBUaGlzIGVtYWls IG9yaWdpbmF0ZWQgZnJvbSBvdXRzaWRlIG9mIHRoZSBvcmdhbml6YXRpb24uIERvIG5vdCBjbGlj aw0KPiA+IGxpbmtzIG9yIG9wZW4gYXR0YWNobWVudHMgdW5sZXNzIHlvdSByZWNvZ25pemUgdGhl IHNlbmRlciBhbmQga25vdyB0aGUNCj4gPiBjb250ZW50IGlzIHNhZmUuDQo+ID4NCj4gPiBIaSBU aXJ1IQ0KPiA+DQo+ID4gPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+ID4gRnJvbTog aWVzZyBbbWFpbHRvOmllc2ctYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEtvbmRhLA0K PiA+ID4gVGlydW1hbGVzd2FyIFJlZGR5DQo+ID4gPiBTZW50OiBUaHVyc2RheSwgSnVseSAxMSwg MjAxOSA1OjA3IEFNDQo+ID4gPiBUbzogUm9tYW4gRGFueWxpdyA8cmRkQGNlcnQub3JnPjsgVGhl IElFU0cgPGllc2dAaWV0Zi5vcmc+DQo+ID4gPiBDYzogdHJhbS1jaGFpcnNAaWV0Zi5vcmc7IGRy YWZ0LWlldGYtdHJhbS10dXJuYmlzQGlldGYub3JnOw0KPiA+ID4gdHJhbUBpZXRmLm9yZzsgYnJh bmRvbi53aWxsaWFtc0Bha2FtYWkuY29tDQo+ID4gPiBTdWJqZWN0OiBSRTogW3RyYW1dIFJvbWFu IERhbnlsaXcncyBEaXNjdXNzIG9uIGRyYWZ0LWlldGYtdHJhbS10dXJuYmlzLTI3Og0KPiA+ID4g KHdpdGggRElTQ1VTUyBhbmQgQ09NTUVOVCkNCj4gPiA+DQo+ID4gPiBIaSBSb21hbiwNCj4gPiA+ DQo+ID4gPiBUaGFua3MgZm9yIHRoZSByZXZpZXcuIFBsZWFzZSBzZWUgaW5saW5lDQo+ID4gPg0K PiA+ID4gPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+ID4gPiBGcm9tOiB0cmFtIDx0 cmFtLWJvdW5jZXNAaWV0Zi5vcmc+IE9uIEJlaGFsZiBPZiBSb21hbiBEYW55bGl3IHZpYQ0KPiA+ ID4gPiBEYXRhdHJhY2tlcg0KPiA+ID4gPiBTZW50OiBUaHVyc2RheSwgSnVseSAxMSwgMjAxOSA0 OjIwIEFNDQo+ID4gPiA+IFRvOiBUaGUgSUVTRyA8aWVzZ0BpZXRmLm9yZz4NCj4gPiA+ID4gQ2M6 IHRyYW0tY2hhaXJzQGlldGYub3JnOyBkcmFmdC1pZXRmLXRyYW0tdHVybmJpc0BpZXRmLm9yZzsN Cj4gPiA+ID4gdHJhbUBpZXRmLm9yZzsgYnJhbmRvbi53aWxsaWFtc0Bha2FtYWkuY29tDQo+ID4g PiA+IFN1YmplY3Q6IFt0cmFtXSBSb21hbiBEYW55bGl3J3MgRGlzY3VzcyBvbiBkcmFmdC1pZXRm LXRyYW0tdHVybmJpcy0yNzoNCj4gPiA+ID4gKHdpdGggRElTQ1VTUyBhbmQgQ09NTUVOVCkNCj4g PiA+ID4NCj4gPiA+ID4gVGhpcyBlbWFpbCBvcmlnaW5hdGVkIGZyb20gb3V0c2lkZSBvZiB0aGUg b3JnYW5pemF0aW9uLiBEbyBub3QNCj4gPiA+ID4gY2xpY2sgbGlua3Mgb3Igb3BlbiBhdHRhY2ht ZW50cyB1bmxlc3MgeW91IHJlY29nbml6ZSB0aGUgc2VuZGVyDQo+ID4gPiA+IGFuZCBrbm93IHRo ZSBjb250ZW50IGlzIHNhZmUuDQo+ID4gPiA+DQo+ID4gPiA+IFJvbWFuIERhbnlsaXcgaGFzIGVu dGVyZWQgdGhlIGZvbGxvd2luZyBiYWxsb3QgcG9zaXRpb24gZm9yDQo+ID4gPiA+IGRyYWZ0LWll dGYtdHJhbS10dXJuYmlzLTI3OiBEaXNjdXNzDQo+ID4gPiA+DQo+ID4gPiA+IFdoZW4gcmVzcG9u ZGluZywgcGxlYXNlIGtlZXAgdGhlIHN1YmplY3QgbGluZSBpbnRhY3QgYW5kIHJlcGx5IHRvDQo+ ID4gPiA+IGFsbCBlbWFpbCBhZGRyZXNzZXMgaW5jbHVkZWQgaW4gdGhlIFRvIGFuZCBDQyBsaW5l cy4gKEZlZWwgZnJlZSB0bw0KPiA+ID4gPiBjdXQgdGhpcyBpbnRyb2R1Y3RvcnkgcGFyYWdyYXBo LCBob3dldmVyLikNCj4gPiA+ID4NCj4gPiA+ID4NCj4gPiA+ID4gUGxlYXNlIHJlZmVyIHRvDQo+ ID4gPiA+IGh0dHBzOi8vd3d3LmlldGYub3JnL2llc2cvc3RhdGVtZW50L2Rpc2N1c3MtY3JpdGVy aWEuaHRtbA0KPiA+ID4gPiBmb3IgbW9yZSBpbmZvcm1hdGlvbiBhYm91dCBJRVNHIERJU0NVU1Mg YW5kIENPTU1FTlQgcG9zaXRpb25zLg0KPiA+ID4gPg0KPiA+ID4gPg0KPiA+ID4gPiBUaGUgZG9j dW1lbnQsIGFsb25nIHdpdGggb3RoZXIgYmFsbG90IHBvc2l0aW9ucywgY2FuIGJlIGZvdW5kIGhl cmU6DQo+ID4gPiA+IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYt dHJhbS10dXJuYmlzLw0KPiA+ID4gPg0KPiA+ID4gPg0KPiA+ID4gPg0KPiA+ID4gPiAtLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0NCj4gPiA+ID4gLS0NCj4gPiA+ID4gLS0NCj4gPiA+ID4gRElTQ1VTUzoNCj4gPiA+ID4gLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tDQo+ID4gPiA+IC0tDQo+ID4gPiA+IC0tDQo+ID4gPiA+DQo+ID4gPiA+ICgxKSBTZWN0 aW9uIDEyLjEuNi4gIChQZXIgdGhlIGJhY2stYW5kLWZvcnRoIG9uIENocmlzIFdvb2TigJlzDQo+ ID4gPiA+IFNFQ0RJUiByZXZpZXcg4oCTIHRoYW5rIHlvdSBDaHJpcyEpIFBlciDigJxDb25maWRl bnRpYWxpdHkgaXMgb25seSBhDQo+ID4gPiA+IHNlY29uZGFyeSBjb25jZXJuLCBhcyBUVVJOIGNv bnRyb2wgbWVzc2FnZXMgZG8gbm90IGluY2x1ZGUNCj4gPiA+ID4gaW5mb3JtYXRpb24gdGhhdCBp cyBwYXJ0aWN1bGFybHkgc2Vuc2l0aXZl4oCdLCB3b3VsZG7igJl0IHRoZSBVU0VSTkFNRQ0KPiA+ ID4gPiBhbmQgUkVBTE0gcG90ZW50aWFsbHkgYmUgcHJpdmFjeSBzZW5zaXRpdmU/ICBJZiB0aGV5 IGFyZW7igJl0DQo+ID4gPiA+IHNlbnNpdGl2ZSBpbiBhbGwgY2FzZXMgKGUuZy4sIHVzZXJuYW1l cyBtaWdodCBiZSBlcGhlbWVyYWwpLCB0aGlzIHNob3VsZA0KPiBiZSBub3RlZCBhbmQgY2l0ZWQu DQo+ID4gPg0KPiA+ID4gQWdyZWVkLCBhZGRlZCB0aGUgZm9sbG93aW5nIHBhcmFncmFwaDoNCj4g PiA+DQo+ID4gPiAgICBJZiB0aGUgVFVSTiBjbGllbnQgYW5kIHNlcnZlciB1c2UgdGhlIFNUVU4g RXh0ZW5zaW9uIGZvciBUaGlyZC1QYXJ0eQ0KPiA+ID4gICAgQXV0aG9yaXphdGlvbiBbUkZDNzYz NV0gKGZvciBleGFtcGxlIGl0IGlzIHVzZWQgaW4gV2ViUlRDKSwgdGhlDQo+ID4gPiAgICB1c2Vy bmFtZSBkb2VzIG5vdCByZXZlYWwgdGhlIHJlYWwgdXNlcidzIGlkZW50aXR5LCB0aGUgVVNFUk5B TUUNCj4gPiA+ICAgIGF0dHJpYnV0ZSBjYXJyaWVzIGFuIGVwaGVtZXJhbCBhbmQgdW5pcXVlIGtl eSBpZGVudGlmaWVyLiAgSWYgdGhlDQo+ID4gPiAgICBUVVJOIGNsaWVudCBhbmQgc2VydmVyIHVz ZSB0aGUgU1RVTiBsb25nLXRlcm0gY3JlZGVudGlhbCBtZWNoYW5pc20NCj4gPiA+ICAgIGFuZCB0 aGUgdXNlcm5hbWUgcmV2ZWFscyB0aGUgcmVhbCB1c2VyJ3MgaWRlbnRpdHksIHRoZSBjbGllbnQg bmVlZHMNCj4gPiA+ICAgIHRvIHVzZSAoRClUTFMgdHJhbnNwb3J0IGJldHdlZW4gdGhlIGNsaWVu dCBhbmQgdGhlIHNlcnZlciBvciB1c2UgdGhlDQo+ID4gPiAgICBVU0VSSEFTSCBhdHRyaWJ1dGUg aW5zdGVhZCBvZiB0aGUgVVNFUk5BTUUgYXR0cmlidXRlIHRvIGFub255bm1pemUNCj4gPiA+ICAg IHRoZSB1c2VybmFtZS4NCj4gPiA+DQo+ID4gPiAgICBJZiB0aGUgVFVSTiBjbGllbnQgYW5kIHNl cnZlciB1c2UgdGhlIFNUVU4gbG9uZy10ZXJtIGNyZWRlbnRpYWwNCj4gPiA+ICAgIG1lY2hhbmlz bSBhbmQgcmVhbG0gaW5mb3JtYXRpb24gaXMgcHJpdmFjeSBzZW5zaXRpdmUsIFRVUk4gY2FuIGJl IHJ1bg0KPiA+ID4gICAgb3ZlciAoRClUTFMuICBBcyBhIHJlbWluZGVyLCBTVFVOIEV4dGVuc2lv biBmb3IgVGhpcmQtUGFydHkNCj4gPiA+ICAgIEF1dGhvcml6YXRpb24gZG9lcyBub3QgdXNlIHJl YWxtLg0KPiA+DQo+ID4gVGhhbmsgeW91LiAgVGhpcyB0ZXh0IHdvdWxkIGFkZHJlc3MgbXkgY29u Y2Vybi4NCj4gPg0KPiA+ID4gPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gPiA+ID4gLS0NCj4gPiA+ID4gLS0NCj4g PiA+ID4gQ09NTUVOVDoNCj4gPiA+ID4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ID4gPiA+IC0tDQo+ID4gPiA+IC0t DQo+ID4gPiA+DQo+ID4gPiA+ICgyKSBUaGlzIGRyYWZ0IHJlbGllcyBvbiB0aGUgZHJhZnQtaWV0 Zi10cmFtLXN0dW5iaXPigJlzIFNUVU4NCj4gPiA+ID4gUGFzc3dvcmQgQWxnbyBSZWdpc3RyeSB3 aGljaCBoYXMgTUQ1IGFuZCBTSEEtMjU2LiAgU2VjdGlvbiAxNi4xLjENCj4gPiA+ID4gb2YgdGhh dCBkcmFmdCBhbHJlYWR5IGRpc2N1c3NlcyB0aGUgbGltaXRhdGlvbiBvZiBTSEEtMjU2ICh3aGlj aA0KPiA+ID4gPiBpdCBtaWdodCBiZSB1c2VmdWwgdG8NCj4gPiA+IHJlZmVyZW5jZSkuDQo+ID4g PiA+IE5ldmVydGhlbGVzcywgYXJlIHRoZXJlIGNhc2VzIHdoZXJlIE1ENSBzaG91bGQgYmUgdXNl ZCBvdmVyDQo+ID4gPiA+IFNIQS0yNTYgaWYgdGhlcmUgaXMgYSBjaG9pY2U/ICBJcyB0aGVyZSBh IHJlYXNvbiBub3QgdG8gcmVjb21tZW5kDQo+ID4gPiA+IHRoYXQgaW1wbGVtZW50YXRpb25zIOKA nFNIT1VMRCBOT1QgdXNlIE1ENeKAnT8NCj4gPiA+DQo+ID4gPiBUaGUgb25seSByZWFzb24gZHJh ZnQtaWV0Zi10cmFtLXN0dW5iaXMgcmV0YWluZWQgTUQ1IGlzIGZvcg0KPiA+ID4gYmFja3dhcmQt IGNvbXBhdGliaWxpdHkgKGNsaWVudCB1c2luZyBvbGRlciB2ZXJzaW9uIG9mIFNUVU4gKFJGQzUz ODkpKS4NCj4gPg0KPiA+IFVuZGVyc3Rvb2QuICBDb3VsZCB3ZSBzYXkgc29tZXRoaW5nIG9uIHRo ZSBvcmRlciBvZiAiaWYgYSBjbGllbnQNCj4gPiBzdXBwb3J0cyBib3RoIE1ENSBhbmQgU0hBLTI1 NiwgdGhlIGxhdHRlciBTSE9VTEQgQkUgdXNlZCI/DQo+IA0KPiBZZXMsIG1vZGlmaWVkIHRoZSBh Ym92ZSB0ZXh0IGFzIGZvbGxvd3M6DQo+IA0KPiBOb3RlIHRoYXQgaWYgdGhlIHJlc3BvbnNlIGNv bnRhaW5zIGEgUEFTU1dPUkQtQUxHT1JJVEhNUyBhdHRyaWJ1dGUgYW5kDQo+IHRoaXMgYXR0cmli dXRlIGNvbnRhaW5zIGJvdGggTUQ1IGFuZCBTSEEtMjU2IGFsZ29yaXRobXMsIGFuZCB0aGUgY2xp ZW50IGFsc28NCj4gc3VwcG9ydHMgYm90aCB0aGUgYWxnb3JpdGhtcywgdGhlIHJlcXVlc3QgTVVT VCBjb250YWluIGEgUEFTU1dPUkQtDQo+IEFMR09SSVRITSBhdHRyaWJ1dGUgd2l0aCB0aGUgU0hB LTI1NiBhbGdvcml0aG0uDQo+IA0KPiBDaGVlcnMsDQo+IC1UaXJ1DQo+IA0KPiA+DQo+ID4gPiA+ DQo+ID4gPiA+ICgzKSBTZWN0aW9uIDUuIFBlciDigJxUaGUgY2xpZW50IFNIT1VMRCBpbmNsdWRl IHRoZSBTT0ZUV0FSRSDigKbigJ0gYW5kDQo+ID4gPiA+IOKAnFRoZSBjbGllbnQgYW5kIHRoZSBz ZXJ2ZXIgTUFZIGluY2x1ZGUgdGhlIEZJTkdFUlBSSU5UIGF0dHJpYnV0ZQ0KPiA+ID4gPiDigKbi gJ0sIHdoeSBpcyB0aGUgc2VuZGluZyBvZiBTT0ZUV0FSRSBub3QgYSDigJxNQVnigJ0gdG9vPw0K PiA+ID4NCj4gPiA+IFRoaXMgc2FtZSBiZWhhdmlvciBpcyBkZWZpbmVkIGluIFJGQzU3NjYgYW5k IHR1cm5iaXMgZG9lcyBub3QgbW9kaWZ5DQo+ID4gPiB0aGUgYmVoYXZpb3IsIGFuZCB0byBhZGRy ZXNzIHRoZSBjb21tZW50IGZyb20gQ2hyaXMgV29vZCAoU2VjZGlyDQo+ID4gPiByZXZpZXcpIGFk ZGVkIHRoZSBmb2xsb3dpbmcgbGluZSB0byBTZWN1cml0eSBDb25zaWRlcmF0aW9ucyBzZWN0aW9u Og0KPiA+ID4NCj4gPiA+IFNPRlRXQVJFIGF0dHJpYnV0ZSBjYW4gcmV2ZWFsIHRoZSBzcGVjaWZp YyBzb2Z0d2FyZSB2ZXJzaW9uIG9mIHRoZQ0KPiA+ID4gVFVSTiBjbGllbnQgYW5kIHNlcnZlciB0 byBlYXZlc2Ryb3BwZXIgYW5kIGl0IG1pZ2h0IHBvc3NpYmx5IGFsbG93DQo+ID4gPiBhdHRhY2tz IGFnYWluc3QgdnVsbmVyYWJsZSBzb2Z0d2FyZSB0aGF0IGlzIGtub3duIHRvIGNvbnRhaW4NCj4g PiA+IHNlY3VyaXR5IGhvbGVzLiBJZiBpdCBpcyBpbXBvcnRhbnQgdG8gcHJldmVudCBhbiBlYXZl c2Ryb3BwZXIgZnJvbQ0KPiA+ID4gbGVhcm5pbmcgdGhlIHNvZnR3YXJlIHZlcnNpb24sIFRVUk4g Y2FuIGJlIHJ1biBvdmVyIChEKVRMUy4NCj4gPg0KPiA+IFVuZGVyc3Rvb2QuICBJIGNhbiBsaXZl IHdpdGggYW4gYXJndW1lbnQgdGhhdCB0dXJuYmlzIHNob3VsZG4ndCBtb2RpZnkNCj4gPiB0aGUg YmVoYXZpb3IgaW4gdGhpcyBjYXNlIGdpdmVuIHRoaXMgYWRkaXRpb25hbCAoaGVscGZ1bCkgbGFu Z3VhZ2UuICBUaGFua3MuDQo+ID4NCj4gPiA+ID4NCj4gPiA+ID4gKDQpIFNlY3Rpb24gNS4gIChQ ZXIgdGhlIGJhY2stYW5kLWZvcnRoIG9uIENocmlzIFdvb2TigJlzIFNFQ0RJUg0KPiA+ID4gPiBy ZXZpZXcpIFJlY29tbWVuZCBjaXRpbmcgU2VjdGlvbiA2LjMuMSBvZg0KPiA+ID4gPiBbZHJhZnQt aWV0Zi10cmFtLXN0dW5iaXNdIGFzIHNvdXJjZSBvZiA0MCBzZWNvbmQgcmVxdWVzdCBidWZmZXIN Cj4gPiA+ID4gdGltZW91dA0KPiA+ID4NCj4gPiA+IERvbmUuDQo+ID4NCj4gPiBUaGFua3MuDQo+ ID4NCj4gPiA+ID4NCj4gPiA+ID4gKDUpIFNlY3Rpb24gMjEuNC4gIFBlciDigJxJdCBpcyBSRUNP TU1FTkRFRCB0aGF0IFRVUk4gc2VydmVycyBub3QNCj4gPiA+ID4gYWNjZXB0IGFsbG9jYXRpb24g b3IgY2hhbm5lbCBiaW5kaW5nIHJlcXVlc3RzIGZyb20gYWRkcmVzc2VzIGtub3duDQo+ID4gPiA+ IHRvIGJlIHR1bm5lbGVk4oCdLCBJIGNvbmN1ciB3aXRoIHRoZSBhZHZpY2UuICBIb3cgd291bGQg b25lDQo+ID4gPiA+IHJlY29nbml6ZSB0aGF0IHRoZSBhZGRyZXNzIGlzIGJlaW5nIHR1bm5lbGVk Pw0KPiA+ID4NCj4gPiA+IEJ5IG1hbmFnaW5nIGRyb3AtbGlzdCBvZiB0dW5uZWwgSVAgYWRkcmVz c2VzLCBpdCBpcyB0aGUgc2FtZQ0KPiA+ID4gdGVjaG5pcXVlIHVzZWQgYnkgc2V2ZXJhbCB3ZWJz aXRlcyB0byBibG9jayBWUE4gYWNjZXNzIChzZWUNCj4gPiA+IGh0dHBzOi8vd3d3Lmhvd3RvZ2Vl ay5jb20vNDAzNzcxL3doeS1kby1zb21lLXdlYnNpdGVzLWJsb2NrLQ0KPiA+IHZwbnMvKQ0KPiA+ DQo+ID4gUmlnaHQuICBJIGRpZG4ndCBrbm93IGlmIHRoZXJlIHdhcyBzb21ldGhpbmcgZmFuY2ll ciBJIHdhcyBtaXNzaW5nLg0KPiA+DQo+ID4gSSBhcHByZWNpYXRlIHRoZXNlIGNoYW5nZXMgYW5k IGV4cGxhbmF0aW9ucyENCj4gPg0KPiA+IFJvbWFuDQo+ID4NCj4gPg0KPiA+ID4gQ2hlZXJzLA0K PiA+ID4gLVRpcnUNCj4gPiA+DQo+ID4gPiA+DQo+ID4gPiA+DQo+ID4gPiA+IF9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4gPiA+IHRyYW0gbWFpbGlu ZyBsaXN0DQo+ID4gPiA+IHRyYW1AaWV0Zi5vcmcNCj4gPiA+ID4gaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby90cmFtDQo= From nobody Wed Jul 17 05:50:12 2019 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 2F7C812004D for ; Wed, 17 Jul 2019 05:50:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.999 X-Spam-Level: X-Spam-Status: No, score=-3.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=mcafee.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v5SK2or1674R for ; Wed, 17 Jul 2019 05:50:07 -0700 (PDT) Received: from us-smtp-delivery-210.mimecast.com (us-smtp-delivery-210.mimecast.com [63.128.21.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A2BD1200DE for ; Wed, 17 Jul 2019 05:50:07 -0700 (PDT) X-NAI-Header: Modified by McAfee Email Gateway (5500) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mcafee.com; s=s_mcafee; t=1563366232; h=ARC-Seal: ARC-Message-Signature:ARC-Authentication-Results: From:To:CC:Subject:Thread-Topic:Thread-Index: Date:Message-ID:References:In-Reply-To:Accept-Language: Content-Language:X-MS-Has-Attach:X-MS-TNEF-Correlator: dlp-product:dlp-version:dlp-reaction:authentication-results: x-originating-ip:x-ms-publictraffictype:x-ms-office365-filtering-correlation-id: x-microsoft-antispam:x-ms-traffictypediagnostic: x-ms-exchange-purlcount:x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers:x-forefront-prvs: x-forefront-antispam-report:received-spf:x-ms-exchange-senderadcheck: x-microsoft-antispam-message-info:Content-Type: Content-Transfer-Encoding:MIME-Version:X-MS-Exchange-CrossTenant-Network-Message-Id: X-MS-Exchange-CrossTenant-originalarrivaltime: X-MS-Exchange-CrossTenant-fromentityheader: X-MS-Exchange-CrossTenant-id:X-MS-Exchange-CrossTenant-mailboxtype: X-MS-Exchange-CrossTenant-userprincipalname: X-MS-Exchange-Transport-CrossTenantHeadersStamped: X-OriginatorOrg:X-NAI-Spam-Flag:X-NAI-Spam-Level: X-NAI-Spam-Threshold:X-NAI-Spam-Score:X-NAI-Spam-Version; bh=XIxL5PXtTOv2leRRPTqjKq/M6bwawwaTmcqg67 7UgYY=; b=Vt83B0iccUu7wvE9j+cLvNnvdCttIdxzNFhcmiQ0 gRfori/Jm/mulVuIykzS/bA6JayOMbPa9R12B9oy5Vpi/ZDekN peU2CPX15L21ZVhhfJNuuLgVqhLrRDEv09AfgGOiTGioQT3R0l A70zmF4Zp45J2wKlxT826QjPOWPjCK0= Received: from DNVWSMAILOUT1.mcafee.com (dnvwsmailout1.mcafee.com [161.69.31.173]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-244-mOPfTrtiMN2k953TwVTrMw-1; Wed, 17 Jul 2019 08:34:48 -0400 Received: from DNVEXAPP1N04.corpzone.internalzone.com (DNVEXAPP1N04.corpzone.internalzone.com [10.44.48.88]) by DNVWSMAILOUT1.mcafee.com with smtp (TLS: TLSv1/SSLv3,256bits,ECDHE-RSA-AES256-SHA384) id 6bf8_4068_b5c46a7b_3fa2_45d2_8941_56e794881cb7; Wed, 17 Jul 2019 06:23:51 -0600 Received: from DNVEXAPP1N04.corpzone.internalzone.com (10.44.48.88) by DNVEXAPP1N04.corpzone.internalzone.com (10.44.48.88) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Wed, 17 Jul 2019 06:34:43 -0600 Received: from DNVO365EDGE2.corpzone.internalzone.com (10.44.176.74) by DNVEXAPP1N04.corpzone.internalzone.com (10.44.48.88) with Microsoft SMTP Server (TLS) id 15.0.1395.4 via Frontend Transport; Wed, 17 Jul 2019 06:34:43 -0600 Received: from NAM03-DM3-obe.outbound.protection.outlook.com (10.44.176.242) by edge.mcafee.com (10.44.176.74) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Wed, 17 Jul 2019 06:34:41 -0600 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=RjJQJdTldhstoFjEAICM6W28s7QBkj1N3p3YYuqKQuRNpjcapC3QlTJo1YvdgUqycJSNoD5RO8DChq+dZx9smjgb+9zb1yfpMmoX/bj43n6n1j1hqBUE61LHhjS4KEVDmJ6dPqsihJWbuKy3RUXOGW5QnYCSiu7/1nT5t9lE/wXXqn8m/gbuXy2cEBDreke9qYM5QFYRVLB4z3AehiSudB+ZYeADm0foyf1mf9dOpb3RiqDSc2DLprYN+e2atrzqJg1N9xFs2WXiYjWmYi5nuSPSwdkmvadxz55SG/qBcenU52D8T0rXCUoui4KwYdBOs6Q2J0FkRcMLzYdRAST9iA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=XIxL5PXtTOv2leRRPTqjKq/M6bwawwaTmcqg677UgYY=; b=VoDxI+LhC110nEecbe8l7d/FU5jcbSxRCTUCw/CqhtCZPF1YfuG1keHn56lQuyD/twNvu6sQXOLN4slGVg9w73/dxg9naWBnK7aI54qJFyTQXuJCh4zlpLM2n+1VtDRs3dJGHROWaqSR5yVbzhqa0ubYrt6ru1uuhfgVNPqe8utyEIBjufLouAzek8PuDg6J3C0HEUUkSt9kMzlgLMev8/+B9oMTF9tE0AJWLy3td0tAhiv+sI7ba7SLaIWDwizRNd3XQxEIk6UAEuq0lAnZ0P+Uf08fqNxUMnRZvlFR8OuAdGZSlWibYYEQf9rrV/jEVLTVv9kUKUiRRRwpzxs4pA== ARC-Authentication-Results: i=1; mx.microsoft.com 1;spf=pass smtp.mailfrom=mcafee.com;dmarc=pass action=none header.from=mcafee.com;dkim=pass header.d=mcafee.com;arc=none Received: from DM5PR16MB1705.namprd16.prod.outlook.com (10.172.44.147) by DM5PR16MB1578.namprd16.prod.outlook.com (10.173.211.12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2073.14; Wed, 17 Jul 2019 12:34:41 +0000 Received: from DM5PR16MB1705.namprd16.prod.outlook.com ([fe80::570:2208:75c2:5f17]) by DM5PR16MB1705.namprd16.prod.outlook.com ([fe80::570:2208:75c2:5f17%8]) with mapi id 15.20.2073.012; Wed, 17 Jul 2019 12:34:41 +0000 From: "Konda, Tirumaleswar Reddy" To: Benjamin Kaduk CC: The IESG , "tram-chairs@ietf.org" , "draft-ietf-tram-turnbis@ietf.org" , "tram@ietf.org" , "brandon.williams@akamai.com" Thread-Topic: [tram] Benjamin Kaduk's Discuss on draft-ietf-tram-turnbis-27: (with DISCUSS and COMMENT) Thread-Index: AQHVN6sj5hqeZIdQXEa8/G2g6Mwv66bFIQEggAKxEACAAC4dEIAGk5Ww Date: Wed, 17 Jul 2019 12:34:41 +0000 Message-ID: References: <156282359426.15056.17118634579091500165.idtracker@ietfa.amsl.com> <20190713021429.GR16418@mit.edu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.3.0.16 dlp-reaction: no-action x-originating-ip: [49.37.206.28] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 19eddaa3-fa7b-4970-f725-08d70ab323fd x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:DM5PR16MB1578; x-ms-traffictypediagnostic: DM5PR16MB1578: x-ms-exchange-purlcount: 7 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 01018CB5B3 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(346002)(366004)(376002)(39860400002)(396003)(136003)(32952001)(199004)(189003)(51914003)(54094003)(13464003)(71190400001)(80792005)(186003)(305945005)(52536014)(71200400001)(229853002)(4326008)(3846002)(33656002)(7736002)(6116002)(25786009)(11346002)(476003)(478600001)(30864003)(966005)(74316002)(446003)(5660300002)(256004)(5024004)(14444005)(2906002)(81156014)(8936002)(81166006)(14454004)(9686003)(6306002)(7696005)(53946003)(6916009)(68736007)(66066001)(55016002)(6436002)(54906003)(86362001)(26005)(2171002)(6506007)(53546011)(102836004)(6246003)(8676002)(99286004)(486006)(66556008)(76116006)(316002)(53936002)(64756008)(66476007)(66946007)(76176011)(66446008)(85282002)(579004)(559001); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR16MB1578; H:DM5PR16MB1705.namprd16.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: PJMPIt6y1geM0UnlsSbF11YnoxKwIgmLHK9TqeTVdYFspEU2wbM1e5NUX7J3okvwDGH76N5fY7lTjp/2MH2QxoMtneC3XyR20LC/VI0Vr2Oz7Ns4jo48wMiSzfwm2fJCE091nWwHvUtTHFzg1/rT3QBvRuJGJ9yEArJkM9jVOLUIOPCbQ6K9sf+pkekR3bZ5B9RWgr+Z0lPCO+TcHs3Duq7ewGL3Iv4UGcRZNwa1GVJN9ngsEu/Q7S2sLp5yLhjkAhN6aerTCLoyggeT7vm7H1MK7d0eQrSLY2N/bDNEze/NrmTlBFbNuVNpUvz6ZtuU1aceurM1uVFV+ggaRNtI8Cev20jbqZISaHsuMO6Y+0A5VZnqHQc93NLVq2EjPxD5CrAOg8v/UorSmdyX6cf8kfSzX9YmtRtqF9kcQ++IU/k= MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 19eddaa3-fa7b-4970-f725-08d70ab323fd X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Jul 2019 12:34:41.4784 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: TirumaleswarReddy_Konda@McAfee.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR16MB1578 X-OriginatorOrg: mcafee.com X-NAI-Spam-Flag: NO X-NAI-Spam-Level: X-NAI-Spam-Threshold: 15 X-NAI-Spam-Score: 0.3 X-NAI-Spam-Version: 2.3.0.9418 : core <6591> : inlines <7120> : streams <1827614> : uri <2868588> X-MC-Unique: mOPfTrtiMN2k953TwVTrMw-1 X-Mimecast-Spam-Score: 0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [tram] Benjamin Kaduk's Discuss on draft-ietf-tram-turnbis-27: (with DISCUSS and COMMENT) X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.29 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 Jul 2019 12:50:11 -0000 Hi Ben, I have updated the draft to address your Discuss and comments in both Secdi= r thread and this one (Please see https://github.com/tireddy2/TURNbis/blob/= master/Diff%20%20draft-ietf-tram-turnbis-27.txt%20-%20draft-ietf-tram-turnb= is-28.pdf). Please review. =20 Cheers, -Tiru > -----Original Message----- > From: Konda, Tirumaleswar Reddy > Sent: Saturday, July 13, 2019 11:41 AM > To: Benjamin Kaduk > Cc: The IESG ; tram-chairs@ietf.org; draft-ietf-tram- > turnbis@ietf.org; tram@ietf.org; brandon.williams@akamai.com > Subject: RE: [tram] Benjamin Kaduk's Discuss on draft-ietf-tram-turnbis-2= 7: > (with DISCUSS and COMMENT) >=20 > Hi Ben, >=20 > Please see inline >=20 > > -----Original Message----- > > From: Benjamin Kaduk > > Sent: Saturday, July 13, 2019 7:45 AM > > To: Konda, Tirumaleswar Reddy > > > Cc: The IESG ; tram-chairs@ietf.org; draft-ietf-tram- > > turnbis@ietf.org; tram@ietf.org; brandon.williams@akamai.com > > Subject: Re: [tram] Benjamin Kaduk's Discuss on draft-ietf-tram-turnbis= -27: > > (with DISCUSS and COMMENT) > > > > This email originated from outside of the organization. Do not click > > links or open attachments unless you recognize the sender and know the > > content is safe. > > > > Hi Tiru, > > > > On Thu, Jul 11, 2019 at 03:47:19PM +0000, Konda, Tirumaleswar Reddy > wrote: > > > Hi Ben, > > > > > > Thanks for the detailed review. Please see inline > > > > Sorry to have made you deduplicate with the reviews that had already > > come in -- I wrote this text fairly early (on just the diff) with > > intent to return and tidy up, but ran out of time and had to just submi= t > what I had. >=20 > No problem, the review helped to improve the draft. >=20 > > > > > > -----Original Message----- > > > > From: tram On Behalf Of Benjamin Kaduk via > > > > Datatracker > > > > Sent: Thursday, July 11, 2019 11:10 AM > > > > To: The IESG > > > > Cc: tram-chairs@ietf.org; draft-ietf-tram-turnbis@ietf.org; > > > > tram@ietf.org; brandon.williams@akamai.com > > > > Subject: [tram] Benjamin Kaduk's Discuss on > > > > draft-ietf-tram-turnbis-27: (with DISCUSS and COMMENT) > > > > > > > > > > > > > > > > Benjamin Kaduk has entered the following ballot position for > > > > draft-ietf-tram-turnbis-27: 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-turnbis/ > > > > > > > > > > > > > > > > ------------------------------------------------------------------ > > > > -- > > > > -- > > > > DISCUSS: > > > > ------------------------------------------------------------------ > > > > -- > > > > -- > > > > > > > > I support Roman's Discuss. > > > > > > I have updated the draft to address Roman's Discuss. > > > > > > > > > > > I think I'm confused about whether REQUESTED-ADDRESS-FAMILY and > > > > ADDITIONAL-ADDRESS-FAMILY are mutually exclusive. > > > > > > Yes, both attributes are mutually exclusive. It is discussed in > > > Section 7.1, > > Clients MUST NOT include REQUESTED-ADDRESS-FAMILY and ADDITIONAL- > > ADDRESS-FAMILY attributes in the same request. > > > > Okay. This seems weird to me and I wouldn't object if some very > > blunt text was added early on about "when both IPv4 and IPv6 are > > desired, the ADDITIONAL-ADDRESS-FAMILY attribute alone serves to > > request both address types; otherwise the single > > REQUESTED-ADDRESS-FAMILY attribute suffices", but this point clearly is > not Discuss-worthy. >=20 > This point is already covered in Section 5 (General Behavior) as follows: >=20 > TURN, as defined in this specification, supports both IPv4 and IPv6. IPv6 > support in TURN includes IPv4-to-IPv6, IPv6-to-IPv6, and IPv6-to-IPv4 > relaying. The REQUESTED-ADDRESS-FAMILY attribute allows a client to > explicitly request the address type the TURN server will allocate (e.g., = an > IPv4-only node may request the TURN server to allocate an IPv6 address). > The ADDITIONAL-ADDRESS-FAMILY attribute allows a client to request the > server to allocate one IPv4 and one IPv6 relay address in a single Alloca= te > request. This saves local ports on the client and reduces the number of > messages sent between the client and the TURN server. >=20 > > > > > > Does sending just the > > > > "additional" one secretly mean that you want both v4 and v6? > > > > > > Yes, ADDITIONAL-ADDRESS-FAMILY is used for allocation of both IPv4 > > > and > > IPv6. > > > > > > > > > > > Section 5 > > > > > > > > I see that the secdir reviewer asked about why it is a "SHOULD" to > > > > send SOFTWARE, and only got a response that it is defined in > > > > stunbis, but not about why it is recommended. There remain some > > > > privacy/security considerations with it, and we should either > > > > point to the stunbis security considerations or not recommend using= it. > > > > (FINGERPRINT is, IIRC, less interesting from a security > > > > perspective as it's just about confirming that given traffic is in > > > > fact STUN and not something else.) > > > > > > This "SHOULD" to send SOFTWARE attribute is defined in RFC5766 (As > > > you > > may know, TURN is used in the field for several years) and turnbis > > does not modify the behavior for backward compatibility, and to > > address the possible threat added the following lines: > > > > > > SOFTWARE attribute can reveal the specific software version of the > > > TURN > > client and server to eavesdropper and it might possibly allow attacks > > against vulnerable software that is known to contain security holes. > > If it is important to prevent an eavesdropper from learning the > > software version, TURN can be run over (D)TLS. > > > > (let's keep this on the secdir thread) >=20 > Okay. >=20 > > > > > > > > > > Section 12 > > > > > > > > Do we need to say anything about backwards compatibility with RFC > > > > 5766 peers that use a wider range of channel IDs? > > > > > > Yes, added the following line: > > > Note that the channel number range is not backwards compatible with > > > [RFC5766], and cannot be used in environments where such > > > compatibility is required. > > > > I see now that Adam also raised this topic, and I'd like to hear his > > thoughts on this proposed text. Since we normally don't make breaking > changes in "bis" > > documents, I'd also like to hear a bit more about what knoweldge we > > have (if > > any) about implementations that might be affected and are not affected. >=20 > Update to the TURN channel number range is done in > https://tools.ietf.org/html/rfc7983#section-9.3 to distinguish multiplexe= d > protocols, and the range is updated in turnbis to align with RFC7983 . >=20 > > > > > > > > > > Section 12.7 > > > > > > > > When the server receives an ICMP packet, the server processes it= as > > > > described in Section 11.5. A Data indication MUST be sent regar= dless > > > > of whether there is a channel bound to the peer that was the > > > > destination of the UDP datagram that triggered the reception of = the > > > > ICMP packet. > > > > > > > > This MUST seems potentially in conflict with the previous > > > > discussion about permissions checks in Section 11.5. > > > > > > Good catch, removed conflicting text from Section 12.7. > > > > > > > > > > > Section 20 > > > > > > > > Looking at the > > > > new nonce in the example ("obMatJos2AAABadl7W7PeDU4hKE72jda"), > > and > > > > noting that it starts with the nonce cookie, help me decode the > > > > security feature bits. The magic prefix is "obMatJos2" so the > > > > capability bits are encoded as "AAAB", which decodes to (hex) 00 > > > > 00 01. But stunbis says that the bits are ordered from 0 (MSB of > > > > first > > > > byte) to 23 (LSB of last byte), so this would have bit 23 set, > > > > which is in contrast to the registry marking bit 0 as the > > > > password-algorithms > > feature. Where am I messing this up? > > > > > > You are right, replaced with "obMatJos2gAAAadl7W7PeDU4hKE72jda" > > > (hex) > > > 80 00 00 > > > > It's reassuring to know that I wasn't missing something obvious; thanks= ! >=20 > Thanks for catching it :) >=20 > > > > > > > > > > I'd prefer if the examples showed more usage of MESSAGE-INTEGRITY- > > > > SHA256 (especially, any from the server) and fewer MESSAGE- > INTEGRITY. > > > > > > Sure, updated examples. > > > > > > > > > > > > > > > ------------------------------------------------------------------ > > > > -- > > > > -- > > > > COMMENT: > > > > ------------------------------------------------------------------ > > > > -- > > > > -- > > > > > > > > Thanks for keeping the diff from RFC 5766 relatively contained! > > > > I only reviewed the diff due to time constraints, but in general > > > > support reviewing the full document for internal consistency and > > > > any remarks that have not aged well, especially with respect to > > > > IANA > > considerations. > > > > > > > > Section 2 > > > > > > > > RFC 8174 has an updated version of the BCP 14 boilerplate text. > > > > > > Fixed. > > > > > > > > > > > Section 3.1 > > > > > > > > I appreciate the response to the secdir review, but even the > > > > linked stunbis section does not say much about which PKI's trust > > > > root is expected to be used. I'm forced to assume the Web PKI but > > > > don't have much grounds for that assumption. > > > > > > Yes, use pre-populated trust store on the endpoint to validate the > > certificate path. > > > > > > > > > > > Section 3.2 > > > > > > > > The secdir reviewer's comments seem to have some relevance. > > > > It seems like even when the third-party authorization mechanism is > > > > used, the client is still limited to "the server is authenticated > > > > because it gives me the service I asked for", which is not really > > > > documented anywhere yet. The long-term password mechanism at > > > > least generates an HMAC integrity tag on messages from server to > > > > client, which can provide some level of authentication via key > confirmation. > > > > > > No, STURN third-party authorization provides message integrity for > > > both > > request and response messages (please see > > https://tools.ietf.org/html/rfc7635#section-5). The mac_key to > > compute the message integrity can change per call and this mechanism > > is better than the long-term password mechanism. Note that WebRTC uses > > third-party authorization mechanism. > > > > Ah, that's reassuring to learn. Sorry for the confusion. > > > > > > > > > > Section 3.7 > > > > > > > > If the TURN server carrying = out > > > > packet translation from IPv4-to-IPv6 cannot get the Don't Fragme= nt > > > > (DF) bit in the IPv4 header, it MUST reject the Allocate request= with > > > > DONT-FRAGMENT attribute. > > > > > > > > nit: does "cannot get" mean something like "read the value as sent > > > > on the wire" (e.g., due to implementation/API limitations)? > > > > > > Yes, cannot read the value as sent on wire. > > > > I'd suggest "is unable to access the state of", but that's entirely > > editorial and at your discretion. >=20 > Thanks, updated. >=20 > > > > > > > > > > Section 6 > > > > > > > > o the relayed transport address or addresses; > > > > [...] > > > > > > > > [...] > > > > address. The relayed transport address MUST be unique across al= l > > > > allocations, so it can be used to uniquely identify the allocati= on. > > > > > > > > nit: there's maybe a singular/plural mismatch going on here, but I > > > > don't have any good ideas. > > > > > > > > Section 7.1 > > > > > > > > If the client wishes to obtain one IPv6 and one IPv4 relayed > > > > transport address then it includes an ADDITIONAL-ADDRESS-FAMILY > > > > attribute in the request. This attribute specifies that the ser= ver > > > > must allocate both address types. The attribute value in the > > > > ADDITIONAL-ADDRESS-FAMILY MUST be set to 0x02 (IPv6 address > > family). > > > > Clients MUST NOT include REQUESTED-ADDRESS-FAMILY and > > ADDITIONAL- > > > > ADDRESS-FAMILY attributes in the same request. [...] > > > > > > > > This reads like setting REQUESTED-ADDRESS-FAMILY and ADDITIONAL- > > > > ADDRESS-FAMILY are mutually exclusive. Is that the correct reading= ? > > > > > > Yes. > > > > > > > (Naively, one might expect that the thing named "additional" > > > > is applied on top of the base-level request, so I have to ask.) > > > > > > > > Section 7.2 > > > > > > > > Why do we only have a SHOULD-level requirement for authentication > > > > of Allocate requests where 5766 had MUST? Could we say "may allow > > > > unauthenticated requests in order to support [use case] but > > > > otherwise MUST require authentication" (with better wording)? I > > > > suppose this has probably been discussed ad nauseum already, so > > > > feel free to point me at the archives before getting into an actual > discussion. > > > > > > You missed the next line, it says the authentication of the request > > > is optional to allow TURN servers provided by the local or access > > > network to accept Allocation requests from new and/or guest users in > > > the network who do not necessarily possess long term credentials for > > > STUN authentication and its security implications are discussed in > > > [RFC8155]. > > > > I saw the next line; the current formulation also allows non-use of > > authentication in other situations, which is why I suggested an > > alternate wording. > > > > > The WG spent several cycles discussing the downgrade of a MUST level > > requirement (please see https://tools.ietf.org/html/rfc8155#section-9). > > > > To be clear, I do not object to removing the MUST for the local-use > > case; I'm concerned with the wording of the text that, as written, > > also weakens the requirement for all other cases. >=20 > Got it, updated step as follows: >=20 > 1. The TURN server provided by the local or access network MAY > allow unauthenticated request in order to accept Allocation > requests from new and/or guest users in the network who do not > necessarily possess long term credentials for STUN > authentication and its security implications are discussed in > [RFC8155]. Otherwise, the server MUST require that the request > be authenticated. If the request is authenticated, the > authentication MUST be done either using the long-term credential > mechanism of [I-D.ietf-tram-stunbis] or the STUN Extension for > Third-Party Authorization [RFC7635] unless the client and server > agree to use another mechanism through some procedure outside > the scope of this document. >=20 > > > > > > > > > > 7. If the server does not support the address family requested= by > > > > the client in REQUESTED-ADDRESS-FAMILY or is disabled by lo= cal > > > > policy, it MUST generate an Allocate error response, and it= MUST > > > > include an ERROR-CODE attribute with the 440 (Address Famil= y not > > > > Supported) response code. [...] > > > > > > > > nit: "or is disabled" needs a subject. > > > > > > Fixed, updated text as follows: > > > If the server does not support the address family requested by the > > > client in > > REQUESTED-ADDRESS-FAMILY or if the allocation of the requested address > > family is disabled by local policy, it MUST generate an Allocate error > > response, and it MUST include an ERROR-CODE attribute with the 440 > > (Address Family not Supported) response code. > > > > Thanks > > > > > > 9. The server checks if the request contains an ADDITIONAL- > ADDRESS- > > > > FAMILY attribute. If yes, and the attribute value is 0x01 = (IPv4 > > > > address family), then the server rejects the request with a= 400 > > > > (Bad Request) error. Otherwise, the server checks if it ca= n > > > > allocate relayed transport addresses of both address types.= If > > > > the server cannot satisfy the request, then the server > > > > rejects > > > > > > > > What are "both" address types? > > > > > > Both IPv4 and IPv6 address families. > > > > I guess once I realize that "ADDITIONAL-ADDRESS-FAMILY" is just code > > for > > "IPv4 and IPv6" with no other options, this doesn't look as unclear. > > > > > > We only have the ADDITIONAL-ADDRESS- FAMILY (which contains one > > > > type) and no REQUESTED-ADDRESS-FAMILY. > > > > > > If ADDITIONAL-ADDRESS-FAMILY is used, the server will allocate both > > > IPv4 > > and IPv6 relayed transport addresses. > > > > > > > > > > > Section 8.1 > > > > > > > > When refreshing a dual allocation, the client includes REQUESTED= - > > > > ADDRESS-FAMILY attribute indicating the address family type that > > > > should be refreshed. If no REQUESTED-ADDRESS-FAMILY is > > > > included > > then > > > > the request should be treated as applying to all current allocat= ions. > > > > The client MUST only include family types it previously allocate= d and > > > > has not yet deleted. [...] > > > > > > > > I'm a bit confused about "only include family types" plural; I > > > > thought there could only be at most one REQUESTED-ADDRESS-FAMILY > > and > > > > that it would only indicate one family type. So how could there > > > > be multiple types getting included by the client? > > > > > > Good catch, replaced "types" with "type" > > > > (It needs a definite article, then for "only include the family type") >=20 > Done. >=20 > Cheers, > -Tiru >=20 > > > > > > > > > > Section 11.5 > > > > > > > > [check that "type and code" is valid in both ICMPv4 and v6] > > > > > > Yes, it is valid. > > > > Sorry; that was supposed to be a note to myself! > > But yes, luckily for me this is not the point of difference between > > ICMPv4 and ICMPv6 that I was vaguely remembering. > > > > > > > > > > Section 12 > > > > > > > > Reserved values may be used in the future by other protocols. W= hen > > > > the client uses channel binding, it MUST comply with the > > > > demultiplexing scheme discussed above. > > > > > > > > "channel binding" is a term of art in the security world; is this > > > > usage intended to roughly mean "channel multiplexing"? > > > > (I do see that the subsections are talking about the specific > > > > ChannelBind request, so I assume so; I just want to double check.) > > > > > > Yes, a channel binding is created or refreshed using a ChannelBind > > transaction (Please see Section 12.1). > > > > Great. Well, not great that there's a collision of jargon, but it's > > way too late to do anything about, now. > > > > > > > > > > > > > > Section 13 > > > > > > > > The descriptions below have two parts: a preferred behavior and = an > > > > alternate behavior. The server SHOULD implement the preferred > > > > behavior. Otherwise, the server MUST implement the alternate > > > > behavior and MUST NOT do anything else for the reasons detailed = in > > > > [RFC7915]. [...] > > > > > > > > RFC 5766 had this split on a per-field basis, but this text > > > > suggests that if the preferred behavior is not possible for a > > > > given field, then the alternate behavior is used for the entire pac= ket. > > > > I note that section 14 does retain the "for a particular field" > > > > language for UDP-to-UDP relaying, as do section 15 for TCP-to-UDP > > > > relaying and section 16 for UDP-to-TCP relaying. > > > > > > Good point, fixed text as follows: > > > Otherwise, if that is not possible for a particular field, the > > > server MUST > > implement the alternate behavior and MUST NOT do anything else for the > > reasons detailed in [RFC7915]. > > > > > > > > > > > Section 13.2 > > > > > > > > Is this flow label text consistent with both the inbound and > > > > outbound translation directions (specifically, using relayed/peer > > > > addresses in the 5- tuple to identify the flow)? > > > > > > > > If the incoming packet did not include a Fragment header and = the > > > > outgoing packet size exceeds the outgoing link's MTU, the TUR= N > > > > server drops the outgoing packet and send an ICMP message of = type > > > > 2 code 0 ("Packet too big") to the sender of the incoming pac= ket. > > > > If the packet is being sent to the peer, the TURN server red= uces > > > > the MTU reported in the ICMP message by 48 bytes to allow roo= m > for > > > > the overhead of a Data indication. > > > > > > > > (nit?) "If the packet is being send to the peer" seems to > > > > grammatically refer to the outgoing packet that would exceed link > > > > MTU, as opposed to the ICMP message being generated. But I think > > > > it's supposed to refer to the ICMP message being generated, which > > > > has > > not yet been referred to as a "packet" > > > > in this text. > > > > > > Suresh raised the same comment, fixed text as follows: > > > If the ICMPv6 packet ("Packet too big") is being sent to the peer, > > > the TURN > > server reduces the MTU reported in the ICMP message by 48 bytes to > > allow room for the overhead of a Data indication. > > > > Great; t hanks > > > > > > > > > > Section 13.3 > > > > > > > > [Same comment about ICMP packet generation/grammar] > > > > > > Fixed text as follows: > > > If the ICMPv4 packet (Destination Unreachable (Type 3) with Code 4) > > > is > > being sent to the peer, the TURN server SHOULD reduce the MTU reported > > in the ICMP message by 48 bytes to allow room for the overhead of a > > Data indication. > > > > > > > > > > > Section 15 > > > > > > > > Maybe note that SIP and WebRTC are the primary consumers of TURN? > > > > > > Yes, it is mentioned in several places in the document that WebRTC > > > and SIP > > use TURN. > > > > Okay; my fault for only looking at the diff, probably. > > > > > > > > > > Even if bot= h > > > > TCP-AO and UDP authentication would be used between TURN client > > and > > > > server, it would not change the end-to-end security properties o= f the > > > > UDP payload being relayed. [...] > > > > > > > > I wonder if we even need to say "UDP" in "payload being relayed". > > > > > > Replaced "UDP" with "application" > > > > > > > > > > > Section 16 > > > > > > > > Fragmentation > > > > > > > > Preferred Behavior: Any fragmented packets are reassembled in= the > > > > server and then forwarded to the client over the TCP connecti= on. > > > > ICMP messages resulting from the UDP datagrams sent to the pe= er > > > > MUST be forwarded to the client using TURN's mechanism for > > > > relevant ICMP types and codes. > > > > > > > > As in section 12.7, I wonder if this MUST could be seen as > > > > overriding other logic for ICMP handling. > > > > > > Modified text for clarity as follows: > > > > > > ICMP messages resulting from the UDP datagrams sent to the peer are > > > processed by the server as described in Section 11.5 and forwarded > > > to the client using TURN's mechanism for relevant ICMP types and code= s. > > > > Thanks > > > > > > > > > > Section 21.16 > > > > > > > > I agree with the secdir reviewer that there is at least potential > > > > for username and realm to be sensitive. > > > > > > I proposed to add the following text: > > > > > > If the TURN client and server use the STUN Extension for Third-Par= ty > > > Authorization [RFC7635] (for example it is used in WebRTC), the > > > username does not reveal the real user's identity, the USERNAME > > > attribute carries an ephemeral and unique key identifier. If the > > > TURN client and server use the STUN long-term credential mechanism > > > and the username reveals the real user's identity, the client need= s > > > to use (D)TLS transport between the client and the server or use t= he > > > USERHASH attribute instead of the USERNAME attribute to anonynmize > > > the username. > > > > > > If the TURN client and server use the STUN long-term credential > > > mechanism and realm information is privacy sensitive, TURN can be = run > > > over (D)TLS. As a reminder, STUN Extension for Third-Party > > > Authorization does not use realm. > > > > Excellent; thank you! > > > > > > > > > > Section 21.4 > > > > > > > > Do we need references for Teredo and/or 6to4? > > > > > > https://tools.ietf.org/html/rfc6156 did not add references to Teredo > > > and > > 6to4. > > > > Okay; just wanted to check. > > > > > > > > > > Section 22 > > > > > > > > The codepoints for the STUN error codes defined in this specific= ation > > > > are listed in Section 19. [IANA is requested to update the refe= rence > > > > from [RFC5766] to RFC-to-be for the STUN error codes listed in > > > > Section 19.] > > > > > > > > (I think some of them are from RFC 6156 as well as from 5766.) > > > > > > Yes, added RFC6156. > > > > > > > > > > > Section 23 > > > > > > > > It seems prudent to revisit these listed IAB Considerations for > > > > whether the situation has changed in the past ten years (though I > > > > don't have any specific points that I would change). > > > > > > > > Section 25 > > > > > > > > (nit) are these really "updates" to RFC 6156 so much as > > > > incorporating its content wholesale into the core TURN specificatio= n? > > > > > > Yes, several sections in RFC6156 are updated. > > > > Okay, thanks. > > > > -Ben From nobody Wed Jul 17 06:06:21 2019 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 5A91D120098 for ; Wed, 17 Jul 2019 06:06:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.999 X-Spam-Level: X-Spam-Status: No, score=-3.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=mcafee.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5MQynUaWNmnU for ; Wed, 17 Jul 2019 06:06:10 -0700 (PDT) Received: from us-smtp-delivery-210.mimecast.com (us-smtp-delivery-210.mimecast.com [63.128.21.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8EBC6120224 for ; Wed, 17 Jul 2019 06:06:10 -0700 (PDT) X-NAI-Header: Modified by McAfee Email Gateway (5500) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mcafee.com; s=s_mcafee; t=1563366292; h=ARC-Seal: ARC-Message-Signature:ARC-Authentication-Results: From:To:CC:Subject:Thread-Topic:Thread-Index: Date:Message-ID:References:In-Reply-To:Accept-Language: Content-Language:X-MS-Has-Attach:X-MS-TNEF-Correlator: dlp-product:dlp-version:dlp-reaction:authentication-results: x-originating-ip:x-ms-publictraffictype:x-ms-office365-filtering-correlation-id: x-microsoft-antispam:x-ms-traffictypediagnostic: x-ms-exchange-purlcount:x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers:x-forefront-prvs: x-forefront-antispam-report:received-spf:x-ms-exchange-senderadcheck: x-microsoft-antispam-message-info:Content-Type: Content-Transfer-Encoding:MIME-Version:X-MS-Exchange-CrossTenant-Network-Message-Id: X-MS-Exchange-CrossTenant-originalarrivaltime: X-MS-Exchange-CrossTenant-fromentityheader: X-MS-Exchange-CrossTenant-id:X-MS-Exchange-CrossTenant-mailboxtype: X-MS-Exchange-CrossTenant-userprincipalname: X-MS-Exchange-Transport-CrossTenantHeadersStamped: X-OriginatorOrg:X-NAI-Spam-Flag:X-NAI-Spam-Level: X-NAI-Spam-Threshold:X-NAI-Spam-Score:X-NAI-Spam-Version; bh=p239S4JrDXbkJgq8j0Kdeaj9x9qFDcPOuxGzLd Stjjc=; b=J9AmMW5LAvI0gCzb89mMduxy93d/XsZ0hIQFQJSt hXV5uioR2lWNPn02ilQzcRlk14aGsY62UxeSkA8Uj87Qz1yl6c +Qsfxz0xVqz+dgwCLO3LZeyuwIHGnDuDZZ716Wi+y7xJpLGp+4 MkAIuPqFaYpOISYxE+PIy3PieTpON9Q= Received: from DNVWSMAILOUT1.mcafee.com (dnvwsmailout1.mcafee.com [161.69.31.173]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-134-BsHKzs1oOJ-Jvdya6YRJiw-1; Wed, 17 Jul 2019 08:35:47 -0400 Received: from DNVEXAPP1N06.corpzone.internalzone.com (DNVEXAPP1N06.corpzone.internalzone.com [10.44.48.90]) by DNVWSMAILOUT1.mcafee.com with smtp (TLS: TLSv1/SSLv3,256bits,ECDHE-RSA-AES256-SHA384) id 6bf8_43ff_acfb61d9_aa1a_4cce_862f_856e5e73c518; Wed, 17 Jul 2019 06:24:51 -0600 Received: from DNVEXAPP1N05.corpzone.internalzone.com (10.44.48.89) by DNVEXAPP1N06.corpzone.internalzone.com (10.44.48.90) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Wed, 17 Jul 2019 06:35:44 -0600 Received: from DNVO365EDGE2.corpzone.internalzone.com (10.44.176.74) by DNVEXAPP1N05.corpzone.internalzone.com (10.44.48.89) with Microsoft SMTP Server (TLS) id 15.0.1395.4 via Frontend Transport; Wed, 17 Jul 2019 06:35:43 -0600 Received: from NAM03-DM3-obe.outbound.protection.outlook.com (10.44.176.240) by edge.mcafee.com (10.44.176.74) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Wed, 17 Jul 2019 06:35:42 -0600 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ToidbuN1ws2Jz4wnjoXlE/a34C6LL1vJd9dqSCmrzwnrW4rgfKIrk17Rhi+fC+UV0M7Shdge/uTzdgVI/0U6X8eC5GZyDSfI7uFlfQdUKZJ5eZ1Kb1UzRXQRSIwWB1ZbF/HXkyXXC8uHCR1tHMq3GKHa5AzGVAVLYpC0jooSn+IfdX+yONJYbxg075RnpJqWp9ZUG8ImmLuEyzVMZNiMG7R8vC7LUhNkeBrhk8iESVKqsnYi/SvoQHBz8DlqS52ez4NReBKy4v0pkxwluNUefNitxehxIvOK3Fvx65PPdA2TTCc2fsNN71Y0jkCRJYDvRjj8CX5wibAycgExqfTQkQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=p239S4JrDXbkJgq8j0Kdeaj9x9qFDcPOuxGzLdStjjc=; b=EJj254BugxvDGmYKx3Lgu6uzRXSzHPIneiDCubfclOsQB1uQjm/3BtKh/5XOlHZH0OI+QORax3iqw6QfAUWcRatknbvycWnS+0hDaY9z6+2wQdtSqhYsCOOOkKxa4IIvtskH1q8Z+OBA33dJwNKIpny/9v1C+sGmfXF7h00c6Zf57jQudUqgB1n5/0twylHzjpCAWUbpu94FVYCG8xOy/0z6IV8i8eR+9Cuw2efBI4iWJurhNyCakYLIN3JWFyis5LRs67VAJMaMagAj/igpj7AjVVPjZk6RMiRvwF6Je7kbyUWGAEYHNSf85Jryw9QiW8O4nWY2KxeSSdmPrGtB3g== ARC-Authentication-Results: i=1; mx.microsoft.com 1;spf=pass smtp.mailfrom=mcafee.com;dmarc=pass action=none header.from=mcafee.com;dkim=pass header.d=mcafee.com;arc=none Received: from DM5PR16MB1705.namprd16.prod.outlook.com (10.172.44.147) by DM5PR16MB1578.namprd16.prod.outlook.com (10.173.211.12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2073.14; Wed, 17 Jul 2019 12:35:42 +0000 Received: from DM5PR16MB1705.namprd16.prod.outlook.com ([fe80::570:2208:75c2:5f17]) by DM5PR16MB1705.namprd16.prod.outlook.com ([fe80::570:2208:75c2:5f17%8]) with mapi id 15.20.2073.012; Wed, 17 Jul 2019 12:35:42 +0000 From: "Konda, Tirumaleswar Reddy" To: =?utf-8?B?TWlyamEgS8O8aGxld2luZA==?= , The IESG CC: "tram-chairs@ietf.org" , "draft-ietf-tram-turnbis@ietf.org" , "tram@ietf.org" , "brandon.williams@akamai.com" Thread-Topic: =?utf-8?B?W3RyYW1dIE1pcmphIEvDvGhsZXdpbmQncyBEaXNjdXNzIG9uIGRyYWZ0LWll?= =?utf-8?Q?tf-tram-turnbis-27:_(with_DISCUSS_and_COMMENT)?= Thread-Index: AQHVNzftWkN2G8olS0aOBDqJ1prLPKbG+S0ggAecAUA= Date: Wed, 17 Jul 2019 12:35:42 +0000 Message-ID: References: <156277411459.15353.13243689830942672102.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.3.0.16 dlp-reaction: no-action x-originating-ip: [49.37.206.28] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 1efa0781-c015-443b-9b7c-08d70ab34879 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:DM5PR16MB1578; x-ms-traffictypediagnostic: DM5PR16MB1578: x-ms-exchange-purlcount: 6 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 01018CB5B3 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(346002)(366004)(376002)(39860400002)(396003)(136003)(76094002)(32952001)(199004)(189003)(51914003)(13464003)(71190400001)(80792005)(186003)(305945005)(52536014)(71200400001)(229853002)(4326008)(3846002)(33656002)(7736002)(6116002)(25786009)(11346002)(476003)(478600001)(30864003)(966005)(74316002)(446003)(5660300002)(66574012)(256004)(5024004)(14444005)(224303003)(2906002)(81156014)(8936002)(81166006)(14454004)(9686003)(6306002)(7696005)(68736007)(66066001)(55016002)(6436002)(110136005)(54906003)(86362001)(26005)(6506007)(53546011)(102836004)(6246003)(99286004)(486006)(66556008)(76116006)(316002)(53936002)(64756008)(66476007)(66946007)(76176011)(66446008)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR16MB1578; H:DM5PR16MB1705.namprd16.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: lRAZ6dxDPq2Vg9KNCMgCkJfQXkF/NMZ0zAXcOlz8w1OwCVbz9Y+/I086FYIiJvI9oqMoiV6YieIntnAbwjZt0adCF1lQ8LLEv2fEtuCnPu/cTVt8HL9rPouYXpfKtAqJiiSUcK5WC1RnQ4xNPrwZdoBzye1QR8+aJJJFUr5W9X+M98Avv1ASAipuXcdJ1VfS1RE7pOTkXcA5yk82A0Jcb/2afYs14iRApIrc1b7C6+TdM41HflMkhsK9aMVnPGweMSuTVkKtCO+dVEG39uQUAxX52UEeUBFMro3hdrLUr839auJsmWU6pSQBiVJqBarOsHYDouVCO75XqyTQJfLUUfbvXBIHDmXE+5EzRmou71I8Uqzn/XjjnJ/gjV50FAJlMtzprLg0+t/xpXJp4XD4wTjperB2peilrruubHjoH4g= MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 1efa0781-c015-443b-9b7c-08d70ab34879 X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Jul 2019 12:35:42.6876 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: TirumaleswarReddy_Konda@McAfee.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR16MB1578 X-OriginatorOrg: mcafee.com X-NAI-Spam-Flag: NO X-NAI-Spam-Level: X-NAI-Spam-Threshold: 15 X-NAI-Spam-Score: 0.2 X-NAI-Spam-Version: 2.3.0.9418 : core <6591> : inlines <7120> : streams <1827614> : uri <2868588> X-MC-Unique: BsHKzs1oOJ-Jvdya6YRJiw-1 X-Mimecast-Spam-Score: 0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Archived-At: Subject: Re: [tram] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf-?= =?utf-8?q?tram-turnbis-27=3A_=28with_DISCUSS_and_COMMENT=29?= X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.29 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 Jul 2019 13:06:13 -0000 SGkgTWlyamEsDQoNCkkgaGF2ZSB1cGRhdGVkIHRoZSBkcmFmdCB0byBhZGRyZXNzIHlvdXIgRGlz Y3VzcyBhbmQgY29tbWVudHMgKHNlZSBodHRwczovL2dpdGh1Yi5jb20vdGlyZWRkeTIvVFVSTmJp cy9ibG9iL21hc3Rlci9EaWZmJTIwJTIwZHJhZnQtaWV0Zi10cmFtLXR1cm5iaXMtMjcudHh0JTIw LSUyMGRyYWZ0LWlldGYtdHJhbS10dXJuYmlzLTI4LnBkZikuIA0KUGxlYXNlIGhhdmUgYSBsb29r Lg0KDQpDaGVlcnMsDQotVGlydQ0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZy b206IEtvbmRhLCBUaXJ1bWFsZXN3YXIgUmVkZHkNCj4gU2VudDogTW9uZGF5LCBKdWx5IDE1LCAy MDE5IDEyOjAxIFBNDQo+IFRvOiBNaXJqYSBLw7xobGV3aW5kIDxpZXRmQGt1ZWhsZXdpbmQubmV0 PjsgVGhlIElFU0cgPGllc2dAaWV0Zi5vcmc+DQo+IENjOiB0cmFtLWNoYWlyc0BpZXRmLm9yZzsg ZHJhZnQtaWV0Zi10cmFtLXR1cm5iaXNAaWV0Zi5vcmc7IHRyYW1AaWV0Zi5vcmc7DQo+IGJyYW5k b24ud2lsbGlhbXNAYWthbWFpLmNvbQ0KPiBTdWJqZWN0OiBSRTogW3RyYW1dIE1pcmphIEvDvGhs ZXdpbmQncyBEaXNjdXNzIG9uIGRyYWZ0LWlldGYtdHJhbS10dXJuYmlzLTI3Og0KPiAod2l0aCBE SVNDVVNTIGFuZCBDT01NRU5UKQ0KPiANCj4gSGkgTWlyamEsDQo+IA0KPiBUaGFua3MgZm9yIHRo ZSByZXZpZXcuIFBsZWFzZSBzZWUgaW5saW5lDQo+IA0KPiA+IC0tLS0tT3JpZ2luYWwgTWVzc2Fn ZS0tLS0tDQo+ID4gRnJvbTogdHJhbSA8dHJhbS1ib3VuY2VzQGlldGYub3JnPiBPbiBCZWhhbGYg T2YgTWlyamEgS8O8aGxld2luZCB2aWENCj4gPiBEYXRhdHJhY2tlcg0KPiA+IFNlbnQ6IFdlZG5l c2RheSwgSnVseSAxMCwgMjAxOSA5OjI1IFBNDQo+ID4gVG86IFRoZSBJRVNHIDxpZXNnQGlldGYu b3JnPg0KPiA+IENjOiB0cmFtLWNoYWlyc0BpZXRmLm9yZzsgZHJhZnQtaWV0Zi10cmFtLXR1cm5i aXNAaWV0Zi5vcmc7DQo+ID4gdHJhbUBpZXRmLm9yZzsgYnJhbmRvbi53aWxsaWFtc0Bha2FtYWku Y29tDQo+ID4gU3ViamVjdDogW3RyYW1dIE1pcmphIEvDvGhsZXdpbmQncyBEaXNjdXNzIG9uDQo+ ID4gZHJhZnQtaWV0Zi10cmFtLXR1cm5iaXMtMjc6ICh3aXRoIERJU0NVU1MgYW5kIENPTU1FTlQp DQo+ID4NCj4gPiBUaGlzIGVtYWlsIG9yaWdpbmF0ZWQgZnJvbSBvdXRzaWRlIG9mIHRoZSBvcmdh bml6YXRpb24uIERvIG5vdCBjbGljaw0KPiA+IGxpbmtzIG9yIG9wZW4gYXR0YWNobWVudHMgdW5s ZXNzIHlvdSByZWNvZ25pemUgdGhlIHNlbmRlciBhbmQga25vdyB0aGUNCj4gPiBjb250ZW50IGlz IHNhZmUuDQo+ID4NCj4gPiBNaXJqYSBLw7xobGV3aW5kIGhhcyBlbnRlcmVkIHRoZSBmb2xsb3dp bmcgYmFsbG90IHBvc2l0aW9uIGZvcg0KPiA+IGRyYWZ0LWlldGYtdHJhbS10dXJuYmlzLTI3OiBE aXNjdXNzDQo+ID4NCj4gPiBXaGVuIHJlc3BvbmRpbmcsIHBsZWFzZSBrZWVwIHRoZSBzdWJqZWN0 IGxpbmUgaW50YWN0IGFuZCByZXBseSB0byBhbGwNCj4gPiBlbWFpbCBhZGRyZXNzZXMgaW5jbHVk ZWQgaW4gdGhlIFRvIGFuZCBDQyBsaW5lcy4gKEZlZWwgZnJlZSB0byBjdXQNCj4gPiB0aGlzIGlu dHJvZHVjdG9yeSBwYXJhZ3JhcGgsIGhvd2V2ZXIuKQ0KPiA+DQo+ID4NCj4gPiBQbGVhc2UgcmVm ZXIgdG8NCj4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9pZXNnL3N0YXRlbWVudC9kaXNjdXNzLWNy aXRlcmlhLmh0bWwNCj4gPiBmb3IgbW9yZSBpbmZvcm1hdGlvbiBhYm91dCBJRVNHIERJU0NVU1Mg YW5kIENPTU1FTlQgcG9zaXRpb25zLg0KPiA+DQo+ID4NCj4gPiBUaGUgZG9jdW1lbnQsIGFsb25n IHdpdGggb3RoZXIgYmFsbG90IHBvc2l0aW9ucywgY2FuIGJlIGZvdW5kIGhlcmU6DQo+ID4gaHR0 cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi10cmFtLXR1cm5iaXMvDQo+ ID4NCj4gPg0KPiA+DQo+ID4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiA+IERJU0NVU1M6DQo+ID4gLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLQ0KPiA+DQo+ID4gT25lIHF1aWNrIGRpc2N1c3Npb24gd2hpY2ggcHJvYmFibHkgaXMg b25seSBhbiBvdmVyc2lnaHQgYW5kIHRoZXJlZm9yZQ0KPiA+IHNob3VsZCBiZSBlYXN5IGdvdCBm aXg6DQo+ID4NCj4gPiBJJ20gYml0IGNvbmZ1c2VkIGFib3V0IHRoZSByZXF1aXJlbWVudCBvbiB1 c2luZyBhdXRoZW50aWNhdGlvbi4gVGhpcw0KPiA+IGRyYWZ0IHNheXMgaW4gc2VjdGlvbiA1IChh cyBSRkM1NzY2IGRvZXMpOg0KPiA+DQo+ID4gIlRoZSBzZXJ2ZXIgTVVTVCBkZW1hbmQgdGhhdCBh bGwgcmVxdWVzdHMNCj4gPiAgICBmcm9tIHRoZSBjbGllbnQgYmUgYXV0aGVudGljYXRlZCB1c2lu ZyB0aGlzIG1lY2hhbmlzbSwgb3IgdGhhdCBhDQo+ID4gICAgZXF1YWxseSBzdHJvbmcgb3Igc3Ry b25nZXIgbWVjaGFuaXNtIGZvciBjbGllbnQgYXV0aGVudGljYXRpb24gaXMNCj4gPiAgICB1c2Vk LiINCj4gPg0KPiA+IEhvd2V2ZXIsIFJGQyA4MTU1IHdoaWNoIGlzIGV2ZW4gbm93IGNpdGVkIGlu IHRoaXMgZHJhZnQsIHVwZGF0ZXMNCj4gPiBSRkM1NzY2IGFuZCByZWxheGVzIHRoaXMgcmVxdWly ZW1lbnQuIExhdGVyIGluIHRoZSBzZWN0aW9uIDcuMi4gdGhpcyBkcmFmdA0KPiBzYXlzOg0KPiA+ DQo+ID4gIlRoZSBzZXJ2ZXIgU0hPVUxEIHJlcXVpcmUgdGhhdCB0aGUgcmVxdWVzdCBiZSBhdXRo ZW50aWNhdGVkLiINCj4gPg0KPiA+IEkgYXNzdW1lIHRoZSByZXF1aXJlbWVudCBpbiBzZWN0aW9u IDUgaXMgYW4gb3ZlcnNpZ2h0Pw0KPiANCj4gWWVzLCByZW1vdmVkIHRoZSByZXF1aXJlbWVudCBp biBTZWN0aW9uIDUuDQo+IA0KPiA+DQo+ID4gSSBhbHNvIHJlY29tbWVuZCB0byBvbmx5IHNwZWNp ZnkgdGhpcyByZXF1aXJlbWVudCBub3JtYXRpdmVseSBpbiBvbmUgcGxhY2UuDQo+IA0KPiBEb25l LCB1cGRhdGVkIHN0ZXAgMSBpbiBTZWN0aW9uIDUgdG8gYWRkcmVzcyB0aGUgY29tbWVudCBmcm9t IEJlbiBhcw0KPiBmb2xsb3dzOg0KPiANCj4gICAgMS4gICBUaGUgVFVSTiBzZXJ2ZXIgcHJvdmlk ZWQgYnkgdGhlIGxvY2FsIG9yIGFjY2VzcyBuZXR3b3JrIE1BWQ0KPiAgICAgICAgIGFsbG93IHVu YXV0aGVudGljYXRlZCByZXF1ZXN0IGluIG9yZGVyIHRvIGFjY2VwdCBBbGxvY2F0aW9uDQo+ICAg ICAgICAgcmVxdWVzdHMgZnJvbSBuZXcgYW5kL29yIGd1ZXN0IHVzZXJzIGluIHRoZSBuZXR3b3Jr IHdobyBkbyBub3QNCj4gICAgICAgICBuZWNlc3NhcmlseSBwb3NzZXNzIGxvbmcgdGVybSBjcmVk ZW50aWFscyBmb3IgU1RVTg0KPiAgICAgICAgIGF1dGhlbnRpY2F0aW9uIGFuZCBpdHMgc2VjdXJp dHkgaW1wbGljYXRpb25zIGFyZSBkaXNjdXNzZWQgaW4NCj4gICAgICAgICBbUkZDODE1NV0uICBP dGhlcndpc2UsIHRoZSBzZXJ2ZXIgTVVTVCByZXF1aXJlIHRoYXQgdGhlIHJlcXVlc3QNCj4gICAg ICAgICBiZSBhdXRoZW50aWNhdGVkLiAgSWYgdGhlIHJlcXVlc3QgaXMgYXV0aGVudGljYXRlZCwg dGhlDQo+ICAgICAgICAgYXV0aGVudGljYXRpb24gTVVTVCBiZSBkb25lIGVpdGhlciB1c2luZyB0 aGUgbG9uZy10ZXJtDQo+ICAgICAgICAgY3JlZGVudGlhbCBtZWNoYW5pc20gb2YgW0ktRC5pZXRm LXRyYW0tc3R1bmJpc10gb3IgdGhlIFNUVU4NCj4gICAgICAgICBFeHRlbnNpb24gZm9yIFRoaXJk LVBhcnR5IEF1dGhvcml6YXRpb24gW1JGQzc2MzVdIHVubGVzcyB0aGUNCj4gICAgICAgICBjbGll bnQgYW5kIHNlcnZlciBhZ3JlZSB0byB1c2UgYW5vdGhlciBtZWNoYW5pc20gdGhyb3VnaCBzb21l DQo+ICAgICAgICAgcHJvY2VkdXJlIG91dHNpZGUgdGhlIHNjb3BlIG9mIHRoaXMgZG9jdW1lbnQu DQo+IA0KPiA+DQo+ID4NCj4gPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ID4gQ09NTUVOVDoNCj4gPiAtLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tDQo+ID4NCj4gPiBTb21lIG90aGVyIHRlY2huaWNhbCBjb21tZW50cy9xdWVzdGlv bnM6DQo+ID4NCj4gPiAxKSBTZWMgMy43Og0KPiA+ICJvciB1c2UgVURQIGZyYWdtZW50YXRpb24g W0ktRC5pZXRmLXRzdndnLXVkcC1vcHRpb25zXS4iDQo+ID4gSSBiZWxpZXZlIHRoZSBwb3NzaWJp bGl0eSB0byB1c2UgVURQIGZyYWdtZW50YXRpb24gd2FzIGJyb3VnaHQgdXAgYnkNCj4gPiB0aGUg VFNWLUFSVCByZXZpZXcgKFRoYW5rcyBKb2UhKS4gSG93ZXZlciwgSSB3b3VsZCBsaWtlIHRvIG1l bnRpb24NCj4gPiB0aGF0IHRoaXMgY2FuIG9ubHkgYmUgdXNlZCBpZiBzdXBwb3J0ZWQgYnkgYm90 aCBlbmRwb2ludHMgYW5kIHRoYXQNCj4gPiBzaG91bGQgcHJvYmFibHkgYWxzbyBiZSByZW1hcmtl ZCBoZXJlLiBUaGUgbmV4dCBzZW50ZW5jZSBpbiB0aGUgZHJhZnQNCj4gPiBpbmRpY2F0ZWQgdGhp cyBieSBzYXlpbmcgInVudGlsIFVEUCBmcmFnbWVudGF0aW9uIHN1cHBvcnQgaXMNCj4gPiBhdmFp bGFibGUiLCBob3dldmVyLCB0aGlzIGFjdHVhbGx5IHNlZW0gdG8gYmUgZWRpdG9yaWFsbHkgYSBi aXQNCj4gPiBtaXNwbGFjZWQgdGhlcmUgYW5kIGNvdWxkIGV4cGxhaW4gbW9yZS4gU2VlIGFsc28g dGhpcyB0ZXh0IGluDQo+ID4gZHJhZnQtaWV0Zi10c3Z3Zy11ZHAtb3B0aW9uczoNCj4gPg0KPiA+ ICJGUkFHIG5lZWRzIHRvIGJlIHVzZWQgd2l0aCBleHRyZW1lIGNhcmUgYmVjYXVzZSBpdCB3aWxs IHByZXNlbnQNCj4gPiAgICBpbmNvcnJlY3QgZGF0YWdyYW0gYm91bmRhcmllcyB0byBhIGxlZ2Fj eSByZWNlaXZlciwgdW5sZXNzIGVuY29kZWQNCj4gPiAgICBhcyBMSVRFIGRhdGEgKHNlZSBTZWN0 aW9uIDUuOCkuIg0KPiA+DQo+ID4gQWxzbyBub3RlIHRoYXQgZHJhZnQtaWV0Zi10c3Z3Zy11ZHAt b3B0aW9ucyBpcyBzdGlsbCB1bmRlciBkZXZlbG9wbWVudA0KPiA+IGFuZCB3ZSBkb24ndCBoYXZl IG11Y2ggZGVwbG95bWVudCBleHBlcmllbmNlIHdpdGggaXQgeWV0Lg0KPiANCj4gWWVzLCBKb2Ug c3VnZ2VzdCB0aGUgYWJvdmUgY2hhbmdlLiBJIGhhdmUgYWRkZWQgdGhlIGZvbGxvd2luZyBsaW5l Og0KPiBOb3RlIHRoYXQgdGhlIFVEUCBmcmFnbWVudGF0aW9uIG9wdGlvbiBuZWVkcyB0byBiZSBz dXBwb3J0ZWQgYnkgYm90aA0KPiBlbmRwb2ludHMsIGFuZCBhdCB0aGUgdGltZSBvZiB3cml0aW5n IG9mIHRoaXMgZG9jdW1lbnQsIFVEUCBmcmFnbWVudGF0aW9uDQo+IHN1cHBvcnQgaXMgdW5kZXIg ZGlzY3Vzc2lvbiBhbmQgaXMgbm90IGRlcGxveWVkLg0KPiANCj4gPg0KPiA+IEFuZCBmdXJ0aGVy LCBpbiB0aGUgc2FtZSBzZWN0aW9uLiBUaGVyZSBpcyBhbHNvDQo+ID4gZHJhZnQtaWV0Zi10c3Z3 Zy1kYXRhZ3JhbS0gcGxwbXR1ZCBvbiAiUGFja2V0aXphdGlvbiBMYXllciBQYXRoIE1UVQ0KPiA+ IERpc2NvdmVyeSBmb3IgRGF0YWdyYW0gVHJhbnNwb3J0cyIuIFBsZWFzZSBhbHNvIGJlIGF3YXJl IHRoYXQgdGhlcmUgaXMNCj4gPiBhbiBleHRlbnNpdmUgVFNWLUFSVCBmb3IgZHJhZnQtaWV0Zi10 cmFtLXN0dW4tcG10dWQuIEJvdGggbWlnaHQgaW1wYWN0DQo+ID4gdGhlIGZpbmFsIGNvbnRlbnQg b2YgdGhpcyBzZWN0aW9uLg0KPiANCj4gVGhlIGRyYWZ0IGRvZXMgbm90IHJlZmVyIHRvIGRyYWZ0 LWlldGYtdHN2d2ctZGF0YWdyYW0tIHBscG10dWQuDQo+IA0KPiA+DQo+ID4gMikgc2VjIDExLjU6 DQo+ID4gIldoZW4gdGhlIHNlcnZlciByZWNlaXZlcyBhbiBJQ01QIHBhY2tldCwgdGhlIHNlcnZl ciB2ZXJpZmllcyB0aGF0IHRoZQ0KPiA+ICAgIHR5cGUgaXMgZWl0aGVyIDMgb3IgMTEgZm9yIGFu IElDTVB2NCBbUkZDMDc5Ml0gcGFja2V0IG9yIGVpdGhlciAxLCAyLA0KPiA+ICAgIG9yIDMgZm9y IGFuIElDTVB2NiBbUkZDNDQ0M10gcGFja2V0LiINCj4gPiBSZXN0cmljdGluZyB0byBhIHNldCBv ZiBrbm93biB0eXBlcywgZG9lc24ndCBzZWVtIHRvIHN1cHBvcnQgZnV0dXJlDQo+ID4gZXh0ZW5z aWJpbGl0eSB2ZXJ5IHdlbGwuLi4NCj4gDQo+IEdvb2QgcG9pbnQsIGFkZGVkIHRoZSBmb2xsb3dp bmcgbGluZXM6DQo+IE5ldyBJQ01QIHR5cGVzIG9yIGNvZGVzIGNhbiBiZSBkZWZpbmVkIGluIGZ1 dHVyZSBzcGVjaWZpY2F0aW9ucy4gSWYgdGhlDQo+IHNlcnZlciByZWNlaXZlcyBhbiBJQ01QIGVy cm9yIHBhY2tldCwgYW5kIHRoZSBuZXcgdHlwZSBvciBjb2RlIGZpZWxkIGNhbg0KPiBoZWxwIHRo ZSBjbGllbnQgdG8gbWFrZSB1c2Ugb2YgdGhlIElDTVAgZXJyb3Igbm90aWZpY2F0aW9uIGFuZCBn ZW5lcmF0ZQ0KPiBmZWVkYmFjayB0byB0aGUgYXBwbGljYXRpb24gbGF5ZXIsIHRoZSBzZXJ2ZXIg c2VuZHMgdGhlIERhdGEgaW5kaWNhdGlvbiB3aXRoDQo+IGFuIElDTVAgYXR0cmlidXRlIGNvbnZl eWluZyB0aGUgbmV3IElDTVAgdHlwZSBvciBjb2RlLg0KPiANCj4gPg0KPiA+IDMpIHNlYyAxMi41 Og0KPiA+ICJPdmVyIFRDUCBhbmQgVExTLW92ZXItVENQLCB0aGUgQ2hhbm5lbERhdGEgbWVzc2Fn ZSBNVVNUIGJlIHBhZGRlZA0KPiB0bw0KPiA+ICAgIGEgbXVsdGlwbGUgb2YgZm91ciBieXRlcyBp biBvcmRlciB0byBlbnN1cmUgdGhlIGFsaWdubWVudCBvZg0KPiA+ICAgIHN1YnNlcXVlbnQgbWVz c2FnZXMuIg0KPiA+IE5vdCBleGFjdGx5IHN1cmUgd2h5IHRoaXMgaXMgdXNlZnVsLi4uPyBJcyB0 aGlzIHRvIGFsaWduIHdpdGggU1RVTiBhbmQNCj4gPiB0aGVyZWZvcmUgbWFrZSBwcm9jZXNzaW5n IHNvbWVob3cgZWFzaWVyPyBJcyB0aGF0IHJlYWxseSBuZWVkZWQuIEFuZA0KPiA+IGV4Y2VwdGlv biBzaG91bGQgYmUgZWFzeSB0byBpbXBsZW1lbnQgYW5kIHNob3VsZCBzYXZlIHNvbWUgYnl0ZXMg d2hpY2gNCj4gPiBpcyB0aGUgYXMgSSB1bmRlcnN0b29kIGl0IHRoZSB3aG9sZSBwdXJwb3NlIG9m IGNoYW5uZWxzLCBubz8NCj4gDQo+IFRoaXMgYmVoYXZpb3IgaXMgbm90IG5ldywgaXQgaXMgZGVm aW5lZCBhbmQgZGVwbG95ZWQgaW4gVFVSTg0KPiBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwv cmZjNTc2NiNzZWN0aW9uLTExLjUNCj4gDQo+ID4NCj4gPiA0KSAxMi42Og0KPiA+ICJOb3RlIHRo YXQgaWYNCj4gPiAgICB0aGUgTGVuZ3RoIGZpZWxkIGluIHRoZSBDaGFubmVsRGF0YSBtZXNzYWdl IGlzIDAsIHRoZW4gdGhlcmUgd2lsbCBiZQ0KPiA+ICAgIG5vIGRhdGEgaW4gdGhlIFVEUCBkYXRh Z3JhbSwgYnV0IHRoZSBVRFAgZGF0YWdyYW0gaXMgc3RpbGwgZm9ybWVkIGFuZA0KPiA+ICAgIHNl bnQuIg0KPiA+IENhbiB5b3UgbWF5YmUgYWRkIHNvbWUgbW9yZSB0ZXh0IGFuZCBleHBsYWluIHdo eSB0aGlzIGlzIHVzZWZ1bD8NCj4gDQo+IFN1cmUsIGFkZGVkIHJlZmVyZW5jZSB0byBTZWN0aW9u IDQuMSBpbiBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNjI2Mw0KPiANCj4gPg0KPiA+ IDUpIHNlYyAxNToNCj4gPiBSRkM2ODI0IHdpbGwgc29vbiBiZSBvYnNvbGV0ZWQgYnkgZHJhZnQt aWV0Zi1tcHRjcC1yZmM2ODI0YmlzIGFuZA0KPiA+IHBsZWFzZSBzL1RDUCBtdWx0aS1wYXRoL011 bHRpcGF0aCBUQ1AvLg0KPiANCj4gVGhhbmtzLCB1cGRhdGVkLg0KPiANCj4gPg0KPiA+IDYpIEp1 c3QgYSB0aG91Z2h0IGxvb2tpbmcgYXQgc2VjdGlvbiAxNCBhbmQgMTY6IEl0IGNvdWxkIGhhdmUg YmVlbg0KPiA+IG5pY2UgdG8gcHJvdmlkZSBhbiBFQ04gZmVlZGJhY2sgZmllbGQgZnJvbSB0aGUg c2VydmVyIHRvIHRoZSBjbGllbnQgaW4NCj4gPiBjYXNlIGEgRUNOIG1hcmtlZCBwYWNrZXQgaXMg cmVjZWl2ZWQgZnJvbSB0aGUgcGVlci4uLiBob3dldmVyLCBJIGd1ZXNzDQo+ID4gdGhhdCBmdXR1 cmUgd29yayBhdCB0aGlzIHBvaW50IGluIHRoZSBwcm9jZXNzLi4uDQo+ID4NCj4gPiA3KSBzZWMg MTguMTM6IE1heWJlIEkgbWlzc2VkIHRoaXMgYmVjYXVzZSBJIHJldmlld2VkIHRoaXMgZG9jIG92 ZXIgMw0KPiA+IGRheXMsIGJ1dCBpcyBvbmx5IHRoZSBJQ01QIEF0dHJpYnV0ZSBzZW5kIHRvIHRo ZSBjbGllbnQgb3IgaXMgdGhlDQo+ID4gYWN0dWFsIElDTVAgcGFja2V0cyBvciBhcyBtdWNoIGFz IHBvc3NpYmxlIG9mIHRoYXQgcGFja2V0IGluY2x1ZGVzIGFzIHdlbGw/DQo+IA0KPiBZZXMsIG9u bHkgdGhlIElDTVAgYXR0cmlidXRlIGlzIHNlbnQgdG8gdGhlIGNsaWVudC4NCj4gDQo+ID4NCj4g PiA4KSBzZWMgMjM6DQo+ID4gIlJlc3BvbnNlOiBUVVJOIHdpbGwgbm8gbG9uZ2VyIGJlIG5lZWRl ZCBvbmNlIHRoZXJlIGFyZSBubyBsb25nZXIgYW55DQo+ID4gICAgTkFUcy4gIFVuZm9ydHVuYXRl bHksIGFzIG9mIHRoZSBkYXRlIG9mIHB1YmxpY2F0aW9uIG9mIHRoaXMgZG9jdW1lbnQsDQo+ID4g ICAgaXQgbm8gbG9uZ2VyIHNlZW1zIHZlcnkgbGlrZWx5IHRoYXQgTkFUcyB3aWxsIGdvIGF3YXkg YW55IHRpbWUgc29vbi4NCj4gPiAgICBIb3dldmVyLCB0aGUgbmVlZCBmb3IgVFVSTiB3aWxsIGFs c28gZGVjcmVhc2UgYXMgdGhlIG51bWJlciBvZiBOQVRzDQo+ID4gICAgd2l0aCB0aGUgbWFwcGlu ZyBwcm9wZXJ0eSBvZiBFbmRwb2ludC1JbmRlcGVuZGVudCBNYXBwaW5nIFtSRkM0Nzg3XQ0KPiA+ ICAgIGluY3JlYXNlcy4iDQo+ID4gWWVzLi4uIHNvIHlvdSBkb24ndCB0aGluayB0aGF0IElQdjYg d2lsbCBiZSBhbnkgaGVscCBoZXJlPw0KPiANCj4gWWVzLCBJUHY2IHdpbGwgbm90IGhlbHAgaW4g c29tZSBzY2VuYXJpb3MsIHVwZGF0ZWQgSW50cm9kdWN0aW9uIHRvIGxpc3QgdGhlbS4NCj4gDQo+ ICAgIEluIG1hbnkgZW50ZXJwcmlzZSBuZXR3b3JrcywgZGlyZWN0IFVEUCB0cmFuc21pc3Npb25z IGFyZSBub3QNCj4gICAgcGVybWl0dGVkIGJldHdlZW4gY2xpZW50cyBvbiB0aGUgaW50ZXJuYWwg bmV0d29ya3MgYW5kIGV4dGVybmFsIElQDQo+ICAgIGFkZHJlc3Nlcy4gIFRvIHBlcm1pdCBtZWRp YSBzZXNzaW9ucyBpbiBzdWNoIGEgc2l0dWF0aW9uIHRvIHVzZSBVRFANCj4gICAgYW5kIHRvIGF2 b2lkIGZvcmNpbmcgdGhlIG1lZGlhIHNlc3Npb25zIHRocm91Z2ggVENQLCBFbnRlcnByaXNlDQo+ ICAgIEZpcmV3YWxsIGNhbiBiZSBjb25maWd1cmVkIHRvIGFsbG93IFVEUCB0cmFmZmljIHJlbGF5 ZWQgdGhyb3VnaCBhbg0KPiAgICBFbnRlcnByaXNlIHJlbGF5IHNlcnZlci4gIFRoaXMgc2NlbmFy aW8gaXMgcmVxdWlyZWQgdG8gYmUgc3VwcG9ydGVkDQo+ICAgIGJ5IHRoZSBXZWJSVEMgcmVxdWly ZW1lbnRzIChTZWN0aW9uIDIuMy41LjEgaW4gW1JGQzc0NzhdKS4gIEluDQo+ICAgIGFkZGl0aW9u LCBpbiBhIFNJUCBvciBXZWJSVEMgY2FsbCwgaWYgdGhlIHVzZXIgd2FudHMgSVAgbG9jYXRpb24N Cj4gICAgcHJpdmFjeSBmcm9tIHRoZSBwZWVyIHRoZW4gdGhlIGNsaWVudCBjYW4gc2VsZWN0IGEg cmVsYXkgc2VydmVyDQo+ICAgIG9mZmVyaW5nIElQIGxvY2F0aW9uIHByaXZhY3kgYW5kIG9ubHkg Y29udmV5IHRoZSByZWxheWVkIGNhbmRpZGF0ZXMNCj4gICAgdG8gdGhlIHBlZXIgZm9yIElDRSBj b25uZWN0aXZpdHkgY2hlY2tzIChzZWUgU2VjdGlvbiA0LjIuNCBpbg0KPiAgICBbSS1ELmlldGYt cnRjd2ViLXNlY3VyaXR5XSkuDQo+IA0KPiA+DQo+ID4gRWRpdG9yaWFsIGNvbW1lbnRzOg0KPiA+ DQo+ID4gMSkgU2VjIDY6DQo+ID4gIlRoZSByZWxheWVkIHRyYW5zcG9ydCBhZGRyZXNzIE1VU1Qg YmUgdW5pcXVlIGFjcm9zcyBhbGwNCj4gPiAgICBhbGxvY2F0aW9ucywgc28gaXQgY2FuIGJlIHVz ZWQgdG8gdW5pcXVlbHkgaWRlbnRpZnkgdGhlIGFsbG9jYXRpb24uDQo+ID4NCj4gPiAgICBCb3Ro IHRoZSByZWxheWVkIHRyYW5zcG9ydCBhZGRyZXNzIGFuZCB0aGUgNS10dXBsZSBNVVNUIGJlIHVu aXF1ZQ0KPiA+ICAgIGFjcm9zcyBhbGwgYWxsb2NhdGlvbnMsIHNvIGVpdGhlciBvbmUgY2FuIGJl IHVzZWQgdG8gdW5pcXVlbHkNCj4gPiAgICBpZGVudGlmeSB0aGUgYWxsb2NhdGlvbiwgWy4uLl0i DQo+ID4gVGhlc2UgdHdvIHNlbnRlbmNlcyBzZWVtIHF1aXRlIHJlZHVuZGFudC4gVGhlIGZpcnN0 IG9uZSB3YXMgYWRkZWQgaW4NCj4gPiB0aGlzIGRyYWZ0LiBUaGUgc2Vjb25kIG9uZSB3YXMgYWxy ZWFkeSB0aGVyZSBpbiBSRkM1NzY2Lg0KPiANCj4gVGhhbmtzLCByZW1vdmVkIHRoZSBzZWNvbmQg c2VudGVuY2UuDQo+IA0KPiA+DQo+ID4gMikgc2VjIDcuMToNCj4gPiAiU2luY2UgdGhpcyBzcGVj aWZpY2F0aW9uIG9ubHkNCj4gPiAgICBhbGxvd3MgVURQIGJldHdlZW4gdGhlIHNlcnZlciBhbmQg dGhlIHBlZXJzLCBpdCBpcyBSRUNPTU1FTkRFRCB0aGF0DQo+ID4gWy4uLl0iDQo+ID4gV29yZGlu Z3MgKCJvbmx5IGFsbG93cyIpIHNlZW1zIHdlaXJkIHRvIG1lIGdpdmVuIHVzZSBvZiBvdGhlcg0K PiA+IHByb3Bvc2FscyBpcyBhdCBsZWFzdCB0byBzb21lIGV4dGVuZCBkaXNjdXNzZWQuDQo+IA0K PiBUaGUgc3BlY2lmaWNhdGlvbiBkb2VzIG5vdCBhbGxvdyBhbnkgb3RoZXIgcHJvdG9jb2wgb3Ro ZXIgdGhhbiBVRFAgYmV0d2Vlbg0KPiB0aGUgc2VydmVyIGFuZCBwZWVycyAoQXMgeW91IGtub3cs IFVEUCBpcyB0aGUgcHJlZmVycmVkIHRyYW5zcG9ydCBmb3IgbWVkaWENCj4gc3RyZWFtcykuDQo+ IA0KPiA+DQo+ID4gTml0czoNCj4gPiBzZWMgNy4xLjogcy90aGUgY2xpZW50IHBpY2sgYSBjdXJy ZW50bHkgdW51c2VkIHRyYW5zcG9ydCBhZGRyZXNzL3RoZQ0KPiA+IGNsaWVudCBwaWNrcyBhIGN1 cnJlbnRseSB1bnVzZWQgdHJhbnNwb3J0IGFkZHJlc3MvDQo+IA0KPiBGaXhlZC4NCj4gDQo+IENo ZWVycywNCj4gLVRpcnUNCj4gPg0KPiA+DQo+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCj4gPiB0cmFtIG1haWxpbmcgbGlzdA0KPiA+IHRyYW1AaWV0 Zi5vcmcNCj4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RyYW0NCg== From nobody Thu Jul 18 13:10:40 2019 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 890A5120112; Thu, 18 Jul 2019 13:10:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 M_fMu2aplWtk; Thu, 18 Jul 2019 13:10:28 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 D67F6120074; Thu, 18 Jul 2019 13:10:27 -0700 (PDT) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x6IKAKOU026859 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 18 Jul 2019 16:10:23 -0400 Date: Thu, 18 Jul 2019 15:10:20 -0500 From: Benjamin Kaduk To: "Konda, Tirumaleswar Reddy" Cc: The IESG , "tram-chairs@ietf.org" , "draft-ietf-tram-turnbis@ietf.org" , "tram@ietf.org" , "brandon.williams@akamai.com" Message-ID: <20190718201019.GI83144@kduck.mit.edu> References: <156282359426.15056.17118634579091500165.idtracker@ietfa.amsl.com> <20190713021429.GR16418@mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [tram] Benjamin Kaduk's Discuss on draft-ietf-tram-turnbis-27: (with DISCUSS and COMMENT) X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.29 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, 18 Jul 2019 20:10:32 -0000 On Sat, Jul 13, 2019 at 06:10:55AM +0000, Konda, Tirumaleswar Reddy wrote: > Hi Ben, > > Please see inline > > > -----Original Message----- > > From: Benjamin Kaduk > > Sent: Saturday, July 13, 2019 7:45 AM > > To: Konda, Tirumaleswar Reddy > > Cc: The IESG ; tram-chairs@ietf.org; draft-ietf-tram- > > turnbis@ietf.org; tram@ietf.org; brandon.williams@akamai.com > > Subject: Re: [tram] Benjamin Kaduk's Discuss on draft-ietf-tram-turnbis-27: > > (with DISCUSS and COMMENT) > > > > This email originated from outside of the organization. Do not click links or > > open attachments unless you recognize the sender and know the content is > > safe. > > > > Hi Tiru, > > > > On Thu, Jul 11, 2019 at 03:47:19PM +0000, Konda, Tirumaleswar Reddy wrote: > > > Hi Ben, > > > > > > Thanks for the detailed review. Please see inline > > > > Sorry to have made you deduplicate with the reviews that had already come > > in -- I wrote this text fairly early (on just the diff) with intent to return and > > tidy up, but ran out of time and had to just submit what I had. > > No problem, the review helped to improve the draft. > > > > > > > -----Original Message----- > > > > From: tram On Behalf Of Benjamin Kaduk via > > > > Datatracker > > > > Sent: Thursday, July 11, 2019 11:10 AM > > > > To: The IESG > > > > Cc: tram-chairs@ietf.org; draft-ietf-tram-turnbis@ietf.org; > > > > tram@ietf.org; brandon.williams@akamai.com > > > > Subject: [tram] Benjamin Kaduk's Discuss on > > > > draft-ietf-tram-turnbis-27: (with DISCUSS and COMMENT) > > > > > > > > > > > > > > > > Benjamin Kaduk has entered the following ballot position for > > > > draft-ietf-tram-turnbis-27: 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-turnbis/ > > > > > > > > > > > > > > > > -------------------------------------------------------------------- > > > > -- > > > > DISCUSS: > > > > -------------------------------------------------------------------- > > > > -- > > > > > > > > I support Roman's Discuss. > > > > > > I have updated the draft to address Roman's Discuss. > > > > > > > > > > > I think I'm confused about whether REQUESTED-ADDRESS-FAMILY and > > > > ADDITIONAL-ADDRESS-FAMILY are mutually exclusive. > > > > > > Yes, both attributes are mutually exclusive. It is discussed in Section 7.1, > > Clients MUST NOT include REQUESTED-ADDRESS-FAMILY and ADDITIONAL- > > ADDRESS-FAMILY attributes in the same request. > > > > Okay. This seems weird to me and I wouldn't object if some very blunt text > > was added early on about "when both IPv4 and IPv6 are desired, the > > ADDITIONAL-ADDRESS-FAMILY attribute alone serves to request both > > address types; otherwise the single REQUESTED-ADDRESS-FAMILY attribute > > suffices", but this point clearly is not Discuss-worthy. > > This point is already covered in Section 5 (General Behavior) as follows: > > TURN, as defined in this specification, supports both IPv4 and IPv6. IPv6 support in TURN includes IPv4-to-IPv6, IPv6-to-IPv6, and IPv6-to-IPv4 relaying. The REQUESTED-ADDRESS-FAMILY attribute allows a client to explicitly request the address type the TURN server will allocate (e.g., an IPv4-only node may request the TURN server to allocate an IPv6 address). The ADDITIONAL-ADDRESS-FAMILY attribute allows a client to request the server to allocate one IPv4 and one IPv6 relay address in a single Allocate request. This saves local ports on the client and reduces the number of messages sent between the client and the TURN server. I was thinking more like "When only a single address type is desired, the REQUESTED-ADDRESS-FAMILY attribute is used to explicitly request [...]. If both IPv4 and IPv6 are desired, the single ADDITIONAL-ADDRESS-FAMILY attribute indicates a request to the server to allocate [...]". > > > > > > Does sending just the > > > > "additional" one secretly mean that you want both v4 and v6? > > > > > > Yes, ADDITIONAL-ADDRESS-FAMILY is used for allocation of both IPv4 and > > IPv6. > > > > > > > > > > > Section 5 > > > > > > > > I see that the secdir reviewer asked about why it is a "SHOULD" to > > > > send SOFTWARE, and only got a response that it is defined in > > > > stunbis, but not about why it is recommended. There remain some > > > > privacy/security considerations with it, and we should either point > > > > to the stunbis security considerations or not recommend using it. > > > > (FINGERPRINT is, IIRC, less interesting from a security perspective > > > > as it's just about confirming that given traffic is in fact STUN and > > > > not something else.) > > > > > > This "SHOULD" to send SOFTWARE attribute is defined in RFC5766 (As you > > may know, TURN is used in the field for several years) and turnbis does not > > modify the behavior for backward compatibility, and to address the possible > > threat added the following lines: > > > > > > SOFTWARE attribute can reveal the specific software version of the TURN > > client and server to eavesdropper and it might possibly allow attacks against > > vulnerable software that is known to contain security holes. If it is important > > to prevent an eavesdropper from learning the software version, TURN can > > be run over (D)TLS. > > > > (let's keep this on the secdir thread) > > Okay. > > > > > > > > > > > Section 12 > > > > > > > > Do we need to say anything about backwards compatibility with RFC > > > > 5766 peers that use a wider range of channel IDs? > > > > > > Yes, added the following line: > > > Note that the channel number range is not backwards compatible with > > > [RFC5766], and cannot be used in environments where such compatibility > > > is required. > > > > I see now that Adam also raised this topic, and I'd like to hear his thoughts on > > this proposed text. Since we normally don't make breaking changes in "bis" > > documents, I'd also like to hear a bit more about what knoweldge we have (if > > any) about implementations that might be affected and are not affected. > > Update to the TURN channel number range is done in https://tools.ietf.org/html/rfc7983#section-9.3 to distinguish multiplexed protocols, and the range is updated in turnbis to align with RFC7983 . > > > > > > > > > > > Section 12.7 > > > > > > > > When the server receives an ICMP packet, the server processes it as > > > > described in Section 11.5. A Data indication MUST be sent regardless > > > > of whether there is a channel bound to the peer that was the > > > > destination of the UDP datagram that triggered the reception of the > > > > ICMP packet. > > > > > > > > This MUST seems potentially in conflict with the previous discussion > > > > about permissions checks in Section 11.5. > > > > > > Good catch, removed conflicting text from Section 12.7. > > > > > > > > > > > Section 20 > > > > > > > > Looking at the > > > > new nonce in the example ("obMatJos2AAABadl7W7PeDU4hKE72jda"), > > and > > > > noting that it starts with the nonce cookie, help me decode the > > > > security feature bits. The magic prefix is "obMatJos2" so the > > > > capability bits are encoded as "AAAB", which decodes to (hex) 00 00 > > > > 01. But stunbis says that the bits are ordered from 0 (MSB of first > > > > byte) to 23 (LSB of last byte), so this would have bit 23 set, which > > > > is in contrast to the registry marking bit 0 as the password-algorithms > > feature. Where am I messing this up? > > > > > > You are right, replaced with "obMatJos2gAAAadl7W7PeDU4hKE72jda" (hex) > > > 80 00 00 > > > > It's reassuring to know that I wasn't missing something obvious; thanks! > > Thanks for catching it :) > > > > > > > > > > > I'd prefer if the examples showed more usage of MESSAGE-INTEGRITY- > > > > SHA256 (especially, any from the server) and fewer MESSAGE-INTEGRITY. > > > > > > Sure, updated examples. > > > > > > > > > > > > > > > -------------------------------------------------------------------- > > > > -- > > > > COMMENT: > > > > -------------------------------------------------------------------- > > > > -- > > > > > > > > Thanks for keeping the diff from RFC 5766 relatively contained! > > > > I only reviewed the diff due to time constraints, but in general > > > > support reviewing the full document for internal consistency and any > > > > remarks that have not aged well, especially with respect to IANA > > considerations. > > > > > > > > Section 2 > > > > > > > > RFC 8174 has an updated version of the BCP 14 boilerplate text. > > > > > > Fixed. > > > > > > > > > > > Section 3.1 > > > > > > > > I appreciate the response to the secdir review, but even the linked > > > > stunbis section does not say much about which PKI's trust root is > > > > expected to be used. I'm forced to assume the Web PKI but don't > > > > have much grounds for that assumption. > > > > > > Yes, use pre-populated trust store on the endpoint to validate the > > certificate path. > > > > > > > > > > > Section 3.2 > > > > > > > > The secdir reviewer's comments seem to have some relevance. > > > > It seems like even when the third-party authorization mechanism is > > > > used, the client is still limited to "the server is authenticated > > > > because it gives me the service I asked for", which is not really > > > > documented anywhere yet. The long-term password mechanism at least > > > > generates an HMAC integrity tag on messages from server to client, > > > > which can provide some level of authentication via key confirmation. > > > > > > No, STURN third-party authorization provides message integrity for both > > request and response messages (please see > > https://tools.ietf.org/html/rfc7635#section-5). The mac_key to compute the > > message integrity can change per call and this mechanism is better than the > > long-term password mechanism. Note that WebRTC uses third-party > > authorization mechanism. > > > > Ah, that's reassuring to learn. Sorry for the confusion. > > > > > > > > > > Section 3.7 > > > > > > > > If the TURN server carrying out > > > > packet translation from IPv4-to-IPv6 cannot get the Don't Fragment > > > > (DF) bit in the IPv4 header, it MUST reject the Allocate request with > > > > DONT-FRAGMENT attribute. > > > > > > > > nit: does "cannot get" mean something like "read the value as sent > > > > on the wire" (e.g., due to implementation/API limitations)? > > > > > > Yes, cannot read the value as sent on wire. > > > > I'd suggest "is unable to access the state of", but that's entirely editorial and > > at your discretion. > > Thanks, updated. > > > > > > > > > > > Section 6 > > > > > > > > o the relayed transport address or addresses; > > > > [...] > > > > > > > > [...] > > > > address. The relayed transport address MUST be unique across all > > > > allocations, so it can be used to uniquely identify the allocation. > > > > > > > > nit: there's maybe a singular/plural mismatch going on here, but I > > > > don't have any good ideas. > > > > > > > > Section 7.1 > > > > > > > > If the client wishes to obtain one IPv6 and one IPv4 relayed > > > > transport address then it includes an ADDITIONAL-ADDRESS-FAMILY > > > > attribute in the request. This attribute specifies that the server > > > > must allocate both address types. The attribute value in the > > > > ADDITIONAL-ADDRESS-FAMILY MUST be set to 0x02 (IPv6 address > > family). > > > > Clients MUST NOT include REQUESTED-ADDRESS-FAMILY and > > ADDITIONAL- > > > > ADDRESS-FAMILY attributes in the same request. [...] > > > > > > > > This reads like setting REQUESTED-ADDRESS-FAMILY and ADDITIONAL- > > > > ADDRESS-FAMILY are mutually exclusive. Is that the correct reading? > > > > > > Yes. > > > > > > > (Naively, one might expect that the thing named "additional" > > > > is applied on top of the base-level request, so I have to ask.) > > > > > > > > Section 7.2 > > > > > > > > Why do we only have a SHOULD-level requirement for authentication of > > > > Allocate requests where 5766 had MUST? Could we say "may allow > > > > unauthenticated requests in order to support [use case] but > > > > otherwise MUST require authentication" (with better wording)? I > > > > suppose this has probably been discussed ad nauseum already, so feel > > > > free to point me at the archives before getting into an actual discussion. > > > > > > You missed the next line, it says the authentication of the request is > > > optional to allow TURN servers provided by the local or access network > > > to accept Allocation requests from new and/or guest users in the > > > network who do not necessarily possess long term credentials for STUN > > > authentication and its security implications are discussed in > > > [RFC8155]. > > > > I saw the next line; the current formulation also allows non-use of > > authentication in other situations, which is why I suggested an alternate > > wording. > > > > > The WG spent several cycles discussing the downgrade of a MUST level > > requirement (please see https://tools.ietf.org/html/rfc8155#section-9). > > > > To be clear, I do not object to removing the MUST for the local-use case; I'm > > concerned with the wording of the text that, as written, also weakens the > > requirement for all other cases. > > Got it, updated step as follows: > > 1. The TURN server provided by the local or access network MAY > allow unauthenticated request in order to accept Allocation > requests from new and/or guest users in the network who do not > necessarily possess long term credentials for STUN > authentication and its security implications are discussed in > [RFC8155]. Otherwise, the server MUST require that the request > be authenticated. If the request is authenticated, the > authentication MUST be done either using the long-term credential > mechanism of [I-D.ietf-tram-stunbis] or the STUN Extension for > Third-Party Authorization [RFC7635] unless the client and server > agree to use another mechanism through some procedure outside > the scope of this document. That should work (though I wonder if the RFC Editor will tweak things, since the "otherwise" is separated by another sentence from the initial case it's contrasting with). I do note that the diff link you sent out also removes some text (in a 4.x or 5.x section?) about "the server MUST demand that all requests from the client be authenticated" after the "MUST implement [long-term credentials]" requirement. It might be worth making a forward reference from that location to this text, if possible. Thanks, Ben > > > > > > > > > > 7. If the server does not support the address family requested by > > > > the client in REQUESTED-ADDRESS-FAMILY or is disabled by local > > > > policy, it MUST generate an Allocate error response, and it MUST > > > > include an ERROR-CODE attribute with the 440 (Address Family not > > > > Supported) response code. [...] > > > > > > > > nit: "or is disabled" needs a subject. > > > > > > Fixed, updated text as follows: > > > If the server does not support the address family requested by the client in > > REQUESTED-ADDRESS-FAMILY or if the allocation of the requested address > > family is disabled by local policy, it MUST generate an Allocate error response, > > and it MUST include an ERROR-CODE attribute with the 440 (Address Family > > not Supported) response code. > > > > Thanks > > > > > > 9. The server checks if the request contains an ADDITIONAL-ADDRESS- > > > > FAMILY attribute. If yes, and the attribute value is 0x01 (IPv4 > > > > address family), then the server rejects the request with a 400 > > > > (Bad Request) error. Otherwise, the server checks if it can > > > > allocate relayed transport addresses of both address types. If > > > > the server cannot satisfy the request, then the server > > > > rejects > > > > > > > > What are "both" address types? > > > > > > Both IPv4 and IPv6 address families. > > > > I guess once I realize that "ADDITIONAL-ADDRESS-FAMILY" is just code for > > "IPv4 and IPv6" with no other options, this doesn't look as unclear. > > > > > > We only have the ADDITIONAL-ADDRESS- FAMILY (which contains one > > > > type) and no REQUESTED-ADDRESS-FAMILY. > > > > > > If ADDITIONAL-ADDRESS-FAMILY is used, the server will allocate both IPv4 > > and IPv6 relayed transport addresses. > > > > > > > > > > > Section 8.1 > > > > > > > > When refreshing a dual allocation, the client includes REQUESTED- > > > > ADDRESS-FAMILY attribute indicating the address family type that > > > > should be refreshed. If no REQUESTED-ADDRESS-FAMILY is included > > then > > > > the request should be treated as applying to all current allocations. > > > > The client MUST only include family types it previously allocated and > > > > has not yet deleted. [...] > > > > > > > > I'm a bit confused about "only include family types" plural; I > > > > thought there could only be at most one REQUESTED-ADDRESS-FAMILY > > and > > > > that it would only indicate one family type. So how could there be > > > > multiple types getting included by the client? > > > > > > Good catch, replaced "types" with "type" > > > > (It needs a definite article, then for "only include the family type") > > Done. > > Cheers, > -Tiru > > > > > > > > > > > Section 11.5 > > > > > > > > [check that "type and code" is valid in both ICMPv4 and v6] > > > > > > Yes, it is valid. > > > > Sorry; that was supposed to be a note to myself! > > But yes, luckily for me this is not the point of difference between ICMPv4 > > and ICMPv6 that I was vaguely remembering. > > > > > > > > > > Section 12 > > > > > > > > Reserved values may be used in the future by other protocols. When > > > > the client uses channel binding, it MUST comply with the > > > > demultiplexing scheme discussed above. > > > > > > > > "channel binding" is a term of art in the security world; is this > > > > usage intended to roughly mean "channel multiplexing"? > > > > (I do see that the subsections are talking about the specific > > > > ChannelBind request, so I assume so; I just want to double check.) > > > > > > Yes, a channel binding is created or refreshed using a ChannelBind > > transaction (Please see Section 12.1). > > > > Great. Well, not great that there's a collision of jargon, but it's way too late to > > do anything about, now. > > > > > > > > > > > > > > Section 13 > > > > > > > > The descriptions below have two parts: a preferred behavior and an > > > > alternate behavior. The server SHOULD implement the preferred > > > > behavior. Otherwise, the server MUST implement the alternate > > > > behavior and MUST NOT do anything else for the reasons detailed in > > > > [RFC7915]. [...] > > > > > > > > RFC 5766 had this split on a per-field basis, but this text suggests > > > > that if the preferred behavior is not possible for a given field, > > > > then the alternate behavior is used for the entire packet. > > > > I note that section 14 does retain the "for a particular field" > > > > language for UDP-to-UDP relaying, as do section 15 for TCP-to-UDP > > > > relaying and section 16 for UDP-to-TCP relaying. > > > > > > Good point, fixed text as follows: > > > Otherwise, if that is not possible for a particular field, the server MUST > > implement the alternate behavior and MUST NOT do anything else for the > > reasons detailed in [RFC7915]. > > > > > > > > > > > Section 13.2 > > > > > > > > Is this flow label text consistent with both the inbound and > > > > outbound translation directions (specifically, using relayed/peer > > > > addresses in the 5- tuple to identify the flow)? > > > > > > > > If the incoming packet did not include a Fragment header and the > > > > outgoing packet size exceeds the outgoing link's MTU, the TURN > > > > server drops the outgoing packet and send an ICMP message of type > > > > 2 code 0 ("Packet too big") to the sender of the incoming packet. > > > > If the packet is being sent to the peer, the TURN server reduces > > > > the MTU reported in the ICMP message by 48 bytes to allow room for > > > > the overhead of a Data indication. > > > > > > > > (nit?) "If the packet is being send to the peer" seems to > > > > grammatically refer to the outgoing packet that would exceed link > > > > MTU, as opposed to the ICMP message being generated. But I think > > > > it's supposed to refer to the ICMP message being generated, which has > > not yet been referred to as a "packet" > > > > in this text. > > > > > > Suresh raised the same comment, fixed text as follows: > > > If the ICMPv6 packet ("Packet too big") is being sent to the peer, the TURN > > server reduces the MTU reported in the ICMP message by 48 bytes to allow > > room for the overhead of a Data indication. > > > > Great; t hanks > > > > > > > > > > Section 13.3 > > > > > > > > [Same comment about ICMP packet generation/grammar] > > > > > > Fixed text as follows: > > > If the ICMPv4 packet (Destination Unreachable (Type 3) with Code 4) is > > being sent to the peer, the TURN server SHOULD reduce the MTU reported > > in the ICMP message by 48 bytes to allow room for the overhead of a Data > > indication. > > > > > > > > > > > Section 15 > > > > > > > > Maybe note that SIP and WebRTC are the primary consumers of TURN? > > > > > > Yes, it is mentioned in several places in the document that WebRTC and SIP > > use TURN. > > > > Okay; my fault for only looking at the diff, probably. > > > > > > > > > > Even if both > > > > TCP-AO and UDP authentication would be used between TURN client > > and > > > > server, it would not change the end-to-end security properties of the > > > > UDP payload being relayed. [...] > > > > > > > > I wonder if we even need to say "UDP" in "payload being relayed". > > > > > > Replaced "UDP" with "application" > > > > > > > > > > > Section 16 > > > > > > > > Fragmentation > > > > > > > > Preferred Behavior: Any fragmented packets are reassembled in the > > > > server and then forwarded to the client over the TCP connection. > > > > ICMP messages resulting from the UDP datagrams sent to the peer > > > > MUST be forwarded to the client using TURN's mechanism for > > > > relevant ICMP types and codes. > > > > > > > > As in section 12.7, I wonder if this MUST could be seen as > > > > overriding other logic for ICMP handling. > > > > > > Modified text for clarity as follows: > > > > > > ICMP messages resulting from the UDP datagrams sent to the peer are > > > processed by the server as described in Section 11.5 and forwarded to > > > the client using TURN's mechanism for relevant ICMP types and codes. > > > > Thanks > > > > > > > > > > Section 21.16 > > > > > > > > I agree with the secdir reviewer that there is at least potential > > > > for username and realm to be sensitive. > > > > > > I proposed to add the following text: > > > > > > If the TURN client and server use the STUN Extension for Third-Party > > > Authorization [RFC7635] (for example it is used in WebRTC), the > > > username does not reveal the real user's identity, the USERNAME > > > attribute carries an ephemeral and unique key identifier. If the > > > TURN client and server use the STUN long-term credential mechanism > > > and the username reveals the real user's identity, the client needs > > > to use (D)TLS transport between the client and the server or use the > > > USERHASH attribute instead of the USERNAME attribute to anonynmize > > > the username. > > > > > > If the TURN client and server use the STUN long-term credential > > > mechanism and realm information is privacy sensitive, TURN can be run > > > over (D)TLS. As a reminder, STUN Extension for Third-Party > > > Authorization does not use realm. > > > > Excellent; thank you! > > > > > > > > > > Section 21.4 > > > > > > > > Do we need references for Teredo and/or 6to4? > > > > > > https://tools.ietf.org/html/rfc6156 did not add references to Teredo and > > 6to4. > > > > Okay; just wanted to check. > > > > > > > > > > Section 22 > > > > > > > > The codepoints for the STUN error codes defined in this specification > > > > are listed in Section 19. [IANA is requested to update the reference > > > > from [RFC5766] to RFC-to-be for the STUN error codes listed in > > > > Section 19.] > > > > > > > > (I think some of them are from RFC 6156 as well as from 5766.) > > > > > > Yes, added RFC6156. > > > > > > > > > > > Section 23 > > > > > > > > It seems prudent to revisit these listed IAB Considerations for > > > > whether the situation has changed in the past ten years (though I > > > > don't have any specific points that I would change). > > > > > > > > Section 25 > > > > > > > > (nit) are these really "updates" to RFC 6156 so much as > > > > incorporating its content wholesale into the core TURN specification? > > > > > > Yes, several sections in RFC6156 are updated. > > > > Okay, thanks. > > > > -Ben > From nobody Thu Jul 18 22:30:18 2019 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 D12321200FB for ; Thu, 18 Jul 2019 22:30:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4 X-Spam-Level: X-Spam-Status: No, score=-4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=mcafee.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SNfn0UrNe1KK for ; Thu, 18 Jul 2019 22:30:11 -0700 (PDT) Received: from us-smtp-delivery-210.mimecast.com (us-smtp-delivery-210.mimecast.com [63.128.21.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 047801200D7 for ; Thu, 18 Jul 2019 22:30:10 -0700 (PDT) X-NAI-Header: Modified by McAfee Email Gateway (5500) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mcafee.com; s=s_mcafee; t=1563513539; h=ARC-Seal: ARC-Message-Signature:ARC-Authentication-Results: From:To:CC:Subject:Thread-Topic:Thread-Index: Date:Message-ID:References:In-Reply-To:Accept-Language: Content-Language:X-MS-Has-Attach:X-MS-TNEF-Correlator: dlp-product:dlp-version:dlp-reaction:authentication-results: x-originating-ip:x-ms-publictraffictype:x-ms-office365-filtering-correlation-id: x-microsoft-antispam:x-ms-traffictypediagnostic: x-ms-exchange-purlcount:x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers:x-forefront-prvs: x-forefront-antispam-report:received-spf:x-ms-exchange-senderadcheck: x-microsoft-antispam-message-info:Content-Type: Content-Transfer-Encoding:MIME-Version:X-MS-Exchange-CrossTenant-Network-Message-Id: X-MS-Exchange-CrossTenant-originalarrivaltime: X-MS-Exchange-CrossTenant-fromentityheader: X-MS-Exchange-CrossTenant-id:X-MS-Exchange-CrossTenant-mailboxtype: X-MS-Exchange-CrossTenant-userprincipalname: X-MS-Exchange-Transport-CrossTenantHeadersStamped: X-OriginatorOrg:X-NAI-Spam-Flag:X-NAI-Spam-Level: X-NAI-Spam-Threshold:X-NAI-Spam-Score:X-NAI-Spam-Version; bh=1748xzme8SSWJxnrOYOn6ECb/9v+cQzNi3SEpO JEDVE=; b=lPQfOElkAs7m9Dn7V7jivM1SGjG0/t8qGa3Donbg sWWJ8NLSDqlJEUCeFs9qoUbYh3DaKZXHb2wcV9+HCis8Me+frQ 8WfN4hAbywdJJTjNP6zek8KGq3PiaWWjbjKs5DEgo6JOov0m9r 9MJoWNomdEU+GgzJTPpxNwCWvGL+kWE= Received: from DNVWSMAILOUT1.mcafee.com (dnvwsmailout1.mcafee.com [161.69.31.173]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-228-BzK8DFVxPXScSRpIuC5uRQ-1; Fri, 19 Jul 2019 01:30:00 -0400 Received: from DNVEXAPP1N06.corpzone.internalzone.com (unknown [10.44.48.90]) by DNVWSMAILOUT1.mcafee.com with smtp (TLS: TLSv1/SSLv3,256bits,ECDHE-RSA-AES256-SHA384) id 6f0d_083f_215f385b_2258_4474_a1c8_150a5e68324f; Thu, 18 Jul 2019 23:18:57 -0600 Received: from DNVEXAPP1N05.corpzone.internalzone.com (10.44.48.89) by DNVEXAPP1N06.corpzone.internalzone.com (10.44.48.90) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Thu, 18 Jul 2019 23:29:48 -0600 Received: from DNVO365EDGE1.corpzone.internalzone.com (10.44.176.66) by DNVEXAPP1N05.corpzone.internalzone.com (10.44.48.89) with Microsoft SMTP Server (TLS) id 15.0.1395.4 via Frontend Transport; Thu, 18 Jul 2019 23:29:49 -0600 Received: from NAM03-CO1-obe.outbound.protection.outlook.com (10.44.176.243) by edge.mcafee.com (10.44.176.66) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Thu, 18 Jul 2019 23:29:48 -0600 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=R/n3CyS5BRykXky+HHx9asXSLk2lRZ6g6+aBLf02Tr+si+Q1J2h8MhIzxFbwtj08Qnrf7/gQtpKlc01fxUAFAsCALmMEVoj38m+vuX65v/N8nHTtrlWP8dGdB3bd5F9tgr/nnWrILXaJ+QdwHSFuV0xrwpRUU7vb9BmG0/rCjQtatRum+9j59vQSr9bEaOfzchgKSoPgQ0fBOi4lmkjHShCzGnAmHyIs1U3vknUfyTvXnyQxPJKDjQBLCt7qvM1GIY3Sdn+nLUmMT9NwohFRUIkNoTdH966XYGOYKu97XBEZ+KBGBiEcbFlFymt2ANk3dLAMx84+u/6+oKpsmlcLpw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=1748xzme8SSWJxnrOYOn6ECb/9v+cQzNi3SEpOJEDVE=; b=WpzqIagUC0US/xvlQUb4SpqSTRRDqn6qx5f1Bc6PSG5l6krvX1+OSTHlidvk5la073ttS7v+soJj4B//NDQ2PfomwXcMXrh4P9vOeYpUmAviQrBKwQ66Rn9BgU6il21Sjp25mK7ndm6ZW20ntLWEpp9vZhdjYFXGF4nK7L2vzSHEXhJKIXNXBTcX85U/SF440Pslf0JtXGvWAMtQwFal7Y4ClKRhPKu/3c1HuiOUUb6AZAFfRUOWiSLgzmDrJksfu0Cxc0OIUDzJxjRyET81Hqzhx/UGCcw9RqKWSCo3PwafuLEnLWzoMaNzSXJe74XlP1KPgh9rJ+oea6dVTkI2/A== ARC-Authentication-Results: i=1; mx.microsoft.com 1;spf=pass smtp.mailfrom=mcafee.com;dmarc=pass action=none header.from=mcafee.com;dkim=pass header.d=mcafee.com;arc=none Received: from DM5PR16MB1705.namprd16.prod.outlook.com (10.172.44.147) by DM5PR16MB2262.namprd16.prod.outlook.com (52.132.142.39) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2073.10; Fri, 19 Jul 2019 05:29:45 +0000 Received: from DM5PR16MB1705.namprd16.prod.outlook.com ([fe80::570:2208:75c2:5f17]) by DM5PR16MB1705.namprd16.prod.outlook.com ([fe80::570:2208:75c2:5f17%8]) with mapi id 15.20.2073.012; Fri, 19 Jul 2019 05:29:45 +0000 From: "Konda, Tirumaleswar Reddy" To: Benjamin Kaduk CC: The IESG , "tram-chairs@ietf.org" , "draft-ietf-tram-turnbis@ietf.org" , "tram@ietf.org" , "brandon.williams@akamai.com" Thread-Topic: [tram] Benjamin Kaduk's Discuss on draft-ietf-tram-turnbis-27: (with DISCUSS and COMMENT) Thread-Index: AQHVN6sj5hqeZIdQXEa8/G2g6Mwv66bFIQEggAKxEACAAC4dEIAI2iEAgACJI0A= Date: Fri, 19 Jul 2019 05:29:44 +0000 Message-ID: References: <156282359426.15056.17118634579091500165.idtracker@ietfa.amsl.com> <20190713021429.GR16418@mit.edu> <20190718201019.GI83144@kduck.mit.edu> In-Reply-To: <20190718201019.GI83144@kduck.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.3.0.16 dlp-reaction: no-action x-originating-ip: [185.221.69.46] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: c6d0b7ed-6a0f-4f06-ff2f-08d70c0a1bc9 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:DM5PR16MB2262; x-ms-traffictypediagnostic: DM5PR16MB2262: x-ms-exchange-purlcount: 6 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 01039C93E4 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(376002)(136003)(39860400002)(366004)(346002)(396003)(32952001)(51914003)(199004)(54094003)(13464003)(189003)(9686003)(25786009)(53946003)(3846002)(14454004)(2171002)(6306002)(30864003)(76176011)(55016002)(305945005)(6116002)(54906003)(14444005)(5024004)(229853002)(256004)(53546011)(81156014)(71190400001)(71200400001)(7696005)(26005)(102836004)(6506007)(186003)(2906002)(53936002)(86362001)(966005)(6246003)(476003)(6436002)(478600001)(7736002)(74316002)(11346002)(6916009)(446003)(4326008)(66946007)(5660300002)(99286004)(66066001)(76116006)(8676002)(316002)(8936002)(64756008)(66556008)(66476007)(80792005)(52536014)(33656002)(81166006)(66446008)(68736007)(486006)(85282002)(579004)(559001); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR16MB2262; H:DM5PR16MB1705.namprd16.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: OcqN+FDxp3IktPCHjU9G4X3q35J1q0a5wKIsFsBohrEw9yDO8AWZ4O7fViPCm1qnsvcJ/Nn1iGjSwpzVgZ25JyO0Keo5FTf7byNwgDfWmzbIZXWfWHG+GRtfaCSF0FNagZOg0iFNx468KckK97uLGfTtkFhbmbtjiB/nWy8Xo7ywSS48HpatjS0EkaIlKW/8U0qmkoD2kdC/yZy65vOIOLFYVBK8gy8zeJM8Uui+YPLpRCuPGk9dP6jFNceKGU0Ry/fIuUXYs+7hHh0vIueIIwN0QpuPcgR5G68fvonQwdCB2qnXQkPKzGnLDZdXH7TZDKvyto8ee1Gf6kdEfOv1ic2vBFObbq/SLhw5j3Re1kr8hC9hLt9c8pSYERM+oktYPIg3OjslL7NbPYAt7PcM8/9PFqgNuxdubuKXEgkMXco= MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: c6d0b7ed-6a0f-4f06-ff2f-08d70c0a1bc9 X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Jul 2019 05:29:44.9301 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: TirumaleswarReddy_Konda@McAfee.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR16MB2262 X-OriginatorOrg: mcafee.com X-NAI-Spam-Flag: NO X-NAI-Spam-Level: X-NAI-Spam-Threshold: 15 X-NAI-Spam-Score: 0.3 X-NAI-Spam-Version: 2.3.0.9418 : core <6593> : inlines <7120> : streams <1827777> : uri <2869217> X-MC-Unique: BzK8DFVxPXScSRpIuC5uRQ-1 X-Mimecast-Spam-Score: 0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [tram] Benjamin Kaduk's Discuss on draft-ietf-tram-turnbis-27: (with DISCUSS and COMMENT) X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.29 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 Jul 2019 05:30:16 -0000 Hi Ben, Please see inline=20 > -----Original Message----- > From: Benjamin Kaduk > Sent: Friday, July 19, 2019 1:40 AM > To: Konda, Tirumaleswar Reddy > Cc: The IESG ; tram-chairs@ietf.org; draft-ietf-tram- > turnbis@ietf.org; tram@ietf.org; brandon.williams@akamai.com > Subject: Re: [tram] Benjamin Kaduk's Discuss on draft-ietf-tram-turnbis-2= 7: > (with DISCUSS and COMMENT) >=20 > This email originated from outside of the organization. Do not click link= s or > open attachments unless you recognize the sender and know the content is > safe. >=20 > On Sat, Jul 13, 2019 at 06:10:55AM +0000, Konda, Tirumaleswar Reddy wrote= : > > Hi Ben, > > > > Please see inline > > > > > -----Original Message----- > > > From: Benjamin Kaduk > > > Sent: Saturday, July 13, 2019 7:45 AM > > > To: Konda, Tirumaleswar Reddy > > > > Cc: The IESG ; tram-chairs@ietf.org; draft-ietf-tram- > > > turnbis@ietf.org; tram@ietf.org; brandon.williams@akamai.com > > > Subject: Re: [tram] Benjamin Kaduk's Discuss on draft-ietf-tram-turnb= is- > 27: > > > (with DISCUSS and COMMENT) > > > > > > This email originated from outside of the organization. Do not click > > > links or open attachments unless you recognize the sender and know > > > the content is safe. > > > > > > Hi Tiru, > > > > > > On Thu, Jul 11, 2019 at 03:47:19PM +0000, Konda, Tirumaleswar Reddy > wrote: > > > > Hi Ben, > > > > > > > > Thanks for the detailed review. Please see inline > > > > > > Sorry to have made you deduplicate with the reviews that had already > > > come in -- I wrote this text fairly early (on just the diff) with > > > intent to return and tidy up, but ran out of time and had to just sub= mit > what I had. > > > > No problem, the review helped to improve the draft. > > > > > > > > > > -----Original Message----- > > > > > From: tram On Behalf Of Benjamin Kaduk > > > > > via Datatracker > > > > > Sent: Thursday, July 11, 2019 11:10 AM > > > > > To: The IESG > > > > > Cc: tram-chairs@ietf.org; draft-ietf-tram-turnbis@ietf.org; > > > > > tram@ietf.org; brandon.williams@akamai.com > > > > > Subject: [tram] Benjamin Kaduk's Discuss on > > > > > draft-ietf-tram-turnbis-27: (with DISCUSS and COMMENT) > > > > > > > > > > > > > > > > > > > > Benjamin Kaduk has entered the following ballot position for > > > > > draft-ietf-tram-turnbis-27: 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 her= e: > > > > > https://datatracker.ietf.org/doc/draft-ietf-tram-turnbis/ > > > > > > > > > > > > > > > > > > > > ---------------------------------------------------------------- > > > > > ---- > > > > > -- > > > > > DISCUSS: > > > > > ---------------------------------------------------------------- > > > > > ---- > > > > > -- > > > > > > > > > > I support Roman's Discuss. > > > > > > > > I have updated the draft to address Roman's Discuss. > > > > > > > > > > > > > > I think I'm confused about whether REQUESTED-ADDRESS-FAMILY > and > > > > > ADDITIONAL-ADDRESS-FAMILY are mutually exclusive. > > > > > > > > Yes, both attributes are mutually exclusive. It is discussed in > > > > Section 7.1, > > > Clients MUST NOT include REQUESTED-ADDRESS-FAMILY and > ADDITIONAL- > > > ADDRESS-FAMILY attributes in the same request. > > > > > > Okay. This seems weird to me and I wouldn't object if some very > > > blunt text was added early on about "when both IPv4 and IPv6 are > > > desired, the ADDITIONAL-ADDRESS-FAMILY attribute alone serves to > > > request both address types; otherwise the single > > > REQUESTED-ADDRESS-FAMILY attribute suffices", but this point clearly = is > not Discuss-worthy. > > > > This point is already covered in Section 5 (General Behavior) as follow= s: > > > > TURN, as defined in this specification, supports both IPv4 and IPv6. IP= v6 > support in TURN includes IPv4-to-IPv6, IPv6-to-IPv6, and IPv6-to-IPv4 > relaying. The REQUESTED-ADDRESS-FAMILY attribute allows a client to > explicitly request the address type the TURN server will allocate (e.g., = an > IPv4-only node may request the TURN server to allocate an IPv6 address). > The ADDITIONAL-ADDRESS-FAMILY attribute allows a client to request the > server to allocate one IPv4 and one IPv6 relay address in a single Alloca= te > request. This saves local ports on the client and reduces the number of > messages sent between the client and the TURN server. >=20 > I was thinking more like "When only a single address type is desired, the > REQUESTED-ADDRESS-FAMILY attribute is used to explicitly request [...]. > If both IPv4 and IPv6 are desired, the single ADDITIONAL-ADDRESS-FAMILY > attribute indicates a request to the server to allocate [...]". Works for me, updated draft. >=20 > > > > > > > > Does sending just the > > > > > "additional" one secretly mean that you want both v4 and v6? > > > > > > > > Yes, ADDITIONAL-ADDRESS-FAMILY is used for allocation of both IPv4 > > > > and > > > IPv6. > > > > > > > > > > > > > > Section 5 > > > > > > > > > > I see that the secdir reviewer asked about why it is a "SHOULD" > > > > > to send SOFTWARE, and only got a response that it is defined in > > > > > stunbis, but not about why it is recommended. There remain some > > > > > privacy/security considerations with it, and we should either > > > > > point to the stunbis security considerations or not recommend usi= ng it. > > > > > (FINGERPRINT is, IIRC, less interesting from a security > > > > > perspective as it's just about confirming that given traffic is > > > > > in fact STUN and not something else.) > > > > > > > > This "SHOULD" to send SOFTWARE attribute is defined in RFC5766 (As > > > > you > > > may know, TURN is used in the field for several years) and turnbis > > > does not modify the behavior for backward compatibility, and to > > > address the possible threat added the following lines: > > > > > > > > SOFTWARE attribute can reveal the specific software version of the > > > > TURN > > > client and server to eavesdropper and it might possibly allow > > > attacks against vulnerable software that is known to contain > > > security holes. If it is important to prevent an eavesdropper from > > > learning the software version, TURN can be run over (D)TLS. > > > > > > (let's keep this on the secdir thread) > > > > Okay. > > > > > > > > > > > > > > > Section 12 > > > > > > > > > > Do we need to say anything about backwards compatibility with > > > > > RFC > > > > > 5766 peers that use a wider range of channel IDs? > > > > > > > > Yes, added the following line: > > > > Note that the channel number range is not backwards compatible > > > > with [RFC5766], and cannot be used in environments where such > > > > compatibility is required. > > > > > > I see now that Adam also raised this topic, and I'd like to hear his > > > thoughts on this proposed text. Since we normally don't make breakin= g > changes in "bis" > > > documents, I'd also like to hear a bit more about what knoweldge we > > > have (if > > > any) about implementations that might be affected and are not affecte= d. > > > > Update to the TURN channel number range is done in > https://tools.ietf.org/html/rfc7983#section-9.3 to distinguish multiplexe= d > protocols, and the range is updated in turnbis to align with RFC7983 . > > > > > > > > > > > > > > > Section 12.7 > > > > > > > > > > When the server receives an ICMP packet, the server processes = it as > > > > > described in Section 11.5. A Data indication MUST be sent reg= ardless > > > > > of whether there is a channel bound to the peer that was the > > > > > destination of the UDP datagram that triggered the reception o= f the > > > > > ICMP packet. > > > > > > > > > > This MUST seems potentially in conflict with the previous > > > > > discussion about permissions checks in Section 11.5. > > > > > > > > Good catch, removed conflicting text from Section 12.7. > > > > > > > > > > > > > > Section 20 > > > > > > > > > > Looking at the > > > > > new nonce in the example > ("obMatJos2AAABadl7W7PeDU4hKE72jda"), > > > and > > > > > noting that it starts with the nonce cookie, help me decode the > > > > > security feature bits. The magic prefix is "obMatJos2" so the > > > > > capability bits are encoded as "AAAB", which decodes to (hex) 00 > > > > > 00 01. But stunbis says that the bits are ordered from 0 (MSB > > > > > of first > > > > > byte) to 23 (LSB of last byte), so this would have bit 23 set, > > > > > which is in contrast to the registry marking bit 0 as the > > > > > password-algorithms > > > feature. Where am I messing this up? > > > > > > > > You are right, replaced with "obMatJos2gAAAadl7W7PeDU4hKE72jda" > > > > (hex) > > > > 80 00 00 > > > > > > It's reassuring to know that I wasn't missing something obvious; than= ks! > > > > Thanks for catching it :) > > > > > > > > > > > > > > > I'd prefer if the examples showed more usage of > > > > > MESSAGE-INTEGRITY- > > > > > SHA256 (especially, any from the server) and fewer MESSAGE- > INTEGRITY. > > > > > > > > Sure, updated examples. > > > > > > > > > > > > > > > > > > > ---------------------------------------------------------------- > > > > > ---- > > > > > -- > > > > > COMMENT: > > > > > ---------------------------------------------------------------- > > > > > ---- > > > > > -- > > > > > > > > > > Thanks for keeping the diff from RFC 5766 relatively contained! > > > > > I only reviewed the diff due to time constraints, but in general > > > > > support reviewing the full document for internal consistency and > > > > > any remarks that have not aged well, especially with respect to > > > > > IANA > > > considerations. > > > > > > > > > > Section 2 > > > > > > > > > > RFC 8174 has an updated version of the BCP 14 boilerplate text. > > > > > > > > Fixed. > > > > > > > > > > > > > > Section 3.1 > > > > > > > > > > I appreciate the response to the secdir review, but even the > > > > > linked stunbis section does not say much about which PKI's trust > > > > > root is expected to be used. I'm forced to assume the Web PKI > > > > > but don't have much grounds for that assumption. > > > > > > > > Yes, use pre-populated trust store on the endpoint to validate the > > > certificate path. > > > > > > > > > > > > > > Section 3.2 > > > > > > > > > > The secdir reviewer's comments seem to have some relevance. > > > > > It seems like even when the third-party authorization mechanism > > > > > is used, the client is still limited to "the server is > > > > > authenticated because it gives me the service I asked for", > > > > > which is not really documented anywhere yet. The long-term > > > > > password mechanism at least generates an HMAC integrity tag on > > > > > messages from server to client, which can provide some level of > authentication via key confirmation. > > > > > > > > No, STURN third-party authorization provides message integrity for > > > > both > > > request and response messages (please see > > > https://tools.ietf.org/html/rfc7635#section-5). The mac_key to > > > compute the message integrity can change per call and this mechanism > > > is better than the long-term password mechanism. Note that WebRTC > > > uses third-party authorization mechanism. > > > > > > Ah, that's reassuring to learn. Sorry for the confusion. > > > > > > > > > > > > > Section 3.7 > > > > > > > > > > If the TURN server carryin= g out > > > > > packet translation from IPv4-to-IPv6 cannot get the Don't Frag= ment > > > > > (DF) bit in the IPv4 header, it MUST reject the Allocate reque= st with > > > > > DONT-FRAGMENT attribute. > > > > > > > > > > nit: does "cannot get" mean something like "read the value as > > > > > sent on the wire" (e.g., due to implementation/API limitations)? > > > > > > > > Yes, cannot read the value as sent on wire. > > > > > > I'd suggest "is unable to access the state of", but that's entirely > > > editorial and at your discretion. > > > > Thanks, updated. > > > > > > > > > > > > > > > Section 6 > > > > > > > > > > o the relayed transport address or addresses; > > > > > [...] > > > > > > > > > > [...] > > > > > address. The relayed transport address MUST be unique across = all > > > > > allocations, so it can be used to uniquely identify the alloca= tion. > > > > > > > > > > nit: there's maybe a singular/plural mismatch going on here, but > > > > > I don't have any good ideas. > > > > > > > > > > Section 7.1 > > > > > > > > > > If the client wishes to obtain one IPv6 and one IPv4 relayed > > > > > transport address then it includes an ADDITIONAL-ADDRESS-FAMIL= Y > > > > > attribute in the request. This attribute specifies that the s= erver > > > > > must allocate both address types. The attribute value in the > > > > > ADDITIONAL-ADDRESS-FAMILY MUST be set to 0x02 (IPv6 address > > > family). > > > > > Clients MUST NOT include REQUESTED-ADDRESS-FAMILY and > > > ADDITIONAL- > > > > > ADDRESS-FAMILY attributes in the same request. [...] > > > > > > > > > > This reads like setting REQUESTED-ADDRESS-FAMILY and > ADDITIONAL- > > > > > ADDRESS-FAMILY are mutually exclusive. Is that the correct readi= ng? > > > > > > > > Yes. > > > > > > > > > (Naively, one might expect that the thing named "additional" > > > > > is applied on top of the base-level request, so I have to ask.) > > > > > > > > > > Section 7.2 > > > > > > > > > > Why do we only have a SHOULD-level requirement for > > > > > authentication of Allocate requests where 5766 had MUST? Could > > > > > we say "may allow unauthenticated requests in order to support > > > > > [use case] but otherwise MUST require authentication" (with > > > > > better wording)? I suppose this has probably been discussed ad > > > > > nauseum already, so feel free to point me at the archives before > getting into an actual discussion. > > > > > > > > You missed the next line, it says the authentication of the > > > > request is optional to allow TURN servers provided by the local or > > > > access network to accept Allocation requests from new and/or guest > > > > users in the network who do not necessarily possess long term > > > > credentials for STUN authentication and its security implications > > > > are discussed in [RFC8155]. > > > > > > I saw the next line; the current formulation also allows non-use of > > > authentication in other situations, which is why I suggested an > > > alternate wording. > > > > > > > The WG spent several cycles discussing the downgrade of a MUST > > > > level > > > requirement (please see https://tools.ietf.org/html/rfc8155#section-9= ). > > > > > > To be clear, I do not object to removing the MUST for the local-use > > > case; I'm concerned with the wording of the text that, as written, > > > also weakens the requirement for all other cases. > > > > Got it, updated step as follows: > > > > 1. The TURN server provided by the local or access network MAY > > allow unauthenticated request in order to accept Allocation > > requests from new and/or guest users in the network who do not > > necessarily possess long term credentials for STUN > > authentication and its security implications are discussed in > > [RFC8155]. Otherwise, the server MUST require that the request > > be authenticated. If the request is authenticated, the > > authentication MUST be done either using the long-term credenti= al > > mechanism of [I-D.ietf-tram-stunbis] or the STUN Extension for > > Third-Party Authorization [RFC7635] unless the client and serve= r > > agree to use another mechanism through some procedure outside > > the scope of this document. >=20 > That should work (though I wonder if the RFC Editor will tweak things, si= nce > the "otherwise" is separated by another sentence from the initial case it= 's > contrasting with). >=20 > I do note that the diff link you sent out also removes some text (in a 4.= x or > 5.x section?) about "the server MUST demand that all requests from the > client be authenticated" after the "MUST implement [long-term credentials= ]" > requirement. =20 Yes, removed above text from Section 5 to avoid discussing the requirement = normatively twice (Thanks to the suggestion from Mirja). > It might be worth making a forward reference from that > location to this text, if possible. Done, update text as follows: TURN servers and clients MUST implement this mechanism, and the authenticat= ion options are discussed in Section 7.2. Cheers, -Tiru >=20 > Thanks, >=20 > Ben >=20 > > > > > > > > > > > > > 7. If the server does not support the address family request= ed by > > > > > the client in REQUESTED-ADDRESS-FAMILY or is disabled by = local > > > > > policy, it MUST generate an Allocate error response, and = it MUST > > > > > include an ERROR-CODE attribute with the 440 (Address Fam= ily > not > > > > > Supported) response code. [...] > > > > > > > > > > nit: "or is disabled" needs a subject. > > > > > > > > Fixed, updated text as follows: > > > > If the server does not support the address family requested by the > > > > client in > > > REQUESTED-ADDRESS-FAMILY or if the allocation of the requested > > > address family is disabled by local policy, it MUST generate an > > > Allocate error response, and it MUST include an ERROR-CODE attribute > > > with the 440 (Address Family not Supported) response code. > > > > > > Thanks > > > > > > > > 9. The server checks if the request contains an ADDITIONAL- > ADDRESS- > > > > > FAMILY attribute. If yes, and the attribute value is 0x0= 1 (IPv4 > > > > > address family), then the server rejects the request with= a 400 > > > > > (Bad Request) error. Otherwise, the server checks if it = can > > > > > allocate relayed transport addresses of both address type= s. If > > > > > the server cannot satisfy the request, then the server > > > > > rejects > > > > > > > > > > What are "both" address types? > > > > > > > > Both IPv4 and IPv6 address families. > > > > > > I guess once I realize that "ADDITIONAL-ADDRESS-FAMILY" is just code > > > for > > > "IPv4 and IPv6" with no other options, this doesn't look as unclear. > > > > > > > > We only have the ADDITIONAL-ADDRESS- FAMILY (which contains > one > > > > > type) and no REQUESTED-ADDRESS-FAMILY. > > > > > > > > If ADDITIONAL-ADDRESS-FAMILY is used, the server will allocate > > > > both IPv4 > > > and IPv6 relayed transport addresses. > > > > > > > > > > > > > > Section 8.1 > > > > > > > > > > When refreshing a dual allocation, the client includes REQUEST= ED- > > > > > ADDRESS-FAMILY attribute indicating the address family type th= at > > > > > should be refreshed. If no REQUESTED-ADDRESS-FAMILY is > > > > > included > > > then > > > > > the request should be treated as applying to all current alloc= ations. > > > > > The client MUST only include family types it previously alloca= ted and > > > > > has not yet deleted. [...] > > > > > > > > > > I'm a bit confused about "only include family types" plural; I > > > > > thought there could only be at most one REQUESTED-ADDRESS- > FAMILY > > > and > > > > > that it would only indicate one family type. So how could > > > > > there be multiple types getting included by the client? > > > > > > > > Good catch, replaced "types" with "type" > > > > > > (It needs a definite article, then for "only include the family > > > type") > > > > Done. > > > > Cheers, > > -Tiru > > > > > > > > > > > > > > > Section 11.5 > > > > > > > > > > [check that "type and code" is valid in both ICMPv4 and v6] > > > > > > > > Yes, it is valid. > > > > > > Sorry; that was supposed to be a note to myself! > > > But yes, luckily for me this is not the point of difference between > > > ICMPv4 and ICMPv6 that I was vaguely remembering. > > > > > > > > > > > > > Section 12 > > > > > > > > > > Reserved values may be used in the future by other protocols. > When > > > > > the client uses channel binding, it MUST comply with the > > > > > demultiplexing scheme discussed above. > > > > > > > > > > "channel binding" is a term of art in the security world; is > > > > > this usage intended to roughly mean "channel multiplexing"? > > > > > (I do see that the subsections are talking about the specific > > > > > ChannelBind request, so I assume so; I just want to double > > > > > check.) > > > > > > > > Yes, a channel binding is created or refreshed using a > > > > ChannelBind > > > transaction (Please see Section 12.1). > > > > > > Great. Well, not great that there's a collision of jargon, but it's > > > way too late to do anything about, now. > > > > > > > > > > > > > > > > > > Section 13 > > > > > > > > > > The descriptions below have two parts: a preferred behavior an= d an > > > > > alternate behavior. The server SHOULD implement the preferred > > > > > behavior. Otherwise, the server MUST implement the alternate > > > > > behavior and MUST NOT do anything else for the reasons detaile= d in > > > > > [RFC7915]. [...] > > > > > > > > > > RFC 5766 had this split on a per-field basis, but this text > > > > > suggests that if the preferred behavior is not possible for a > > > > > given field, then the alternate behavior is used for the entire p= acket. > > > > > I note that section 14 does retain the "for a particular field" > > > > > language for UDP-to-UDP relaying, as do section 15 for > > > > > TCP-to-UDP relaying and section 16 for UDP-to-TCP relaying. > > > > > > > > Good point, fixed text as follows: > > > > Otherwise, if that is not possible for a particular field, the > > > > server MUST > > > implement the alternate behavior and MUST NOT do anything else for > > > the reasons detailed in [RFC7915]. > > > > > > > > > > > > > > Section 13.2 > > > > > > > > > > Is this flow label text consistent with both the inbound and > > > > > outbound translation directions (specifically, using > > > > > relayed/peer addresses in the 5- tuple to identify the flow)? > > > > > > > > > > If the incoming packet did not include a Fragment header an= d the > > > > > outgoing packet size exceeds the outgoing link's MTU, the T= URN > > > > > server drops the outgoing packet and send an ICMP message o= f > type > > > > > 2 code 0 ("Packet too big") to the sender of the incoming p= acket. > > > > > If the packet is being sent to the peer, the TURN server r= educes > > > > > the MTU reported in the ICMP message by 48 bytes to allow r= oom > for > > > > > the overhead of a Data indication. > > > > > > > > > > (nit?) "If the packet is being send to the peer" seems to > > > > > grammatically refer to the outgoing packet that would exceed > > > > > link MTU, as opposed to the ICMP message being generated. But I > > > > > think it's supposed to refer to the ICMP message being > > > > > generated, which has > > > not yet been referred to as a "packet" > > > > > in this text. > > > > > > > > Suresh raised the same comment, fixed text as follows: > > > > If the ICMPv6 packet ("Packet too big") is being sent to the peer, > > > > the TURN > > > server reduces the MTU reported in the ICMP message by 48 bytes to > > > allow room for the overhead of a Data indication. > > > > > > Great; t hanks > > > > > > > > > > > > > Section 13.3 > > > > > > > > > > [Same comment about ICMP packet generation/grammar] > > > > > > > > Fixed text as follows: > > > > If the ICMPv4 packet (Destination Unreachable (Type 3) with Code > > > > 4) is > > > being sent to the peer, the TURN server SHOULD reduce the MTU > > > reported in the ICMP message by 48 bytes to allow room for the > > > overhead of a Data indication. > > > > > > > > > > > > > > Section 15 > > > > > > > > > > Maybe note that SIP and WebRTC are the primary consumers of > TURN? > > > > > > > > Yes, it is mentioned in several places in the document that WebRTC > > > > and SIP > > > use TURN. > > > > > > Okay; my fault for only looking at the diff, probably. > > > > > > > > > > > > > Even if b= oth > > > > > TCP-AO and UDP authentication would be used between TURN > > > > > client > > > and > > > > > server, it would not change the end-to-end security properties= of > the > > > > > UDP payload being relayed. [...] > > > > > > > > > > I wonder if we even need to say "UDP" in "payload being relayed". > > > > > > > > Replaced "UDP" with "application" > > > > > > > > > > > > > > Section 16 > > > > > > > > > > Fragmentation > > > > > > > > > > Preferred Behavior: Any fragmented packets are reassembled = in > the > > > > > server and then forwarded to the client over the TCP connec= tion. > > > > > ICMP messages resulting from the UDP datagrams sent to the = peer > > > > > MUST be forwarded to the client using TURN's mechanism for > > > > > relevant ICMP types and codes. > > > > > > > > > > As in section 12.7, I wonder if this MUST could be seen as > > > > > overriding other logic for ICMP handling. > > > > > > > > Modified text for clarity as follows: > > > > > > > > ICMP messages resulting from the UDP datagrams sent to the peer > > > > are processed by the server as described in Section 11.5 and > > > > forwarded to the client using TURN's mechanism for relevant ICMP > types and codes. > > > > > > Thanks > > > > > > > > > > > > > Section 21.16 > > > > > > > > > > I agree with the secdir reviewer that there is at least > > > > > potential for username and realm to be sensitive. > > > > > > > > I proposed to add the following text: > > > > > > > > If the TURN client and server use the STUN Extension for Third-P= arty > > > > Authorization [RFC7635] (for example it is used in WebRTC), the > > > > username does not reveal the real user's identity, the USERNAME > > > > attribute carries an ephemeral and unique key identifier. If th= e > > > > TURN client and server use the STUN long-term credential mechani= sm > > > > and the username reveals the real user's identity, the client ne= eds > > > > to use (D)TLS transport between the client and the server or use= the > > > > USERHASH attribute instead of the USERNAME attribute to > anonynmize > > > > the username. > > > > > > > > If the TURN client and server use the STUN long-term credential > > > > mechanism and realm information is privacy sensitive, TURN can b= e > run > > > > over (D)TLS. As a reminder, STUN Extension for Third-Party > > > > Authorization does not use realm. > > > > > > Excellent; thank you! > > > > > > > > > > > > > Section 21.4 > > > > > > > > > > Do we need references for Teredo and/or 6to4? > > > > > > > > https://tools.ietf.org/html/rfc6156 did not add references to > > > > Teredo and > > > 6to4. > > > > > > Okay; just wanted to check. > > > > > > > > > > > > > Section 22 > > > > > > > > > > The codepoints for the STUN error codes defined in this > specification > > > > > are listed in Section 19. [IANA is requested to update the re= ference > > > > > from [RFC5766] to RFC-to-be for the STUN error codes listed in > > > > > Section 19.] > > > > > > > > > > (I think some of them are from RFC 6156 as well as from 5766.) > > > > > > > > Yes, added RFC6156. > > > > > > > > > > > > > > Section 23 > > > > > > > > > > It seems prudent to revisit these listed IAB Considerations for > > > > > whether the situation has changed in the past ten years (though > > > > > I don't have any specific points that I would change). > > > > > > > > > > Section 25 > > > > > > > > > > (nit) are these really "updates" to RFC 6156 so much as > > > > > incorporating its content wholesale into the core TURN specificat= ion? > > > > > > > > Yes, several sections in RFC6156 are updated. > > > > > > Okay, thanks. > > > > > > -Ben > > From nobody Sun Jul 21 09:11:22 2019 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 AC634120180; Sun, 21 Jul 2019 09:11:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=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=cert.org 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 DxyruxwSFx9S; Sun, 21 Jul 2019 09:11:04 -0700 (PDT) Received: from veto.sei.cmu.edu (veto.sei.cmu.edu [147.72.252.17]) (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 A9773120199; Sun, 21 Jul 2019 09:11:04 -0700 (PDT) Received: from delp.sei.cmu.edu (delp.sei.cmu.edu [10.64.21.31]) by veto.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id x6LGB0Qv019501; Sun, 21 Jul 2019 12:11:00 -0400 DKIM-Filter: OpenDKIM Filter v2.11.0 veto.sei.cmu.edu x6LGB0Qv019501 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cert.org; s=yc2bmwvrj62m; t=1563725460; bh=X6jT72Hl870TR1+uSPU5lR//XelgsFp7rT4R8OPSEHY=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=JiR/6K7ZGIiBZTeYwZv8Sw+7vFPNgyhH8UouNzNXFSQ3dQsu0EBM7HZEnsQVwgd+b QyKjMc2EF/Fz3bYKEo3zYsEjJ4x5NQ1V9Aj9mKq8z5tmFJHp6DRrIHwsCJEIOCjz45 CYc+K5ihgZVJXqXumGU8Z/qko22XbOrRvD+qv8Kg= Received: from CASSINA.ad.sei.cmu.edu (cassina.ad.sei.cmu.edu [10.64.28.249]) by delp.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id x6LGAv7S037963; Sun, 21 Jul 2019 12:10:57 -0400 Received: from MARCHAND.ad.sei.cmu.edu ([10.64.28.251]) by CASSINA.ad.sei.cmu.edu ([10.64.28.249]) with mapi id 14.03.0439.000; Sun, 21 Jul 2019 12:10:56 -0400 From: Roman Danyliw To: "Konda, Tirumaleswar Reddy" , The IESG CC: "tram-chairs@ietf.org" , "draft-ietf-tram-turnbis@ietf.org" , "tram@ietf.org" , "brandon.williams@akamai.com" Thread-Topic: [tram] Roman Danyliw's Discuss on draft-ietf-tram-turnbis-27: (with DISCUSS and COMMENT) Thread-Index: AQHVN3HNOcpHzxrvaEaIlo9IaIQd0abFZEuAgADMpZCAAMcpgIAIE8eAgAY3KfA= Date: Sun, 21 Jul 2019 16:10:55 +0000 Message-ID: <359EC4B99E040048A7131E0F4E113AFC01B33DE345@marchand> References: <156279899179.15443.1948808943181719878.idtracker@ietfa.amsl.com> <359EC4B99E040048A7131E0F4E113AFC01B33CE08D@marchand> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.22.6] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [tram] Roman Danyliw's Discuss on draft-ietf-tram-turnbis-27: (with DISCUSS and COMMENT) X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.29 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, 21 Jul 2019 16:11:13 -0000 SGkgVGlydSENCg0KVGhpcyBwcm9wb3NlZCAtMjggYWRkcmVzc2VzIGFsbCBvZiBteSBjb25jZXJu cy4gIFRoYW5rIHlvdSBmb3IgdGhlIHVwZGF0ZS4NCg0KUm9tYW4NCg0KPiAtLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBLb25kYSwgVGlydW1hbGVzd2FyIFJlZGR5DQo+IFttYWls dG86VGlydW1hbGVzd2FyUmVkZHlfS29uZGFAbWNhZmVlLmNvbV0NCj4gU2VudDogV2VkbmVzZGF5 LCBKdWx5IDE3LCAyMDE5IDg6MzQgQU0NCj4gVG86IFJvbWFuIERhbnlsaXcgPHJkZEBjZXJ0Lm9y Zz47IFRoZSBJRVNHIDxpZXNnQGlldGYub3JnPg0KPiBDYzogdHJhbS1jaGFpcnNAaWV0Zi5vcmc7 IGRyYWZ0LWlldGYtdHJhbS10dXJuYmlzQGlldGYub3JnOyB0cmFtQGlldGYub3JnOw0KPiBicmFu ZG9uLndpbGxpYW1zQGFrYW1haS5jb20NCj4gU3ViamVjdDogUkU6IFt0cmFtXSBSb21hbiBEYW55 bGl3J3MgRGlzY3VzcyBvbiBkcmFmdC1pZXRmLXRyYW0tdHVybmJpcy0yNzoNCj4gKHdpdGggRElT Q1VTUyBhbmQgQ09NTUVOVCkNCj4gDQo+IEhpIFJvbWFuLA0KPiANCj4gSSBoYXZlIHVwZGF0ZWQg dGhlIGRyYWZ0IHRvIGFkZHJlc3MgeW91ciBEaXNjdXNzIGFuZCBjb21tZW50cyAoc2VlDQo+IGh0 dHBzOi8vZ2l0aHViLmNvbS90aXJlZGR5Mi9UVVJOYmlzL2Jsb2IvbWFzdGVyL0RpZmYlMjAlMjBk cmFmdC1pZXRmLQ0KPiB0cmFtLXR1cm5iaXMtMjcudHh0JTIwLSUyMGRyYWZ0LWlldGYtdHJhbS10 dXJuYmlzLTI4LnBkZikuDQo+IFBsZWFzZSBoYXZlIGEgbG9vay4NCj4gDQo+IENoZWVycywNCj4g LVRpcnUNCj4gDQo+ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPiBGcm9tOiBLb25k YSwgVGlydW1hbGVzd2FyIFJlZGR5DQo+ID4gU2VudDogRnJpZGF5LCBKdWx5IDEyLCAyMDE5IDI6 NDMgUE0NCj4gPiBUbzogUm9tYW4gRGFueWxpdyA8cmRkQGNlcnQub3JnPjsgVGhlIElFU0cgPGll c2dAaWV0Zi5vcmc+DQo+ID4gQ2M6IHRyYW0tY2hhaXJzQGlldGYub3JnOyBkcmFmdC1pZXRmLXRy YW0tdHVybmJpc0BpZXRmLm9yZzsNCj4gPiB0cmFtQGlldGYub3JnOyBicmFuZG9uLndpbGxpYW1z QGFrYW1haS5jb20NCj4gPiBTdWJqZWN0OiBSRTogW3RyYW1dIFJvbWFuIERhbnlsaXcncyBEaXNj dXNzIG9uIGRyYWZ0LWlldGYtdHJhbS10dXJuYmlzLTI3Og0KPiA+ICh3aXRoIERJU0NVU1MgYW5k IENPTU1FTlQpDQo+ID4NCj4gPiBIaSBSb21hbiwNCj4gPg0KPiA+IFBsZWFzZSBzZWUgaW5saW5l DQo+ID4NCj4gPiA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4gPiBGcm9tOiBSb21h biBEYW55bGl3IDxyZGRAY2VydC5vcmc+DQo+ID4gPiBTZW50OiBGcmlkYXksIEp1bHkgMTIsIDIw MTkgNzowMCBBTQ0KPiA+ID4gVG86IEtvbmRhLCBUaXJ1bWFsZXN3YXIgUmVkZHkNCj4gPiA+IDxU aXJ1bWFsZXN3YXJSZWRkeV9Lb25kYUBNY0FmZWUuY29tPjsgVGhlIElFU0cgPGllc2dAaWV0Zi5v cmc+DQo+ID4gPiBDYzogdHJhbS1jaGFpcnNAaWV0Zi5vcmc7IGRyYWZ0LWlldGYtdHJhbS10dXJu YmlzQGlldGYub3JnOw0KPiA+ID4gdHJhbUBpZXRmLm9yZzsgYnJhbmRvbi53aWxsaWFtc0Bha2Ft YWkuY29tDQo+ID4gPiBTdWJqZWN0OiBSRTogW3RyYW1dIFJvbWFuIERhbnlsaXcncyBEaXNjdXNz IG9uIGRyYWZ0LWlldGYtdHJhbS10dXJuYmlzLQ0KPiAyNzoNCj4gPiA+ICh3aXRoIERJU0NVU1Mg YW5kIENPTU1FTlQpDQo+ID4gPg0KPiA+ID4gVGhpcyBlbWFpbCBvcmlnaW5hdGVkIGZyb20gb3V0 c2lkZSBvZiB0aGUgb3JnYW5pemF0aW9uLiBEbyBub3QgY2xpY2sNCj4gPiA+IGxpbmtzIG9yIG9w ZW4gYXR0YWNobWVudHMgdW5sZXNzIHlvdSByZWNvZ25pemUgdGhlIHNlbmRlciBhbmQga25vdw0K PiA+ID4gdGhlIGNvbnRlbnQgaXMgc2FmZS4NCj4gPiA+DQo+ID4gPiBIaSBUaXJ1IQ0KPiA+ID4N Cj4gPiA+ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPiA+ID4gRnJvbTogaWVzZyBb bWFpbHRvOmllc2ctYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEtvbmRhLA0KPiA+ID4g PiBUaXJ1bWFsZXN3YXIgUmVkZHkNCj4gPiA+ID4gU2VudDogVGh1cnNkYXksIEp1bHkgMTEsIDIw MTkgNTowNyBBTQ0KPiA+ID4gPiBUbzogUm9tYW4gRGFueWxpdyA8cmRkQGNlcnQub3JnPjsgVGhl IElFU0cgPGllc2dAaWV0Zi5vcmc+DQo+ID4gPiA+IENjOiB0cmFtLWNoYWlyc0BpZXRmLm9yZzsg ZHJhZnQtaWV0Zi10cmFtLXR1cm5iaXNAaWV0Zi5vcmc7DQo+ID4gPiA+IHRyYW1AaWV0Zi5vcmc7 IGJyYW5kb24ud2lsbGlhbXNAYWthbWFpLmNvbQ0KPiA+ID4gPiBTdWJqZWN0OiBSRTogW3RyYW1d IFJvbWFuIERhbnlsaXcncyBEaXNjdXNzIG9uIGRyYWZ0LWlldGYtdHJhbS10dXJuYmlzLQ0KPiAy NzoNCj4gPiA+ID4gKHdpdGggRElTQ1VTUyBhbmQgQ09NTUVOVCkNCj4gPiA+ID4NCj4gPiA+ID4g SGkgUm9tYW4sDQo+ID4gPiA+DQo+ID4gPiA+IFRoYW5rcyBmb3IgdGhlIHJldmlldy4gUGxlYXNl IHNlZSBpbmxpbmUNCj4gPiA+ID4NCj4gPiA+ID4gPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t LQ0KPiA+ID4gPiA+IEZyb206IHRyYW0gPHRyYW0tYm91bmNlc0BpZXRmLm9yZz4gT24gQmVoYWxm IE9mIFJvbWFuIERhbnlsaXcNCj4gPiA+ID4gPiB2aWEgRGF0YXRyYWNrZXINCj4gPiA+ID4gPiBT ZW50OiBUaHVyc2RheSwgSnVseSAxMSwgMjAxOSA0OjIwIEFNDQo+ID4gPiA+ID4gVG86IFRoZSBJ RVNHIDxpZXNnQGlldGYub3JnPg0KPiA+ID4gPiA+IENjOiB0cmFtLWNoYWlyc0BpZXRmLm9yZzsg ZHJhZnQtaWV0Zi10cmFtLXR1cm5iaXNAaWV0Zi5vcmc7DQo+ID4gPiA+ID4gdHJhbUBpZXRmLm9y ZzsgYnJhbmRvbi53aWxsaWFtc0Bha2FtYWkuY29tDQo+ID4gPiA+ID4gU3ViamVjdDogW3RyYW1d IFJvbWFuIERhbnlsaXcncyBEaXNjdXNzIG9uIGRyYWZ0LWlldGYtdHJhbS10dXJuYmlzLQ0KPiAy NzoNCj4gPiA+ID4gPiAod2l0aCBESVNDVVNTIGFuZCBDT01NRU5UKQ0KPiA+ID4gPiA+DQo+ID4g PiA+ID4gVGhpcyBlbWFpbCBvcmlnaW5hdGVkIGZyb20gb3V0c2lkZSBvZiB0aGUgb3JnYW5pemF0 aW9uLiBEbyBub3QNCj4gPiA+ID4gPiBjbGljayBsaW5rcyBvciBvcGVuIGF0dGFjaG1lbnRzIHVu bGVzcyB5b3UgcmVjb2duaXplIHRoZSBzZW5kZXINCj4gPiA+ID4gPiBhbmQga25vdyB0aGUgY29u dGVudCBpcyBzYWZlLg0KPiA+ID4gPiA+DQo+ID4gPiA+ID4gUm9tYW4gRGFueWxpdyBoYXMgZW50 ZXJlZCB0aGUgZm9sbG93aW5nIGJhbGxvdCBwb3NpdGlvbiBmb3INCj4gPiA+ID4gPiBkcmFmdC1p ZXRmLXRyYW0tdHVybmJpcy0yNzogRGlzY3Vzcw0KPiA+ID4gPiA+DQo+ID4gPiA+ID4gV2hlbiBy ZXNwb25kaW5nLCBwbGVhc2Uga2VlcCB0aGUgc3ViamVjdCBsaW5lIGludGFjdCBhbmQgcmVwbHkN Cj4gPiA+ID4gPiB0byBhbGwgZW1haWwgYWRkcmVzc2VzIGluY2x1ZGVkIGluIHRoZSBUbyBhbmQg Q0MgbGluZXMuIChGZWVsDQo+ID4gPiA+ID4gZnJlZSB0byBjdXQgdGhpcyBpbnRyb2R1Y3Rvcnkg cGFyYWdyYXBoLCBob3dldmVyLikNCj4gPiA+ID4gPg0KPiA+ID4gPiA+DQo+ID4gPiA+ID4gUGxl YXNlIHJlZmVyIHRvDQo+ID4gPiA+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaWVzZy9zdGF0ZW1l bnQvZGlzY3Vzcy1jcml0ZXJpYS5odG1sDQo+ID4gPiA+ID4gZm9yIG1vcmUgaW5mb3JtYXRpb24g YWJvdXQgSUVTRyBESVNDVVNTIGFuZCBDT01NRU5UIHBvc2l0aW9ucy4NCj4gPiA+ID4gPg0KPiA+ ID4gPiA+DQo+ID4gPiA+ID4gVGhlIGRvY3VtZW50LCBhbG9uZyB3aXRoIG90aGVyIGJhbGxvdCBw b3NpdGlvbnMsIGNhbiBiZSBmb3VuZCBoZXJlOg0KPiA+ID4gPiA+IGh0dHBzOi8vZGF0YXRyYWNr ZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtdHJhbS10dXJuYmlzLw0KPiA+ID4gPiA+DQo+ID4g PiA+ID4NCj4gPiA+ID4gPg0KPiA+ID4gPiA+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gPiA+ID4gPiAtLQ0KPiA+ID4g PiA+IC0tDQo+ID4gPiA+ID4gLS0NCj4gPiA+ID4gPiBESVNDVVNTOg0KPiA+ID4gPiA+IC0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0NCj4gPiA+ID4gPiAtLQ0KPiA+ID4gPiA+IC0tDQo+ID4gPiA+ID4gLS0NCj4gPiA+ID4gPg0K PiA+ID4gPiA+ICgxKSBTZWN0aW9uIDEyLjEuNi4gIChQZXIgdGhlIGJhY2stYW5kLWZvcnRoIG9u IENocmlzIFdvb2TigJlzDQo+ID4gPiA+ID4gU0VDRElSIHJldmlldyDigJMgdGhhbmsgeW91IENo cmlzISkgUGVyIOKAnENvbmZpZGVudGlhbGl0eSBpcyBvbmx5IGENCj4gPiA+ID4gPiBzZWNvbmRh cnkgY29uY2VybiwgYXMgVFVSTiBjb250cm9sIG1lc3NhZ2VzIGRvIG5vdCBpbmNsdWRlDQo+ID4g PiA+ID4gaW5mb3JtYXRpb24gdGhhdCBpcyBwYXJ0aWN1bGFybHkgc2Vuc2l0aXZl4oCdLCB3b3Vs ZG7igJl0IHRoZQ0KPiA+ID4gPiA+IFVTRVJOQU1FIGFuZCBSRUFMTSBwb3RlbnRpYWxseSBiZSBw cml2YWN5IHNlbnNpdGl2ZT8gIElmIHRoZXkNCj4gPiA+ID4gPiBhcmVu4oCZdCBzZW5zaXRpdmUg aW4gYWxsIGNhc2VzIChlLmcuLCB1c2VybmFtZXMgbWlnaHQgYmUNCj4gPiA+ID4gPiBlcGhlbWVy YWwpLCB0aGlzIHNob3VsZA0KPiA+IGJlIG5vdGVkIGFuZCBjaXRlZC4NCj4gPiA+ID4NCj4gPiA+ ID4gQWdyZWVkLCBhZGRlZCB0aGUgZm9sbG93aW5nIHBhcmFncmFwaDoNCj4gPiA+ID4NCj4gPiA+ ID4gICAgSWYgdGhlIFRVUk4gY2xpZW50IGFuZCBzZXJ2ZXIgdXNlIHRoZSBTVFVOIEV4dGVuc2lv biBmb3IgVGhpcmQtUGFydHkNCj4gPiA+ID4gICAgQXV0aG9yaXphdGlvbiBbUkZDNzYzNV0gKGZv ciBleGFtcGxlIGl0IGlzIHVzZWQgaW4gV2ViUlRDKSwgdGhlDQo+ID4gPiA+ICAgIHVzZXJuYW1l IGRvZXMgbm90IHJldmVhbCB0aGUgcmVhbCB1c2VyJ3MgaWRlbnRpdHksIHRoZSBVU0VSTkFNRQ0K PiA+ID4gPiAgICBhdHRyaWJ1dGUgY2FycmllcyBhbiBlcGhlbWVyYWwgYW5kIHVuaXF1ZSBrZXkg aWRlbnRpZmllci4gIElmIHRoZQ0KPiA+ID4gPiAgICBUVVJOIGNsaWVudCBhbmQgc2VydmVyIHVz ZSB0aGUgU1RVTiBsb25nLXRlcm0gY3JlZGVudGlhbCBtZWNoYW5pc20NCj4gPiA+ID4gICAgYW5k IHRoZSB1c2VybmFtZSByZXZlYWxzIHRoZSByZWFsIHVzZXIncyBpZGVudGl0eSwgdGhlIGNsaWVu dCBuZWVkcw0KPiA+ID4gPiAgICB0byB1c2UgKEQpVExTIHRyYW5zcG9ydCBiZXR3ZWVuIHRoZSBj bGllbnQgYW5kIHRoZSBzZXJ2ZXIgb3IgdXNlIHRoZQ0KPiA+ID4gPiAgICBVU0VSSEFTSCBhdHRy aWJ1dGUgaW5zdGVhZCBvZiB0aGUgVVNFUk5BTUUgYXR0cmlidXRlIHRvDQo+IGFub255bm1pemUN Cj4gPiA+ID4gICAgdGhlIHVzZXJuYW1lLg0KPiA+ID4gPg0KPiA+ID4gPiAgICBJZiB0aGUgVFVS TiBjbGllbnQgYW5kIHNlcnZlciB1c2UgdGhlIFNUVU4gbG9uZy10ZXJtIGNyZWRlbnRpYWwNCj4g PiA+ID4gICAgbWVjaGFuaXNtIGFuZCByZWFsbSBpbmZvcm1hdGlvbiBpcyBwcml2YWN5IHNlbnNp dGl2ZSwgVFVSTiBjYW4gYmUNCj4gcnVuDQo+ID4gPiA+ICAgIG92ZXIgKEQpVExTLiAgQXMgYSBy ZW1pbmRlciwgU1RVTiBFeHRlbnNpb24gZm9yIFRoaXJkLVBhcnR5DQo+ID4gPiA+ICAgIEF1dGhv cml6YXRpb24gZG9lcyBub3QgdXNlIHJlYWxtLg0KPiA+ID4NCj4gPiA+IFRoYW5rIHlvdS4gIFRo aXMgdGV4dCB3b3VsZCBhZGRyZXNzIG15IGNvbmNlcm4uDQo+ID4gPg0KPiA+ID4gPiA+IC0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0NCj4gPiA+ID4gPiAtLQ0KPiA+ID4gPiA+IC0tDQo+ID4gPiA+ID4gLS0NCj4gPiA+ID4gPiBD T01NRU5UOg0KPiA+ID4gPiA+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gPiA+ID4gPiAtLQ0KPiA+ID4gPiA+IC0tDQo+ ID4gPiA+ID4gLS0NCj4gPiA+ID4gPg0KPiA+ID4gPiA+ICgyKSBUaGlzIGRyYWZ0IHJlbGllcyBv biB0aGUgZHJhZnQtaWV0Zi10cmFtLXN0dW5iaXPigJlzIFNUVU4NCj4gPiA+ID4gPiBQYXNzd29y ZCBBbGdvIFJlZ2lzdHJ5IHdoaWNoIGhhcyBNRDUgYW5kIFNIQS0yNTYuICBTZWN0aW9uDQo+ID4g PiA+ID4gMTYuMS4xIG9mIHRoYXQgZHJhZnQgYWxyZWFkeSBkaXNjdXNzZXMgdGhlIGxpbWl0YXRp b24gb2YgU0hBLTI1Ng0KPiA+ID4gPiA+ICh3aGljaCBpdCBtaWdodCBiZSB1c2VmdWwgdG8NCj4g PiA+ID4gcmVmZXJlbmNlKS4NCj4gPiA+ID4gPiBOZXZlcnRoZWxlc3MsIGFyZSB0aGVyZSBjYXNl cyB3aGVyZSBNRDUgc2hvdWxkIGJlIHVzZWQgb3Zlcg0KPiA+ID4gPiA+IFNIQS0yNTYgaWYgdGhl cmUgaXMgYSBjaG9pY2U/ICBJcyB0aGVyZSBhIHJlYXNvbiBub3QgdG8NCj4gPiA+ID4gPiByZWNv bW1lbmQgdGhhdCBpbXBsZW1lbnRhdGlvbnMg4oCcU0hPVUxEIE5PVCB1c2UgTUQ14oCdPw0KPiA+ ID4gPg0KPiA+ID4gPiBUaGUgb25seSByZWFzb24gZHJhZnQtaWV0Zi10cmFtLXN0dW5iaXMgcmV0 YWluZWQgTUQ1IGlzIGZvcg0KPiA+ID4gPiBiYWNrd2FyZC0gY29tcGF0aWJpbGl0eSAoY2xpZW50 IHVzaW5nIG9sZGVyIHZlcnNpb24gb2YgU1RVTiAoUkZDNTM4OSkpLg0KPiA+ID4NCj4gPiA+IFVu ZGVyc3Rvb2QuICBDb3VsZCB3ZSBzYXkgc29tZXRoaW5nIG9uIHRoZSBvcmRlciBvZiAiaWYgYSBj bGllbnQNCj4gPiA+IHN1cHBvcnRzIGJvdGggTUQ1IGFuZCBTSEEtMjU2LCB0aGUgbGF0dGVyIFNI T1VMRCBCRSB1c2VkIj8NCj4gPg0KPiA+IFllcywgbW9kaWZpZWQgdGhlIGFib3ZlIHRleHQgYXMg Zm9sbG93czoNCj4gPg0KPiA+IE5vdGUgdGhhdCBpZiB0aGUgcmVzcG9uc2UgY29udGFpbnMgYSBQ QVNTV09SRC1BTEdPUklUSE1TIGF0dHJpYnV0ZQ0KPiBhbmQNCj4gPiB0aGlzIGF0dHJpYnV0ZSBj b250YWlucyBib3RoIE1ENSBhbmQgU0hBLTI1NiBhbGdvcml0aG1zLCBhbmQgdGhlDQo+ID4gY2xp ZW50IGFsc28gc3VwcG9ydHMgYm90aCB0aGUgYWxnb3JpdGhtcywgdGhlIHJlcXVlc3QgTVVTVCBj b250YWluIGENCj4gPiBQQVNTV09SRC0gQUxHT1JJVEhNIGF0dHJpYnV0ZSB3aXRoIHRoZSBTSEEt MjU2IGFsZ29yaXRobS4NCj4gPg0KPiA+IENoZWVycywNCj4gPiAtVGlydQ0KPiA+DQo+ID4gPg0K PiA+ID4gPiA+DQo+ID4gPiA+ID4gKDMpIFNlY3Rpb24gNS4gUGVyIOKAnFRoZSBjbGllbnQgU0hP VUxEIGluY2x1ZGUgdGhlIFNPRlRXQVJFIOKApuKAnQ0KPiA+ID4gPiA+IGFuZCDigJxUaGUgY2xp ZW50IGFuZCB0aGUgc2VydmVyIE1BWSBpbmNsdWRlIHRoZSBGSU5HRVJQUklOVA0KPiA+ID4gPiA+ IGF0dHJpYnV0ZSDigKbigJ0sIHdoeSBpcyB0aGUgc2VuZGluZyBvZiBTT0ZUV0FSRSBub3QgYSDi gJxNQVnigJ0gdG9vPw0KPiA+ID4gPg0KPiA+ID4gPiBUaGlzIHNhbWUgYmVoYXZpb3IgaXMgZGVm aW5lZCBpbiBSRkM1NzY2IGFuZCB0dXJuYmlzIGRvZXMgbm90DQo+ID4gPiA+IG1vZGlmeSB0aGUg YmVoYXZpb3IsIGFuZCB0byBhZGRyZXNzIHRoZSBjb21tZW50IGZyb20gQ2hyaXMgV29vZA0KPiA+ ID4gPiAoU2VjZGlyDQo+ID4gPiA+IHJldmlldykgYWRkZWQgdGhlIGZvbGxvd2luZyBsaW5lIHRv IFNlY3VyaXR5IENvbnNpZGVyYXRpb25zIHNlY3Rpb246DQo+ID4gPiA+DQo+ID4gPiA+IFNPRlRX QVJFIGF0dHJpYnV0ZSBjYW4gcmV2ZWFsIHRoZSBzcGVjaWZpYyBzb2Z0d2FyZSB2ZXJzaW9uIG9m IHRoZQ0KPiA+ID4gPiBUVVJOIGNsaWVudCBhbmQgc2VydmVyIHRvIGVhdmVzZHJvcHBlciBhbmQg aXQgbWlnaHQgcG9zc2libHkgYWxsb3cNCj4gPiA+ID4gYXR0YWNrcyBhZ2FpbnN0IHZ1bG5lcmFi bGUgc29mdHdhcmUgdGhhdCBpcyBrbm93biB0byBjb250YWluDQo+ID4gPiA+IHNlY3VyaXR5IGhv bGVzLiBJZiBpdCBpcyBpbXBvcnRhbnQgdG8gcHJldmVudCBhbiBlYXZlc2Ryb3BwZXIgZnJvbQ0K PiA+ID4gPiBsZWFybmluZyB0aGUgc29mdHdhcmUgdmVyc2lvbiwgVFVSTiBjYW4gYmUgcnVuIG92 ZXIgKEQpVExTLg0KPiA+ID4NCj4gPiA+IFVuZGVyc3Rvb2QuICBJIGNhbiBsaXZlIHdpdGggYW4g YXJndW1lbnQgdGhhdCB0dXJuYmlzIHNob3VsZG4ndA0KPiA+ID4gbW9kaWZ5IHRoZSBiZWhhdmlv ciBpbiB0aGlzIGNhc2UgZ2l2ZW4gdGhpcyBhZGRpdGlvbmFsIChoZWxwZnVsKSBsYW5ndWFnZS4N Cj4gVGhhbmtzLg0KPiA+ID4NCj4gPiA+ID4gPg0KPiA+ID4gPiA+ICg0KSBTZWN0aW9uIDUuICAo UGVyIHRoZSBiYWNrLWFuZC1mb3J0aCBvbiBDaHJpcyBXb29k4oCZcyBTRUNESVINCj4gPiA+ID4g PiByZXZpZXcpIFJlY29tbWVuZCBjaXRpbmcgU2VjdGlvbiA2LjMuMSBvZg0KPiA+ID4gPiA+IFtk cmFmdC1pZXRmLXRyYW0tc3R1bmJpc10gYXMgc291cmNlIG9mIDQwIHNlY29uZCByZXF1ZXN0IGJ1 ZmZlcg0KPiA+ID4gPiA+IHRpbWVvdXQNCj4gPiA+ID4NCj4gPiA+ID4gRG9uZS4NCj4gPiA+DQo+ ID4gPiBUaGFua3MuDQo+ID4gPg0KPiA+ID4gPiA+DQo+ID4gPiA+ID4gKDUpIFNlY3Rpb24gMjEu NC4gIFBlciDigJxJdCBpcyBSRUNPTU1FTkRFRCB0aGF0IFRVUk4gc2VydmVycyBub3QNCj4gPiA+ ID4gPiBhY2NlcHQgYWxsb2NhdGlvbiBvciBjaGFubmVsIGJpbmRpbmcgcmVxdWVzdHMgZnJvbSBh ZGRyZXNzZXMNCj4gPiA+ID4gPiBrbm93biB0byBiZSB0dW5uZWxlZOKAnSwgSSBjb25jdXIgd2l0 aCB0aGUgYWR2aWNlLiAgSG93IHdvdWxkIG9uZQ0KPiA+ID4gPiA+IHJlY29nbml6ZSB0aGF0IHRo ZSBhZGRyZXNzIGlzIGJlaW5nIHR1bm5lbGVkPw0KPiA+ID4gPg0KPiA+ID4gPiBCeSBtYW5hZ2lu ZyBkcm9wLWxpc3Qgb2YgdHVubmVsIElQIGFkZHJlc3NlcywgaXQgaXMgdGhlIHNhbWUNCj4gPiA+ ID4gdGVjaG5pcXVlIHVzZWQgYnkgc2V2ZXJhbCB3ZWJzaXRlcyB0byBibG9jayBWUE4gYWNjZXNz IChzZWUNCj4gPiA+ID4gaHR0cHM6Ly93d3cuaG93dG9nZWVrLmNvbS80MDM3NzEvd2h5LWRvLXNv bWUtd2Vic2l0ZXMtYmxvY2stDQo+ID4gPiB2cG5zLykNCj4gPiA+DQo+ID4gPiBSaWdodC4gIEkg ZGlkbid0IGtub3cgaWYgdGhlcmUgd2FzIHNvbWV0aGluZyBmYW5jaWVyIEkgd2FzIG1pc3Npbmcu DQo+ID4gPg0KPiA+ID4gSSBhcHByZWNpYXRlIHRoZXNlIGNoYW5nZXMgYW5kIGV4cGxhbmF0aW9u cyENCj4gPiA+DQo+ID4gPiBSb21hbg0KPiA+ID4NCj4gPiA+DQo+ID4gPiA+IENoZWVycywNCj4g PiA+ID4gLVRpcnUNCj4gPiA+ID4NCj4gPiA+ID4gPg0KPiA+ID4gPiA+DQo+ID4gPiA+ID4gX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPiA+ID4gPiB0 cmFtIG1haWxpbmcgbGlzdA0KPiA+ID4gPiA+IHRyYW1AaWV0Zi5vcmcNCj4gPiA+ID4gPiBodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RyYW0NCg== From nobody Mon Jul 22 02:40:16 2019 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 215231201EC; Mon, 22 Jul 2019 02:40:08 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: tram@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.99.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: tram@ietf.org Message-ID: <156378840804.28007.5765944769645518210@ietfa.amsl.com> Date: Mon, 22 Jul 2019 02:40:08 -0700 Archived-At: Subject: [tram] I-D Action: draft-ietf-tram-turnbis-28.txt X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.29 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, 22 Jul 2019 09:40:08 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the TURN Revised and Modernized WG of the IETF. Title : Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN) Authors : Tirumaleswar Reddy Alan Johnston Philip Matthews Jonathan Rosenberg Filename : draft-ietf-tram-turnbis-28.txt Pages : 92 Date : 2019-07-22 Abstract: If a host is located behind a NAT, then in certain situations it can be impossible for that host to communicate directly with other hosts (peers). In these situations, it is necessary for the host to use the services of an intermediate node that acts as a communication relay. This specification defines a protocol, called TURN (Traversal Using Relays around NAT), that allows the host to control the operation of the relay and to exchange packets with its peers using the relay. TURN differs from other relay control protocols in that it allows a client to communicate with multiple peers using a single relay address. The TURN protocol was designed to be used as part of the ICE (Interactive Connectivity Establishment) approach to NAT traversal, though it also can be used without ICE. This document obsoletes RFC 5766 and RFC 6156. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tram-turnbis/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-tram-turnbis-28 https://datatracker.ietf.org/doc/html/draft-ietf-tram-turnbis-28 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tram-turnbis-28 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Jul 22 03:01:36 2019 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 D5BAF12021F for ; Mon, 22 Jul 2019 03:01:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UtA_klESZhml for ; Mon, 22 Jul 2019 03:01:33 -0700 (PDT) Received: from mail-io1-xd2f.google.com (mail-io1-xd2f.google.com [IPv6:2607:f8b0:4864:20::d2f]) (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 16DAD12021D for ; Mon, 22 Jul 2019 03:01:33 -0700 (PDT) Received: by mail-io1-xd2f.google.com with SMTP id k20so72548977ios.10 for ; Mon, 22 Jul 2019 03:01:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=VpVJ+dN7V0ZN4Wdh1Df5I40t3nwEOt+S5vgynuaKkUg=; b=Fnmubyq4TsDCxH7zWNz/RYlk1Zi4nYIvaVFe9RBRx78Cv7Z4utr92t0ld2yXAfn4b7 WoZ1R4hPacipRovy5ZAV8JI++sxMvNBU6O0zdpSD0Zpl+O6xHMjyn2OsGCraX23b2tcs teMi3OcUBSiVEiF/PYKHHj/lHTeMRyf1u6i6aATwHQX/CKk1DKuxv7MlNiNzcONRC2tP VG7o3MDa2arJsoDxDjTIVvi4C42GBqR6fwMvJDTjYTvy3SLDyStDZTXRYjvpEpWumU94 vhOXHXgCknHH3CEeo9alYpSRCRfvZAzfGkk54O4zbPsA4rPi5okqPRTeJlSK7V2GBxqR +RdQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=VpVJ+dN7V0ZN4Wdh1Df5I40t3nwEOt+S5vgynuaKkUg=; b=apMYlfUAfo4+BLFKn3TPqGLCs3l2ef4QqbC2PCEau8egKeEwPwLTNb8cFznZI6ByPp m3Q9UUEVPeFVML8RQoCwr3cL21E1px2Vrp5s1yvhs5mYOMVboklWPIDjbAwNmGAenLW5 kzDMGRYMzDDEBJEmv1oXtLlk553bL308cI3ZqAM4mA071khRr9sHw5eY14pTbyEe9AaO 1L7fP8t3J/EjfQkfgnYBFoG9+iVdZd27bQRzzsn+RQRKoiL+w3eBzljRYQziScLPDcob uLFKE3vmoRgJzofzYTz+EGwycF90yvf1FWfq4ZxhO+yXXd+ItCOLdufyDWAFtOCvgj9E bNgA== X-Gm-Message-State: APjAAAV8RBsuSqRTORm1r/4VPwkEhUCoFF6/fK9ISjqJCLQzASdrIQF4 gRxaxJsfJEXz2MVAigsMvn5nzDgTg8CdJb+aXU3ggFQh X-Google-Smtp-Source: APXvYqzSz/tmDrzsZO/rUI/cUIL0D2VCJ+itYxYcH1+6077epERIcdBKvia36ypC4iALaaYklMaCh8pk8sfshG7UV74= X-Received: by 2002:a02:aa0d:: with SMTP id r13mr71534309jam.129.1563789692052; Mon, 22 Jul 2019 03:01:32 -0700 (PDT) MIME-Version: 1.0 References: <156378840844.28007.1060920586650003823.idtracker@ietfa.amsl.com> In-Reply-To: <156378840844.28007.1060920586650003823.idtracker@ietfa.amsl.com> From: tirumal reddy Date: Mon, 22 Jul 2019 15:31:19 +0530 Message-ID: To: tram@ietf.org, Roman Danyliw , Benjamin Kaduk , evyncke@cisco.com, Suresh@kaloom.com, ietf@kuehlewind.net, adam@nostrum.com, magnus.westerlund@ericsson.com Content-Type: multipart/alternative; boundary="0000000000001926ba058e4229ab" Archived-At: Subject: [tram] Fwd: New Version Notification for draft-ietf-tram-turnbis-28.txt X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.29 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, 22 Jul 2019 10:01:35 -0000 --0000000000001926ba058e4229ab Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable This revision https://tools.ietf.org/html/draft-ietf-dots-requirements-19 addresses Discuss and comments from ISEG review by Roman Danyliw, =C3=89ric Vyncke, Adam Roach, Suresh Krishnan, Mirja K=C3=BChlewind and Benjamin Kadu= k. -Tiru ---------- Forwarded message --------- From: Date: Mon, 22 Jul 2019 at 15:10 Subject: New Version Notification for draft-ietf-tram-turnbis-28.txt To: Philip Matthews , Tirumaleswar Reddy < kondtir@gmail.com>, Jonathan Rosenberg , Alan Johnston A new version of I-D, draft-ietf-tram-turnbis-28.txt has been successfully submitted by Tirumaleswar Reddy and posted to the IETF repository. Name: draft-ietf-tram-turnbis Revision: 28 Title: Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN) Document date: 2019-07-22 Group: tram Pages: 92 URL: https://www.ietf.org/internet-drafts/draft-ietf-tram-turnbis-28.txt Status: https://datatracker.ietf.org/doc/draft-ietf-tram-turnbis/ Htmlized: https://tools.ietf.org/html/draft-ietf-tram-turnbis-28 Htmlized: https://datatracker.ietf.org/doc/html/draft-ietf-tram-turnbis Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tram-turnbis= -28 Abstract: If a host is located behind a NAT, then in certain situations it can be impossible for that host to communicate directly with other hosts (peers). In these situations, it is necessary for the host to use the services of an intermediate node that acts as a communication relay. This specification defines a protocol, called TURN (Traversal Using Relays around NAT), that allows the host to control the operation of the relay and to exchange packets with its peers using the relay. TURN differs from other relay control protocols in that it allows a client to communicate with multiple peers using a single relay address. The TURN protocol was designed to be used as part of the ICE (Interactive Connectivity Establishment) approach to NAT traversal, though it also can be used without ICE. This document obsoletes RFC 5766 and RFC 6156. Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat --0000000000001926ba058e4229ab Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
This revision https://tools.ietf.org/html/draft-ietf-dots-req= uirements-19 addresses Discuss and comments from ISEG review by=C2=A0Ro= man Danyliw, =C3=89ric Vyncke, Adam Roach, Suresh Krishnan, Mirja K=C3=BChl= ewind and Benjamin Kaduk.

-Tiru

---------= - Forwarded message ---------
From: <internet-drafts@ietf.org>
D= ate: Mon, 22 Jul 2019 at 15:10
Subject: New Version Notification for dra= ft-ietf-tram-turnbis-28.txt
To: Philip Matthews <philip_matthews@magma.ca>, Tirumaleswar Redd= y <kondtir@gmail.com>, Jonat= han Rosenberg <jdrosen@jdrosen.ne= t>, Alan Johnston <a= lan.b.johnston@gmail.com>



A new version of I-D, draft-ietf-tram-turnbis-28.txt
has been successfully submitted by Tirumaleswar Reddy and posted to the
IETF repository.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-ietf-tram-turnbis
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A028
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Traversal Using Relays around NAT = (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN)
Document date:=C2=A0 2019-07-22
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 tram
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 92
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/internet-drafts/draft-ietf-tram-turnbis-2= 8.txt
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0ht= tps://datatracker.ietf.org/doc/draft-ietf-tram-turnbis/
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://to= ols.ietf.org/html/draft-ietf-tram-turnbis-28
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0htt= ps://datatracker.ietf.org/doc/html/draft-ietf-tram-turnbis
Diff:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tram-turnbis-28<= br>
Abstract:
=C2=A0 =C2=A0If a host is located behind a NAT, then in certain situations = it can
=C2=A0 =C2=A0be impossible for that host to communicate directly with other= hosts
=C2=A0 =C2=A0(peers).=C2=A0 In these situations, it is necessary for the ho= st to use
=C2=A0 =C2=A0the services of an intermediate node that acts as a communicat= ion
=C2=A0 =C2=A0relay.=C2=A0 This specification defines a protocol, called TUR= N (Traversal
=C2=A0 =C2=A0Using Relays around NAT), that allows the host to control the<= br> =C2=A0 =C2=A0operation of the relay and to exchange packets with its peers = using
=C2=A0 =C2=A0the relay.=C2=A0 TURN differs from other relay control protoco= ls in that
=C2=A0 =C2=A0it allows a client to communicate with multiple peers using a = single
=C2=A0 =C2=A0relay address.

=C2=A0 =C2=A0The TURN protocol was designed to be used as part of the ICE =C2=A0 =C2=A0(Interactive Connectivity Establishment) approach to NAT trave= rsal,
=C2=A0 =C2=A0though it also can be used without ICE.

=C2=A0 =C2=A0This document obsoletes RFC 5766 and RFC 6156.




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

The IETF Secretariat

--0000000000001926ba058e4229ab-- From nobody Mon Jul 22 03:06:32 2019 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 D8985120072 for ; Mon, 22 Jul 2019 03:06:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.998 X-Spam-Level: X-Spam-Status: No, score=-3.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (public key: not available)" header.d=mcafee.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7iwiUqma2JHf for ; Mon, 22 Jul 2019 03:06:28 -0700 (PDT) Received: from us-smtp-delivery-210.mimecast.com (us-smtp-delivery-210.mimecast.com [63.128.21.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 04791120219 for ; Mon, 22 Jul 2019 03:06:27 -0700 (PDT) X-NAI-Header: Modified by McAfee Email Gateway (5500) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mcafee.com; s=s_mcafee; t=1563789309; h=ARC-Seal: ARC-Message-Signature:ARC-Authentication-Results: From:To:Subject:Thread-Topic:Thread-Index: Date:Message-ID:References:In-Reply-To:Accept-Language: Content-Language:X-MS-Has-Attach:X-MS-TNEF-Correlator: dlp-product:dlp-version:dlp-reaction:authentication-results: x-originating-ip:x-ms-publictraffictype:x-ms-office365-filtering-correlation-id: x-microsoft-antispam:x-ms-traffictypediagnostic: x-ms-exchange-purlcount:x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers:x-forefront-prvs: x-forefront-antispam-report:received-spf:x-ms-exchange-senderadcheck: x-microsoft-antispam-message-info:Content-Type: MIME-Version:X-MS-Exchange-CrossTenant-Network-Message-Id: X-MS-Exchange-CrossTenant-originalarrivaltime: X-MS-Exchange-CrossTenant-fromentityheader: X-MS-Exchange-CrossTenant-id:X-MS-Exchange-CrossTenant-mailboxtype: X-MS-Exchange-CrossTenant-userprincipalname: X-MS-Exchange-Transport-CrossTenantHeadersStamped: X-OriginatorOrg:X-NAI-Spam-Flag:X-NAI-Spam-Threshold: X-NAI-Spam-Score:X-NAI-Spam-Version; bh=r I7zXInu5OZJZC/6fGVi/Zlb+tnrL+1jOLdPMCk/zh g=; b=IWHFBbGHdKfQP/BmUmm3L8CjEBlmnxWWD+4wsOAV8jg7 ykTXworci6KtLMRG7E6VQ0KG5YRrtsDS9xxrizYdECd3/eDbdM x2MWOwNJnllwzbUPsYVggxMfzpxHknrJR0BDeiGw5cSeMrKq91 EmLewSpqkQEEmaFH9logQPF+154= Received: from DNVWSMAILOUT1.mcafee.com (dnvwsmailout1.mcafee.com [161.69.31.173]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-34-Tws1IYOQOi2RdOVHTvYjcQ-1; Mon, 22 Jul 2019 06:06:22 -0400 Received: from DNVEXAPP1N04.corpzone.internalzone.com (unknown [10.44.48.88]) by DNVWSMAILOUT1.mcafee.com with smtp (TLS: TLSv1/SSLv3,256bits,ECDHE-RSA-AES256-SHA384) id 298c_90c3_4f0604db_1104_4d08_b823_2b1479f27991; Mon, 22 Jul 2019 03:55:09 -0600 Received: from DNVEXAPP1N05.corpzone.internalzone.com (10.44.48.89) by DNVEXAPP1N04.corpzone.internalzone.com (10.44.48.88) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Mon, 22 Jul 2019 04:06:17 -0600 Received: from DNVO365EDGE2.corpzone.internalzone.com (10.44.176.74) by DNVEXAPP1N05.corpzone.internalzone.com (10.44.48.89) with Microsoft SMTP Server (TLS) id 15.0.1395.4 via Frontend Transport; Mon, 22 Jul 2019 04:06:17 -0600 Received: from NAM01-BY2-obe.outbound.protection.outlook.com (10.44.176.241) by edge.mcafee.com (10.44.176.74) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Mon, 22 Jul 2019 04:06:16 -0600 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=eKJr35P50R22s7y1FCPgZ5xV2cdsHhGBUGkN6Rh2kWNjDDr+YQV8IESf6Mb6wjAZoyGZOgN3tAGww+to3tuIhK1aZb/SrxPQ11yY9VESLlD+xgYyCQVLBknVNdqaWxpWgMQ2Lx0uT+8GKZ5aZmHGn7ZPd+PJYKhUMnI2Qt3/dYalR6vwpO/lczKH4VkPIXDNRt0zQ9NJvUpy0CJke7VMqvKbLX+3TgwNQunJ45KWZSxsT//vZB0gPMInY+OoZweYKvjimwv0g2uwTtCbx4ccBXzVGHjpyvLUauC215gIZRegzRJ3aB1mm8Xzm66ZCutJ9dKHHlIPjuiGicp7in8CwQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=rI7zXInu5OZJZC/6fGVi/Zlb+tnrL+1jOLdPMCk/zhg=; b=jZy3492+IwBfhALQSnoYah1bFRJat8MzSisG0HmANeh1gcR99ZQr4cR4a46LTUpjP/33gcG7t4rTztXIgogdVKVQVcWACcr4muzlX4x4YB6Ozj6k65914GJOfmqlUT6B3ULfLLYh9SK5+IhnHh/EKv64l5n8TpR5fkikakjPVqyjHPkFOoHV97oAoSp8pvbmCABcpzitlEGm6e2pJTTRLQp3ATZ/QHZd/462fudfmRuaEQZfH7i+oigs8gaINXpSC8gMPeIvcCB/F0YROEqBUtN8L7aPMCssssWXFfgf3mVt39vTL6oCXg8KZo1GnetG3fu2SPlb0WZT+nBGVikjbQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1;spf=pass smtp.mailfrom=mcafee.com;dmarc=pass action=none header.from=mcafee.com;dkim=pass header.d=mcafee.com;arc=none Received: from DM5PR16MB1705.namprd16.prod.outlook.com (10.172.44.147) by DM5PR16MB2374.namprd16.prod.outlook.com (52.132.142.165) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2094.15; Mon, 22 Jul 2019 10:06:16 +0000 Received: from DM5PR16MB1705.namprd16.prod.outlook.com ([fe80::570:2208:75c2:5f17]) by DM5PR16MB1705.namprd16.prod.outlook.com ([fe80::570:2208:75c2:5f17%8]) with mapi id 15.20.2094.013; Mon, 22 Jul 2019 10:06:16 +0000 From: "Konda, Tirumaleswar Reddy" To: tirumal reddy , "tram@ietf.org" , "Roman Danyliw" , Benjamin Kaduk , "evyncke@cisco.com" , "Suresh@kaloom.com" , "ietf@kuehlewind.net" , "adam@nostrum.com" , "magnus.westerlund@ericsson.com" Thread-Topic: [tram] Fwd: New Version Notification for draft-ietf-tram-turnbis-28.txt Thread-Index: AQHVQHSKnWw9OX3biEStRi7bVhnJMabWaNBg Date: Mon, 22 Jul 2019 10:06:16 +0000 Message-ID: References: <156378840844.28007.1060920586650003823.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.3.0.16 dlp-reaction: no-action x-originating-ip: [103.245.47.20] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 494d2759-041f-413c-b438-08d70e8c3c3c x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:DM5PR16MB2374; x-ms-traffictypediagnostic: DM5PR16MB2374: x-ms-exchange-purlcount: 9 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 01068D0A20 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(346002)(136003)(376002)(39860400002)(366004)(396003)(32952001)(199004)(189003)(22974007)(256004)(14454004)(102836004)(606006)(76176011)(53546011)(6506007)(71190400001)(71200400001)(68736007)(66556008)(25786009)(14444005)(5024004)(6436002)(7736002)(74316002)(86362001)(64756008)(66946007)(76116006)(66446008)(66476007)(476003)(2906002)(8936002)(11346002)(446003)(26005)(229853002)(7696005)(7110500001)(8676002)(186003)(66574012)(81156014)(81166006)(3846002)(53386004)(2171002)(6116002)(33656002)(6246003)(6306002)(110136005)(54896002)(55016002)(9686003)(2501003)(478600001)(99286004)(316002)(5660300002)(15650500001)(2420400007)(53936002)(66066001)(966005)(486006)(2201001)(52536014)(80792005)(236005)(790700001)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR16MB2374; H:DM5PR16MB1705.namprd16.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: 91XnoaSTcxr/6B8BBXOHe/UE81fCO3kgisABHUtexUcnWpkOI5Sc9jGw2bPJtLXH/o7n/p6T+dxx+THGfMChBs0sgla9xI+Q9h1L3UNMaxUeMq2gOlAcFfngFeDQHJi85pmgUxK4VRWuUzBv+P51a68oYgU20fbxTzvHNbTWKHhVgOsRS4CJxSxOoElP5u0jsiWjSkauIevnCKt7buTNqDlhsbzB1auCmOpVPVwe1TpP9Vz6Drb4+pxprQ5xio30dhopLm1Qr8lUOVjcqSxySb2RahIQ4zCwx6oJH1sFb3ClUYVojxgP+oD9V+oLIFqZ1BUnWzi3SD89OF7YO9BlsiMIpeuzPoRh1NEqgjAQCmtG8X2PEezjwWZ8uCXdyLXO4rv7tlTCewGCAueg5A43VSm1th7VSAGxvH6lyRqqLu8= MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 494d2759-041f-413c-b438-08d70e8c3c3c X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Jul 2019 10:06:16.3644 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: TirumaleswarReddy_Konda@McAfee.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR16MB2374 X-OriginatorOrg: mcafee.com X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 15 X-NAI-Spam-Score: 0 X-NAI-Spam-Version: 2.3.0.9418 : core <6594> : inlines <7122> : streams <1828082> : uri <2870738> X-MC-Unique: Tws1IYOQOi2RdOVHTvYjcQ-1 X-Mimecast-Spam-Score: 0 Content-Type: multipart/alternative; boundary="_000_DM5PR16MB17052F791A4CBAF3E4852611EAC40DM5PR16MB1705namp_" Archived-At: Subject: Re: [tram] Fwd: New Version Notification for draft-ietf-tram-turnbis-28.txt X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.29 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, 22 Jul 2019 10:06:31 -0000 --_000_DM5PR16MB17052F791A4CBAF3E4852611EAC40DM5PR16MB1705namp_ Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 VHlwbywgSSBtZWFudCBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi10cmFt LXR1cm5iaXMtMjgNCg0KLVRpcnUNCg0KRnJvbTogdHJhbSA8dHJhbS1ib3VuY2VzQGlldGYub3Jn PiBPbiBCZWhhbGYgT2YgdGlydW1hbCByZWRkeQ0KU2VudDogTW9uZGF5LCBKdWx5IDIyLCAyMDE5 IDM6MzEgUE0NClRvOiB0cmFtQGlldGYub3JnOyBSb21hbiBEYW55bGl3IDxyZGRAY2VydC5vcmc+ OyBCZW5qYW1pbiBLYWR1ayA8a2FkdWtAbWl0LmVkdT47IGV2eW5ja2VAY2lzY28uY29tOyBTdXJl c2hAa2Fsb29tLmNvbTsgaWV0ZkBrdWVobGV3aW5kLm5ldDsgYWRhbUBub3N0cnVtLmNvbTsgbWFn bnVzLndlc3Rlcmx1bmRAZXJpY3Nzb24uY29tDQpTdWJqZWN0OiBbdHJhbV0gRndkOiBOZXcgVmVy c2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWlldGYtdHJhbS10dXJuYmlzLTI4LnR4dA0KDQoN CkNBVVRJT046IEV4dGVybmFsIGVtYWlsLiBEbyBub3QgY2xpY2sgbGlua3Mgb3Igb3BlbiBhdHRh Y2htZW50cyB1bmxlc3MgeW91IHJlY29nbml6ZSB0aGUgc2VuZGVyIGFuZCBrbm93IHRoZSBjb250 ZW50IGlzIHNhZmUuDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpUaGlzIHJl dmlzaW9uIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWRvdHMtcmVxdWly ZW1lbnRzLTE5IGFkZHJlc3NlcyBEaXNjdXNzIGFuZCBjb21tZW50cyBmcm9tIElTRUcgcmV2aWV3 IGJ5IFJvbWFuIERhbnlsaXcsIMOJcmljIFZ5bmNrZSwgQWRhbSBSb2FjaCwgU3VyZXNoIEtyaXNo bmFuLCBNaXJqYSBLw7xobGV3aW5kIGFuZCBCZW5qYW1pbiBLYWR1ay4NCg0KLVRpcnUNCg0KLS0t LS0tLS0tLSBGb3J3YXJkZWQgbWVzc2FnZSAtLS0tLS0tLS0NCkZyb206IDxpbnRlcm5ldC1kcmFm dHNAaWV0Zi5vcmc8bWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZz4+DQpEYXRlOiBNb24s IDIyIEp1bCAyMDE5IGF0IDE1OjEwDQpTdWJqZWN0OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24g Zm9yIGRyYWZ0LWlldGYtdHJhbS10dXJuYmlzLTI4LnR4dA0KVG86IFBoaWxpcCBNYXR0aGV3cyA8 cGhpbGlwX21hdHRoZXdzQG1hZ21hLmNhPG1haWx0bzpwaGlsaXBfbWF0dGhld3NAbWFnbWEuY2E+ PiwgVGlydW1hbGVzd2FyIFJlZGR5IDxrb25kdGlyQGdtYWlsLmNvbTxtYWlsdG86a29uZHRpckBn bWFpbC5jb20+PiwgSm9uYXRoYW4gUm9zZW5iZXJnIDxqZHJvc2VuQGpkcm9zZW4ubmV0PG1haWx0 bzpqZHJvc2VuQGpkcm9zZW4ubmV0Pj4sIEFsYW4gSm9obnN0b24gPGFsYW4uYi5qb2huc3RvbkBn bWFpbC5jb208bWFpbHRvOmFsYW4uYi5qb2huc3RvbkBnbWFpbC5jb20+Pg0KDQoNCg0KQSBuZXcg dmVyc2lvbiBvZiBJLUQsIGRyYWZ0LWlldGYtdHJhbS10dXJuYmlzLTI4LnR4dA0KaGFzIGJlZW4g c3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBUaXJ1bWFsZXN3YXIgUmVkZHkgYW5kIHBvc3RlZCB0 byB0aGUNCklFVEYgcmVwb3NpdG9yeS4NCg0KTmFtZTogICAgICAgICAgIGRyYWZ0LWlldGYtdHJh bS10dXJuYmlzDQpSZXZpc2lvbjogICAgICAgMjgNClRpdGxlOiAgICAgICAgICBUcmF2ZXJzYWwg VXNpbmcgUmVsYXlzIGFyb3VuZCBOQVQgKFRVUk4pOiBSZWxheSBFeHRlbnNpb25zIHRvIFNlc3Np b24gVHJhdmVyc2FsIFV0aWxpdGllcyBmb3IgTkFUIChTVFVOKQ0KRG9jdW1lbnQgZGF0ZTogIDIw MTktMDctMjINCkdyb3VwOiAgICAgICAgICB0cmFtDQpQYWdlczogICAgICAgICAgOTINClVSTDog ICAgICAgICAgICBodHRwczovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtaWV0 Zi10cmFtLXR1cm5iaXMtMjgudHh0DQpTdGF0dXM6ICAgICAgICAgaHR0cHM6Ly9kYXRhdHJhY2tl ci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi10cmFtLXR1cm5iaXMvDQpIdG1saXplZDogICAgICAg aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtdHJhbS10dXJuYmlzLTI4DQpI dG1saXplZDogICAgICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFm dC1pZXRmLXRyYW0tdHVybmJpcw0KRGlmZjogICAgICAgICAgIGh0dHBzOi8vd3d3LmlldGYub3Jn L3JmY2RpZmY/dXJsMj1kcmFmdC1pZXRmLXRyYW0tdHVybmJpcy0yOA0KDQpBYnN0cmFjdDoNCiAg IElmIGEgaG9zdCBpcyBsb2NhdGVkIGJlaGluZCBhIE5BVCwgdGhlbiBpbiBjZXJ0YWluIHNpdHVh dGlvbnMgaXQgY2FuDQogICBiZSBpbXBvc3NpYmxlIGZvciB0aGF0IGhvc3QgdG8gY29tbXVuaWNh dGUgZGlyZWN0bHkgd2l0aCBvdGhlciBob3N0cw0KICAgKHBlZXJzKS4gIEluIHRoZXNlIHNpdHVh dGlvbnMsIGl0IGlzIG5lY2Vzc2FyeSBmb3IgdGhlIGhvc3QgdG8gdXNlDQogICB0aGUgc2Vydmlj ZXMgb2YgYW4gaW50ZXJtZWRpYXRlIG5vZGUgdGhhdCBhY3RzIGFzIGEgY29tbXVuaWNhdGlvbg0K ICAgcmVsYXkuICBUaGlzIHNwZWNpZmljYXRpb24gZGVmaW5lcyBhIHByb3RvY29sLCBjYWxsZWQg VFVSTiAoVHJhdmVyc2FsDQogICBVc2luZyBSZWxheXMgYXJvdW5kIE5BVCksIHRoYXQgYWxsb3dz IHRoZSBob3N0IHRvIGNvbnRyb2wgdGhlDQogICBvcGVyYXRpb24gb2YgdGhlIHJlbGF5IGFuZCB0 byBleGNoYW5nZSBwYWNrZXRzIHdpdGggaXRzIHBlZXJzIHVzaW5nDQogICB0aGUgcmVsYXkuICBU VVJOIGRpZmZlcnMgZnJvbSBvdGhlciByZWxheSBjb250cm9sIHByb3RvY29scyBpbiB0aGF0DQog ICBpdCBhbGxvd3MgYSBjbGllbnQgdG8gY29tbXVuaWNhdGUgd2l0aCBtdWx0aXBsZSBwZWVycyB1 c2luZyBhIHNpbmdsZQ0KICAgcmVsYXkgYWRkcmVzcy4NCg0KICAgVGhlIFRVUk4gcHJvdG9jb2wg d2FzIGRlc2lnbmVkIHRvIGJlIHVzZWQgYXMgcGFydCBvZiB0aGUgSUNFDQogICAoSW50ZXJhY3Rp dmUgQ29ubmVjdGl2aXR5IEVzdGFibGlzaG1lbnQpIGFwcHJvYWNoIHRvIE5BVCB0cmF2ZXJzYWws DQogICB0aG91Z2ggaXQgYWxzbyBjYW4gYmUgdXNlZCB3aXRob3V0IElDRS4NCg0KICAgVGhpcyBk b2N1bWVudCBvYnNvbGV0ZXMgUkZDIDU3NjYgYW5kIFJGQyA2MTU2Lg0KDQoNCg0KDQpQbGVhc2Ug bm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBv ZiBzdWJtaXNzaW9uDQp1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZh aWxhYmxlIGF0IHRvb2xzLmlldGYub3JnPGh0dHA6Ly90b29scy5pZXRmLm9yZz4uDQoNClRoZSBJ RVRGIFNlY3JldGFyaWF0DQo= --_000_DM5PR16MB17052F791A4CBAF3E4852611EAC40DM5PR16MB1705namp_ Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYg MyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpEZW5nWGlhbjsNCglwYW5vc2UtMToy IDEgNiAwIDMgMSAxIDEgMSAxO30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsN CglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFt aWx5OiJcQERlbmdYaWFuIjsNCglwYW5vc2UtMToyIDEgNiAwIDMgMSAxIDEgMSAxO30NCi8qIFN0 eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9y bWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTox MS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFu Lk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0 ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtG b2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQt ZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5tc29ub3JtYWwwLCBsaS5tc29ub3JtYWwwLCBkaXYu bXNvbm9ybWFsMA0KCXttc28tc3R5bGUtbmFtZTptc29ub3JtYWw7DQoJbXNvLW1hcmdpbi10b3At YWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToi Q2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUyMA0KCXttc28tc3R5bGUtdHlw ZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCglj b2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9y dC1vbmx5O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJn aW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldv cmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hh cGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlm XS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQi Pg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94 bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIg dmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRkkiPlR5cG8sIEkgbWVhbnQ8L3NwYW4+PHNwYW4gbGFuZz0i RkkiPiZuYnNwOzwvc3Bhbj48YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJh ZnQtaWV0Zi10cmFtLXR1cm5iaXMtMjgiIHRhcmdldD0iX2JsYW5rIj48c3BhbiBsYW5nPSJGSSI+ aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtdHJhbS10dXJuYmlzLTI4PC9z cGFuPjwvYT48c3BhbiBsYW5nPSJGSSI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRkkiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPi1UaXJ1PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6 bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGlu IDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj5Gcm9tOjwvYj4gdHJhbSAmbHQ7dHJhbS1i b3VuY2VzQGlldGYub3JnJmd0OyA8Yj5PbiBCZWhhbGYgT2YgPC9iPg0KdGlydW1hbCByZWRkeTxi cj4NCjxiPlNlbnQ6PC9iPiBNb25kYXksIEp1bHkgMjIsIDIwMTkgMzozMSBQTTxicj4NCjxiPlRv OjwvYj4gdHJhbUBpZXRmLm9yZzsgUm9tYW4gRGFueWxpdyAmbHQ7cmRkQGNlcnQub3JnJmd0Ozsg QmVuamFtaW4gS2FkdWsgJmx0O2thZHVrQG1pdC5lZHUmZ3Q7OyBldnluY2tlQGNpc2NvLmNvbTsg U3VyZXNoQGthbG9vbS5jb207IGlldGZAa3VlaGxld2luZC5uZXQ7IGFkYW1Abm9zdHJ1bS5jb207 IG1hZ251cy53ZXN0ZXJsdW5kQGVyaWNzc29uLmNvbTxicj4NCjxiPlN1YmplY3Q6PC9iPiBbdHJh bV0gRndkOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWlldGYtdHJhbS10dXJu YmlzLTI4LnR4dDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjx0YWJsZSBjbGFzcz0iTXNvTm9y bWFsVGFibGUiIGJvcmRlcj0iMSIgY2VsbHBhZGRpbmc9IjAiIHN0eWxlPSJiYWNrZ3JvdW5kOiNG M0ZGMzM7Ym9yZGVyOnNvbGlkICM5QjlBODcgMS41cHQiPg0KPHRib2R5Pg0KPHRyPg0KPHRkIHN0 eWxlPSJib3JkZXI6bm9uZTtwYWRkaW5nOi43NXB0IC43NXB0IC43NXB0IC43NXB0Ij4NCjxwPjxz dHJvbmc+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6IzlCOEIzRSI+Q0FVVElPTjwvc3Bhbj48L3N0cm9uZz48c3BhbiBzdHlsZT0iZm9u dC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojOUI4QjNFIj46PC9z cGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOmJsYWNrIj4gRXh0ZXJuYWwgZW1haWwuIERvIG5vdCBjbGljayBsaW5rcyBvciBvcGVu DQogYXR0YWNobWVudHMgdW5sZXNzIHlvdSByZWNvZ25pemUgdGhlIHNlbmRlciBhbmQga25vdyB0 aGUgY29udGVudCBpcyBzYWZlLjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7 QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC90ZD4NCjwv dHI+DQo8L3Rib2R5Pg0KPC90YWJsZT4NCjxkaXYgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImNl bnRlciIgc3R5bGU9InRleHQtYWxpZ246Y2VudGVyIj4NCjxociBzaXplPSIyIiB3aWR0aD0iMTAw JSIgYWxpZ249ImNlbnRlciI+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ VGhpcyByZXZpc2lvbiA8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQt aWV0Zi1kb3RzLXJlcXVpcmVtZW50cy0xOSI+DQpodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwv ZHJhZnQtaWV0Zi1kb3RzLXJlcXVpcmVtZW50cy0xOTwvYT4gYWRkcmVzc2VzIERpc2N1c3MgYW5k IGNvbW1lbnRzIGZyb20gSVNFRyByZXZpZXcgYnkmbmJzcDtSb21hbiBEYW55bGl3LCDDiXJpYyBW eW5ja2UsIEFkYW0gUm9hY2gsIFN1cmVzaCBLcmlzaG5hbiwgTWlyamEgS8O8aGxld2luZCBhbmQg QmVuamFtaW4gS2FkdWsuPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj4tVGlydTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj4tLS0tLS0tLS0tIEZvcndhcmRlZCBtZXNzYWdlIC0tLS0tLS0tLTxicj4NCkZyb206 ICZsdDs8YSBocmVmPSJtYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIj5pbnRlcm5ldC1k cmFmdHNAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCkRhdGU6IE1vbiwgMjIgSnVsIDIwMTkgYXQgMTU6 MTA8YnI+DQpTdWJqZWN0OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWlldGYt dHJhbS10dXJuYmlzLTI4LnR4dDxicj4NClRvOiBQaGlsaXAgTWF0dGhld3MgJmx0OzxhIGhyZWY9 Im1haWx0bzpwaGlsaXBfbWF0dGhld3NAbWFnbWEuY2EiPnBoaWxpcF9tYXR0aGV3c0BtYWdtYS5j YTwvYT4mZ3Q7LCBUaXJ1bWFsZXN3YXIgUmVkZHkgJmx0OzxhIGhyZWY9Im1haWx0bzprb25kdGly QGdtYWlsLmNvbSI+a29uZHRpckBnbWFpbC5jb208L2E+Jmd0OywgSm9uYXRoYW4gUm9zZW5iZXJn ICZsdDs8YSBocmVmPSJtYWlsdG86amRyb3NlbkBqZHJvc2VuLm5ldCI+amRyb3NlbkBqZHJvc2Vu Lm5ldDwvYT4mZ3Q7LCBBbGFuDQogSm9obnN0b24gJmx0OzxhIGhyZWY9Im1haWx0bzphbGFuLmIu am9obnN0b25AZ21haWwuY29tIj5hbGFuLmIuam9obnN0b25AZ21haWwuY29tPC9hPiZndDs8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1i b3R0b206MTIuMHB0Ij48YnI+DQo8YnI+DQo8YnI+DQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJh ZnQtaWV0Zi10cmFtLXR1cm5iaXMtMjgudHh0PGJyPg0KaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1 Ym1pdHRlZCBieSBUaXJ1bWFsZXN3YXIgUmVkZHkgYW5kIHBvc3RlZCB0byB0aGU8YnI+DQpJRVRG IHJlcG9zaXRvcnkuPGJyPg0KPGJyPg0KTmFtZTombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwO2RyYWZ0LWlldGYtdHJhbS10dXJuYmlzPGJyPg0KUmV2aXNpb246Jm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7Mjg8YnI+DQpUaXRsZTombmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7IFRyYXZlcnNhbCBVc2luZyBSZWxheXMgYXJvdW5kIE5BVCAoVFVSTik6IFJl bGF5IEV4dGVuc2lvbnMgdG8gU2Vzc2lvbiBUcmF2ZXJzYWwgVXRpbGl0aWVzIGZvciBOQVQgKFNU VU4pPGJyPg0KRG9jdW1lbnQgZGF0ZTombmJzcDsgMjAxOS0wNy0yMjxicj4NCkdyb3VwOiZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgdHJhbTxicj4NClBhZ2VzOiZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgOTI8YnI+DQpVUkw6Jm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaW50ZXJu ZXQtZHJhZnRzL2RyYWZ0LWlldGYtdHJhbS10dXJuYmlzLTI4LnR4dCIgdGFyZ2V0PSJfYmxhbmsi Pg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWlldGYtdHJhbS10 dXJuYmlzLTI4LnR4dDwvYT48YnI+DQpTdGF0dXM6Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWll dGYtdHJhbS10dXJuYmlzLyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0 Zi5vcmcvZG9jL2RyYWZ0LWlldGYtdHJhbS10dXJuYmlzLzwvYT48YnI+DQpIdG1saXplZDombmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDs8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0 bWwvZHJhZnQtaWV0Zi10cmFtLXR1cm5iaXMtMjgiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3Rv b2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi10cmFtLXR1cm5iaXMtMjg8L2E+PGJyPg0KSHRt bGl6ZWQ6Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJh Y2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC1pZXRmLXRyYW0tdHVybmJpcyIgdGFyZ2V0PSJf YmxhbmsiPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQtaWV0Zi10 cmFtLXR1cm5iaXM8L2E+PGJyPg0KRGlmZjombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFm dC1pZXRmLXRyYW0tdHVybmJpcy0yOCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYu b3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1pZXRmLXRyYW0tdHVybmJpcy0yODwvYT48YnI+DQo8YnI+ DQpBYnN0cmFjdDo8YnI+DQombmJzcDsgJm5ic3A7SWYgYSBob3N0IGlzIGxvY2F0ZWQgYmVoaW5k IGEgTkFULCB0aGVuIGluIGNlcnRhaW4gc2l0dWF0aW9ucyBpdCBjYW48YnI+DQombmJzcDsgJm5i c3A7YmUgaW1wb3NzaWJsZSBmb3IgdGhhdCBob3N0IHRvIGNvbW11bmljYXRlIGRpcmVjdGx5IHdp dGggb3RoZXIgaG9zdHM8YnI+DQombmJzcDsgJm5ic3A7KHBlZXJzKS4mbmJzcDsgSW4gdGhlc2Ug c2l0dWF0aW9ucywgaXQgaXMgbmVjZXNzYXJ5IGZvciB0aGUgaG9zdCB0byB1c2U8YnI+DQombmJz cDsgJm5ic3A7dGhlIHNlcnZpY2VzIG9mIGFuIGludGVybWVkaWF0ZSBub2RlIHRoYXQgYWN0cyBh cyBhIGNvbW11bmljYXRpb248YnI+DQombmJzcDsgJm5ic3A7cmVsYXkuJm5ic3A7IFRoaXMgc3Bl Y2lmaWNhdGlvbiBkZWZpbmVzIGEgcHJvdG9jb2wsIGNhbGxlZCBUVVJOIChUcmF2ZXJzYWw8YnI+ DQombmJzcDsgJm5ic3A7VXNpbmcgUmVsYXlzIGFyb3VuZCBOQVQpLCB0aGF0IGFsbG93cyB0aGUg aG9zdCB0byBjb250cm9sIHRoZTxicj4NCiZuYnNwOyAmbmJzcDtvcGVyYXRpb24gb2YgdGhlIHJl bGF5IGFuZCB0byBleGNoYW5nZSBwYWNrZXRzIHdpdGggaXRzIHBlZXJzIHVzaW5nPGJyPg0KJm5i c3A7ICZuYnNwO3RoZSByZWxheS4mbmJzcDsgVFVSTiBkaWZmZXJzIGZyb20gb3RoZXIgcmVsYXkg Y29udHJvbCBwcm90b2NvbHMgaW4gdGhhdDxicj4NCiZuYnNwOyAmbmJzcDtpdCBhbGxvd3MgYSBj bGllbnQgdG8gY29tbXVuaWNhdGUgd2l0aCBtdWx0aXBsZSBwZWVycyB1c2luZyBhIHNpbmdsZTxi cj4NCiZuYnNwOyAmbmJzcDtyZWxheSBhZGRyZXNzLjxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDtU aGUgVFVSTiBwcm90b2NvbCB3YXMgZGVzaWduZWQgdG8gYmUgdXNlZCBhcyBwYXJ0IG9mIHRoZSBJ Q0U8YnI+DQombmJzcDsgJm5ic3A7KEludGVyYWN0aXZlIENvbm5lY3Rpdml0eSBFc3RhYmxpc2ht ZW50KSBhcHByb2FjaCB0byBOQVQgdHJhdmVyc2FsLDxicj4NCiZuYnNwOyAmbmJzcDt0aG91Z2gg aXQgYWxzbyBjYW4gYmUgdXNlZCB3aXRob3V0IElDRS48YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7 VGhpcyBkb2N1bWVudCBvYnNvbGV0ZXMgUkZDIDU3NjYgYW5kIFJGQyA2MTU2Ljxicj4NCjxicj4N Cjxicj4NCjxicj4NCjxicj4NClBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUg b2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb248YnI+DQp1bnRpbCB0aGUgaHRt bGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IDxhIGhyZWY9Imh0dHA6Ly90 b29scy5pZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPg0KdG9vbHMuaWV0Zi5vcmc8L2E+Ljxicj4N Cjxicj4NClRoZSBJRVRGIFNlY3JldGFyaWF0PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYm9k eT4NCjwvaHRtbD4NCg== --_000_DM5PR16MB17052F791A4CBAF3E4852611EAC40DM5PR16MB1705namp_-- From nobody Mon Jul 22 21:18:42 2019 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 6E294120041; Mon, 22 Jul 2019 21:18:40 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Benjamin Kaduk via Datatracker To: "The IESG" Cc: draft-ietf-tram-turnbis@ietf.org, Brandon Williams , tram-chairs@ietf.org, brandon.williams@akamai.com, tram@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.99.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Benjamin Kaduk Message-ID: <156385552040.22775.12095521381624465727.idtracker@ietfa.amsl.com> Date: Mon, 22 Jul 2019 21:18:40 -0700 Archived-At: Subject: [tram] Benjamin Kaduk's No Objection on draft-ietf-tram-turnbis-28: (with COMMENT) X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.29 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 Jul 2019 04:18:41 -0000 Benjamin Kaduk has entered the following ballot position for draft-ietf-tram-turnbis-28: 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-turnbis/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you for addressing my Discuss points! From nobody Tue Jul 23 22:48:25 2019 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 A0012120281 for ; Tue, 23 Jul 2019 22:48:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4 X-Spam-Level: X-Spam-Status: No, score=-4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (public key: not available)" header.d=mcafee.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nHUgtm82FjLk for ; Tue, 23 Jul 2019 22:48:22 -0700 (PDT) Received: from us-smtp-delivery-210.mimecast.com (us-smtp-delivery-210.mimecast.com [63.128.21.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D6BF12007C for ; Tue, 23 Jul 2019 22:48:22 -0700 (PDT) X-NAI-Header: Modified by McAfee Email Gateway (5500) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mcafee.com; s=s_mcafee; t=1563946546; h=ARC-Seal: ARC-Message-Signature:ARC-Authentication-Results: From:To:CC:Subject:Thread-Topic:Thread-Index: Date:Message-ID:References:In-Reply-To:Accept-Language: Content-Language:X-MS-Has-Attach:X-MS-TNEF-Correlator: dlp-product:dlp-version:dlp-reaction:authentication-results: x-originating-ip:x-ms-publictraffictype:x-ms-office365-filtering-correlation-id: x-microsoft-antispam:x-ms-traffictypediagnostic: x-ms-exchange-purlcount:x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers:x-forefront-prvs: x-forefront-antispam-report:received-spf:x-ms-exchange-senderadcheck: x-microsoft-antispam-message-info:Content-Type: Content-Transfer-Encoding:MIME-Version:X-MS-Exchange-CrossTenant-Network-Message-Id: X-MS-Exchange-CrossTenant-originalarrivaltime: X-MS-Exchange-CrossTenant-fromentityheader: X-MS-Exchange-CrossTenant-id:X-MS-Exchange-CrossTenant-mailboxtype: X-MS-Exchange-CrossTenant-userprincipalname: X-MS-Exchange-Transport-CrossTenantHeadersStamped: X-OriginatorOrg:X-NAI-Spam-Flag:X-NAI-Spam-Level: X-NAI-Spam-Threshold:X-NAI-Spam-Score:X-NAI-Spam-Version; bh=/IDWN1VdRXIoTbxV6ZJUIGQb6L/jMp/XmUIsge /4rK8=; b=hcYHoGdLk1fJLhz3QrWbuEcTPbS6IfsTZPCXTcGP XE+L2NAVDHP5McMSAm3Odyl0F5qvOmtaNKNUFgFh5x4AZiaswe balrF8TfWTl0lxd0LWZ+itCVxNCctbw6iQHyuzhGsZHboVQ3oH /D1uPMCq6jRVqusZFtzzuNux/Jbohlo= Received: from DNVWSMAILOUT1.mcafee.com (dnvwsmailout1.mcafee.com [161.69.31.173]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-156-78pU0ACzMm-1E_28oTQCSw-1; Wed, 24 Jul 2019 01:47:05 -0400 Received: from DNVEXAPP1N04.corpzone.internalzone.com (unknown [10.44.48.88]) by DNVWSMAILOUT1.mcafee.com with smtp (TLS: TLSv1/SSLv3,256bits,ECDHE-RSA-AES256-SHA384) id 1536_08a5_68cad2a7_9e19_4ce9_846c_078592276669; Tue, 23 Jul 2019 23:35:45 -0600 Received: from DNVEXAPP1N04.corpzone.internalzone.com (10.44.48.88) by DNVEXAPP1N04.corpzone.internalzone.com (10.44.48.88) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Tue, 23 Jul 2019 23:46:19 -0600 Received: from DNVO365EDGE2.corpzone.internalzone.com (10.44.176.74) by DNVEXAPP1N04.corpzone.internalzone.com (10.44.48.88) with Microsoft SMTP Server (TLS) id 15.0.1395.4 via Frontend Transport; Tue, 23 Jul 2019 23:46:19 -0600 Received: from NAM03-BY2-obe.outbound.protection.outlook.com (10.44.176.243) by edge.mcafee.com (10.44.176.74) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Tue, 23 Jul 2019 23:46:07 -0600 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=iOSU85KQpAamZFgEVawbpAk3/wBa8yTW5coj2glIBPRjETfobXPEFikN+qe/Xuo1sbjVPWKH6xTd5yoahcyKOAbYoIq40wkh8aK6eYBrHo3QO3ahpPylpX7LVwd+osm4/rVjngQGpxXV/hH4zj/lrtvajIw93+RnFqvOSo5mTs7N81NX3n3ntZ6S+io52IX6XU5K59aNEADdyV1PQ/MYn6JnuIh2IaTPh0StnqCXf6lVl1+YQAQq9mtDkS9fI4nCxT1LPbJeSGTxEObCTbg9gAfzZZ4GZ9zfSKuJeWxfunEn5HJq8GNn4X78aJxiLdDscnuY5QZxJ9I+hsbHxNwu+w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=/IDWN1VdRXIoTbxV6ZJUIGQb6L/jMp/XmUIsge/4rK8=; b=TYlETHYr6198cEbx80nh3Wv5SuDj6XyhjvrawD3hpOSy9JMPMzqIMYZOayxOMWj63JBLJ0XfuUd+GMpzN+iO1QIM74ue8N/BDFYp2MeHmLBXyMLFvjkQkbHxsWwJg0ptvZM15B0w1fvXU5YkvP2a8X2G6183A+aWnBElRxpGYH6B7gbhhnVYVejk9fDH0BYYeFo94NRty1FKR07ribRiPZ9U7+VJ88D8umCGRnF9u1AAzp7BBGNQaWB6S3eeu8cHKWRNyxfcDVf15Fq9Ipcpdga1UQi0Vtfkfd/82QTPY4snddJAUeyWtt9DLmEH/2hE+D2hgNj+o/jnmay+DyDQ8w== ARC-Authentication-Results: i=1; mx.microsoft.com 1;spf=pass smtp.mailfrom=mcafee.com;dmarc=pass action=none header.from=mcafee.com;dkim=pass header.d=mcafee.com;arc=none Received: from DM5PR16MB1705.namprd16.prod.outlook.com (10.172.44.147) by DM5PR16MB1452.namprd16.prod.outlook.com (10.173.211.10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2094.15; Wed, 24 Jul 2019 05:46:05 +0000 Received: from DM5PR16MB1705.namprd16.prod.outlook.com ([fe80::6c22:21e:7528:3dc5]) by DM5PR16MB1705.namprd16.prod.outlook.com ([fe80::6c22:21e:7528:3dc5%6]) with mapi id 15.20.2115.005; Wed, 24 Jul 2019 05:46:05 +0000 From: "Konda, Tirumaleswar Reddy" To: =?utf-8?B?TWlyamEgS8O8aGxld2luZA==?= , The IESG CC: "tram-chairs@ietf.org" , "draft-ietf-tram-turnbis@ietf.org" , "tram@ietf.org" , "brandon.williams@akamai.com" Thread-Topic: =?utf-8?B?W3RyYW1dIE1pcmphIEvDvGhsZXdpbmQncyBEaXNjdXNzIG9uIGRyYWZ0LWll?= =?utf-8?Q?tf-tram-turnbis-27:_(with_DISCUSS_and_COMMENT)?= Thread-Index: AQHVNzftWkN2G8olS0aOBDqJ1prLPKbG+S0ggAecAUCACbymgA== Date: Wed, 24 Jul 2019 05:46:05 +0000 Message-ID: References: <156277411459.15353.13243689830942672102.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.3.0.16 dlp-reaction: no-action x-originating-ip: [185.221.69.46] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 78559412-fc09-47b7-275d-08d70ffa386a x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:DM5PR16MB1452; x-ms-traffictypediagnostic: DM5PR16MB1452: x-ms-exchange-purlcount: 7 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0108A997B2 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(346002)(376002)(396003)(366004)(39860400002)(136003)(189003)(199004)(13464003)(32952001)(51914003)(76094002)(224303003)(4326008)(66556008)(25786009)(66446008)(64756008)(81156014)(66066001)(54906003)(5660300002)(81166006)(6116002)(66946007)(52536014)(76116006)(66476007)(3846002)(53936002)(478600001)(80792005)(966005)(6246003)(9686003)(229853002)(55016002)(6306002)(6436002)(86362001)(102836004)(14454004)(6506007)(66574012)(53546011)(26005)(2906002)(33656002)(71200400001)(74316002)(71190400001)(7696005)(305945005)(316002)(476003)(76176011)(11346002)(486006)(68736007)(446003)(8936002)(7736002)(5024004)(186003)(99286004)(256004)(30864003)(110136005)(14444005)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR16MB1452; H:DM5PR16MB1705.namprd16.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: q4RMj386kiHW+Hy5wi62Tb6XwahZ0q+dbSj3DhPNG8BdEcKrzkkJVmnMkghw849xOSV3+FkdQRcv++pHUhIqpMxX1+D6KuWjNUcmkd4X+b47gM7hJAUxLKcVFj5N2mgP3GrJviKHGG2qpFwhbvEeA8L1lahcO6LXHBxc+5cEVpwYJbRk6WHno/yp6tJly08z8j4kaHerRluMYaimE/wVALZd3cz4u//AhEYbMZM8oJJEDLRSG0qEXqYhDzgrs6FYnNZ26xSqFIVSnI3CXgP2Ys9JjFiRWnAXWdZ5Zmqc+10ej5CPV3p+VKk1E/puswjgSN3sKL0o7M/+6vBRhVrwNSvkC6pW+StxDKKft5LF0FPsKvYXxBZWOnJk4aHeSsdhwdqCCaNBHOnPZpeY/HuQKuvUhHeZJhtJNwCrP6jJ4ZU= MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 78559412-fc09-47b7-275d-08d70ffa386a X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Jul 2019 05:46:05.7545 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: TirumaleswarReddy_Konda@McAfee.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR16MB1452 X-OriginatorOrg: mcafee.com X-NAI-Spam-Flag: NO X-NAI-Spam-Level: X-NAI-Spam-Threshold: 15 X-NAI-Spam-Score: 0.2 X-NAI-Spam-Version: 2.3.0.9418 : core <6596> : inlines <7125> : streams <1828256> : uri <2871684> X-MC-Unique: 78pU0ACzMm-1E_28oTQCSw-1 X-Mimecast-Spam-Score: 0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Archived-At: Subject: Re: [tram] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf-?= =?utf-8?q?tram-turnbis-27=3A_=28with_DISCUSS_and_COMMENT=29?= X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.29 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, 24 Jul 2019 05:48:25 -0000 SGkgTWlyamEsDQoNCldlIGhhdmUgdXBkYXRlZCB0aGUgZHJhZnQgdG8gYWRkcmVzcyB5b3VyIERp c2N1c3MgYW5kIGNvbW1lbnRzIChodHRwczovL3Rvb2xzLmlldGYub3JnL3JmY2RpZmY/dXJsMj1k cmFmdC1pZXRmLXRyYW0tdHVybmJpcy0yOC50eHQpLiAgUGxlYXNlIGhhdmUgYSBsb29rLg0KDQpD aGVlcnMsDQotVGlydQ0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IEtv bmRhLCBUaXJ1bWFsZXN3YXIgUmVkZHkNCj4gU2VudDogV2VkbmVzZGF5LCBKdWx5IDE3LCAyMDE5 IDY6MDYgUE0NCj4gVG86IE1pcmphIEvDvGhsZXdpbmQgPGlldGZAa3VlaGxld2luZC5uZXQ+OyBU aGUgSUVTRyA8aWVzZ0BpZXRmLm9yZz4NCj4gQ2M6IHRyYW0tY2hhaXJzQGlldGYub3JnOyBkcmFm dC1pZXRmLXRyYW0tdHVybmJpc0BpZXRmLm9yZzsgdHJhbUBpZXRmLm9yZzsNCj4gYnJhbmRvbi53 aWxsaWFtc0Bha2FtYWkuY29tDQo+IFN1YmplY3Q6IFJFOiBbdHJhbV0gTWlyamEgS8O8aGxld2lu ZCdzIERpc2N1c3Mgb24gZHJhZnQtaWV0Zi10cmFtLXR1cm5iaXMtMjc6DQo+ICh3aXRoIERJU0NV U1MgYW5kIENPTU1FTlQpDQo+IA0KPiBIaSBNaXJqYSwNCj4gDQo+IEkgaGF2ZSB1cGRhdGVkIHRo ZSBkcmFmdCB0byBhZGRyZXNzIHlvdXIgRGlzY3VzcyBhbmQgY29tbWVudHMgKHNlZQ0KPiBodHRw czovL2dpdGh1Yi5jb20vdGlyZWRkeTIvVFVSTmJpcy9ibG9iL21hc3Rlci9EaWZmJTIwJTIwZHJh ZnQtaWV0Zi0NCj4gdHJhbS10dXJuYmlzLTI3LnR4dCUyMC0lMjBkcmFmdC1pZXRmLXRyYW0tdHVy bmJpcy0yOC5wZGYpLg0KPiBQbGVhc2UgaGF2ZSBhIGxvb2suDQo+IA0KPiBDaGVlcnMsDQo+IC1U aXJ1DQo+IA0KPiA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4gRnJvbTogS29uZGEs IFRpcnVtYWxlc3dhciBSZWRkeQ0KPiA+IFNlbnQ6IE1vbmRheSwgSnVseSAxNSwgMjAxOSAxMjow MSBQTQ0KPiA+IFRvOiBNaXJqYSBLw7xobGV3aW5kIDxpZXRmQGt1ZWhsZXdpbmQubmV0PjsgVGhl IElFU0cgPGllc2dAaWV0Zi5vcmc+DQo+ID4gQ2M6IHRyYW0tY2hhaXJzQGlldGYub3JnOyBkcmFm dC1pZXRmLXRyYW0tdHVybmJpc0BpZXRmLm9yZzsNCj4gPiB0cmFtQGlldGYub3JnOyBicmFuZG9u LndpbGxpYW1zQGFrYW1haS5jb20NCj4gPiBTdWJqZWN0OiBSRTogW3RyYW1dIE1pcmphIEvDvGhs ZXdpbmQncyBEaXNjdXNzIG9uIGRyYWZ0LWlldGYtdHJhbS10dXJuYmlzLTI3Og0KPiA+ICh3aXRo IERJU0NVU1MgYW5kIENPTU1FTlQpDQo+ID4NCj4gPiBIaSBNaXJqYSwNCj4gPg0KPiA+IFRoYW5r cyBmb3IgdGhlIHJldmlldy4gUGxlYXNlIHNlZSBpbmxpbmUNCj4gPg0KPiA+ID4gLS0tLS1Pcmln aW5hbCBNZXNzYWdlLS0tLS0NCj4gPiA+IEZyb206IHRyYW0gPHRyYW0tYm91bmNlc0BpZXRmLm9y Zz4gT24gQmVoYWxmIE9mIE1pcmphIEvDvGhsZXdpbmQgdmlhDQo+ID4gPiBEYXRhdHJhY2tlcg0K PiA+ID4gU2VudDogV2VkbmVzZGF5LCBKdWx5IDEwLCAyMDE5IDk6MjUgUE0NCj4gPiA+IFRvOiBU aGUgSUVTRyA8aWVzZ0BpZXRmLm9yZz4NCj4gPiA+IENjOiB0cmFtLWNoYWlyc0BpZXRmLm9yZzsg ZHJhZnQtaWV0Zi10cmFtLXR1cm5iaXNAaWV0Zi5vcmc7DQo+ID4gPiB0cmFtQGlldGYub3JnOyBi cmFuZG9uLndpbGxpYW1zQGFrYW1haS5jb20NCj4gPiA+IFN1YmplY3Q6IFt0cmFtXSBNaXJqYSBL w7xobGV3aW5kJ3MgRGlzY3VzcyBvbg0KPiA+ID4gZHJhZnQtaWV0Zi10cmFtLXR1cm5iaXMtMjc6 ICh3aXRoIERJU0NVU1MgYW5kIENPTU1FTlQpDQo+ID4gPg0KPiA+ID4gVGhpcyBlbWFpbCBvcmln aW5hdGVkIGZyb20gb3V0c2lkZSBvZiB0aGUgb3JnYW5pemF0aW9uLiBEbyBub3QgY2xpY2sNCj4g PiA+IGxpbmtzIG9yIG9wZW4gYXR0YWNobWVudHMgdW5sZXNzIHlvdSByZWNvZ25pemUgdGhlIHNl bmRlciBhbmQga25vdw0KPiA+ID4gdGhlIGNvbnRlbnQgaXMgc2FmZS4NCj4gPiA+DQo+ID4gPiBN aXJqYSBLw7xobGV3aW5kIGhhcyBlbnRlcmVkIHRoZSBmb2xsb3dpbmcgYmFsbG90IHBvc2l0aW9u IGZvcg0KPiA+ID4gZHJhZnQtaWV0Zi10cmFtLXR1cm5iaXMtMjc6IERpc2N1c3MNCj4gPiA+DQo+ ID4gPiBXaGVuIHJlc3BvbmRpbmcsIHBsZWFzZSBrZWVwIHRoZSBzdWJqZWN0IGxpbmUgaW50YWN0 IGFuZCByZXBseSB0bw0KPiA+ID4gYWxsIGVtYWlsIGFkZHJlc3NlcyBpbmNsdWRlZCBpbiB0aGUg VG8gYW5kIENDIGxpbmVzLiAoRmVlbCBmcmVlIHRvDQo+ID4gPiBjdXQgdGhpcyBpbnRyb2R1Y3Rv cnkgcGFyYWdyYXBoLCBob3dldmVyLikNCj4gPiA+DQo+ID4gPg0KPiA+ID4gUGxlYXNlIHJlZmVy IHRvDQo+ID4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9pZXNnL3N0YXRlbWVudC9kaXNjdXNzLWNy aXRlcmlhLmh0bWwNCj4gPiA+IGZvciBtb3JlIGluZm9ybWF0aW9uIGFib3V0IElFU0cgRElTQ1VT UyBhbmQgQ09NTUVOVCBwb3NpdGlvbnMuDQo+ID4gPg0KPiA+ID4NCj4gPiA+IFRoZSBkb2N1bWVu dCwgYWxvbmcgd2l0aCBvdGhlciBiYWxsb3QgcG9zaXRpb25zLCBjYW4gYmUgZm91bmQgaGVyZToN Cj4gPiA+IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtdHJhbS10 dXJuYmlzLw0KPiA+ID4NCj4gPiA+DQo+ID4gPg0KPiA+ID4gLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gPiA+IC0t DQo+ID4gPiBESVNDVVNTOg0KPiA+ID4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gPiA+IC0tDQo+ID4gPg0KPiA+ ID4gT25lIHF1aWNrIGRpc2N1c3Npb24gd2hpY2ggcHJvYmFibHkgaXMgb25seSBhbiBvdmVyc2ln aHQgYW5kDQo+ID4gPiB0aGVyZWZvcmUgc2hvdWxkIGJlIGVhc3kgZ290IGZpeDoNCj4gPiA+DQo+ ID4gPiBJJ20gYml0IGNvbmZ1c2VkIGFib3V0IHRoZSByZXF1aXJlbWVudCBvbiB1c2luZyBhdXRo ZW50aWNhdGlvbi4gVGhpcw0KPiA+ID4gZHJhZnQgc2F5cyBpbiBzZWN0aW9uIDUgKGFzIFJGQzU3 NjYgZG9lcyk6DQo+ID4gPg0KPiA+ID4gIlRoZSBzZXJ2ZXIgTVVTVCBkZW1hbmQgdGhhdCBhbGwg cmVxdWVzdHMNCj4gPiA+ICAgIGZyb20gdGhlIGNsaWVudCBiZSBhdXRoZW50aWNhdGVkIHVzaW5n IHRoaXMgbWVjaGFuaXNtLCBvciB0aGF0IGENCj4gPiA+ICAgIGVxdWFsbHkgc3Ryb25nIG9yIHN0 cm9uZ2VyIG1lY2hhbmlzbSBmb3IgY2xpZW50IGF1dGhlbnRpY2F0aW9uIGlzDQo+ID4gPiAgICB1 c2VkLiINCj4gPiA+DQo+ID4gPiBIb3dldmVyLCBSRkMgODE1NSB3aGljaCBpcyBldmVuIG5vdyBj aXRlZCBpbiB0aGlzIGRyYWZ0LCB1cGRhdGVzDQo+ID4gPiBSRkM1NzY2IGFuZCByZWxheGVzIHRo aXMgcmVxdWlyZW1lbnQuIExhdGVyIGluIHRoZSBzZWN0aW9uIDcuMi4gdGhpcw0KPiA+ID4gZHJh ZnQNCj4gPiBzYXlzOg0KPiA+ID4NCj4gPiA+ICJUaGUgc2VydmVyIFNIT1VMRCByZXF1aXJlIHRo YXQgdGhlIHJlcXVlc3QgYmUgYXV0aGVudGljYXRlZC4iDQo+ID4gPg0KPiA+ID4gSSBhc3N1bWUg dGhlIHJlcXVpcmVtZW50IGluIHNlY3Rpb24gNSBpcyBhbiBvdmVyc2lnaHQ/DQo+ID4NCj4gPiBZ ZXMsIHJlbW92ZWQgdGhlIHJlcXVpcmVtZW50IGluIFNlY3Rpb24gNS4NCj4gPg0KPiA+ID4NCj4g PiA+IEkgYWxzbyByZWNvbW1lbmQgdG8gb25seSBzcGVjaWZ5IHRoaXMgcmVxdWlyZW1lbnQgbm9y bWF0aXZlbHkgaW4gb25lDQo+IHBsYWNlLg0KPiA+DQo+ID4gRG9uZSwgdXBkYXRlZCBzdGVwIDEg aW4gU2VjdGlvbiA1IHRvIGFkZHJlc3MgdGhlIGNvbW1lbnQgZnJvbSBCZW4gYXMNCj4gPiBmb2xs b3dzOg0KPiA+DQo+ID4gICAgMS4gICBUaGUgVFVSTiBzZXJ2ZXIgcHJvdmlkZWQgYnkgdGhlIGxv Y2FsIG9yIGFjY2VzcyBuZXR3b3JrIE1BWQ0KPiA+ICAgICAgICAgYWxsb3cgdW5hdXRoZW50aWNh dGVkIHJlcXVlc3QgaW4gb3JkZXIgdG8gYWNjZXB0IEFsbG9jYXRpb24NCj4gPiAgICAgICAgIHJl cXVlc3RzIGZyb20gbmV3IGFuZC9vciBndWVzdCB1c2VycyBpbiB0aGUgbmV0d29yayB3aG8gZG8g bm90DQo+ID4gICAgICAgICBuZWNlc3NhcmlseSBwb3NzZXNzIGxvbmcgdGVybSBjcmVkZW50aWFs cyBmb3IgU1RVTg0KPiA+ICAgICAgICAgYXV0aGVudGljYXRpb24gYW5kIGl0cyBzZWN1cml0eSBp bXBsaWNhdGlvbnMgYXJlIGRpc2N1c3NlZCBpbg0KPiA+ICAgICAgICAgW1JGQzgxNTVdLiAgT3Ro ZXJ3aXNlLCB0aGUgc2VydmVyIE1VU1QgcmVxdWlyZSB0aGF0IHRoZSByZXF1ZXN0DQo+ID4gICAg ICAgICBiZSBhdXRoZW50aWNhdGVkLiAgSWYgdGhlIHJlcXVlc3QgaXMgYXV0aGVudGljYXRlZCwg dGhlDQo+ID4gICAgICAgICBhdXRoZW50aWNhdGlvbiBNVVNUIGJlIGRvbmUgZWl0aGVyIHVzaW5n IHRoZSBsb25nLXRlcm0NCj4gPiAgICAgICAgIGNyZWRlbnRpYWwgbWVjaGFuaXNtIG9mIFtJLUQu aWV0Zi10cmFtLXN0dW5iaXNdIG9yIHRoZSBTVFVODQo+ID4gICAgICAgICBFeHRlbnNpb24gZm9y IFRoaXJkLVBhcnR5IEF1dGhvcml6YXRpb24gW1JGQzc2MzVdIHVubGVzcyB0aGUNCj4gPiAgICAg ICAgIGNsaWVudCBhbmQgc2VydmVyIGFncmVlIHRvIHVzZSBhbm90aGVyIG1lY2hhbmlzbSB0aHJv dWdoIHNvbWUNCj4gPiAgICAgICAgIHByb2NlZHVyZSBvdXRzaWRlIHRoZSBzY29wZSBvZiB0aGlz IGRvY3VtZW50Lg0KPiA+DQo+ID4gPg0KPiA+ID4NCj4gPiA+IC0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ID4gPiAt LQ0KPiA+ID4gQ09NTUVOVDoNCj4gPiA+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ID4gPiAtLQ0KPiA+ID4NCj4g PiA+IFNvbWUgb3RoZXIgdGVjaG5pY2FsIGNvbW1lbnRzL3F1ZXN0aW9uczoNCj4gPiA+DQo+ID4g PiAxKSBTZWMgMy43Og0KPiA+ID4gIm9yIHVzZSBVRFAgZnJhZ21lbnRhdGlvbiBbSS1ELmlldGYt dHN2d2ctdWRwLW9wdGlvbnNdLiINCj4gPiA+IEkgYmVsaWV2ZSB0aGUgcG9zc2liaWxpdHkgdG8g dXNlIFVEUCBmcmFnbWVudGF0aW9uIHdhcyBicm91Z2h0IHVwIGJ5DQo+ID4gPiB0aGUgVFNWLUFS VCByZXZpZXcgKFRoYW5rcyBKb2UhKS4gSG93ZXZlciwgSSB3b3VsZCBsaWtlIHRvIG1lbnRpb24N Cj4gPiA+IHRoYXQgdGhpcyBjYW4gb25seSBiZSB1c2VkIGlmIHN1cHBvcnRlZCBieSBib3RoIGVu ZHBvaW50cyBhbmQgdGhhdA0KPiA+ID4gc2hvdWxkIHByb2JhYmx5IGFsc28gYmUgcmVtYXJrZWQg aGVyZS4gVGhlIG5leHQgc2VudGVuY2UgaW4gdGhlDQo+ID4gPiBkcmFmdCBpbmRpY2F0ZWQgdGhp cyBieSBzYXlpbmcgInVudGlsIFVEUCBmcmFnbWVudGF0aW9uIHN1cHBvcnQgaXMNCj4gPiA+IGF2 YWlsYWJsZSIsIGhvd2V2ZXIsIHRoaXMgYWN0dWFsbHkgc2VlbSB0byBiZSBlZGl0b3JpYWxseSBh IGJpdA0KPiA+ID4gbWlzcGxhY2VkIHRoZXJlIGFuZCBjb3VsZCBleHBsYWluIG1vcmUuIFNlZSBh bHNvIHRoaXMgdGV4dCBpbg0KPiA+ID4gZHJhZnQtaWV0Zi10c3Z3Zy11ZHAtb3B0aW9uczoNCj4g PiA+DQo+ID4gPiAiRlJBRyBuZWVkcyB0byBiZSB1c2VkIHdpdGggZXh0cmVtZSBjYXJlIGJlY2F1 c2UgaXQgd2lsbCBwcmVzZW50DQo+ID4gPiAgICBpbmNvcnJlY3QgZGF0YWdyYW0gYm91bmRhcmll cyB0byBhIGxlZ2FjeSByZWNlaXZlciwgdW5sZXNzIGVuY29kZWQNCj4gPiA+ICAgIGFzIExJVEUg ZGF0YSAoc2VlIFNlY3Rpb24gNS44KS4iDQo+ID4gPg0KPiA+ID4gQWxzbyBub3RlIHRoYXQgZHJh ZnQtaWV0Zi10c3Z3Zy11ZHAtb3B0aW9ucyBpcyBzdGlsbCB1bmRlcg0KPiA+ID4gZGV2ZWxvcG1l bnQgYW5kIHdlIGRvbid0IGhhdmUgbXVjaCBkZXBsb3ltZW50IGV4cGVyaWVuY2Ugd2l0aCBpdA0K PiB5ZXQuDQo+ID4NCj4gPiBZZXMsIEpvZSBzdWdnZXN0IHRoZSBhYm92ZSBjaGFuZ2UuIEkgaGF2 ZSBhZGRlZCB0aGUgZm9sbG93aW5nIGxpbmU6DQo+ID4gTm90ZSB0aGF0IHRoZSBVRFAgZnJhZ21l bnRhdGlvbiBvcHRpb24gbmVlZHMgdG8gYmUgc3VwcG9ydGVkIGJ5IGJvdGgNCj4gPiBlbmRwb2lu dHMsIGFuZCBhdCB0aGUgdGltZSBvZiB3cml0aW5nIG9mIHRoaXMgZG9jdW1lbnQsIFVEUA0KPiA+ IGZyYWdtZW50YXRpb24gc3VwcG9ydCBpcyB1bmRlciBkaXNjdXNzaW9uIGFuZCBpcyBub3QgZGVw bG95ZWQuDQo+ID4NCj4gPiA+DQo+ID4gPiBBbmQgZnVydGhlciwgaW4gdGhlIHNhbWUgc2VjdGlv bi4gVGhlcmUgaXMgYWxzbw0KPiA+ID4gZHJhZnQtaWV0Zi10c3Z3Zy1kYXRhZ3JhbS0gcGxwbXR1 ZCBvbiAiUGFja2V0aXphdGlvbiBMYXllciBQYXRoIE1UVQ0KPiA+ID4gRGlzY292ZXJ5IGZvciBE YXRhZ3JhbSBUcmFuc3BvcnRzIi4gUGxlYXNlIGFsc28gYmUgYXdhcmUgdGhhdCB0aGVyZQ0KPiA+ ID4gaXMgYW4gZXh0ZW5zaXZlIFRTVi1BUlQgZm9yIGRyYWZ0LWlldGYtdHJhbS1zdHVuLXBtdHVk LiBCb3RoIG1pZ2h0DQo+ID4gPiBpbXBhY3QgdGhlIGZpbmFsIGNvbnRlbnQgb2YgdGhpcyBzZWN0 aW9uLg0KPiA+DQo+ID4gVGhlIGRyYWZ0IGRvZXMgbm90IHJlZmVyIHRvIGRyYWZ0LWlldGYtdHN2 d2ctZGF0YWdyYW0tIHBscG10dWQuDQo+ID4NCj4gPiA+DQo+ID4gPiAyKSBzZWMgMTEuNToNCj4g PiA+ICJXaGVuIHRoZSBzZXJ2ZXIgcmVjZWl2ZXMgYW4gSUNNUCBwYWNrZXQsIHRoZSBzZXJ2ZXIg dmVyaWZpZXMgdGhhdCB0aGUNCj4gPiA+ICAgIHR5cGUgaXMgZWl0aGVyIDMgb3IgMTEgZm9yIGFu IElDTVB2NCBbUkZDMDc5Ml0gcGFja2V0IG9yIGVpdGhlciAxLCAyLA0KPiA+ID4gICAgb3IgMyBm b3IgYW4gSUNNUHY2IFtSRkM0NDQzXSBwYWNrZXQuIg0KPiA+ID4gUmVzdHJpY3RpbmcgdG8gYSBz ZXQgb2Yga25vd24gdHlwZXMsIGRvZXNuJ3Qgc2VlbSB0byBzdXBwb3J0IGZ1dHVyZQ0KPiA+ID4g ZXh0ZW5zaWJpbGl0eSB2ZXJ5IHdlbGwuLi4NCj4gPg0KPiA+IEdvb2QgcG9pbnQsIGFkZGVkIHRo ZSBmb2xsb3dpbmcgbGluZXM6DQo+ID4gTmV3IElDTVAgdHlwZXMgb3IgY29kZXMgY2FuIGJlIGRl ZmluZWQgaW4gZnV0dXJlIHNwZWNpZmljYXRpb25zLiBJZg0KPiA+IHRoZSBzZXJ2ZXIgcmVjZWl2 ZXMgYW4gSUNNUCBlcnJvciBwYWNrZXQsIGFuZCB0aGUgbmV3IHR5cGUgb3IgY29kZQ0KPiA+IGZp ZWxkIGNhbiBoZWxwIHRoZSBjbGllbnQgdG8gbWFrZSB1c2Ugb2YgdGhlIElDTVAgZXJyb3Igbm90 aWZpY2F0aW9uDQo+ID4gYW5kIGdlbmVyYXRlIGZlZWRiYWNrIHRvIHRoZSBhcHBsaWNhdGlvbiBs YXllciwgdGhlIHNlcnZlciBzZW5kcyB0aGUNCj4gPiBEYXRhIGluZGljYXRpb24gd2l0aCBhbiBJ Q01QIGF0dHJpYnV0ZSBjb252ZXlpbmcgdGhlIG5ldyBJQ01QIHR5cGUgb3INCj4gY29kZS4NCj4g Pg0KPiA+ID4NCj4gPiA+IDMpIHNlYyAxMi41Og0KPiA+ID4gIk92ZXIgVENQIGFuZCBUTFMtb3Zl ci1UQ1AsIHRoZSBDaGFubmVsRGF0YSBtZXNzYWdlIE1VU1QgYmUgcGFkZGVkDQo+ID4gdG8NCj4g PiA+ICAgIGEgbXVsdGlwbGUgb2YgZm91ciBieXRlcyBpbiBvcmRlciB0byBlbnN1cmUgdGhlIGFs aWdubWVudCBvZg0KPiA+ID4gICAgc3Vic2VxdWVudCBtZXNzYWdlcy4iDQo+ID4gPiBOb3QgZXhh Y3RseSBzdXJlIHdoeSB0aGlzIGlzIHVzZWZ1bC4uLj8gSXMgdGhpcyB0byBhbGlnbiB3aXRoIFNU VU4NCj4gPiA+IGFuZCB0aGVyZWZvcmUgbWFrZSBwcm9jZXNzaW5nIHNvbWVob3cgZWFzaWVyPyBJ cyB0aGF0IHJlYWxseSBuZWVkZWQuDQo+ID4gPiBBbmQgZXhjZXB0aW9uIHNob3VsZCBiZSBlYXN5 IHRvIGltcGxlbWVudCBhbmQgc2hvdWxkIHNhdmUgc29tZSBieXRlcw0KPiA+ID4gd2hpY2ggaXMg dGhlIGFzIEkgdW5kZXJzdG9vZCBpdCB0aGUgd2hvbGUgcHVycG9zZSBvZiBjaGFubmVscywgbm8/ DQo+ID4NCj4gPiBUaGlzIGJlaGF2aW9yIGlzIG5vdCBuZXcsIGl0IGlzIGRlZmluZWQgYW5kIGRl cGxveWVkIGluIFRVUk4NCj4gPiBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNTc2NiNz ZWN0aW9uLTExLjUNCj4gPg0KPiA+ID4NCj4gPiA+IDQpIDEyLjY6DQo+ID4gPiAiTm90ZSB0aGF0 IGlmDQo+ID4gPiAgICB0aGUgTGVuZ3RoIGZpZWxkIGluIHRoZSBDaGFubmVsRGF0YSBtZXNzYWdl IGlzIDAsIHRoZW4gdGhlcmUgd2lsbCBiZQ0KPiA+ID4gICAgbm8gZGF0YSBpbiB0aGUgVURQIGRh dGFncmFtLCBidXQgdGhlIFVEUCBkYXRhZ3JhbSBpcyBzdGlsbCBmb3JtZWQgYW5kDQo+ID4gPiAg ICBzZW50LiINCj4gPiA+IENhbiB5b3UgbWF5YmUgYWRkIHNvbWUgbW9yZSB0ZXh0IGFuZCBleHBs YWluIHdoeSB0aGlzIGlzIHVzZWZ1bD8NCj4gPg0KPiA+IFN1cmUsIGFkZGVkIHJlZmVyZW5jZSB0 byBTZWN0aW9uIDQuMSBpbg0KPiA+IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM2MjYz DQo+ID4NCj4gPiA+DQo+ID4gPiA1KSBzZWMgMTU6DQo+ID4gPiBSRkM2ODI0IHdpbGwgc29vbiBi ZSBvYnNvbGV0ZWQgYnkgZHJhZnQtaWV0Zi1tcHRjcC1yZmM2ODI0YmlzIGFuZA0KPiA+ID4gcGxl YXNlIHMvVENQIG11bHRpLXBhdGgvTXVsdGlwYXRoIFRDUC8uDQo+ID4NCj4gPiBUaGFua3MsIHVw ZGF0ZWQuDQo+ID4NCj4gPiA+DQo+ID4gPiA2KSBKdXN0IGEgdGhvdWdodCBsb29raW5nIGF0IHNl Y3Rpb24gMTQgYW5kIDE2OiBJdCBjb3VsZCBoYXZlIGJlZW4NCj4gPiA+IG5pY2UgdG8gcHJvdmlk ZSBhbiBFQ04gZmVlZGJhY2sgZmllbGQgZnJvbSB0aGUgc2VydmVyIHRvIHRoZSBjbGllbnQNCj4g PiA+IGluIGNhc2UgYSBFQ04gbWFya2VkIHBhY2tldCBpcyByZWNlaXZlZCBmcm9tIHRoZSBwZWVy Li4uIGhvd2V2ZXIsIEkNCj4gPiA+IGd1ZXNzIHRoYXQgZnV0dXJlIHdvcmsgYXQgdGhpcyBwb2lu dCBpbiB0aGUgcHJvY2Vzcy4uLg0KPiA+ID4NCj4gPiA+IDcpIHNlYyAxOC4xMzogTWF5YmUgSSBt aXNzZWQgdGhpcyBiZWNhdXNlIEkgcmV2aWV3ZWQgdGhpcyBkb2Mgb3ZlciAzDQo+ID4gPiBkYXlz LCBidXQgaXMgb25seSB0aGUgSUNNUCBBdHRyaWJ1dGUgc2VuZCB0byB0aGUgY2xpZW50IG9yIGlz IHRoZQ0KPiA+ID4gYWN0dWFsIElDTVAgcGFja2V0cyBvciBhcyBtdWNoIGFzIHBvc3NpYmxlIG9m IHRoYXQgcGFja2V0IGluY2x1ZGVzIGFzIHdlbGw/DQo+ID4NCj4gPiBZZXMsIG9ubHkgdGhlIElD TVAgYXR0cmlidXRlIGlzIHNlbnQgdG8gdGhlIGNsaWVudC4NCj4gPg0KPiA+ID4NCj4gPiA+IDgp IHNlYyAyMzoNCj4gPiA+ICJSZXNwb25zZTogVFVSTiB3aWxsIG5vIGxvbmdlciBiZSBuZWVkZWQg b25jZSB0aGVyZSBhcmUgbm8gbG9uZ2VyIGFueQ0KPiA+ID4gICAgTkFUcy4gIFVuZm9ydHVuYXRl bHksIGFzIG9mIHRoZSBkYXRlIG9mIHB1YmxpY2F0aW9uIG9mIHRoaXMgZG9jdW1lbnQsDQo+ID4g PiAgICBpdCBubyBsb25nZXIgc2VlbXMgdmVyeSBsaWtlbHkgdGhhdCBOQVRzIHdpbGwgZ28gYXdh eSBhbnkgdGltZSBzb29uLg0KPiA+ID4gICAgSG93ZXZlciwgdGhlIG5lZWQgZm9yIFRVUk4gd2ls bCBhbHNvIGRlY3JlYXNlIGFzIHRoZSBudW1iZXIgb2YgTkFUcw0KPiA+ID4gICAgd2l0aCB0aGUg bWFwcGluZyBwcm9wZXJ0eSBvZiBFbmRwb2ludC1JbmRlcGVuZGVudCBNYXBwaW5nDQo+IFtSRkM0 Nzg3XQ0KPiA+ID4gICAgaW5jcmVhc2VzLiINCj4gPiA+IFllcy4uLiBzbyB5b3UgZG9uJ3QgdGhp bmsgdGhhdCBJUHY2IHdpbGwgYmUgYW55IGhlbHAgaGVyZT8NCj4gPg0KPiA+IFllcywgSVB2NiB3 aWxsIG5vdCBoZWxwIGluIHNvbWUgc2NlbmFyaW9zLCB1cGRhdGVkIEludHJvZHVjdGlvbiB0byBs aXN0IHRoZW0uDQo+ID4NCj4gPiAgICBJbiBtYW55IGVudGVycHJpc2UgbmV0d29ya3MsIGRpcmVj dCBVRFAgdHJhbnNtaXNzaW9ucyBhcmUgbm90DQo+ID4gICAgcGVybWl0dGVkIGJldHdlZW4gY2xp ZW50cyBvbiB0aGUgaW50ZXJuYWwgbmV0d29ya3MgYW5kIGV4dGVybmFsIElQDQo+ID4gICAgYWRk cmVzc2VzLiAgVG8gcGVybWl0IG1lZGlhIHNlc3Npb25zIGluIHN1Y2ggYSBzaXR1YXRpb24gdG8g dXNlIFVEUA0KPiA+ICAgIGFuZCB0byBhdm9pZCBmb3JjaW5nIHRoZSBtZWRpYSBzZXNzaW9ucyB0 aHJvdWdoIFRDUCwgRW50ZXJwcmlzZQ0KPiA+ICAgIEZpcmV3YWxsIGNhbiBiZSBjb25maWd1cmVk IHRvIGFsbG93IFVEUCB0cmFmZmljIHJlbGF5ZWQgdGhyb3VnaCBhbg0KPiA+ICAgIEVudGVycHJp c2UgcmVsYXkgc2VydmVyLiAgVGhpcyBzY2VuYXJpbyBpcyByZXF1aXJlZCB0byBiZSBzdXBwb3J0 ZWQNCj4gPiAgICBieSB0aGUgV2ViUlRDIHJlcXVpcmVtZW50cyAoU2VjdGlvbiAyLjMuNS4xIGlu IFtSRkM3NDc4XSkuICBJbg0KPiA+ICAgIGFkZGl0aW9uLCBpbiBhIFNJUCBvciBXZWJSVEMgY2Fs bCwgaWYgdGhlIHVzZXIgd2FudHMgSVAgbG9jYXRpb24NCj4gPiAgICBwcml2YWN5IGZyb20gdGhl IHBlZXIgdGhlbiB0aGUgY2xpZW50IGNhbiBzZWxlY3QgYSByZWxheSBzZXJ2ZXINCj4gPiAgICBv ZmZlcmluZyBJUCBsb2NhdGlvbiBwcml2YWN5IGFuZCBvbmx5IGNvbnZleSB0aGUgcmVsYXllZCBj YW5kaWRhdGVzDQo+ID4gICAgdG8gdGhlIHBlZXIgZm9yIElDRSBjb25uZWN0aXZpdHkgY2hlY2tz IChzZWUgU2VjdGlvbiA0LjIuNCBpbg0KPiA+ICAgIFtJLUQuaWV0Zi1ydGN3ZWItc2VjdXJpdHld KS4NCj4gPg0KPiA+ID4NCj4gPiA+IEVkaXRvcmlhbCBjb21tZW50czoNCj4gPiA+DQo+ID4gPiAx KSBTZWMgNjoNCj4gPiA+ICJUaGUgcmVsYXllZCB0cmFuc3BvcnQgYWRkcmVzcyBNVVNUIGJlIHVu aXF1ZSBhY3Jvc3MgYWxsDQo+ID4gPiAgICBhbGxvY2F0aW9ucywgc28gaXQgY2FuIGJlIHVzZWQg dG8gdW5pcXVlbHkgaWRlbnRpZnkgdGhlIGFsbG9jYXRpb24uDQo+ID4gPg0KPiA+ID4gICAgQm90 aCB0aGUgcmVsYXllZCB0cmFuc3BvcnQgYWRkcmVzcyBhbmQgdGhlIDUtdHVwbGUgTVVTVCBiZSB1 bmlxdWUNCj4gPiA+ICAgIGFjcm9zcyBhbGwgYWxsb2NhdGlvbnMsIHNvIGVpdGhlciBvbmUgY2Fu IGJlIHVzZWQgdG8gdW5pcXVlbHkNCj4gPiA+ICAgIGlkZW50aWZ5IHRoZSBhbGxvY2F0aW9uLCBb Li4uXSINCj4gPiA+IFRoZXNlIHR3byBzZW50ZW5jZXMgc2VlbSBxdWl0ZSByZWR1bmRhbnQuIFRo ZSBmaXJzdCBvbmUgd2FzIGFkZGVkIGluDQo+ID4gPiB0aGlzIGRyYWZ0LiBUaGUgc2Vjb25kIG9u ZSB3YXMgYWxyZWFkeSB0aGVyZSBpbiBSRkM1NzY2Lg0KPiA+DQo+ID4gVGhhbmtzLCByZW1vdmVk IHRoZSBzZWNvbmQgc2VudGVuY2UuDQo+ID4NCj4gPiA+DQo+ID4gPiAyKSBzZWMgNy4xOg0KPiA+ ID4gIlNpbmNlIHRoaXMgc3BlY2lmaWNhdGlvbiBvbmx5DQo+ID4gPiAgICBhbGxvd3MgVURQIGJl dHdlZW4gdGhlIHNlcnZlciBhbmQgdGhlIHBlZXJzLCBpdCBpcyBSRUNPTU1FTkRFRA0KPiA+ID4g dGhhdCBbLi4uXSINCj4gPiA+IFdvcmRpbmdzICgib25seSBhbGxvd3MiKSBzZWVtcyB3ZWlyZCB0 byBtZSBnaXZlbiB1c2Ugb2Ygb3RoZXINCj4gPiA+IHByb3Bvc2FscyBpcyBhdCBsZWFzdCB0byBz b21lIGV4dGVuZCBkaXNjdXNzZWQuDQo+ID4NCj4gPiBUaGUgc3BlY2lmaWNhdGlvbiBkb2VzIG5v dCBhbGxvdyBhbnkgb3RoZXIgcHJvdG9jb2wgb3RoZXIgdGhhbiBVRFANCj4gPiBiZXR3ZWVuIHRo ZSBzZXJ2ZXIgYW5kIHBlZXJzIChBcyB5b3Uga25vdywgVURQIGlzIHRoZSBwcmVmZXJyZWQNCj4g PiB0cmFuc3BvcnQgZm9yIG1lZGlhIHN0cmVhbXMpLg0KPiA+DQo+ID4gPg0KPiA+ID4gTml0czoN Cj4gPiA+IHNlYyA3LjEuOiBzL3RoZSBjbGllbnQgcGljayBhIGN1cnJlbnRseSB1bnVzZWQgdHJh bnNwb3J0IGFkZHJlc3MvdGhlDQo+ID4gPiBjbGllbnQgcGlja3MgYSBjdXJyZW50bHkgdW51c2Vk IHRyYW5zcG9ydCBhZGRyZXNzLw0KPiA+DQo+ID4gRml4ZWQuDQo+ID4NCj4gPiBDaGVlcnMsDQo+ ID4gLVRpcnUNCj4gPiA+DQo+ID4gPg0KPiA+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCj4gPiA+IHRyYW0gbWFpbGluZyBsaXN0DQo+ID4gPiB0cmFt QGlldGYub3JnDQo+ID4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Ry YW0NCg== From nobody Fri Jul 26 15:07:17 2019 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 B8F03120181; Fri, 26 Jul 2019 15:07:13 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: =?utf-8?q?Mirja_K=C3=BChlewind_via_Datatracker?= To: "The IESG" Cc: draft-ietf-tram-turnbis@ietf.org, Brandon Williams , tram-chairs@ietf.org, brandon.williams@akamai.com, tram@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.99.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: =?utf-8?q?Mirja_K=C3=BChlewind?= Message-ID: <156417883367.7611.3269428243656056333.idtracker@ietfa.amsl.com> Date: Fri, 26 Jul 2019 15:07:13 -0700 Archived-At: Subject: [tram] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-?= =?utf-8?q?ietf-tram-turnbis-28=3A_=28with_COMMENT=29?= X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.29 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, 26 Jul 2019 22:07:14 -0000 Mirja Kühlewind has entered the following ballot position for draft-ietf-tram-turnbis-28: 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-turnbis/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for addressing my discuss! OLD COMMENTS ---- Some other technical comments/questions: 1) Sec 3.7: "or use UDP fragmentation [I-D.ietf-tsvwg-udp-options]." I believe the possibility to use UDP fragmentation was brought up by the TSV-ART review (Thanks Joe!). However, I would like to mention that this can only be used if supported by both endpoints and that should probably also be remarked here. The next sentence in the draft indicated this by saying "until UDP fragmentation support is available", however, this actually seem to be editorially a bit misplaced there and could explain more. See also this text in draft-ietf-tsvwg-udp-options: "FRAG needs to be used with extreme care because it will present incorrect datagram boundaries to a legacy receiver, unless encoded as LITE data (see Section 5.8)." Also note that draft-ietf-tsvwg-udp-options is still under development and we don't have much deployment experience with it yet. And further, in the same section. There is also draft-ietf-tsvwg-datagram-plpmtud on "Packetization Layer Path MTU Discovery for Datagram Transports". Please also be aware that there is an extensive TSV-ART for draft-ietf-tram-stun-pmtud. Both might impact the final content of this section. 2) sec 11.5: "When the server receives an ICMP packet, the server verifies that the type is either 3 or 11 for an ICMPv4 [RFC0792] packet or either 1, 2, or 3 for an ICMPv6 [RFC4443] packet." Restricting to a set of known types, doesn't seem to support future extensibility very well... 3) sec 12.5: "Over TCP and TLS-over-TCP, the ChannelData message MUST be padded to a multiple of four bytes in order to ensure the alignment of subsequent messages." Not exactly sure why this is useful...? Is this to align with STUN and therefore make processing somehow easier? Is that really needed. And exception should be easy to implement and should save some bytes which is the as I understood it the whole purpose of channels, no? 4) 12.6: "Note that if the Length field in the ChannelData message is 0, then there will be no data in the UDP datagram, but the UDP datagram is still formed and sent." Can you maybe add some more text and explain why this is useful? 5) sec 15: RFC6824 will soon be obsoleted by draft-ietf-mptcp-rfc6824bis and please s/TCP multi-path/Multipath TCP/. 6) Just a thought looking at section 14 and 16: It could have been nice to provide an ECN feedback field from the server to the client in case a ECN marked packet is received from the peer... however, I guess that future work at this point in the process... 7) sec 18.13: Maybe I missed this because I reviewed this doc over 3 days, but is only the ICMP Attribute send to the client or is the actual ICMP packets or as much as possible of that packet includes as well? 8) sec 23: "Response: TURN will no longer be needed once there are no longer any NATs. Unfortunately, as of the date of publication of this document, it no longer seems very likely that NATs will go away any time soon. However, the need for TURN will also decrease as the number of NATs with the mapping property of Endpoint-Independent Mapping [RFC4787] increases." Yes... so you don't think that IPv6 will be any help here? Editorial comments: 1) Sec 6: "The relayed transport address MUST be unique across all allocations, so it can be used to uniquely identify the allocation. Both the relayed transport address and the 5-tuple MUST be unique across all allocations, so either one can be used to uniquely identify the allocation, [...]" These two sentences seem quite redundant. The first one was added in this draft. The second one was already there in RFC5766. 2) sec 7.1: "Since this specification only allows UDP between the server and the peers, it is RECOMMENDED that [...]" Wordings ("only allows") seems weird to me given use of other proposals is at least to some extend discussed. Nits: sec 7.1.: s/the client pick a currently unused transport address/the client picks a currently unused transport address/ From nobody Fri Jul 26 23:13:32 2019 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 5B4C6120020; Fri, 26 Jul 2019 23:13:20 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: tram@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.99.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: tram@ietf.org Message-ID: <156420800026.7607.1187741414158731958@ietfa.amsl.com> Date: Fri, 26 Jul 2019 23:13:20 -0700 Archived-At: Subject: [tram] I-D Action: draft-ietf-tram-turnbis-29.txt X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Jul 2019 06:13:21 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the TURN Revised and Modernized WG of the IETF. Title : Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN) Authors : Tirumaleswar Reddy Alan Johnston Philip Matthews Jonathan Rosenberg Filename : draft-ietf-tram-turnbis-29.txt Pages : 93 Date : 2019-07-26 Abstract: If a host is located behind a NAT, then in certain situations it can be impossible for that host to communicate directly with other hosts (peers). In these situations, it is necessary for the host to use the services of an intermediate node that acts as a communication relay. This specification defines a protocol, called TURN (Traversal Using Relays around NAT), that allows the host to control the operation of the relay and to exchange packets with its peers using the relay. TURN differs from other relay control protocols in that it allows a client to communicate with multiple peers using a single relay address. The TURN protocol was designed to be used as part of the ICE (Interactive Connectivity Establishment) approach to NAT traversal, though it also can be used without ICE. This document obsoletes RFC 5766 and RFC 6156. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tram-turnbis/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-tram-turnbis-29 https://datatracker.ietf.org/doc/html/draft-ietf-tram-turnbis-29 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tram-turnbis-29 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 Fri Jul 26 23:16:56 2019 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 B47861201ED for ; Fri, 26 Jul 2019 23:16:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4 X-Spam-Level: X-Spam-Status: No, score=-4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (public key: not available)" header.d=mcafee.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zYxAGsvjpf9k for ; Fri, 26 Jul 2019 23:16:53 -0700 (PDT) Received: from us-smtp-delivery-210.mimecast.com (us-smtp-delivery-210.mimecast.com [63.128.21.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 70017120020 for ; Fri, 26 Jul 2019 23:16:53 -0700 (PDT) X-NAI-Header: Modified by McAfee Email Gateway (5500) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mcafee.com; s=s_mcafee; t=1564208248; h=ARC-Seal: ARC-Message-Signature:ARC-Authentication-Results: From:To:Subject:Thread-Topic:Thread-Index: Date:Message-ID:References:In-Reply-To:Accept-Language: Content-Language:X-MS-Has-Attach:X-MS-TNEF-Correlator: dlp-product:dlp-version:dlp-reaction:authentication-results: x-originating-ip:x-ms-publictraffictype:x-ms-office365-filtering-correlation-id: x-microsoft-antispam:x-ms-traffictypediagnostic: x-ms-exchange-purlcount:x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers:x-forefront-prvs: x-forefront-antispam-report:received-spf:x-ms-exchange-senderadcheck: x-microsoft-antispam-message-info:Content-Type: Content-Transfer-Encoding:MIME-Version:X-MS-Exchange-CrossTenant-Network-Message-Id: X-MS-Exchange-CrossTenant-originalarrivaltime: X-MS-Exchange-CrossTenant-fromentityheader: X-MS-Exchange-CrossTenant-id:X-MS-Exchange-CrossTenant-mailboxtype: X-MS-Exchange-CrossTenant-userprincipalname: X-MS-Exchange-Transport-CrossTenantHeadersStamped: X-OriginatorOrg:X-NAI-Spam-Flag:X-NAI-Spam-Threshold: X-NAI-Spam-Score:X-NAI-Spam-Version; bh=0 2tryoTCyzJ64BKTJn6SB6DtW+hIKUTMe4UCeDCkMW Q=; b=XqWn3kT6+X5lAOFnx81ZuJdlU/mwXpMgsf9VTRl/PYdv FwwrQSp4Y/fjUWDSdZzjBFwlvzNE6vOfwxYI6DlDtJMvMXrwH8 Z1xVxgEZfCp9HB7QobKhrzl/LbOnO0ax4HkRHfK15PYr3WY2gX x1PS79nb3rFZTpJDPfD/BNCE2a8= Received: from MIVWSMAILOUT1.mcafee.com (mivwsmailout1.mcafee.com [161.69.47.167]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-226-GTLCVzDMOQSsCWfNsJjx2w-1; Sat, 27 Jul 2019 02:16:48 -0400 Received: from DNVEXAPP1N06.corpzone.internalzone.com (DNVEXAPP1N06.corpzone.internalzone.com [10.44.48.90]) by MIVWSMAILOUT1.mcafee.com with smtp (TLS: TLSv1/SSLv3,256bits,ECDHE-RSA-AES256-SHA384) id 1b24_c6a0_2e4d5630_95a2_426c_bbd1_5cf7076ca98f; Sat, 27 Jul 2019 02:17:27 -0400 Received: from DNVEXAPP1N05.corpzone.internalzone.com (10.44.48.89) by DNVEXAPP1N06.corpzone.internalzone.com (10.44.48.90) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Sat, 27 Jul 2019 00:16:35 -0600 Received: from DNVO365EDGE1.corpzone.internalzone.com (10.44.176.66) by DNVEXAPP1N05.corpzone.internalzone.com (10.44.48.89) with Microsoft SMTP Server (TLS) id 15.0.1395.4 via Frontend Transport; Sat, 27 Jul 2019 00:16:36 -0600 Received: from NAM02-BL2-obe.outbound.protection.outlook.com (10.44.176.243) by edge.mcafee.com (10.44.176.66) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Sat, 27 Jul 2019 00:16:35 -0600 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=hUj5tI3dtbJkugsuGivTqGp+wOV6vgpXUfcpICpJbs/6BUheCKLJyH8EjRdjmFH0N/fp2+bUQP8SkoxcZ0ryiO4gbQ43Gexb2hXzz/iFFqKPuWcBs3fJlYTP8m67X8gs3Nm2Tt/oic2bt7z3r+NlbPTnhqplCocVpdsgCVXkp3OcQvgLYxNLzzC/mywBaULIGASWkRDusvIQwyDMFVAh6jT1CKJhpYbzGDI4Y7FCkOcGiV0EFkVnj8VkI8c79qLxcSAz957Oxrz3olxqaKwg9KCgir/EbYY26KhHNi1akKMn2lIzJ3uWA6BWGl9sLFtSf8wAYQZvwHWjsg3FjFY4wA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=02tryoTCyzJ64BKTJn6SB6DtW+hIKUTMe4UCeDCkMWQ=; b=YTr1GolzRMNXPIxmNbX8Wkj2XzOXdVG0OqHeALRH5DSUdXsSBcCUsSEaQTi5GdU86RyfakFyRoI5Jv3KRXp4RZuzrbQsF9XgoFBIAM3PHigbq/FmzgItpxGuywyIDB+ba5ZrdRfzgLl797Usr67z3/6C+f4l52Eu4HgQiBuvH4Dk5oPhO+NUiXa0dyGu+1kPqttq6Q4g3o556ex/aEWFlrsyxwwP2Hjm8+yU2VmoNY7Bwg9xrrghXJxv+2JLiDIP41S2YMn3lgtygfuBOZUgQbuKwQNxMn3V8nrlRbncKvU5gYBhf6cum34oo+VXTuCOKr/b3vJ+h44TysvCShExcQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1;spf=pass smtp.mailfrom=mcafee.com;dmarc=pass action=none header.from=mcafee.com;dkim=pass header.d=mcafee.com;arc=none Received: from DM5PR16MB1705.namprd16.prod.outlook.com (10.172.44.147) by DM5PR16MB2373.namprd16.prod.outlook.com (52.132.142.164) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2094.17; Sat, 27 Jul 2019 06:16:33 +0000 Received: from DM5PR16MB1705.namprd16.prod.outlook.com ([fe80::6c22:21e:7528:3dc5]) by DM5PR16MB1705.namprd16.prod.outlook.com ([fe80::6c22:21e:7528:3dc5%6]) with mapi id 15.20.2115.005; Sat, 27 Jul 2019 06:16:33 +0000 From: "Konda, Tirumaleswar Reddy" To: "tram@ietf.org" Thread-Topic: [tram] I-D Action: draft-ietf-tram-turnbis-29.txt Thread-Index: AQHVREKQdS/a0zwFdUip61ZaiJrx/qbd/PTg Date: Sat, 27 Jul 2019 06:16:33 +0000 Message-ID: References: <156420800026.7607.1187741414158731958@ietfa.amsl.com> In-Reply-To: <156420800026.7607.1187741414158731958@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.3.0.17 dlp-reaction: no-action x-originating-ip: [49.37.200.50] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 93943927-3342-481f-cc53-08d71259f8e1 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:DM5PR16MB2373; x-ms-traffictypediagnostic: DM5PR16MB2373: x-ms-exchange-purlcount: 5 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:7219; x-forefront-prvs: 01110342A5 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(346002)(136003)(376002)(366004)(199004)(189003)(13464003)(32952001)(5024004)(1730700003)(81156014)(256004)(11346002)(305945005)(6116002)(33656002)(74316002)(26005)(71190400001)(86362001)(68736007)(71200400001)(81166006)(53546011)(14454004)(446003)(8676002)(3846002)(2501003)(66066001)(9686003)(66446008)(186003)(6506007)(55016002)(229853002)(2351001)(5660300002)(966005)(5640700003)(66556008)(66574012)(8936002)(2906002)(7736002)(66476007)(6306002)(102836004)(64756008)(6436002)(508600001)(52536014)(7696005)(6246003)(25786009)(76176011)(76116006)(53936002)(486006)(6916009)(476003)(99286004)(80792005)(66946007)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR16MB2373; H:DM5PR16MB1705.namprd16.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: wW3R93LMC2P0yRUsGnjnIqM2hWXrOOtcm2uGAY6eUcFzpl5OfPMk7xaz051wccw1aWf4HIwu4osRfkh6qaVR/i1WLnxdaeooUHA+22/58LNkJ9isn13YaWgIHa1TVAu7ck98yjb1SQalS6gcvrbWBJZJABb0ISAToXAS0PCOT0uWjvCv0/R2XlZI+7eyXdn1chb0Yo7AlzX19pUJUBeOsZp1gFDHky5rIEMiyPik+jdGg4vn9VD/3e8433ycnMt0js8LZtMtzpXn5mBZJ9aZ+w3iNcNIs9wXkOcOCews3fMl4k61lQgXnzMeQf+29a3HGJ1uei1sDJRy00Ye0rQUdZuFcFvxSdqIDYTmbFUiHzz5NqATJvxbZ9UeQaxlSZFccsQBI/bzftiyX9ABopaGY2loVVcpGDdQoWBTOiBhCZs= MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 93943927-3342-481f-cc53-08d71259f8e1 X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Jul 2019 06:16:33.1129 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: TirumaleswarReddy_Konda@McAfee.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR16MB2373 X-OriginatorOrg: mcafee.com X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 15 X-NAI-Spam-Score: 0 X-NAI-Spam-Version: 2.3.0.9418 : core <6599> : inlines <7127> : streams <1828545> : uri <2873459> X-MC-Unique: GTLCVzDMOQSsCWfNsJjx2w-1 X-Mimecast-Spam-Score: 0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [tram] I-D Action: draft-ietf-tram-turnbis-29.txt X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Jul 2019 06:16:56 -0000 This revision https://tools.ietf.org/html/draft-ietf-tram-turnbis-29 addres= ses comments from Brandon. Cheers, -Tiru > -----Original Message----- > From: tram On Behalf Of internet-drafts@ietf.org > Sent: Saturday, July 27, 2019 11:43 AM > To: i-d-announce@ietf.org > Cc: tram@ietf.org > Subject: [tram] I-D Action: draft-ietf-tram-turnbis-29.txt >=20 > This email originated from outside of the organization. Do not click link= s or > open attachments unless you recognize the sender and know the content is > safe. >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the TURN Revised and Modernized WG of the > IETF. >=20 > Title : Traversal Using Relays around NAT (TURN): Relay= Extensions > to Session Traversal Utilities for NAT (STUN) > Authors : Tirumaleswar Reddy > Alan Johnston > Philip Matthews > Jonathan Rosenberg > =09Filename : draft-ietf-tram-turnbis-29.txt > =09Pages : 93 > =09Date : 2019-07-26 >=20 > Abstract: > If a host is located behind a NAT, then in certain situations it can > be impossible for that host to communicate directly with other hosts > (peers). In these situations, it is necessary for the host to use > the services of an intermediate node that acts as a communication > relay. This specification defines a protocol, called TURN (Traversal > Using Relays around NAT), that allows the host to control the > operation of the relay and to exchange packets with its peers using > the relay. TURN differs from other relay control protocols in that > it allows a client to communicate with multiple peers using a single > relay address. >=20 > The TURN protocol was designed to be used as part of the ICE > (Interactive Connectivity Establishment) approach to NAT traversal, > though it also can be used without ICE. >=20 > This document obsoletes RFC 5766 and RFC 6156. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-tram-turnbis/ >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-tram-turnbis-29 > https://datatracker.ietf.org/doc/html/draft-ietf-tram-turnbis-29 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tram-turnbis-29 >=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 Sat Jul 27 00:07:32 2019 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 A906B120121; Sat, 27 Jul 2019 00:07:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=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 oqevK8vSa2lh; Sat, 27 Jul 2019 00:07:27 -0700 (PDT) Received: from wp513.webpack.hosteurope.de (wp513.webpack.hosteurope.de [IPv6:2a01:488:42:1000:50ed:8223::]) (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 04C5A120106; Sat, 27 Jul 2019 00:07:27 -0700 (PDT) Received: from [46.183.103.8] (helo=[172.18.209.92]); authenticated by wp513.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1hrGnV-00057U-VY; Sat, 27 Jul 2019 09:07:20 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Mirja Kuehlewind In-Reply-To: Date: Sat, 27 Jul 2019 03:07:11 -0400 Cc: The IESG , "tram-chairs@ietf.org" , "draft-ietf-tram-turnbis@ietf.org" , "tram@ietf.org" , "brandon.williams@akamai.com" Content-Transfer-Encoding: quoted-printable Message-Id: <54A55B10-F74D-4D55-9CC9-B2FB31F1E26A@kuehlewind.net> References: <156277411459.15353.13243689830942672102.idtracker@ietfa.amsl.com> To: "Konda, Tirumaleswar Reddy" X-Mailer: Apple Mail (2.3445.104.11) X-bounce-key: webpack.hosteurope.de;ietf@kuehlewind.net;1564211247;92726c58; X-HE-SMSGID: 1hrGnV-00057U-VY Archived-At: Subject: Re: [tram] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf-?= =?utf-8?q?tram-turnbis-27=3A_=28with_DISCUSS_and_COMMENT=29?= X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Jul 2019 07:07:31 -0000 Hi Tiru, Thanks for your quick reply and update and sorry for my delay! I=E2=80=99v= e just cleared my discuss but see two quick comments in line below. > On 15. Jul 2019, at 02:31, Konda, Tirumaleswar Reddy = wrote: >=20 > Hi Mirja, >=20 > Thanks for the review. Please see inline >=20 >> -----Original Message----- >> From: tram On Behalf Of Mirja K=C3=BChlewind = via >> Datatracker >> Sent: Wednesday, July 10, 2019 9:25 PM >> To: The IESG >> Cc: tram-chairs@ietf.org; draft-ietf-tram-turnbis@ietf.org; = tram@ietf.org; >> brandon.williams@akamai.com >> Subject: [tram] Mirja K=C3=BChlewind's Discuss on = draft-ietf-tram-turnbis-27: (with >> DISCUSS and COMMENT) >>=20 >> This email originated from outside of the organization. Do not click = links or >> open attachments unless you recognize the sender and know the content = is >> safe. >>=20 >> Mirja K=C3=BChlewind has entered the following ballot position for >> draft-ietf-tram-turnbis-27: Discuss >>=20 >> 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.) >>=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-turnbis/ >>=20 >>=20 >>=20 >> = ---------------------------------------------------------------------- >> DISCUSS: >> = ---------------------------------------------------------------------- >>=20 >> One quick discussion which probably is only an oversight and = therefore >> should be easy got fix: >>=20 >> I'm bit confused about the requirement on using authentication. This = draft >> says in section 5 (as RFC5766 does): >>=20 >> "The server MUST demand that all requests >> from the client be authenticated using this mechanism, or that a >> equally strong or stronger mechanism for client authentication is >> used." >>=20 >> However, RFC 8155 which is even now cited in this draft, updates = RFC5766 >> and relaxes this requirement. Later in the section 7.2. this draft = says: >>=20 >> "The server SHOULD require that the request be authenticated." >>=20 >> I assume the requirement in section 5 is an oversight? >=20 > Yes, removed the requirement in Section 5. >=20 >>=20 >> I also recommend to only specify this requirement normatively in one = place. >=20 > Done, updated step 1 in Section 5 to address the comment from Ben as = follows: >=20 > 1. The TURN server provided by the local or access network MAY > allow unauthenticated request in order to accept Allocation > requests from new and/or guest users in the network who do not > necessarily possess long term credentials for STUN > authentication and its security implications are discussed in > [RFC8155]. Otherwise, the server MUST require that the request > be authenticated. If the request is authenticated, the > authentication MUST be done either using the long-term > credential mechanism of [I-D.ietf-tram-stunbis] or the STUN > Extension for Third-Party Authorization [RFC7635] unless the > client and server agree to use another mechanism through some > procedure outside the scope of this document. >=20 >>=20 >>=20 >> = ---------------------------------------------------------------------- >> COMMENT: >> = ---------------------------------------------------------------------- >>=20 >> Some other technical comments/questions: >>=20 >> 1) Sec 3.7: >> "or use UDP fragmentation [I-D.ietf-tsvwg-udp-options]." >> I believe the possibility to use UDP fragmentation was brought up by = the >> TSV-ART review (Thanks Joe!). However, I would like to mention that = this can >> only be used if supported by both endpoints and that should probably = also >> be remarked here. The next sentence in the draft indicated this by = saying >> "until UDP fragmentation support is available", however, this = actually seem >> to be editorially a bit misplaced there and could explain more. See = also this >> text in >> draft-ietf-tsvwg-udp-options: >>=20 >> "FRAG needs to be used with extreme care because it will present >> incorrect datagram boundaries to a legacy receiver, unless encoded >> as LITE data (see Section 5.8)." >>=20 >> Also note that draft-ietf-tsvwg-udp-options is still under = development and >> we don't have much deployment experience with it yet. >=20 > Yes, Joe suggest the above change. I have added the following line: > Note that the UDP fragmentation option needs to be supported by both = endpoints, and at the time of writing of this document, UDP = fragmentation support is under discussion and is not deployed. >=20 >>=20 >> And further, in the same section. There is also = draft-ietf-tsvwg-datagram- >> plpmtud on "Packetization Layer Path MTU Discovery for Datagram >> Transports". Please also be aware that there is an extensive TSV-ART = for >> draft-ietf-tram-stun-pmtud. Both might impact the final content of = this >> section. >=20 > The draft does not refer to draft-ietf-tsvwg-datagram- plpmtud.=20 Yes, but I though you maybe should cite it as well :-) >=20 >>=20 >> 2) sec 11.5: >> "When the server receives an ICMP packet, the server verifies that = the >> type is either 3 or 11 for an ICMPv4 [RFC0792] packet or either 1, = 2, >> or 3 for an ICMPv6 [RFC4443] packet." >> Restricting to a set of known types, doesn't seem to support future >> extensibility very well... >=20 > Good point, added the following lines: > New ICMP types or codes can be defined in future specifications. If = the server receives an ICMP error packet, and the new type or code field = can help the client to make use of the ICMP error notification and = generate feedback to the application layer, the server sends the Data = indication with an ICMP attribute conveying the new ICMP type or code. >=20 >>=20 >> 3) sec 12.5: >> "Over TCP and TLS-over-TCP, the ChannelData message MUST be padded to >> a multiple of four bytes in order to ensure the alignment of >> subsequent messages." >> Not exactly sure why this is useful...? Is this to align with STUN = and therefore >> make processing somehow easier? Is that really needed. And exception >> should be easy to implement and should save some bytes which is the = as I >> understood it the whole purpose of channels, no? >=20 > This behavior is not new, it is defined and deployed in TURN = https://tools.ietf.org/html/rfc5766#section-11.5=20 >=20 >>=20 >> 4) 12.6: >> "Note that if >> the Length field in the ChannelData message is 0, then there will be >> no data in the UDP datagram, but the UDP datagram is still formed = and >> sent." >> Can you maybe add some more text and explain why this is useful? >=20 > Sure, added reference to Section 4.1 in = https://tools.ietf.org/html/rfc6263=20 >=20 >>=20 >> 5) sec 15: >> RFC6824 will soon be obsoleted by draft-ietf-mptcp-rfc6824bis and = please >> s/TCP multi-path/Multipath TCP/. >=20 > Thanks, updated. >=20 >>=20 >> 6) Just a thought looking at section 14 and 16: It could have been = nice to >> provide an ECN feedback field from the server to the client in case a = ECN >> marked packet is received from the peer... however, I guess that = future >> work at this point in the process... >>=20 >> 7) sec 18.13: Maybe I missed this because I reviewed this doc over 3 = days, but >> is only the ICMP Attribute send to the client or is the actual ICMP = packets or >> as much as possible of that packet includes as well? >=20 > Yes, only the ICMP attribute is sent to the client. Here also, I can imagine that sending as much of the ICMP packet as = possible could be useful as well. Was that considered? Mirja >=20 >>=20 >> 8) sec 23: >> "Response: TURN will no longer be needed once there are no longer any >> NATs. Unfortunately, as of the date of publication of this = document, >> it no longer seems very likely that NATs will go away any time soon. >> However, the need for TURN will also decrease as the number of NATs >> with the mapping property of Endpoint-Independent Mapping [RFC4787] >> increases." >> Yes... so you don't think that IPv6 will be any help here? >=20 > Yes, IPv6 will not help in some scenarios, updated Introduction to = list them. >=20 > In many enterprise networks, direct UDP transmissions are not > permitted between clients on the internal networks and external IP > addresses. To permit media sessions in such a situation to use UDP > and to avoid forcing the media sessions through TCP, Enterprise > Firewall can be configured to allow UDP traffic relayed through an > Enterprise relay server. This scenario is required to be supported > by the WebRTC requirements (Section 2.3.5.1 in [RFC7478]). In > addition, in a SIP or WebRTC call, if the user wants IP location > privacy from the peer then the client can select a relay server > offering IP location privacy and only convey the relayed candidates > to the peer for ICE connectivity checks (see Section 4.2.4 in > [I-D.ietf-rtcweb-security]).=20 >=20 >>=20 >> Editorial comments: >>=20 >> 1) Sec 6: >> "The relayed transport address MUST be unique across all >> allocations, so it can be used to uniquely identify the allocation. >>=20 >> Both the relayed transport address and the 5-tuple MUST be unique >> across all allocations, so either one can be used to uniquely >> identify the allocation, [...]" >> These two sentences seem quite redundant. The first one was added in = this >> draft. The second one was already there in RFC5766. >=20 > Thanks, removed the second sentence.=20 >=20 >>=20 >> 2) sec 7.1: >> "Since this specification only >> allows UDP between the server and the peers, it is RECOMMENDED that >> [...]" >> Wordings ("only allows") seems weird to me given use of other = proposals is >> at least to some extend discussed. >=20 > The specification does not allow any other protocol other than UDP = between the server and peers (As you know, UDP is the preferred = transport for media streams). >=20 >>=20 >> Nits: >> sec 7.1.: s/the client pick a currently unused transport address/the = client >> picks a currently unused transport address/ >=20 > Fixed. >=20 > Cheers, > -Tiru >>=20 >>=20 >> _______________________________________________ >> tram mailing list >> tram@ietf.org >> https://www.ietf.org/mailman/listinfo/tram From nobody Sat Jul 27 08:14:18 2019 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 7048612001B for ; Sat, 27 Jul 2019 08:14:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4 X-Spam-Level: X-Spam-Status: No, score=-4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (public key: not available)" header.d=mcafee.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 31KjCGd_dNBM for ; Sat, 27 Jul 2019 08:14:13 -0700 (PDT) Received: from us-smtp-delivery-210.mimecast.com (us-smtp-delivery-210.mimecast.com [63.128.21.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 69E2612001A for ; Sat, 27 Jul 2019 08:14:13 -0700 (PDT) X-NAI-Header: Modified by McAfee Email Gateway (5500) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mcafee.com; s=s_mcafee; t=1564240424; h=ARC-Seal: ARC-Message-Signature:ARC-Authentication-Results: From:To:CC:Subject:Thread-Topic:Thread-Index: Date:Message-ID:References:In-Reply-To:Accept-Language: Content-Language:X-MS-Has-Attach:X-MS-TNEF-Correlator: dlp-product:dlp-version:dlp-reaction:authentication-results: x-originating-ip:x-ms-publictraffictype:x-ms-office365-filtering-correlation-id: x-microsoft-antispam:x-ms-traffictypediagnostic: x-ms-exchange-purlcount:x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers:x-forefront-prvs: x-forefront-antispam-report:received-spf:x-ms-exchange-senderadcheck: x-microsoft-antispam-message-info:Content-Type: Content-Transfer-Encoding:MIME-Version:X-MS-Exchange-CrossTenant-Network-Message-Id: X-MS-Exchange-CrossTenant-originalarrivaltime: X-MS-Exchange-CrossTenant-fromentityheader: X-MS-Exchange-CrossTenant-id:X-MS-Exchange-CrossTenant-mailboxtype: X-MS-Exchange-CrossTenant-userprincipalname: X-MS-Exchange-Transport-CrossTenantHeadersStamped: X-OriginatorOrg:X-NAI-Spam-Flag:X-NAI-Spam-Level: X-NAI-Spam-Threshold:X-NAI-Spam-Score:X-NAI-Spam-Version; bh=xdSPZMWOJH6ZMqIhPaa2504mJ+UR6K9CG1ZRg6 ORDFw=; b=rN+8XSFdtSULTC0lbU1K8mVWOHIiogS0+BRJM9or mor4hIgxNQwCVQH7cJ0UTprpkfohcZBAeEUWw+IhB75AoIOgWm BeTGrDp9wAncA4mT2pk28F27q31zaGCbOS1Cakp2wFVRY/AYH2 eUH0h+IYd2n3KXPhF5mg46aMt7a4gKI= Received: from MIVWSMAILOUT1.mcafee.com (mivwsmailout1.mcafee.com [161.69.47.167]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-81-tki46S4GOgKwDeAG_jJcwg-1; Sat, 27 Jul 2019 11:13:05 -0400 Received: from DNVEXAPP1N05.corpzone.internalzone.com (DNVEXAPP1N05.corpzone.internalzone.com [10.44.48.89]) by MIVWSMAILOUT1.mcafee.com with smtp (TLS: TLSv1/SSLv3,256bits,ECDHE-RSA-AES256-SHA384) id 0c28_5388_acca985b_bbda_4fb3_9e33_586c876278f0; Sat, 27 Jul 2019 11:13:43 -0400 Received: from DNVEXAPP1N05.corpzone.internalzone.com (10.44.48.89) by DNVEXAPP1N05.corpzone.internalzone.com (10.44.48.89) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Sat, 27 Jul 2019 09:13:00 -0600 Received: from DNVO365EDGE1.corpzone.internalzone.com (10.44.176.66) by DNVEXAPP1N05.corpzone.internalzone.com (10.44.48.89) with Microsoft SMTP Server (TLS) id 15.0.1395.4 via Frontend Transport; Sat, 27 Jul 2019 09:13:00 -0600 Received: from NAM02-CY1-obe.outbound.protection.outlook.com (10.44.176.243) by edge.mcafee.com (10.44.176.66) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Sat, 27 Jul 2019 09:12:58 -0600 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=GRfrwasAeiASq8k81TdWFE6YM7mq8pOzyBcUexEyQeVI6AFnCHanfHuR935EIU9rCEfCZ9jf5/Pe7tEOPKNidALWN3d6h6kV6MNArNCG+qnxRydhxpvS9kW0nnHLY5i5yv+dXve67WHEfNRfwI/Jr2dTYGLq7yNik5NR/uZkUWuSfaJLcCjkRjU3UZ7DJX+1dati6LBEnOOEBka2iYAWH8/ZNNy7usqlMbq761/zcmWJ2eAKb5SKyOfr9a5Jp34mdPBHhpnRXt98su3Eg9Bp8nelb6OT6chVQN/oHySOHsH4pGIiezRYFXwrKqIv4MTcOAdZ5JWqCPhLNepqhjk04g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=xdSPZMWOJH6ZMqIhPaa2504mJ+UR6K9CG1ZRg6ORDFw=; b=QFI2zrcU5PurostWOOgkcVAQpl/6hcVhl6Jr2dvdcwpshz+1GN/cJDL8X75GjfKWreOSXxcXKeYOSs6Gaemeb+GQR5qsCdbw4EzYfd/IkLDF9mmaPiQUDGEUP7Cwb3BLXq/s8Q9OeVI7pFSLAV9gx7y+AfQanMiDxMUMKgDwWbE4UHQpr3kRv/tuVwgOs67L7+FHI7RFb7l1kyT2EVbUnAubHoXKBneNFJ9/HebWOQpYLXfFUGSGOUgw4gPHmOYg2s4oCUc5dvHigzv8B/QyRw94PmsIk+7+9j5UfOn/PP5J43vRkoGTXGumeo2Q3kxM7mx1WWk/U2SDepsLLPcy7Q== ARC-Authentication-Results: i=1; mx.microsoft.com 1;spf=pass smtp.mailfrom=mcafee.com;dmarc=pass action=none header.from=mcafee.com;dkim=pass header.d=mcafee.com;arc=none Received: from DM5PR16MB1705.namprd16.prod.outlook.com (10.172.44.147) by DM5PR16MB2245.namprd16.prod.outlook.com (52.132.142.34) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2094.17; Sat, 27 Jul 2019 15:12:58 +0000 Received: from DM5PR16MB1705.namprd16.prod.outlook.com ([fe80::6c22:21e:7528:3dc5]) by DM5PR16MB1705.namprd16.prod.outlook.com ([fe80::6c22:21e:7528:3dc5%6]) with mapi id 15.20.2115.005; Sat, 27 Jul 2019 15:12:58 +0000 From: "Konda, Tirumaleswar Reddy" To: Mirja Kuehlewind CC: The IESG , "tram-chairs@ietf.org" , "draft-ietf-tram-turnbis@ietf.org" , "tram@ietf.org" , "brandon.williams@akamai.com" Thread-Topic: =?utf-8?B?W3RyYW1dIE1pcmphIEvDvGhsZXdpbmQncyBEaXNjdXNzIG9uIGRyYWZ0LWll?= =?utf-8?Q?tf-tram-turnbis-27:_(with_DISCUSS_and_COMMENT)?= Thread-Index: AQHVNzftWkN2G8olS0aOBDqJ1prLPKbG+S0ggBcsNYCAAIPT0A== Date: Sat, 27 Jul 2019 15:12:58 +0000 Message-ID: References: <156277411459.15353.13243689830942672102.idtracker@ietfa.amsl.com> <54A55B10-F74D-4D55-9CC9-B2FB31F1E26A@kuehlewind.net> In-Reply-To: <54A55B10-F74D-4D55-9CC9-B2FB31F1E26A@kuehlewind.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.3.0.17 dlp-reaction: no-action x-originating-ip: [185.221.69.46] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: f1882376-ec66-4c9c-679b-08d712a4e8bf x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:DM5PR16MB2245; x-ms-traffictypediagnostic: DM5PR16MB2245: x-ms-exchange-purlcount: 6 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 01110342A5 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(39860400002)(396003)(376002)(366004)(346002)(136003)(76094002)(32952001)(51914003)(199004)(13464003)(189003)(102836004)(4326008)(229853002)(71190400001)(6916009)(99286004)(14454004)(186003)(74316002)(64756008)(66574012)(11346002)(66556008)(66476007)(316002)(14444005)(66946007)(26005)(446003)(81166006)(6246003)(86362001)(76116006)(7736002)(5660300002)(256004)(5024004)(71200400001)(52536014)(81156014)(53936002)(54906003)(9686003)(3846002)(2906002)(486006)(6306002)(80792005)(66066001)(8936002)(6436002)(966005)(33656002)(224303003)(6506007)(25786009)(478600001)(76176011)(53546011)(305945005)(66446008)(30864003)(55016002)(476003)(7696005)(68736007)(6116002)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR16MB2245; H:DM5PR16MB1705.namprd16.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: rtXFJNPVils3Vr4WWsEQgisTE6mdtbjnpWtIxz73CLCGBcAbWOCcVILzJMswb8EoeSGLEGhV3w6F4klq/ULkODOVJ361AuT7TKIDPwOm7sxMaDz38h0Z6fVZViM/YTOXtonfV5EFDFs7HLkucGbgCFavHSD0mcMojrqvfB8swl8+eCbI053hqgbGvjpd7U1GY26BLStKjAFoDtinU9H8j0AqSUvZDqWdIXMiQnBnnnM/16IjEXl/IHMQEbNk4lj7jkRs6bjXQBCHCYjiLvh9YEnKoFiPoEL29S5UbVdwZyvyZ68ZfGk9FhGv3I1Xsaui8232FQJ8hlLdg3ryynT21ABt6MVhjLfvZ/OAzt25Es1rLTP+0K+xwWCaaVhXubgGO971Y0MB6O+9wOPZm7F9+PjEn7BSpYuyP8ziIrrK6YY= MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: f1882376-ec66-4c9c-679b-08d712a4e8bf X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Jul 2019 15:12:58.3247 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: TirumaleswarReddy_Konda@McAfee.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR16MB2245 X-OriginatorOrg: mcafee.com X-NAI-Spam-Flag: NO X-NAI-Spam-Level: X-NAI-Spam-Threshold: 15 X-NAI-Spam-Score: 0.2 X-NAI-Spam-Version: 2.3.0.9418 : core <6599> : inlines <7127> : streams <1828580> : uri <2873664> X-MC-Unique: tki46S4GOgKwDeAG_jJcwg-1 X-Mimecast-Spam-Score: 0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Archived-At: Subject: Re: [tram] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf-?= =?utf-8?q?tram-turnbis-27=3A_=28with_DISCUSS_and_COMMENT=29?= X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Jul 2019 15:14:17 -0000 SGkgTWlyamEsDQoNClBsZWFzZSBzZWUgaW5saW5lDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdl LS0tLS0NCj4gRnJvbTogTWlyamEgS3VlaGxld2luZCA8aWV0ZkBrdWVobGV3aW5kLm5ldD4NCj4g U2VudDogU2F0dXJkYXksIEp1bHkgMjcsIDIwMTkgMTI6MzcgUE0NCj4gVG86IEtvbmRhLCBUaXJ1 bWFsZXN3YXIgUmVkZHkgPFRpcnVtYWxlc3dhclJlZGR5X0tvbmRhQE1jQWZlZS5jb20+DQo+IENj OiBUaGUgSUVTRyA8aWVzZ0BpZXRmLm9yZz47IHRyYW0tY2hhaXJzQGlldGYub3JnOyBkcmFmdC1p ZXRmLXRyYW0tDQo+IHR1cm5iaXNAaWV0Zi5vcmc7IHRyYW1AaWV0Zi5vcmc7IGJyYW5kb24ud2ls bGlhbXNAYWthbWFpLmNvbQ0KPiBTdWJqZWN0OiBSZTogW3RyYW1dIE1pcmphIEvDvGhsZXdpbmQn cyBEaXNjdXNzIG9uIGRyYWZ0LWlldGYtdHJhbS10dXJuYmlzLTI3Og0KPiAod2l0aCBESVNDVVNT IGFuZCBDT01NRU5UKQ0KPiANCj4gVGhpcyBlbWFpbCBvcmlnaW5hdGVkIGZyb20gb3V0c2lkZSBv ZiB0aGUgb3JnYW5pemF0aW9uLiBEbyBub3QgY2xpY2sgbGlua3Mgb3INCj4gb3BlbiBhdHRhY2ht ZW50cyB1bmxlc3MgeW91IHJlY29nbml6ZSB0aGUgc2VuZGVyIGFuZCBrbm93IHRoZSBjb250ZW50 IGlzDQo+IHNhZmUuDQo+IA0KPiBIaSBUaXJ1LA0KPiANCj4gVGhhbmtzIGZvciB5b3VyIHF1aWNr IHJlcGx5IGFuZCB1cGRhdGUgYW5kIHNvcnJ5IGZvciBteSBkZWxheSEgSeKAmXZlIGp1c3QNCj4g Y2xlYXJlZCBteSBkaXNjdXNzIGJ1dCBzZWUgdHdvIHF1aWNrIGNvbW1lbnRzIGluIGxpbmUgYmVs b3cuDQo+IA0KPiA+IE9uIDE1LiBKdWwgMjAxOSwgYXQgMDI6MzEsIEtvbmRhLCBUaXJ1bWFsZXN3 YXIgUmVkZHkNCj4gPFRpcnVtYWxlc3dhclJlZGR5X0tvbmRhQE1jQWZlZS5jb20+IHdyb3RlOg0K PiA+DQo+ID4gSGkgTWlyamEsDQo+ID4NCj4gPiBUaGFua3MgZm9yIHRoZSByZXZpZXcuIFBsZWFz ZSBzZWUgaW5saW5lDQo+ID4NCj4gPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPj4g RnJvbTogdHJhbSA8dHJhbS1ib3VuY2VzQGlldGYub3JnPiBPbiBCZWhhbGYgT2YgTWlyamEgS8O8 aGxld2luZCB2aWENCj4gPj4gRGF0YXRyYWNrZXINCj4gPj4gU2VudDogV2VkbmVzZGF5LCBKdWx5 IDEwLCAyMDE5IDk6MjUgUE0NCj4gPj4gVG86IFRoZSBJRVNHIDxpZXNnQGlldGYub3JnPg0KPiA+ PiBDYzogdHJhbS1jaGFpcnNAaWV0Zi5vcmc7IGRyYWZ0LWlldGYtdHJhbS10dXJuYmlzQGlldGYu b3JnOw0KPiA+PiB0cmFtQGlldGYub3JnOyBicmFuZG9uLndpbGxpYW1zQGFrYW1haS5jb20NCj4g Pj4gU3ViamVjdDogW3RyYW1dIE1pcmphIEvDvGhsZXdpbmQncyBEaXNjdXNzIG9uDQo+ID4+IGRy YWZ0LWlldGYtdHJhbS10dXJuYmlzLTI3OiAod2l0aCBESVNDVVNTIGFuZCBDT01NRU5UKQ0KPiA+ Pg0KPiA+PiBUaGlzIGVtYWlsIG9yaWdpbmF0ZWQgZnJvbSBvdXRzaWRlIG9mIHRoZSBvcmdhbml6 YXRpb24uIERvIG5vdCBjbGljaw0KPiA+PiBsaW5rcyBvciBvcGVuIGF0dGFjaG1lbnRzIHVubGVz cyB5b3UgcmVjb2duaXplIHRoZSBzZW5kZXIgYW5kIGtub3cNCj4gPj4gdGhlIGNvbnRlbnQgaXMg c2FmZS4NCj4gPj4NCj4gPj4gTWlyamEgS8O8aGxld2luZCBoYXMgZW50ZXJlZCB0aGUgZm9sbG93 aW5nIGJhbGxvdCBwb3NpdGlvbiBmb3INCj4gPj4gZHJhZnQtaWV0Zi10cmFtLXR1cm5iaXMtMjc6 IERpc2N1c3MNCj4gPj4NCj4gPj4gV2hlbiByZXNwb25kaW5nLCBwbGVhc2Uga2VlcCB0aGUgc3Vi amVjdCBsaW5lIGludGFjdCBhbmQgcmVwbHkgdG8gYWxsDQo+ID4+IGVtYWlsIGFkZHJlc3NlcyBp bmNsdWRlZCBpbiB0aGUgVG8gYW5kIENDIGxpbmVzLiAoRmVlbCBmcmVlIHRvIGN1dA0KPiA+PiB0 aGlzIGludHJvZHVjdG9yeSBwYXJhZ3JhcGgsIGhvd2V2ZXIuKQ0KPiA+Pg0KPiA+Pg0KPiA+PiBQ bGVhc2UgcmVmZXIgdG8NCj4gPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaWVzZy9zdGF0ZW1lbnQv ZGlzY3Vzcy1jcml0ZXJpYS5odG1sDQo+ID4+IGZvciBtb3JlIGluZm9ybWF0aW9uIGFib3V0IElF U0cgRElTQ1VTUyBhbmQgQ09NTUVOVCBwb3NpdGlvbnMuDQo+ID4+DQo+ID4+DQo+ID4+IFRoZSBk b2N1bWVudCwgYWxvbmcgd2l0aCBvdGhlciBiYWxsb3QgcG9zaXRpb25zLCBjYW4gYmUgZm91bmQg aGVyZToNCj4gPj4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi10 cmFtLXR1cm5iaXMvDQo+ID4+DQo+ID4+DQo+ID4+DQo+ID4+IC0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiA+PiAt DQo+ID4+IERJU0NVU1M6DQo+ID4+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiA+PiAtDQo+ID4+DQo+ID4+IE9u ZSBxdWljayBkaXNjdXNzaW9uIHdoaWNoIHByb2JhYmx5IGlzIG9ubHkgYW4gb3ZlcnNpZ2h0IGFu ZA0KPiA+PiB0aGVyZWZvcmUgc2hvdWxkIGJlIGVhc3kgZ290IGZpeDoNCj4gPj4NCj4gPj4gSSdt IGJpdCBjb25mdXNlZCBhYm91dCB0aGUgcmVxdWlyZW1lbnQgb24gdXNpbmcgYXV0aGVudGljYXRp b24uIFRoaXMNCj4gPj4gZHJhZnQgc2F5cyBpbiBzZWN0aW9uIDUgKGFzIFJGQzU3NjYgZG9lcyk6 DQo+ID4+DQo+ID4+ICJUaGUgc2VydmVyIE1VU1QgZGVtYW5kIHRoYXQgYWxsIHJlcXVlc3RzICBm cm9tIHRoZSBjbGllbnQgYmUNCj4gPj4gYXV0aGVudGljYXRlZCB1c2luZyB0aGlzIG1lY2hhbmlz bSwgb3IgdGhhdCBhICBlcXVhbGx5IHN0cm9uZyBvcg0KPiA+PiBzdHJvbmdlciBtZWNoYW5pc20g Zm9yIGNsaWVudCBhdXRoZW50aWNhdGlvbiBpcyAgdXNlZC4iDQo+ID4+DQo+ID4+IEhvd2V2ZXIs IFJGQyA4MTU1IHdoaWNoIGlzIGV2ZW4gbm93IGNpdGVkIGluIHRoaXMgZHJhZnQsIHVwZGF0ZXMN Cj4gPj4gUkZDNTc2NiBhbmQgcmVsYXhlcyB0aGlzIHJlcXVpcmVtZW50LiBMYXRlciBpbiB0aGUg c2VjdGlvbiA3LjIuIHRoaXMgZHJhZnQNCj4gc2F5czoNCj4gPj4NCj4gPj4gIlRoZSBzZXJ2ZXIg U0hPVUxEIHJlcXVpcmUgdGhhdCB0aGUgcmVxdWVzdCBiZSBhdXRoZW50aWNhdGVkLiINCj4gPj4N Cj4gPj4gSSBhc3N1bWUgdGhlIHJlcXVpcmVtZW50IGluIHNlY3Rpb24gNSBpcyBhbiBvdmVyc2ln aHQ/DQo+ID4NCj4gPiBZZXMsIHJlbW92ZWQgdGhlIHJlcXVpcmVtZW50IGluIFNlY3Rpb24gNS4N Cj4gPg0KPiA+Pg0KPiA+PiBJIGFsc28gcmVjb21tZW5kIHRvIG9ubHkgc3BlY2lmeSB0aGlzIHJl cXVpcmVtZW50IG5vcm1hdGl2ZWx5IGluIG9uZQ0KPiBwbGFjZS4NCj4gPg0KPiA+IERvbmUsIHVw ZGF0ZWQgc3RlcCAxIGluIFNlY3Rpb24gNSB0byBhZGRyZXNzIHRoZSBjb21tZW50IGZyb20gQmVu IGFzDQo+IGZvbGxvd3M6DQo+ID4NCj4gPiAgMS4gICBUaGUgVFVSTiBzZXJ2ZXIgcHJvdmlkZWQg YnkgdGhlIGxvY2FsIG9yIGFjY2VzcyBuZXR3b3JrIE1BWQ0KPiA+ICAgICAgIGFsbG93IHVuYXV0 aGVudGljYXRlZCByZXF1ZXN0IGluIG9yZGVyIHRvIGFjY2VwdCBBbGxvY2F0aW9uDQo+ID4gICAg ICAgcmVxdWVzdHMgZnJvbSBuZXcgYW5kL29yIGd1ZXN0IHVzZXJzIGluIHRoZSBuZXR3b3JrIHdo byBkbyBub3QNCj4gPiAgICAgICBuZWNlc3NhcmlseSBwb3NzZXNzIGxvbmcgdGVybSBjcmVkZW50 aWFscyBmb3IgU1RVTg0KPiA+ICAgICAgIGF1dGhlbnRpY2F0aW9uIGFuZCBpdHMgc2VjdXJpdHkg aW1wbGljYXRpb25zIGFyZSBkaXNjdXNzZWQgaW4NCj4gPiAgICAgICBbUkZDODE1NV0uICBPdGhl cndpc2UsIHRoZSBzZXJ2ZXIgTVVTVCByZXF1aXJlIHRoYXQgdGhlIHJlcXVlc3QNCj4gPiAgICAg ICBiZSBhdXRoZW50aWNhdGVkLiAgSWYgdGhlIHJlcXVlc3QgaXMgYXV0aGVudGljYXRlZCwgdGhl DQo+ID4gICAgICAgYXV0aGVudGljYXRpb24gTVVTVCBiZSBkb25lIGVpdGhlciB1c2luZyB0aGUg bG9uZy10ZXJtDQo+ID4gICAgICAgY3JlZGVudGlhbCBtZWNoYW5pc20gb2YgW0ktRC5pZXRmLXRy YW0tc3R1bmJpc10gb3IgdGhlIFNUVU4NCj4gPiAgICAgICBFeHRlbnNpb24gZm9yIFRoaXJkLVBh cnR5IEF1dGhvcml6YXRpb24gW1JGQzc2MzVdIHVubGVzcyB0aGUNCj4gPiAgICAgICBjbGllbnQg YW5kIHNlcnZlciBhZ3JlZSB0byB1c2UgYW5vdGhlciBtZWNoYW5pc20gdGhyb3VnaCBzb21lDQo+ ID4gICAgICAgcHJvY2VkdXJlIG91dHNpZGUgdGhlIHNjb3BlIG9mIHRoaXMgZG9jdW1lbnQuDQo+ ID4NCj4gPj4NCj4gPj4NCj4gPj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ID4+IC0NCj4gPj4gQ09NTUVOVDoN Cj4gPj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tDQo+ID4+IC0NCj4gPj4NCj4gPj4gU29tZSBvdGhlciB0ZWNobmlj YWwgY29tbWVudHMvcXVlc3Rpb25zOg0KPiA+Pg0KPiA+PiAxKSBTZWMgMy43Og0KPiA+PiAib3Ig dXNlIFVEUCBmcmFnbWVudGF0aW9uIFtJLUQuaWV0Zi10c3Z3Zy11ZHAtb3B0aW9uc10uIg0KPiA+ PiBJIGJlbGlldmUgdGhlIHBvc3NpYmlsaXR5IHRvIHVzZSBVRFAgZnJhZ21lbnRhdGlvbiB3YXMg YnJvdWdodCB1cCBieQ0KPiA+PiB0aGUgVFNWLUFSVCByZXZpZXcgKFRoYW5rcyBKb2UhKS4gSG93 ZXZlciwgSSB3b3VsZCBsaWtlIHRvIG1lbnRpb24NCj4gPj4gdGhhdCB0aGlzIGNhbiBvbmx5IGJl IHVzZWQgaWYgc3VwcG9ydGVkIGJ5IGJvdGggZW5kcG9pbnRzIGFuZCB0aGF0DQo+ID4+IHNob3Vs ZCBwcm9iYWJseSBhbHNvIGJlIHJlbWFya2VkIGhlcmUuIFRoZSBuZXh0IHNlbnRlbmNlIGluIHRo ZSBkcmFmdA0KPiA+PiBpbmRpY2F0ZWQgdGhpcyBieSBzYXlpbmcgInVudGlsIFVEUCBmcmFnbWVu dGF0aW9uIHN1cHBvcnQgaXMNCj4gPj4gYXZhaWxhYmxlIiwgaG93ZXZlciwgdGhpcyBhY3R1YWxs eSBzZWVtIHRvIGJlIGVkaXRvcmlhbGx5IGEgYml0DQo+ID4+IG1pc3BsYWNlZCB0aGVyZSBhbmQg Y291bGQgZXhwbGFpbiBtb3JlLiBTZWUgYWxzbyB0aGlzIHRleHQgaW4NCj4gPj4gZHJhZnQtaWV0 Zi10c3Z3Zy11ZHAtb3B0aW9uczoNCj4gPj4NCj4gPj4gIkZSQUcgbmVlZHMgdG8gYmUgdXNlZCB3 aXRoIGV4dHJlbWUgY2FyZSBiZWNhdXNlIGl0IHdpbGwgcHJlc2VudA0KPiA+PiBpbmNvcnJlY3Qg ZGF0YWdyYW0gYm91bmRhcmllcyB0byBhIGxlZ2FjeSByZWNlaXZlciwgdW5sZXNzIGVuY29kZWQN Cj4gPj4gYXMgTElURSBkYXRhIChzZWUgU2VjdGlvbiA1LjgpLiINCj4gPj4NCj4gPj4gQWxzbyBu b3RlIHRoYXQgZHJhZnQtaWV0Zi10c3Z3Zy11ZHAtb3B0aW9ucyBpcyBzdGlsbCB1bmRlcg0KPiA+ PiBkZXZlbG9wbWVudCBhbmQgd2UgZG9uJ3QgaGF2ZSBtdWNoIGRlcGxveW1lbnQgZXhwZXJpZW5j ZSB3aXRoIGl0IHlldC4NCj4gPg0KPiA+IFllcywgSm9lIHN1Z2dlc3QgdGhlIGFib3ZlIGNoYW5n ZS4gSSBoYXZlIGFkZGVkIHRoZSBmb2xsb3dpbmcgbGluZToNCj4gPiBOb3RlIHRoYXQgdGhlIFVE UCBmcmFnbWVudGF0aW9uIG9wdGlvbiBuZWVkcyB0byBiZSBzdXBwb3J0ZWQgYnkgYm90aA0KPiBl bmRwb2ludHMsIGFuZCBhdCB0aGUgdGltZSBvZiB3cml0aW5nIG9mIHRoaXMgZG9jdW1lbnQsIFVE UCBmcmFnbWVudGF0aW9uDQo+IHN1cHBvcnQgaXMgdW5kZXIgZGlzY3Vzc2lvbiBhbmQgaXMgbm90 IGRlcGxveWVkLg0KPiA+DQo+ID4+DQo+ID4+IEFuZCBmdXJ0aGVyLCBpbiB0aGUgc2FtZSBzZWN0 aW9uLiBUaGVyZSBpcyBhbHNvDQo+ID4+IGRyYWZ0LWlldGYtdHN2d2ctZGF0YWdyYW0tIHBscG10 dWQgb24gIlBhY2tldGl6YXRpb24gTGF5ZXIgUGF0aCBNVFUNCj4gPj4gRGlzY292ZXJ5IGZvciBE YXRhZ3JhbSBUcmFuc3BvcnRzIi4gUGxlYXNlIGFsc28gYmUgYXdhcmUgdGhhdCB0aGVyZQ0KPiA+ PiBpcyBhbiBleHRlbnNpdmUgVFNWLUFSVCBmb3IgZHJhZnQtaWV0Zi10cmFtLXN0dW4tcG10dWQu IEJvdGggbWlnaHQNCj4gPj4gaW1wYWN0IHRoZSBmaW5hbCBjb250ZW50IG9mIHRoaXMgc2VjdGlv bi4NCj4gPg0KPiA+IFRoZSBkcmFmdCBkb2VzIG5vdCByZWZlciB0byBkcmFmdC1pZXRmLXRzdndn LWRhdGFncmFtLSBwbHBtdHVkLg0KPiANCj4gWWVzLCBidXQgSSB0aG91Z2ggeW91IG1heWJlIHNo b3VsZCBjaXRlIGl0IGFzIHdlbGwgOi0pDQoNClN1cmUsIHVwZGF0ZWQgdGV4dCBhcyBmb2xsb3dz Og0KVGhlIFBhY2tldGl6ZWQgUGF0aCAgTVRVIERpc2NvdmVyeSBhbGdvcml0aG0gZGVmaW5lZCBp biBbUkZDNDgyMV0gaXMgb25lIHN1Y2ggYWxnb3JpdGhtIGFuZCBhIHNldCBvZiBhbGdvcml0aG1z IGFyZSBkZWZpbmVkIGluIFtJLUQuaWV0Zi10c3Z3Zy1kYXRhZ3JhbS1wbHBtdHVkXS4NCg0KPiAN Cj4gPg0KPiA+Pg0KPiA+PiAyKSBzZWMgMTEuNToNCj4gPj4gIldoZW4gdGhlIHNlcnZlciByZWNl aXZlcyBhbiBJQ01QIHBhY2tldCwgdGhlIHNlcnZlciB2ZXJpZmllcyB0aGF0DQo+ID4+IHRoZSAg dHlwZSBpcyBlaXRoZXIgMyBvciAxMSBmb3IgYW4gSUNNUHY0IFtSRkMwNzkyXSBwYWNrZXQgb3Ig ZWl0aGVyDQo+ID4+IDEsIDIsICBvciAzIGZvciBhbiBJQ01QdjYgW1JGQzQ0NDNdIHBhY2tldC4i DQo+ID4+IFJlc3RyaWN0aW5nIHRvIGEgc2V0IG9mIGtub3duIHR5cGVzLCBkb2Vzbid0IHNlZW0g dG8gc3VwcG9ydCBmdXR1cmUNCj4gPj4gZXh0ZW5zaWJpbGl0eSB2ZXJ5IHdlbGwuLi4NCj4gPg0K PiA+IEdvb2QgcG9pbnQsIGFkZGVkIHRoZSBmb2xsb3dpbmcgbGluZXM6DQo+ID4gTmV3IElDTVAg dHlwZXMgb3IgY29kZXMgY2FuIGJlIGRlZmluZWQgaW4gZnV0dXJlIHNwZWNpZmljYXRpb25zLiBJ ZiB0aGUNCj4gc2VydmVyIHJlY2VpdmVzIGFuIElDTVAgZXJyb3IgcGFja2V0LCBhbmQgdGhlIG5l dyB0eXBlIG9yIGNvZGUgZmllbGQgY2FuDQo+IGhlbHAgdGhlIGNsaWVudCB0byBtYWtlIHVzZSBv ZiB0aGUgSUNNUCBlcnJvciBub3RpZmljYXRpb24gYW5kIGdlbmVyYXRlDQo+IGZlZWRiYWNrIHRv IHRoZSBhcHBsaWNhdGlvbiBsYXllciwgdGhlIHNlcnZlciBzZW5kcyB0aGUgRGF0YSBpbmRpY2F0 aW9uIHdpdGgNCj4gYW4gSUNNUCBhdHRyaWJ1dGUgY29udmV5aW5nIHRoZSBuZXcgSUNNUCB0eXBl IG9yIGNvZGUuDQo+ID4NCj4gPj4NCj4gPj4gMykgc2VjIDEyLjU6DQo+ID4+ICJPdmVyIFRDUCBh bmQgVExTLW92ZXItVENQLCB0aGUgQ2hhbm5lbERhdGEgbWVzc2FnZSBNVVNUIGJlIHBhZGRlZA0K PiB0bw0KPiA+PiBhIG11bHRpcGxlIG9mIGZvdXIgYnl0ZXMgaW4gb3JkZXIgdG8gZW5zdXJlIHRo ZSBhbGlnbm1lbnQgb2YNCj4gPj4gc3Vic2VxdWVudCBtZXNzYWdlcy4iDQo+ID4+IE5vdCBleGFj dGx5IHN1cmUgd2h5IHRoaXMgaXMgdXNlZnVsLi4uPyBJcyB0aGlzIHRvIGFsaWduIHdpdGggU1RV Tg0KPiA+PiBhbmQgdGhlcmVmb3JlIG1ha2UgcHJvY2Vzc2luZyBzb21laG93IGVhc2llcj8gSXMg dGhhdCByZWFsbHkgbmVlZGVkLg0KPiA+PiBBbmQgZXhjZXB0aW9uIHNob3VsZCBiZSBlYXN5IHRv IGltcGxlbWVudCBhbmQgc2hvdWxkIHNhdmUgc29tZSBieXRlcw0KPiA+PiB3aGljaCBpcyB0aGUg YXMgSSB1bmRlcnN0b29kIGl0IHRoZSB3aG9sZSBwdXJwb3NlIG9mIGNoYW5uZWxzLCBubz8NCj4g Pg0KPiA+IFRoaXMgYmVoYXZpb3IgaXMgbm90IG5ldywgaXQgaXMgZGVmaW5lZCBhbmQgZGVwbG95 ZWQgaW4gVFVSTg0KPiA+IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM1NzY2I3NlY3Rp b24tMTEuNQ0KPiA+DQo+ID4+DQo+ID4+IDQpIDEyLjY6DQo+ID4+ICJOb3RlIHRoYXQgaWYNCj4g Pj4gIHRoZSBMZW5ndGggZmllbGQgaW4gdGhlIENoYW5uZWxEYXRhIG1lc3NhZ2UgaXMgMCwgdGhl biB0aGVyZSB3aWxsIGJlDQo+ID4+IG5vIGRhdGEgaW4gdGhlIFVEUCBkYXRhZ3JhbSwgYnV0IHRo ZSBVRFAgZGF0YWdyYW0gaXMgc3RpbGwgZm9ybWVkIGFuZA0KPiA+PiBzZW50LiINCj4gPj4gQ2Fu IHlvdSBtYXliZSBhZGQgc29tZSBtb3JlIHRleHQgYW5kIGV4cGxhaW4gd2h5IHRoaXMgaXMgdXNl ZnVsPw0KPiA+DQo+ID4gU3VyZSwgYWRkZWQgcmVmZXJlbmNlIHRvIFNlY3Rpb24gNC4xIGluDQo+ ID4gaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzYyNjMNCj4gPg0KPiA+Pg0KPiA+PiA1 KSBzZWMgMTU6DQo+ID4+IFJGQzY4MjQgd2lsbCBzb29uIGJlIG9ic29sZXRlZCBieSBkcmFmdC1p ZXRmLW1wdGNwLXJmYzY4MjRiaXMgYW5kDQo+ID4+IHBsZWFzZSBzL1RDUCBtdWx0aS1wYXRoL011 bHRpcGF0aCBUQ1AvLg0KPiA+DQo+ID4gVGhhbmtzLCB1cGRhdGVkLg0KPiA+DQo+ID4+DQo+ID4+ IDYpIEp1c3QgYSB0aG91Z2h0IGxvb2tpbmcgYXQgc2VjdGlvbiAxNCBhbmQgMTY6IEl0IGNvdWxk IGhhdmUgYmVlbg0KPiA+PiBuaWNlIHRvIHByb3ZpZGUgYW4gRUNOIGZlZWRiYWNrIGZpZWxkIGZy b20gdGhlIHNlcnZlciB0byB0aGUgY2xpZW50DQo+ID4+IGluIGNhc2UgYSBFQ04gbWFya2VkIHBh Y2tldCBpcyByZWNlaXZlZCBmcm9tIHRoZSBwZWVyLi4uIGhvd2V2ZXIsIEkNCj4gPj4gZ3Vlc3Mg dGhhdCBmdXR1cmUgd29yayBhdCB0aGlzIHBvaW50IGluIHRoZSBwcm9jZXNzLi4uDQo+ID4+DQo+ ID4+IDcpIHNlYyAxOC4xMzogTWF5YmUgSSBtaXNzZWQgdGhpcyBiZWNhdXNlIEkgcmV2aWV3ZWQg dGhpcyBkb2Mgb3ZlciAzDQo+ID4+IGRheXMsIGJ1dCBpcyBvbmx5IHRoZSBJQ01QIEF0dHJpYnV0 ZSBzZW5kIHRvIHRoZSBjbGllbnQgb3IgaXMgdGhlDQo+ID4+IGFjdHVhbCBJQ01QIHBhY2tldHMg b3IgYXMgbXVjaCBhcyBwb3NzaWJsZSBvZiB0aGF0IHBhY2tldCBpbmNsdWRlcyBhcyB3ZWxsPw0K PiA+DQo+ID4gWWVzLCBvbmx5IHRoZSBJQ01QIGF0dHJpYnV0ZSBpcyBzZW50IHRvIHRoZSBjbGll bnQuDQo+IA0KPiBIZXJlIGFsc28sIEkgY2FuIGltYWdpbmUgdGhhdCBzZW5kaW5nIGFzIG11Y2gg b2YgdGhlIElDTVAgcGFja2V0IGFzIHBvc3NpYmxlDQo+IGNvdWxkIGJlIHVzZWZ1bCBhcyB3ZWxs LiBXYXMgdGhhdCBjb25zaWRlcmVkPw0KDQpZZXMsIHRoZSBkZWNpc2lvbiB3YXMgbm90IHNlbmQg dGhlIElDTVAgcGFja2V0IChQbGVhc2Ugc2VlIGh0dHBzOi8vbWFpbGFyY2hpdmUuaWV0Zi5vcmcv YXJjaC9tc2cvdHJhbS9kazVQelZoQnp6Q1VTQWZ0WVZvU3BZUWwwbzQpIA0KDQpDaGVlcnMsDQot VGlydQ0KDQoNCj4gDQo+IE1pcmphDQo+IA0KPiANCj4gPg0KPiA+Pg0KPiA+PiA4KSBzZWMgMjM6 DQo+ID4+ICJSZXNwb25zZTogVFVSTiB3aWxsIG5vIGxvbmdlciBiZSBuZWVkZWQgb25jZSB0aGVy ZSBhcmUgbm8gbG9uZ2VyIGFueQ0KPiA+PiBOQVRzLiAgVW5mb3J0dW5hdGVseSwgYXMgb2YgdGhl IGRhdGUgb2YgcHVibGljYXRpb24gb2YgdGhpcyBkb2N1bWVudCwNCj4gPj4gaXQgbm8gbG9uZ2Vy IHNlZW1zIHZlcnkgbGlrZWx5IHRoYXQgTkFUcyB3aWxsIGdvIGF3YXkgYW55IHRpbWUgc29vbi4N Cj4gPj4gIEhvd2V2ZXIsIHRoZSBuZWVkIGZvciBUVVJOIHdpbGwgYWxzbyBkZWNyZWFzZSBhcyB0 aGUgbnVtYmVyIG9mIE5BVHMNCj4gPj4gd2l0aCB0aGUgbWFwcGluZyBwcm9wZXJ0eSBvZiBFbmRw b2ludC1JbmRlcGVuZGVudCBNYXBwaW5nIFtSRkM0Nzg3XQ0KPiA+PiBpbmNyZWFzZXMuIg0KPiA+ PiBZZXMuLi4gc28geW91IGRvbid0IHRoaW5rIHRoYXQgSVB2NiB3aWxsIGJlIGFueSBoZWxwIGhl cmU/DQo+ID4NCj4gPiBZZXMsIElQdjYgd2lsbCBub3QgaGVscCBpbiBzb21lIHNjZW5hcmlvcywg dXBkYXRlZCBJbnRyb2R1Y3Rpb24gdG8gbGlzdCB0aGVtLg0KPiA+DQo+ID4gIEluIG1hbnkgZW50 ZXJwcmlzZSBuZXR3b3JrcywgZGlyZWN0IFVEUCB0cmFuc21pc3Npb25zIGFyZSBub3QNCj4gPiBw ZXJtaXR0ZWQgYmV0d2VlbiBjbGllbnRzIG9uIHRoZSBpbnRlcm5hbCBuZXR3b3JrcyBhbmQgZXh0 ZXJuYWwgSVANCj4gPiBhZGRyZXNzZXMuICBUbyBwZXJtaXQgbWVkaWEgc2Vzc2lvbnMgaW4gc3Vj aCBhIHNpdHVhdGlvbiB0byB1c2UgVURQDQo+ID4gYW5kIHRvIGF2b2lkIGZvcmNpbmcgdGhlIG1l ZGlhIHNlc3Npb25zIHRocm91Z2ggVENQLCBFbnRlcnByaXNlDQo+ID4gRmlyZXdhbGwgY2FuIGJl IGNvbmZpZ3VyZWQgdG8gYWxsb3cgVURQIHRyYWZmaWMgcmVsYXllZCB0aHJvdWdoIGFuDQo+ID4g RW50ZXJwcmlzZSByZWxheSBzZXJ2ZXIuICBUaGlzIHNjZW5hcmlvIGlzIHJlcXVpcmVkIHRvIGJl IHN1cHBvcnRlZA0KPiA+IGJ5IHRoZSBXZWJSVEMgcmVxdWlyZW1lbnRzIChTZWN0aW9uIDIuMy41 LjEgaW4gW1JGQzc0NzhdKS4gIEluDQo+ID4gYWRkaXRpb24sIGluIGEgU0lQIG9yIFdlYlJUQyBj YWxsLCBpZiB0aGUgdXNlciB3YW50cyBJUCBsb2NhdGlvbg0KPiA+IHByaXZhY3kgZnJvbSB0aGUg cGVlciB0aGVuIHRoZSBjbGllbnQgY2FuIHNlbGVjdCBhIHJlbGF5IHNlcnZlcg0KPiA+IG9mZmVy aW5nIElQIGxvY2F0aW9uIHByaXZhY3kgYW5kIG9ubHkgY29udmV5IHRoZSByZWxheWVkIGNhbmRp ZGF0ZXMNCj4gPiB0byB0aGUgcGVlciBmb3IgSUNFIGNvbm5lY3Rpdml0eSBjaGVja3MgKHNlZSBT ZWN0aW9uIDQuMi40IGluDQo+ID4gW0ktRC5pZXRmLXJ0Y3dlYi1zZWN1cml0eV0pLg0KPiA+DQo+ ID4+DQo+ID4+IEVkaXRvcmlhbCBjb21tZW50czoNCj4gPj4NCj4gPj4gMSkgU2VjIDY6DQo+ID4+ ICJUaGUgcmVsYXllZCB0cmFuc3BvcnQgYWRkcmVzcyBNVVNUIGJlIHVuaXF1ZSBhY3Jvc3MgYWxs DQo+ID4+IGFsbG9jYXRpb25zLCBzbyBpdCBjYW4gYmUgdXNlZCB0byB1bmlxdWVseSBpZGVudGlm eSB0aGUgYWxsb2NhdGlvbi4NCj4gPj4NCj4gPj4gIEJvdGggdGhlIHJlbGF5ZWQgdHJhbnNwb3J0 IGFkZHJlc3MgYW5kIHRoZSA1LXR1cGxlIE1VU1QgYmUgdW5pcXVlDQo+ID4+IGFjcm9zcyBhbGwg YWxsb2NhdGlvbnMsIHNvIGVpdGhlciBvbmUgY2FuIGJlIHVzZWQgdG8gdW5pcXVlbHkNCj4gPj4g aWRlbnRpZnkgdGhlIGFsbG9jYXRpb24sIFsuLi5dIg0KPiA+PiBUaGVzZSB0d28gc2VudGVuY2Vz IHNlZW0gcXVpdGUgcmVkdW5kYW50LiBUaGUgZmlyc3Qgb25lIHdhcyBhZGRlZCBpbg0KPiA+PiB0 aGlzIGRyYWZ0LiBUaGUgc2Vjb25kIG9uZSB3YXMgYWxyZWFkeSB0aGVyZSBpbiBSRkM1NzY2Lg0K PiA+DQo+ID4gVGhhbmtzLCByZW1vdmVkIHRoZSBzZWNvbmQgc2VudGVuY2UuDQo+ID4NCj4gPj4N Cj4gPj4gMikgc2VjIDcuMToNCj4gPj4gIlNpbmNlIHRoaXMgc3BlY2lmaWNhdGlvbiBvbmx5DQo+ ID4+ICBhbGxvd3MgVURQIGJldHdlZW4gdGhlIHNlcnZlciBhbmQgdGhlIHBlZXJzLCBpdCBpcyBS RUNPTU1FTkRFRCB0aGF0DQo+ID4+IFsuLi5dIg0KPiA+PiBXb3JkaW5ncyAoIm9ubHkgYWxsb3dz Iikgc2VlbXMgd2VpcmQgdG8gbWUgZ2l2ZW4gdXNlIG9mIG90aGVyDQo+ID4+IHByb3Bvc2FscyBp cyBhdCBsZWFzdCB0byBzb21lIGV4dGVuZCBkaXNjdXNzZWQuDQo+ID4NCj4gPiBUaGUgc3BlY2lm aWNhdGlvbiBkb2VzIG5vdCBhbGxvdyBhbnkgb3RoZXIgcHJvdG9jb2wgb3RoZXIgdGhhbiBVRFAN Cj4gYmV0d2VlbiB0aGUgc2VydmVyIGFuZCBwZWVycyAoQXMgeW91IGtub3csIFVEUCBpcyB0aGUg cHJlZmVycmVkIHRyYW5zcG9ydA0KPiBmb3IgbWVkaWEgc3RyZWFtcykuDQo+ID4NCj4gPj4NCj4g Pj4gTml0czoNCj4gPj4gc2VjIDcuMS46IHMvdGhlIGNsaWVudCBwaWNrIGEgY3VycmVudGx5IHVu dXNlZCB0cmFuc3BvcnQgYWRkcmVzcy90aGUNCj4gPj4gY2xpZW50IHBpY2tzIGEgY3VycmVudGx5 IHVudXNlZCB0cmFuc3BvcnQgYWRkcmVzcy8NCj4gPg0KPiA+IEZpeGVkLg0KPiA+DQo+ID4gQ2hl ZXJzLA0KPiA+IC1UaXJ1DQo+ID4+DQo+ID4+DQo+ID4+IF9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4+IHRyYW0gbWFpbGluZyBsaXN0DQo+ID4+IHRy YW1AaWV0Zi5vcmcNCj4gPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90 cmFtDQoNCg== From nobody Mon Jul 29 07:03:22 2019 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 7C6381200F7; Mon, 29 Jul 2019 07:03:04 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.99.1 Auto-Submitted: auto-generated Precedence: bulk Cc: magnus.westerlund@ericsson.com, draft-ietf-tram-turnbis@ietf.org, tram@ietf.org, brandon.williams@akamai.com, Brandon Williams , tram-chairs@ietf.org, The IESG , rfc-editor@rfc-editor.org Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Message-ID: <156440898443.1115.1815898986659372995.idtracker@ietfa.amsl.com> Date: Mon, 29 Jul 2019 07:03:04 -0700 Archived-At: Subject: [tram] Protocol Action: 'Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN)' to Proposed Standard (draft-ietf-tram-turnbis-29.txt) X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.29 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 Jul 2019 14:03:05 -0000 The IESG has approved the following document: - 'Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN)' (draft-ietf-tram-turnbis-29.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 Magnus Westerlund. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-tram-turnbis/ Technical Summary This document updates the definition of Traversal Using Relays around NAT (TURN), RFC5766, a protocol that allows the host to control the operation of the relay and to exchange packets with its peers using the relay. The updates improve protocol support for IPv6 and DTLS, adds support for receiving ICMP packets, and updates PMTUD. The new revision also improves document clarity regarding tunnel amplification attacks and packet translation. Working Group Summary This document represents one of the core milestones for the TRAM working group and as such has undergone significant discussion, review, and revision. There has been no significant controversy of note in the updates to this document. This document's dependence upon some other documents, most notably updates to Session Traversal Utilities for NAT (STUN) I-D.ietf-tram-stunbis, have led to delay in this document's completion, but have not increased the difficulty of coming to consensus on this document's contents. Document Quality This draft has continuously been reviewed by many different people throughout its history. The most significant updates have been the subject of discussion in TRAM WG meetings throughout the documents lifetime. Comprehensive reviews of the full set of updates have been done by two active WG members. This review includes coverage for consistency with the related stunbis document. All of the review feedback has been addressed by the authors. Personnel Document Shepherd: Brandon Williams Responsible Area Director: Magnus Westerlund