From nobody Sun Aug 20 19:26:10 2017 Return-Path: X-Original-To: clue@ietf.org Delivered-To: clue@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D12CF132320; Sun, 20 Aug 2017 19:26:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: clue@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.58.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150328236280.6680.18233661767577330364@ietfa.amsl.com> Date: Sun, 20 Aug 2017 19:26:02 -0700 Archived-At: Subject: [clue] I-D Action: draft-ietf-clue-signaling-12.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.22 List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Aug 2017 02:26:03 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the ControLling mUltiple streams for tElepresence WG of the IETF. Title : Session Signaling for Controlling Multiple Streams for Telepresence (CLUE) Authors : Paul Kyzivat Lennard Xiao Christian Groves Robert Hansen Filename : draft-ietf-clue-signaling-12.txt Pages : 41 Date : 2017-08-20 Abstract: This document specifies how CLUE-specific signaling such as the CLUE protocol and the CLUE data channel are used in conjunction with each other and with existing signaling mechanisms such as SIP and SDP to produce a telepresence call. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-clue-signaling/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-clue-signaling-12 https://datatracker.ietf.org/doc/html/draft-ietf-clue-signaling-12 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-clue-signaling-12 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun Aug 20 19:33:37 2017 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29FCA1321E3 for ; Sun, 20 Aug 2017 19:33:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.521 X-Spam-Level: X-Spam-Status: No, score=-14.521 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tGche8_Tu9n3 for ; Sun, 20 Aug 2017 19:33:33 -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 19EFA13203D for ; Sun, 20 Aug 2017 19:33:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4728; q=dns/txt; s=iport; t=1503282812; x=1504492412; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=Bg2+nDLiMUXHBY8HH19+WJlSxeaS8w56JFLBKmQdYSU=; b=eUyLIdk8TciLYx4eAQKGH3G/SQzgGTLoBhh6JTcz24wfX3vCL0i8Lvq5 16LnLnh4K6eFKUkHt8RP4peOjUOx+IIMBZpKnvnSySC/sIY5lq5yxYabT xhLChAIQpgbP/7TNu64/0taYbQFRO5Cg4NsjkU0MxFF1mcjsXhYvAGVgW I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CaAAAXRZpZ/4ENJK1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgy0tZIEVB44LkBGBbpYeDoIEIQuFGwKDbj8YAQIBAQEBAQEBax0?= =?us-ascii?q?LhRgBAQEBAwEBODQXBAIBCBEEAQEfCQcnCxQJCAIEEwiKKRCyFYIIiUkBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEdgyiCAoMvgyeDJoEaARIBB4YMBYEtAZ8fAgKHUox?= =?us-ascii?q?lghlZhQiKbZYfAR84fwt3NCp2hCEcgWd2h0wHCBeBDIEPAQEB?= X-IronPort-AV: E=Sophos;i="5.41,406,1498521600"; d="scan'208";a="288851024" Received: from alln-core-9.cisco.com ([173.36.13.129]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 21 Aug 2017 02:33:31 +0000 Received: from XCH-RCD-016.cisco.com (xch-rcd-016.cisco.com [173.37.102.26]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id v7L2XVLL011033 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Mon, 21 Aug 2017 02:33:32 GMT Received: from xch-rcd-016.cisco.com (173.37.102.26) by XCH-RCD-016.cisco.com (173.37.102.26) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Sun, 20 Aug 2017 21:33:31 -0500 Received: from xch-rcd-016.cisco.com ([173.37.102.26]) by XCH-RCD-016.cisco.com ([173.37.102.26]) with mapi id 15.00.1210.000; Sun, 20 Aug 2017 21:33:31 -0500 From: "Rob Hansen (rohanse2)" To: "clue@ietf.org" Thread-Topic: [clue] I-D Action: draft-ietf-clue-signaling-12.txt Thread-Index: AQHTGiTfKOawg78csUWdmutizpW7qqKOFZww Date: Mon, 21 Aug 2017 02:33:31 +0000 Message-ID: References: <150328236280.6680.18233661767577330364@ietfa.amsl.com> In-Reply-To: <150328236280.6680.18233661767577330364@ietfa.amsl.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.61.233.41] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [clue] I-D Action: draft-ietf-clue-signaling-12.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Aug 2017 02:33:35 -0000 Hi all, Had planned to have this done several weeks ago but apparently I angered so= me standards deity somehow as minor emergencies kept cropping up that delay= ed me (for instance this evening, literally two minutes after I opened the = xml file to finish it off, a five-meter length of guttering fell off my hou= se with an almighty crash). Curse or not, my apologies on the delay. The summary of changes is as follows: * Title change to expand and elucidate our totally-not-contrived acronym * Explicit reference to RFC3840 added when first mentioning media feature t= ags * Have standardised references to Clue protocol messages to ADVERTISEMENT, = CONFIGURE and ACK, in line with section 12.4.1. of the protocol document (t= hough the protocol document also uses ADV and CONF). * 'MUST' in opening paragraph of 4.2 changed from normative 'MUST' to logic= al 'must' *Per his request, removed Cristian's company affiliation and changed his em= ail address *Other syntactic tweaks based on Paul and Adam's feedback *Clarified that an implementation that chooses not to send media during the= initial negotiation process must still send RTCP as normal *Rewrote the section on adding/remove clue m-lines after the initial exchan= ge to make clear that this is just standard SDP. For non-clue controlled li= nes, recommended they are *deactivated by zeroing the port when turning the= m off after clue is successfully negotiated. *Added guidance that an initial offer containing clue-controlled m-lines MU= ST NOT set them bundle-only unless they somehow know the far end actually s= upports BUNDLE *Added section saying that CLUE devices that do BUNDLE SHOULD do rtcp-mux, = but that the requirement doesn't exist in the other direction (eg, supporti= ng rtcp-mux does not require *or imply the need to implement BUNDLE) *For clue-controlled m-lines where the sender included more encodings than = the recipient wants, have standardised on using "a=3Dinactive" to not recei= ve RTP on them (previously had *a mix of "a=3Dinactive" or port 0, or in so= me cases did not specify). *Page breaks added before the big ladder diagram in the example *Have added a direction attribute to the SDP example in the data channel, a= nd made explicit that Bob is the DTLS client and hence the CLUE Channel Ini= tiator. *Have removed all language that referenced the possibility of having multip= le CLUE groups *Removed names appearing in the authors list from the acknowledgements *Changed the contact for the IANA registration to iesg@ietf.org *Security section updated to clarify that DTLS-SRTP must be supported (as o= pposed to DTLS) and removed the reference to RFC7202. There's also a couple of issues identified in Adam's review that need furth= er discussion; I'll send a separate email for those. Rob -----Original Message----- From: clue [mailto:clue-bounces@ietf.org] On Behalf Of internet-drafts@ietf= .org Sent: 21 August 2017 03:26 To: i-d-announce@ietf.org Cc: clue@ietf.org Subject: [clue] I-D Action: draft-ietf-clue-signaling-12.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the ControLling mUltiple streams for tEleprese= nce WG of the IETF. Title : Session Signaling for Controlling Multiple Stream= s for Telepresence (CLUE) Authors : Paul Kyzivat Lennard Xiao Christian Groves Robert Hansen Filename : draft-ietf-clue-signaling-12.txt Pages : 41 Date : 2017-08-20 Abstract: This document specifies how CLUE-specific signaling such as the CLUE protocol and the CLUE data channel are used in conjunction with each other and with existing signaling mechanisms such as SIP and SDP to produce a telepresence call. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-clue-signaling/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-clue-signaling-12 https://datatracker.ietf.org/doc/html/draft-ietf-clue-signaling-12 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-clue-signaling-12 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. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue From nobody Sun Aug 20 19:40:34 2017 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E69A9132331 for ; Sun, 20 Aug 2017 19:40:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.521 X-Spam-Level: X-Spam-Status: No, score=-14.521 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4wxoL6fKeLBb for ; Sun, 20 Aug 2017 19:40:30 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF07A132320 for ; Sun, 20 Aug 2017 19:40:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=27366; q=dns/txt; s=iport; t=1503283230; x=1504492830; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=+Syez5xtcdRz0i17KDcA4eCgZ98BqLdVasAzW0EtIe8=; b=GdWUgZADyg3W1oW1LC2PYd0QQFLB34z8sf9fTJgDADZ7jn6ydBsTV7t7 8sLpPx022Vz5/kZl2C1MYjJM7+aMHW1FxCYBADRFaWGQng+Y8AZK9cBLm B+KMFRGEZ07WlTKIKSWBwkMX2y87RwQ8sJvwDnrYoKr4czK4V8OLplgLw A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0APAgDSR5pZ/5pdJa1XBhoBAQEBAgEBA?= =?us-ascii?q?QEIAQEBAYNagXkHnhyBbneVJw6CBIVHAhqDVEAXAQIBAQEBAQEBayiFGAEBAQE?= =?us-ascii?q?DIxFABQwEAgEIEQQBAQMCIwMCAgIwFAEICAIEAQ0FCBOKFq9+giaLUQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAR2BC4IZBIExMSCDL4JWHTSEOSIKgyGCYQWBLQGISYc?= =?us-ascii?q?ggWeNTwICiyeJEIIZhWGKbZYfASABNoEKdzQqdoQhHIFmAXaHTAYBgSuBDwEBA?= =?us-ascii?q?Q?= X-IronPort-AV: E=Sophos;i="5.41,406,1498521600"; d="scan'208";a="474527270" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 21 Aug 2017 02:40:28 +0000 Received: from XCH-RCD-020.cisco.com (xch-rcd-020.cisco.com [173.37.102.30]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id v7L2eShH023711 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 21 Aug 2017 02:40:28 GMT Received: from xch-rcd-016.cisco.com (173.37.102.26) by XCH-RCD-020.cisco.com (173.37.102.30) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Sun, 20 Aug 2017 21:40:27 -0500 Received: from xch-rcd-016.cisco.com ([173.37.102.26]) by XCH-RCD-016.cisco.com ([173.37.102.26]) with mapi id 15.00.1210.000; Sun, 20 Aug 2017 21:40:27 -0500 From: "Rob Hansen (rohanse2)" To: Adam Roach , "clue@ietf.org" Thread-Topic: AD Review: draft-ietf-clue-signaling-11 Thread-Index: AQHS2/5y7kSFmrH8ikm+frs9dJG8taKOk+Jg Date: Mon, 21 Aug 2017 02:40:27 +0000 Message-ID: References: <0b69d2f1-11e1-8fd1-d4a1-2faacc0a8528@nostrum.com> In-Reply-To: <0b69d2f1-11e1-8fd1-d4a1-2faacc0a8528@nostrum.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.61.233.41] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [clue] AD Review: draft-ietf-clue-signaling-11 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Aug 2017 02:40:33 -0000 SGkgQWRhbSwNCg0KVGhhbmtzIGFnYWluIGZvciB0aGUgdmVyeSBkZXRhaWxlZCByZXZpZXcuIElu IG1vc3QgY2FzZXMgSSd2ZSBpbmNvcnBvcmF0ZWQgeW91ciBzdWdnZXN0aW9ucyBzdHJhaWdodGZv cndhcmRlZGx5LiBUaGVyZSBhcmUgYSBmZXcgdGhhdCBtYXkgd2FycmFudCBmdXJ0aGVyIGRpc2N1 c3Npb24gaW4gdGhlIGdyb3VwIGFzIGEgd2hvbGUgdGhvdWdoLCB0aG91Z2gsIG9yIHdoZXJlIEkn dmUgZmFpbGVkIHRvIGZpbmQgc29tZXRoaW5nIGluIHRoZSBwcm90b2NvbCBkb2N1bWVudC4NCg0K DQpTZWN0aW9uIDQuNS40LjM6ICJOb3RlIHRoYXQgdGhpcyBpcyBkaXN0aW5jdCBmcm9tIGNhc2Vz IHdoZXJlIHRoZSBDTFVFIHByb3RvY29sIG5lZ290aWF0aW9uIGZhaWxzLCBvciBhbiBlcnJvciBv Y2N1cnMgaW4gdGhlIENMVUUgcHJvdG9jb2w7IHNlZSBbSS1ELmlldGYtY2x1ZS1wcm90b2NvbF0g Zm9yIGRldGFpbHMgb2YgbWVkaWEgYW5kIHN0YXRlIHByZXNlcnZhdGlvbiBpbiB0aGlzIGNpcmN1 bXN0YW5jZS4iIC0tIEkgY2FyZWZ1bGx5IHNjcnViYmVkIHRoZSBDTFVFIHByb3RvY29sIGRvY3Vt ZW50IHRvIHRyeSB0byBkZXRlcm1pbmUgd2hhdCB0aGlzIGlzIHJlZmVycmluZyB0by4gUGxlYXNl IGNoYW5nZSBpdCB0byAic2VlIFtJLUQuaWV0Zi1jbHVlLXByb3RvY29sXSBzZWN0aW9uIFguWS5a IiwgYnV0IHJlcGxhY2luZyAiWC5ZLloiIHdpdGggdGhlIHNlY3Rpb24gdGhhdCBwcm92aWRlcyB0 aGUgZGV0YWlscyB5b3UgYWxsdWRlIHRvLg0KDQpbUm9iXSBJIGJlbGlldmUgd2hlbiBJIHdyb3Rl IHRoaXMgdGhlIHBsYW4gd2FzIHRoYXQgY2FsbCBwcmVzZXJ2YXRpb24gYWN0aW9ucyBpbiB0aGUg ZXZlbnQgb2YgYSBwcm90b2NvbCBlcnJvci9mYWlsdXJlIHdvdWxkIGJlIGFkZHJlc3NlZCBhcyBw YXJ0IG9mIHRoZSBwcm90b2NvbCBkb2N1bWVudCwgYnV0IHRoYXQgdGhpcyBzZWN0aW9uIGhhZCBu b3QgeWV0IGJlZW4gd3JpdHRlbiwgYW5kIHRoYXQgcmVtYWlucyB0aGUgY2FzZS4gU2ltb24sIGlz IHRoaXMgc29tZXRoaW5nIHlvdSBoYXZlIHBsYW5uZWQsIG9yIGNhbiB5b3UgcG9pbnQgbWUgYXQg dGhlIHJlbGV2YW50IHNlY3Rpb24/DQoNCg0KQkxPQ0tFUjogQ29tcGFyZSB0aGUgbm9ybWF0aXZl IHN0YXRlbWVudHMgaW4gcGFyYWdyYXBoIDIgb2YgU2VjdGlvbiA1LjM6DQoNCiAgICBHZW5lcmFs bHksIGltcGxlbWVudGF0aW9ucyB0aGF0IHJlY2VpdmUgbWVzc2FnZXMgZm9yIHdoaWNoIHRoZXkg aGF2ZQ0KICAgIGluY29tcGxldGUgaW5mb3JtYXRpb24gU0hPVUxEIHdhaXQgdW50aWwgdGhleSBo YXZlIHRoZSBjb3JyZXNwb25kaW5nDQogICAgaW5mb3JtYXRpb24gdGhleSBsYWNrIGJlZm9yZSBz ZW5kaW5nIG1lc3NhZ2VzIHRvIG1ha2UgY2hhbmdlcyByZWxhdGVkDQogICAgdG8gdGhhdCBpbmZv cm1hdGlvbi4gIEZvciBleGFtcGxlLCBhbiBhbnN3ZXJlciB0aGF0IHJlY2VpdmVzIGEgbmV3DQog ICAgU0RQIG9mZmVyIHdpdGggdGhyZWUgbmV3ICJhPXNlbmRvbmx5IiBDTFVFICJtPSIgbGluZXMg Zm9yIHdoaWNoIGl0DQogICAgaGFzIHJlY2VpdmVkIG5vIENMVUUgQWR2ZXJ0aXNlbWVudCBwcm92 aWRpbmcgdGhlIGNvcnJlc3BvbmRpbmcNCiAgICBjYXB0dXJlIGluZm9ybWF0aW9uIFNIT1VMRCBp bmNsdWRlIGNvcnJlc3BvbmRpbmcgImE9aW5hY3RpdmUiIGxpbmVzDQogICAgaW4gaXRzIGFuc3dl ciwgYW5kIFNIT1VMRCBtYWtlIGEgbmV3IFNEUCBvZmZlciB3aXRoICJhPXJlY3Zvbmx5IiB3aGVu DQogICAgYW5kIGlmIGEgbmV3IEFkdmVydGlzZW1lbnQgYXJyaXZlcyB3aXRoIENhcHR1cmVzIHJl bGV2YW50IHRvIHRob3NlDQogICAgRW5jb2RpbmdzLg0KDQpXaXRoIHRoZSBub3JtYXRpdmUgc3Rh dGVtZW50cyBpbiBzZWN0aW9uIDQuNS4yLjI6DQoNCiAgICBJZiB0aGUgaW5pdGlhbCBvZmZlciBj b250YWluZWQgImE9cmVjdm9ubHkiIENMVUUtY29udHJvbGxlZCBtZWRpYQ0KICAgIGxpbmVzIHRo ZSByZWNpcGllbnQgU0hPVUxEIGluY2x1ZGUgY29ycmVzcG9uZGluZyAiYT1zZW5kb25seSIgQ0xV RS0NCiAgICBjb250cm9sbGVkIG1lZGlhIGxpbmVzIGZvciBhY2NlcHRlZCBFbmNvZGluZ3MNCiAg ICAuLi4NCiAgICBJZiB0aGUgaW5pdGlhbCBvZmZlciBjb250YWluZWQgImE9c2VuZG9ubHkiIENM VUUtY29udHJvbGxlZCBtZWRpYQ0KICAgIGxpbmVzIHRoZSByZWNpcGllbnQgTUFZIGluY2x1ZGUg Y29ycmVzcG9uZGluZyAiYT1yZWN2b25seSIgQ0xVRS0NCiAgICBjb250cm9sbGVkIG1lZGlhIGxp bmVzDQoNCjUuMyBzYXlzICJTSE9VTEQgc2V0IGE9aW5hY3RpdmUiIGluIHRoZSBleGFjdCBzYW1l IGNpcmN1bXN0YW5jZXMgNC41LjIuMiBzYXlzICJTSE9VTEQgc2V0IGE9c2VuZG9ubHkiLiBQbGVh c2UgcGljayBvbmUgZXhwZWN0ZWQgYmVoYXZpb3IgYW5kIG1ha2Ugc3VyZSBib3RoIHNlY3Rpb25z IGFncmVlLiBJZGVhbGx5LCB5b3Ugd291bGQgcmVmYWN0b3IgdGhpcyBzbyB0aGF0IHRoZSBub3Jt YXRpdmUgc3RhdGVtZW50IGlzIG1hZGUgaW4gb25seSBvbmUgbG9jYXRpb24uDQoNCltSb2JdIEkg ZG9uJ3QgdGhpbmsgdGhlc2Ugc2VjdGlvbnMgYXJlIGluIGNvbmZsaWN0IC0gdGhlIHF1b3RlZCBw YXJhZ3JhcGggZnJvbSBzZWN0aW9uIDUuMyBpcyByZWZlcnJpbmcgdG8gY2FzZXMgd2hlcmUgdGhl IFNEUCBvZmZlciBpbmNsdWRlcyAiYT1zZW5kb25seSIgbGluZXMsIHdoZXJlYXMgdGhlIHNlY3Rp b24gaW4gNC41LjIuMiBzYXlpbmcgIlNIT1VMRCBzZXQgYT1zZW5kb25seSIgaXMgdGFsa2luZyBh Ym91dCB0aGF0IHRoZSBTRFAgKmFuc3dlciogaW5jbHVkaW5nICJhPXNlbmRvbmx5IiBsaW5lcyBp biByZXNwb25zZSB0byB0aGUgb2ZmZXJlcidzICJhPXJlY3Zvbmx5IiBsaW5lcy4gSXQncyB0aGUg cGFyYWdyYXBoIGJlbG93IHRoYXQgY29ycmVzcG9uZHMgdG8gdGhlIHF1b3RlZCA1LjMgcGFyYWdy YXBoLCB3aGljaCBzYXlzIHRoYXQgdGhlIFNEUCAqYW5zd2VyKiBNQVkgaW5jbHVkZSAiYT1yZWN2 b25seSIgaW4gaXRzIHJlc3BvbnNlIG9yICJNQVkiIHdhaXQsIGFuZCB0aGVuIHJlZmVyZW5jZXMg c2VjdGlvbiA1LjMsIHdoaWNoIGlzIHdoZXJlIHRoZSBxdW90ZWQgcGFyYWdyYXBoIHdpdGggcmVj b21tZW5kYXRpb24gdGhhdCBpbXBsZW1lbnRhdGlvbnMgc2hvdWxkIHdhaXQgYW5kIHNlbmQgYSBz dWJzZXF1ZW50IFNEUCBpcyBpbmNsdWRlZC4gV2UgZW5kZWQgdXAgd2l0aCB0aGlzIGFwcHJvYWNo IGJlY2F1c2UsIGV2ZW4gdGhvdWdoIGluIG1vc3QgY2FzZXMgaW1wbGVtZW50YXRpb25zIHNob3Vs ZCB3YWl0IHVudGlsIHRoZXkgcmVjZWl2ZSB0aGUgaW5mb3JtYXRpb24gYWJvdXQgdGhlIGVuY29k aW5ncyBhbmQgdGhlaXIgY29udGVudHMgdmlhIHRoZSBDTFVFIGNoYW5uZWwsIHRoZXJlIGFyZSBz b21lIHZhbGlkIHVzZS1jYXNlcyB3aGVyZSBpbXBsZW1lbnRhdGlvbnMgd2lsbCBrbm93IHRoaXMg dXAtZnJvbnQgYW5kIGhlbmNlIGNhbiBhdm9pZCB0aGUgbmVlZCBmb3IgbXVsdGlwbGUgU0RQIGV4 Y2hhbmdlcy4NCg0KDQpHZW5lcmFsLCBidXQgc3VyZmFjZWQgaW4gc2VjdGlvbiA4OiBUaGUgcHJv Y2VkdXJlcyBkZXNjcmliZWQgaW4gdGhpcyBkb2N1bWVudCB2aXJ0dWFsbHkgZ3VhcmFudGVlIHRo YXQgZXZlcnkgQ0xVRSBjYWxsIHRoYXQgaXMgZXN0YWJsaXNoZWQgd2lsbCByZXN1bHQgaW4gZ2xh cmUgKHJlc3BvbnNlIGNvZGUgNDkxKSBiZWhhdmlvci4gVGhpcyBtaWdodCBjYXVzZSB0aGUgb3Bl cmF0aW9ucyBmb2xrcyBzb21lIGhlYXJ0YnVybiwgYXMgaXQgbWVhbnMgdGhhdCB0aGVpciBlcnJv ciBjb3VudHMgd2lsbCBzcGlrZSBvbmNlIENMVUUgaXMgZGVwbG95ZWQuIEZ1cnRoZXIsIHdpdGhv dXQgZmFpcmx5IGFkdmFuY2VkIGFuYWx5c2lzIG9mIHRoZSBjYWxsZmxvdywgdGhpcyB3aWxsIG1h a2UgaXQgaW1wb3NzaWJsZSB0byBkaXN0aW5ndWlzaCAiZXhwZWN0ZWQiIENMVUUtaW5kdWNlZCA0 OTFzIGZyb20gdGhlIG9kZGJhbGwgYWN0dWFsIGdsYXJlIGNvbmRpdGlvbnMgdXN1YWxseSBzaWdu YWxlZCBieSA0OTEuIEhhcyBhbnkgY29uc2lkZXJhdGlvbiBiZWVuIGdpdmVuIHRvIGF2b2lkaW5n IHRoaXMgc2l0dWF0aW9uIChlLmcuLCBieSBoYXZpbmcgdGhlIGNhbGxlZCBwYXJ0eSB3YWl0IG9u IHRoZSBvcmRlciBvZiBvbmUgc2Vjb25kIGJlZm9yZSBhdHRlbXB0aW5nIHRvIG5lZ290aWF0ZSBp dHMgZW5jb2RpbmdzKT8NCg0KW1JvYl0gSSBkZWZpbml0ZWx5IGFncmVlIHRoYXQgZ2xhcmUgaXMg bXVjaCBtb3JlIGxpa2VseSBhdCB0aGUgc3RhcnQgb2YgYSBDTFVFIGNhbGwuIFRoZXJlIHdhcyBx dWl0ZSBhIGJpdCBvZiBkaXNjdXNzaW9uIGluIHRoZSBncm91cCBvbiB0aGUgcHJvcyBhbmQgY29u cyBvZiBpbnRyb2R1Y2luZyBhbiBhc3ltbWV0cnkgaW50byB0aGUgY2FsbCBtZXNzYWdpbmcgdG8g YXZvaWQgKG9yIHJlZHVjZSB0aGUgZnJlcXVlbmN5KSBvZiBnbGFyZSwgYW5kIGhvdyBiZXN0IHRv IGRvIHNvLCBidXQgdGhlIGZpbmFsIGNvbmNsdXNpb24gaW4gdGhlIGVuZCB3YXMgbm90IHRvIGRv IHNvIGFuZCB0byByZWx5IG9uIFNJUCdzIG1lY2hhbmlzbXMgdG8gcmVzb2x2ZSBpdC4NCg0KDQpT ZWN0aW9uIDEwOiBJdCBpcyByYXRoZXIgdW51c3VhbCB0byBpbmNsdWRlIGF1dGhvcnMgaW4gdGhl IGFja25vd2xlZGdlbWVudHMgc2VjdGlvbi4gRm9yIGVhY2ggb2YgUm9iIEhhbnNlbiwgUGF1bCBL eXppdmF0LCBhbmQgQ2hyaXN0aWFuIEdyb3ZlcywgSSBzdWdnZXN0IHJlbW92aW5nIHRoZSBpbmRp dmlkdWFsJ3MgbmFtZSBmcm9tIGVpdGhlciB0aGUgQWNrbm93bGVkZ2VtZW50cyBzZWN0aW9uIG9y IGZyb20gdGhlIGF1dGhvcnMgbGlzdC4NCg0KW1JvYl0gVGhlIGF1dGhvcnMgbGlzdCBoYXNuJ3Qg cmVhbGx5IGJlZW4gdXBkYXRlZCBzaW5jZSB0aGUgaW5pdGlhbCBzdGFnZXMuIExvb2tpbmcgYXQg b3RoZXIgZG9jcyBsaWtlIHRoZSBmcmFtZXdvcmsgb25lIEkgY2FuIHNlZSB0aGV5J3ZlIGJlZW4g cmV2aXNlZCBhIGZhaXIgYml0LiBGb3Igbm93IEkndmUgbGVmdCB0aGUgYXV0aG9ycyBhcy1pcyBh bmQgcmVtb3ZlZCB0aGUgZHVwbGljYXRlIG5hbWVzIGZyb20gdGhlIGFja25vd2xlZGdlbWVudHMs IGJ1dCB3aWxsIHJlYWNoIG91dCB0byBQYXVsIGFuZCBSb25pIGZvciBndWlkYW5jZSBoZXJlLg0K DQoNClNlY3Rpb24gODogIkluIHRoaXMgY2FzZSBCb2IgaXMgdGhlIENoYW5uZWwgSW5pdGlhdG9y Li4uIiB0aGlzIGlzbid0IGNsZWFyIChhbmQsIGluIGZhY3QsIGl0J3MgY291bnRlcmludHVpdGl2 ZSB0byBtZSkgLS0gcGVyaGFwcyB0aGVyZSBzaG91bGQgYmUgc29tZSB0ZXh0IGluZGljYXRpbmcg KndoeSogQm9iIGlzIHRoZSBDaGFubmVsIEluaXRpYXRvci4NCg0KW1JvYl0gSSd2ZSBtYWRlIGV4 cGxpY2l0IHRoYXQsIHdoZW4gdGhlIFNDVFAgb3ZlciBEVExTIGNoYW5uZWwgaXMgbmVnb3RpYXRl ZCwgQm9iIGVuZHMgdXAgdGhlIGNsaWVudCBhbmQgaGVuY2UgdGhlIENoYW5uZWwgSW5pdGlhdG9y LiBIb3dldmVyLCB3aGVuIEkgd2VudCB0byBkb3VibGUtY2hlY2sgdGhhdCB0aGF0IHdhcyBob3cg dGhlIGluaXRpYXRvciByb2xlIHdhcyBhc3NpZ25lZCwgSSBjYW4ndCBhY3R1YWxseSBmaW5kIGFu eXRoaW5nIGluIHRoZSBwcm90b2NvbCBvciBkYXRhY2hhbm5lbCBkb2N1bWVudCB0aGF0IGRlZmlu ZXMgd2hvIGVuZHMgdXAgd2l0aCB0aGUgSW5pdGlhdG9yIHJvbGUuIFRoYXQgZGVmaW5pdGVseSBz ZWVtcyBsaWtlIHNvbWV0aGluZyB0aGF0IHdlIG5lZWQgdG8gZml4Li4uICh1bmxlc3MgSSd2ZSBq dXN0IGZhaWxpbmcgdG8gZmluZCBpdCkuIFNpbW9uLCBpcyB0aGlzIHNvbWV0aGluZyB5b3UncmUg cGxhbm5pbmcgdG8gYWRkcmVzcz8NCg0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpG cm9tOiBBZGFtIFJvYWNoIFttYWlsdG86YWRhbUBub3N0cnVtLmNvbV0gDQpTZW50OiAwMyBKdW5l IDIwMTcgMDE6MTUNClRvOiBjbHVlQGlldGYub3JnDQpDYzogY2x1ZS1jaGFpcnNAaWV0Zi5vcmc7 IGRyYWZ0LWlldGYtY2x1ZS1zaWduYWxpbmdAdG9vbHMuaWV0Zi5vcmcNClN1YmplY3Q6IEFEIFJl dmlldzogZHJhZnQtaWV0Zi1jbHVlLXNpZ25hbGluZy0xMQ0KDQpDTFVFIHdvcmtpbmcgZ3JvdXAg LS0NCg0KSSBoYXZlIGNvbXBsZXRlZCBteSBBRCByZXZpZXcgZm9yIHRoZSBDTFVFIHNpZ25hbGlu ZyBkb2N1bWVudC4gVGhlIGRvY3VtZW50IGlzIGdlbmVyYWxseSBpbiBnb29kIHNoYXBlLCBidXQg SSB0aGluayB3ZSdsbCBuZWVkIGFub3RoZXIgcmV2aXNpb24gYmVmb3JlIHB1dHRpbmcgaXQgaW4g ZnJvbnQgb2YgdGhlIElFVEYgZm9yIGxhc3QgY2FsbCAoZXNwZWNpYWxseSBkdWUgdG8gdGhlIGFw cGFyZW50IGluY29tcGxldGUgcmVtb3ZhbCBvZiBzdXBwb3J0IGZvciBzcGVjaWZ5aW5nIG11bHRp cGxlIENMVUUgZ3JvdXBzIHBlciBzZXNzaW9uKS4NCg0KTW9zdCBvZiBteSBjb21tZW50cyBiZWxv dyBhcmUgZmVlZGJhY2sgdGhhdCB0aGUgZG9jdW1lbnQgYXV0aG9ycyBzaG91bGQgdHJlYXQgYXMg bm9ybWFsIGxhc3QgY2FsbCBjb21tZW50cy4gVGhlIGZlZWRiYWNrIHRoYXQgSSBjb25zaWRlciB0 byBibG9jayBwcm9ncmVzc2luZyB0aGUgZG9jdW1lbnQsIGluIG15IHJvbGUgYXMgQUQsIGlzIGV4 cGxpY2l0bHkgbWFya2VkIHdpdGggdGhlIHByZWZpeCAiQkxPQ0tFUiIsIGFuZCB0aGVzZSB3aWxs IG5lZWQgdG8gYmUgcmVzb2x2ZWQgaW4gYSBuZXcgdmVyc2lvbiBvZiB0aGUgZG9jdW1lbnQgYmVm b3JlIHByb2dyZXNzaW5nIGl0IGZ1cnRoZXIuIE5vdGUgdGhhdCBpdCBpcyBlbnRpcmVseSBwb3Nz aWJsZSB0aGF0IHNvbWV0aGluZyBJIGhhdmUgbWFya2VkICJCTE9DS0VSIiBtYXkgc3RlbSBmcm9t IGFuIGVycm9yIG9uIG15IHBhcnQ7IHNvIHJlY29nbml6ZSB0aGF0IHRoZXNlIGFyZSBub3QgZGVt YW5kcyBmb3IgY2hhbmdlLCBhcyBtdWNoIGFzIGEgbmVlZCB0byBoYXZlIHRoaW5ncyBlaXRoZXIg Zml4ZWQgaW4gdGhlIGRvY3VtZW50IG9yIGV4cGxhaW5lZCB0byBtZS4NCg0KVGl0bGU6IFRoZSBy dWxlIG9mIHRodW1iIGlzIHRoYXQgYWxsIGJ1dCBhIHNtYWxsIGhhbmRmdWwgb2Ygd2VsbC1rbm93 biBhY3JvbnltcyBuZWVkIHRvIGJlIGV4cGFuZGVkIGluIHRpdGxlcyBhbmQgYWJzdHJhY3RzLiBJ IHJlY29nbml6ZSB0aGF0ICJDTFVFIiBpcyBhIGJpdCB0b3J0dXJlZCwgYXMgYWNyb255bXMgZ28s IGJ1dCB0aGUgdGl0bGUgb2YgdGhpcyBkb2N1bWVudCBpcywgYnJvYWRseSBzcGVha2luZywgb3Bh cXVlLiBQbGVhc2UgY2hhbmdlIGl0IHRvIHNvbWV0aGluZyBtZWFuaW5nZnVsLCBzdWNoIGFzICJT ZXNzaW9uIFNpZ25hbGluZyBmb3IgQ29udHJvbGxpbmcgTXVsdGlwbGUgU3RyZWFtcyBmb3IgVGVs ZXByZXNlbmNlIChDTFVFKSINCg0KQkxPQ0tFUjogR2VuZXJhbDogSXQgaXMgY2xlYXIgZnJvbSBy ZWFkaW5nIHRoaXMgdmVyc2lvbiBvZiB0aGUgZG9jdW1lbnQgdGhhdCBlYXJsaWVyIHZlcnNpb25z IGNvbnRhaW5lZCB0aGUgbm90aW9uIG9mIG11bHRpcGxlICJhPWdyb3VwOkNMVUUiIA0KbGluZXMg aW4gYSBzaW5nbGUgU0RQIGRlc2NyaXB0aW9uLiBUaGlzIHZlcnNpb24gYXBwZWFycyB0byBoYXZl IHRyaWVkIHRvIHJlbW92ZSBhbGwgcmVsYXRlZCB0ZXh0LCBidXQgdGhlcmUgYXJlIHN0aWxsIGVu b3VnaCBtZW50aW9ucyB0aGF0IHRhbGsgYWJvdXQgQ0xVRSBncm91cHMgaW4gYSB3YXkgdGhhdCBp bXBsaWVzIHRoYXQgdGhlcmUgY2FuIGJlIG11bHRpcGxlcyBzbyBhcyB0byBjYXVzZSBjb25mdXNp b24uIFRoZXNlIG5lZWQgdG8gYmUgY2xlYW5lZCB1cC4gSSBjYWxsIHRoZSBzcGVjaWZpYyBpbnN0 YW5jZXMgb3V0IG9uIGEgc2VjdGlvbi1ieS1zZWN0aW9uIGJhc2lzIGJlbG93LiBJJ20gbWVudGlv bmluZyBpdCB1cCBoZXJlIHNpbmNlIGl0J3MgcmVhbGx5IG9ubHkgb25lIGJsb2NrZXIgaXNzdWUg d2l0aCBhIGJ1bmNoIG9mIGluc3RhbmNlcy4NCg0KR2VuZXJhbDogVGhlIF9wcm90b2NvbF8gZG9j dW1lbnQgaGFzIGEgaG9zdCBvZiBkaWZmZXJlbnQgdGVybXMgZm9yIGVhY2gga2luZCBvZiBDTFVF IG1lc3NhZ2UgKGUuZy4sICJBRFZFUlRJU0VNRU5ULCIgIkFEViwiIGFuZCAiYWR2ZXJ0aXNlbWVu dCIgDQpmb3IgdGhlIHNhbWUgb3BlcmF0aW9uKS4gVGhpcyBkb2N1bWVudCBleGFjZXJiYXRlcyB0 aGUgc2l0dWF0aW9uIGJ5IGludHJvZHVjaW5nIHlldCBtb3JlIHZhcmlhdGlvbnMsIHN1Y2ggYXMg IkFkdmVydGlzZW1lbnQiIGFuZCAiQ29uZmlndXJlIi4gUGxlYXNlIGNvb3JkaW5hdGUgd2l0aCBk cmFmdC1pZXRmLWNsdWUtcHJvdG9jb2wgdG8gdXNlIGEgY29uc2lzdGVudCBzZXQgb2YgbmFtZXMg Zm9yIHRoZXNlIG9wZXJhdGlvbnMgYmV0d2VlbiB0aGUgdHdvIGRvY3VtZW50cy4NCg0KSW50cm9k dWN0aW9uOiBUaGUgY29udmVudGlvbiBJIHNlZSBpbiB0aGlzIGRvY3VtZW50IGlzIHRvIHdyaXRl IGRlZmluZWQgdGVybXMgd2l0aCBpbml0aWFsIGNhcHM7IHBsZWFzZSByZXBsYWNlICJlbmNvZGlu ZyBncm91cCIgd2l0aCAiRW5jb2RpbmcgR3JvdXAuIg0KDQpTZWN0aW9uIDM6IFBsZWFzZSBhZGQg YSByZWZlcmVuY2UgdG8gUkZDMzg0MCAoZS5nLjogJ1RoZSAic2lwLmNsdWUiIA0KbWVkaWEgZmVh dHVyZSB0YWcgW1JGQzM4NDBdIGluZGljYXRlcy4uLiIpDQoNClNlY3Rpb24gNC4yOiAiUHJlc2Vu Y2Ugb2YgdGhlIGRhdGEgY2hhbm5lbCBpbiBhIENMVUUgZ3JvdXAuLi4iIGltcGxpZXMgdGhlcmUg Y2FuIGJlIG1vcmUgdGhhbiBvbmUgZ3JvdXAuIFJlcGxhY2UgImEiIHdpdGggInRoZS4iDQoNClNl Y3Rpb24gNC4zOiAuLi5pdHMgIm1pZCIgdmFsdWUgTVVTVCBiZSBpbmNsdWRlZCBpbiBhIENMVUUg Z3JvdXAnIA0KaW1wbGllcyB0aGVyZSBjYW4gYmUgbW9yZSB0aGFuIG9uZSBncm91cC4gUmVwbGFj ZSAiYSIgd2l0aCAidGhlLiINCg0KU2VjdGlvbiA0LjQuMTogIi4uLmluIGEgQ0xVRSBncm91cCBh cyBkZWZpbmVkIGFib3ZlLiIgaW1wbGllcyB0aGVyZSBjYW4gYmUgbW9yZSB0aGFuIG9uZSBncm91 cC4gUmVwbGFjZSAiYSIgd2l0aCAidGhlLiINCg0KU2VjdGlvbiA0LjQuMTogJy4uLiJtPSIgbGlu ZXMgaW4gdGhlIHNhbWUgQ0xVRSBncm91cCBpbiB0aGUgU0RQIG1lc3NhZ2UuLi4nIHZlcnkgc3Ry b25nbHkgaW1wbGllcyB0aGVyZSBjYW4gYmUgbW9yZSB0aGFuIG9uZSBncm91cC4gDQpSZXBocmFz ZSwgcGVyaGFwcyBhbG9uZyB0aGUgbGluZXMgb2YgIi4uLkNMVUUtY29udHJvbGxlZCAibT0iIGxp bmVzIGluIHRoZSBTRFAgbWVzc2FnZS4uLiINCg0KNC40LjI6ICdUaGVzZSAibT0iIGxpbmVzIGFy ZSBDTFVFLWNvbnRyb2xsZWQgYW5kIGhlbmNlIE1VU1QgaW5jbHVkZSB0aGVpciAibWlkIiBpbiB0 aGUgQ0xVRSBncm91cCBjb3JyZXNwb25kaW5nIHRvIHRoZSBDTFVFIGdyb3VwIG9mIHRoZSBFbmNv ZGluZyB0aGV5IHdpc2ggdG8gcmVjZWl2ZS4nIGlzIGdldHRpbmcgcHJldHR5IGV4cGxpY2l0IGFi b3V0IHRoZSBwcmVzZW5jZSBvZiBtdWx0aXBsZSBDTFVFIGdyb3Vwcy4gRml4Lg0KDQo0LjUuMi4x LCBmaXJzdCBzZW50ZW5jZTogUmVwbGFjZSAiSWYgdGhlIHJlY2lwaWVudCBpcyBhIENMVUUtY2Fw YWJsZS4uLiIgDQp3aXRoICJJZiB0aGUgcmVjaXBpZW50IG9mIGFuIG9mZmVyIGlzIGEgQ0xVRS1j YXBhYmxlLi4uIg0KDQpCTE9DS0VSOiBTZWN0aW9uIDQuNS4yLjI6IEZvciBhdm9pZGFuY2Ugb2Yg ZG91YnQsIHRoaXMgc2VjdGlvbiBzaG91bGQgY2xlYXJseSBpbmRpY2F0ZSB3aGF0IHRoZSBhbnN3 ZXIgc2hvdWxkIGRvIHdpdGggQ0xVRS1jb250cm9sbGVkIGxpbmVzIHRoYXQgaXQgaGFzIG5vIGlu dGVudGlvbiBvZiByZWNlaXZpbmcgKGZvciBzZW5kb25seSkgb3Igc2VuZGluZyAoZm9yIHJlY3Zv bmx5KS4gSSBiZWxpZXZlIHRoZSBleHBlY3RhdGlvbiBoZXJlIGlzIHRvIHNldCB0aGUgcG9ydCB0 byB6ZXJvIChyYXRoZXIgdGhhbiwgZS5nLiwgc2V0dGluZyB0aGUgZGlyZWN0aW9uIHRvIGluYWN0 aXZlKS4gVGhlIGRvY3VtZW50IHNob3VsZCBleHBsaWNpdGx5IHN0YXRlIHRoaXMgYmVoYXZpb3I6 IGlmIGltcGxlbWVudGF0aW9ucyBtYWtlIGRpZmZlcmVudCBjaG9pY2VzIGJldHdlZW4gcG9ydC16 ZXJvIGFuZCBpbmFjdGl2ZSBhbmQgZG9uJ3QgZXhwZWN0IHRoZSBvdGhlciBiZWhhdmlvciwgeW91 IGNhbiBlbmQgdXAgd2l0aCBpbmNvbXBhdGliaWxpdGllcy4NCg0KU2VjdGlvbiA0LjUuMy4xLCBw YXJhZ3JhcGggMjogTXkgcmVjb2xsZWN0aW9uIGlzIHRoYXQgdGVsbGluZyBpbXBsZW1lbnRvcnMg bm90IHRvIHNlbmQgbWVkaWEgaXMgZnJlcXVlbnRseSBtaXNpbnRlcnByZXRlZCB0byBtZWFuIHRo YXQgdGhleSBkb24ndCBoYXZlIHRvIHNlbmQvcmVjZWl2ZSBSVENQIGVpdGhlci4gVGhpcyBjYXVz ZXMgYWxsIGtpbmRzIG9mIGdyaWVmLiBJdCB3aWxsIHByb2JhYmx5IGhlYWQgb2ZmIGlzc3VlcyBp ZiB0aGlzIHNlY3Rpb24gaXMgcGhyYXNlZCBtb3JlIGxpa2UgIi4uLk1BWSBjaG9vc2Ugbm90IHRv IHNlbmQgUlRQIG9uIHRoZSBub24tQ0xVRS1jb250cm9sbGVkIGNoYW5uZWxzIChhbHRob3VnaCBS VENQIGlzIHN0aWxsIHNlbnQgYW5kIHJlY2VpdmVkIGFzIG5vcm1hbCkgZHVyaW5nIHRoZSBwZXJp b2QuLi4iDQoNClNlY3Rpb24gNC41LjQuMTogJ1N1YnNlcXVlbnQgb2ZmZXIvYW5zd2VyIGV4Y2hh bmdlcyBNQVkgYWRkIGFkZGl0aW9uYWwgIm09IiBsaW5lcy4uLicgLS0gdGhpcyBzaG91bGQgcHJv YmFibHkgYWxzbyBtZW50aW9uICJhbmQgYWN0aXZhdGUgaW5hY3RpdmUgb25lcy4iDQoNClNlY3Rp b24gNC41LjQuMTogJ1N1YnNlcXVlbnQgb2ZmZXIvYW5zd2VyIGV4Y2hhbmdlcyBNQVkgYWxzbyBk ZWFjdGl2YXRlICJtPSIgbGluZXMgZm9yIENMVUUtY29udHJvbGxlZCBtZWRpYS4nIC0tIGFnYWlu LCB0aGUgaW50ZXJwcmV0YXRpb24gb2YgImRlYWN0aXZhdGUiIG1heSBiZSBkaWZmZXJlbnQgYmV0 d2VlbiBpbXBsZW1lbnRvcnMuIFBsZWFzZSBiZSBjbGVhciBhYm91dCB3aGV0aGVyIHRoaXMgbWVh bnMgImE9aW5hY3RpdmUiLCBwb3J0PTAsIG9yIGJvdGguDQoNClNlY3Rpb24gNC41LjQuMTogVGhl IGZpbmFsIHBhcmFncmFwaCB0YWxrcyBhYm91dCAiZGVhY3RpdmF0aW5nIiBub24tQ0xVRSBtZWRp YS4gQWdhaW4sIHRoaXMgc2hvdWxkIGJlIGV4cGxpY2l0IGFib3V0IHdoYXQgaXMgbWVhbnQuDQoN ClNlY3Rpb24gNC41LjQuMjogJ0lmLCBpbiBhbiBvbmdvaW5nIG5vbi1DTFVFIGNhbGwsIGFuIFNE UCBvZmZlci9hbnN3ZXIgZXhjaGFuZ2UgY29tcGxldGVzIHdpdGggYm90aCBzaWRlcyBoYXZpbmcg aW5jbHVkZWQgYSBkYXRhIGNoYW5uZWwgIm09IiANCmxpbmUgaW4gdGhlaXIgU0RQIGFuZCB3aXRo IHRoZSAibWlkIiBmb3IgdGhhdCBjaGFubmVsIGluIGNvcnJlc3BvbmRpbmcgQ0xVRSBncm91cHMu Li4iIGltcGxpZXMgdGhhdCB0aGVyZSBjYW4gYmUgbW9yZSB0aGFuIG9uZSBDTFVFIGdyb3VwLiBG aXguDQoNClNlY3Rpb24gNC41LjQuMzogIi4uLmluY2x1ZGUgdGhlIGRhdGEgY2hhbm5lbCBpbiBh IG1hdGNoaW5nIENMVUUgZ3JvdXAuLi4iIGltcGxpZXMgdGhlcmUgY2FuIGJlIG1vcmUgdGhhbiBv bmUgZ3JvdXAuIFJlcGxhY2UgImEgbWF0Y2hpbmciIA0Kd2l0aCAidGhlLiINCg0KU2VjdGlvbiA0 LjUuNC4zOiAiQW55IGFjdGl2ZSAibT0iIGxpbmVzIHN0aWxsIGluY2x1ZGVkIGluIGEgQ0xVRSBn cm91cC4uLiIgaW1wbGllcyB0aGVyZSBjYW4gYmUgbW9yZSB0aGFuIG9uZSBncm91cC4gUmVwbGFj ZSAiYSIgd2l0aCAidGhlLiINCg0KU2VjdGlvbiA0LjUuNC4zOiAiTm90ZSB0aGF0IHRoaXMgaXMg ZGlzdGluY3QgZnJvbSBjYXNlcyB3aGVyZSB0aGUgQ0xVRSBwcm90b2NvbCBuZWdvdGlhdGlvbiBm YWlscywgb3IgYW4gZXJyb3Igb2NjdXJzIGluIHRoZSBDTFVFIHByb3RvY29sOyBzZWUgW0ktRC5p ZXRmLWNsdWUtcHJvdG9jb2xdIGZvciBkZXRhaWxzIG9mIG1lZGlhIGFuZCBzdGF0ZSBwcmVzZXJ2 YXRpb24gaW4gdGhpcyBjaXJjdW1zdGFuY2UuIiAtLSBJIGNhcmVmdWxseSBzY3J1YmJlZCB0aGUg Q0xVRSBwcm90b2NvbCBkb2N1bWVudCB0byB0cnkgdG8gZGV0ZXJtaW5lIHdoYXQgdGhpcyBpcyBy ZWZlcnJpbmcgdG8uIFBsZWFzZSBjaGFuZ2UgaXQgdG8gInNlZSBbSS1ELmlldGYtY2x1ZS1wcm90 b2NvbF0gc2VjdGlvbiBYLlkuWiIsIGJ1dCByZXBsYWNpbmcgIlguWS5aIiB3aXRoIHRoZSBzZWN0 aW9uIHRoYXQgcHJvdmlkZXMgdGhlIGRldGFpbHMgeW91IGFsbHVkZSB0by4NCg0KDQpCTE9DS0VS OiBDb21wYXJlIHRoZSBub3JtYXRpdmUgc3RhdGVtZW50cyBpbiBwYXJhZ3JhcGggMiBvZiBTZWN0 aW9uIDUuMzoNCg0KICAgIEdlbmVyYWxseSwgaW1wbGVtZW50YXRpb25zIHRoYXQgcmVjZWl2ZSBt ZXNzYWdlcyBmb3Igd2hpY2ggdGhleSBoYXZlDQogICAgaW5jb21wbGV0ZSBpbmZvcm1hdGlvbiBT SE9VTEQgd2FpdCB1bnRpbCB0aGV5IGhhdmUgdGhlIGNvcnJlc3BvbmRpbmcNCiAgICBpbmZvcm1h dGlvbiB0aGV5IGxhY2sgYmVmb3JlIHNlbmRpbmcgbWVzc2FnZXMgdG8gbWFrZSBjaGFuZ2VzIHJl bGF0ZWQNCiAgICB0byB0aGF0IGluZm9ybWF0aW9uLiAgRm9yIGV4YW1wbGUsIGFuIGFuc3dlcmVy IHRoYXQgcmVjZWl2ZXMgYSBuZXcNCiAgICBTRFAgb2ZmZXIgd2l0aCB0aHJlZSBuZXcgImE9c2Vu ZG9ubHkiIENMVUUgIm09IiBsaW5lcyBmb3Igd2hpY2ggaXQNCiAgICBoYXMgcmVjZWl2ZWQgbm8g Q0xVRSBBZHZlcnRpc2VtZW50IHByb3ZpZGluZyB0aGUgY29ycmVzcG9uZGluZw0KICAgIGNhcHR1 cmUgaW5mb3JtYXRpb24gU0hPVUxEIGluY2x1ZGUgY29ycmVzcG9uZGluZyAiYT1pbmFjdGl2ZSIg bGluZXMNCiAgICBpbiBpdHMgYW5zd2VyLCBhbmQgU0hPVUxEIG1ha2UgYSBuZXcgU0RQIG9mZmVy IHdpdGggImE9cmVjdm9ubHkiIHdoZW4NCiAgICBhbmQgaWYgYSBuZXcgQWR2ZXJ0aXNlbWVudCBh cnJpdmVzIHdpdGggQ2FwdHVyZXMgcmVsZXZhbnQgdG8gdGhvc2UNCiAgICBFbmNvZGluZ3MuDQoN CldpdGggdGhlIG5vcm1hdGl2ZSBzdGF0ZW1lbnRzIGluIHNlY3Rpb24gNC41LjIuMjoNCg0KICAg IElmIHRoZSBpbml0aWFsIG9mZmVyIGNvbnRhaW5lZCAiYT1yZWN2b25seSIgQ0xVRS1jb250cm9s bGVkIG1lZGlhDQogICAgbGluZXMgdGhlIHJlY2lwaWVudCBTSE9VTEQgaW5jbHVkZSBjb3JyZXNw b25kaW5nICJhPXNlbmRvbmx5IiBDTFVFLQ0KICAgIGNvbnRyb2xsZWQgbWVkaWEgbGluZXMgZm9y IGFjY2VwdGVkIEVuY29kaW5ncw0KICAgIC4uLg0KICAgIElmIHRoZSBpbml0aWFsIG9mZmVyIGNv bnRhaW5lZCAiYT1zZW5kb25seSIgQ0xVRS1jb250cm9sbGVkIG1lZGlhDQogICAgbGluZXMgdGhl IHJlY2lwaWVudCBNQVkgaW5jbHVkZSBjb3JyZXNwb25kaW5nICJhPXJlY3Zvbmx5IiBDTFVFLQ0K ICAgIGNvbnRyb2xsZWQgbWVkaWEgbGluZXMNCg0KNS4zIHNheXMgIlNIT1VMRCBzZXQgYT1pbmFj dGl2ZSIgaW4gdGhlIGV4YWN0IHNhbWUgY2lyY3Vtc3RhbmNlcyA0LjUuMi4yIHNheXMgIlNIT1VM RCBzZXQgYT1zZW5kb25seSIuIFBsZWFzZSBwaWNrIG9uZSBleHBlY3RlZCBiZWhhdmlvciBhbmQg bWFrZSBzdXJlIGJvdGggc2VjdGlvbnMgYWdyZWUuIElkZWFsbHksIHlvdSB3b3VsZCByZWZhY3Rv ciB0aGlzIHNvIHRoYXQgdGhlIG5vcm1hdGl2ZSBzdGF0ZW1lbnQgaXMgbWFkZSBpbiBvbmx5IG9u ZSBsb2NhdGlvbi4NCg0KDQpTZWN0aW9uIDcgYXBwZWFycyB0byBiZSBvZGRseSBzaWxlbnQgb24g dGhlIHVzZSBvZiBSVENQIE1VWC4gSSBzdXNwZWN0IHRoYXQgdGhlIGludGVudGlvbiBpcyB0aGF0 IENMVUUgd2lsbCBnZW5lcmFsbHkgbXVsdGlwbGV4IFJUQ1Agd2hlbiB1c2luZyBCVU5ETEU/IEkg d291bGQgZXhwZWN0IHRoaXMgdG8gYmUgY2FsbGVkIG91dC4NCg0KU2VjdGlvbiA3IG9mZmVycyB0 aGF0IHRoZSB1c2Ugb2YgQlVORExFIGhhcyB0aGUgYWR2YW50YWdlIG9mIHJlZHVjaW5nIHRoZSBu dW1iZXIgb2YgSUNFIGNhbmRpZGF0ZXMgdGhhdCBuZWVkIHRvIGJlIGNvbGxlY3RlZC4gVGhpcyBp cyB0cnVlIG9ubHkgaW4gdGhlIGNhc2UgdGhhdCBzb21lIG09IHNlY3Rpb24gYXJlIG1hcmtlZCBh cyBidW5kbGUtb25seTsgdGhpcywgaW4gdHVybiwgaW1wbGllcyB0aGF0IGEgYnVuZGxlZCBvZmZl ciBpcyBnb2luZyB0byBjb250YWluIG9uZSBvciBtb3JlIG09IHNlY3Rpb25zIHRoYXQgd2lsbCBm YWlsIGlmIHRoZSByZW1vdGUgZW5kcG9pbnQgZG9lcyBub3QgaW1wbGVtZW50IEJVTkRMRS4gVGhp cyBpbnRlcmFjdHMgcGFydGljdWxhcmx5IGJhZGx5IHdpdGggdGhlIHRleHQgaW4gc2VjdGlvbiA0 LjUuMSB0aGF0IGFsbG93cywgdW5kZXIgY2VydGFpbiBjaXJjdW1zdGFuY2VzLCB0aGF0ICd0aGUg aW5pdGlhbCBvZmZlciBNQVkgY29udGFpbiAibT0iIGxpbmVzIGZvciBDTFVFLWNvbnRyb2xsZWQg bWVkaWEuJywgc2luY2UgeW91IGNhbiBlbmQgdXAgd2l0aCB0aGUgd2hvbGUgQ0xVRSBzZXNzaW9u IGZhbGxpbmcgYXBhcnQgaWYgdGhlIGJ1bmRsZS1vbmx5IGxpbmVzIGFyZSBub3QgY2hvc2VuIGNh cmVmdWxseS4gVGhpcyBpcyBhIHJlbGF0aXZlbHkgY29tcGxpY2F0ZWQgaXNzdWUgdGhhdCBJIHdv dWxkbid0IGV4cGVjdCBpbXBlbWVudG9ycyB0byBnZXQgY29ycmVjdCB3aXRob3V0IHNvbWUgZ3Vp ZGFuY2Ugb24gdGhlIHVzZSBvZiBidW5kbGUtb25seSwgYW5kIGluIHBhcnRpY3VsYXIgaXRzIGlu dGVyYWN0aW9uIHdpdGggQ0xVRS1jb250cm9sbGVkIGxpbmVzLiBQbGVhc2UgYWRkIHRleHQgdG8g U2VjdGlvbiA3IHRoYXQgZGlzY3Vzc2VzIHRoZXNlIGlzc3Vlcy4NCg0KU2VjdGlvbiA4OiBQbGVh c2UgaW5zZXJ0IGEgcGFnZSBicmVhayBiZWZvcmUgdGhlIGxhZGRlciBkaWFncmFtIHNvIHRoYXQg dGhlIGVudGl0eSBuYW1lcyBkb24ndCBhcHBlYXIgb24gYSBwYWdlIGJ5IHRoZW1zZWx2ZXMuDQoN ClNlY3Rpb24gODogIkluIHRoaXMgY2FzZSBCb2IgaXMgdGhlIENoYW5uZWwgSW5pdGlhdG9yLi4u IiB0aGlzIGlzbid0IGNsZWFyIChhbmQsIGluIGZhY3QsIGl0J3MgY291bnRlcmludHVpdGl2ZSB0 byBtZSkgLS0gcGVyaGFwcyB0aGVyZSBzaG91bGQgYmUgc29tZSB0ZXh0IGluZGljYXRpbmcgKndo eSogQm9iIGlzIHRoZSBDaGFubmVsIEluaXRpYXRvci4NCg0KR2VuZXJhbCwgYnV0IHN1cmZhY2Vk IGluIHNlY3Rpb24gODogVGhlIHByb2NlZHVyZXMgZGVzY3JpYmVkIGluIHRoaXMgZG9jdW1lbnQg dmlydHVhbGx5IGd1YXJhbnRlZSB0aGF0IGV2ZXJ5IENMVUUgY2FsbCB0aGF0IGlzIGVzdGFibGlz aGVkIHdpbGwgcmVzdWx0IGluIGdsYXJlIChyZXNwb25zZSBjb2RlIDQ5MSkgYmVoYXZpb3IuIFRo aXMgbWlnaHQgY2F1c2UgdGhlIG9wZXJhdGlvbnMgZm9sa3Mgc29tZSBoZWFydGJ1cm4sIGFzIGl0 IG1lYW5zIHRoYXQgdGhlaXIgZXJyb3IgY291bnRzIHdpbGwgc3Bpa2Ugb25jZSBDTFVFIGlzIGRl cGxveWVkLiBGdXJ0aGVyLCB3aXRob3V0IGZhaXJseSBhZHZhbmNlZCBhbmFseXNpcyBvZiB0aGUg Y2FsbGZsb3csIHRoaXMgd2lsbCBtYWtlIGl0IGltcG9zc2libGUgdG8gZGlzdGluZ3Vpc2ggImV4 cGVjdGVkIiBDTFVFLWluZHVjZWQgNDkxcyBmcm9tIHRoZSBvZGRiYWxsIGFjdHVhbCBnbGFyZSBj b25kaXRpb25zIHVzdWFsbHkgc2lnbmFsZWQgYnkgNDkxLiBIYXMgYW55IGNvbnNpZGVyYXRpb24g YmVlbiBnaXZlbiB0byBhdm9pZGluZyB0aGlzIHNpdHVhdGlvbiAoZS5nLiwgYnkgaGF2aW5nIHRo ZSBjYWxsZWQgcGFydHkgd2FpdCBvbiB0aGUgb3JkZXIgb2Ygb25lIHNlY29uZCBiZWZvcmUgYXR0 ZW1wdGluZyB0byBuZWdvdGlhdGUgaXRzIGVuY29kaW5ncyk/DQoNCg0KU2VjdGlvbiA4IGNvbnRh aW5zIHRoZSBmb2xsb3dpbmcgdGV4dDoNCg0KICAgIEJvYiBhbHNvIHNlbmRzIGhpcyBTRFAgYW5z d2VyIGFzIHBhcnQgb2YgU0lQIDIwMCBPSyAyLiAgQWxvbmdzaWRlIGhpcw0KICAgIG9yaWdpbmFs IGF1ZGlvLCB2aWRlbyBhbmQgQ0xVRSAibT0iIGxpbmVzIGhlIGluY2x1ZGVzIHR3byBhY3RpdmUN CiAgICByZWN2b25seSAibT0gImxpbmVzIGFuZCBhIHplcm9lZCAibT0iIGxpbmUgZm9yIHRoZSB0 aGlyZC4NCg0KVGhpcyBzaG91bGQgcHJvYmFibHkgYmUgcXVhbGlmaWVkIHRvIGluZGljYXRlIHRo YXQgdGhlc2UgYXJlIHRoZSBzYW1lIG0tc2VjdGlvbnMgYXMgd2VyZSBwcmVzZW50IGluIHRoZSBv ZmZlciAoYXMgb3Bwb3NlZCB0byBjcmVhdGluZyBuZXcgc2VjdGlvbnMpLg0KDQoNClNlY3Rpb24g ODogUmVwbGFjZSAiSGF2aW5nIHJlY2VpdmVkIHRoaXMgQWxpY2UuLi4iIHdpdGggIkhhdmluZyBy ZWNlaXZlZCB0aGlzIG9mZmVyLCBBbGljZS4uLiINCg0KU2VjdGlvbiA5OiAiRnJvbSB0aGUgbGFj ayBvZiB0aGUgZGF0YSBjaGFubmVsIGFuZCBncm91cGluZyBmcmFtZXdvcmsuLi4iIA0KLS0gaXQg c2hvdWxkIGJlIG5vdGVkIHRoYXQgaW1wbGVtZW50YXRpb25zIHRoYXQgZW5kIHVwIGluIGNvbW11 bmljYXRpb24gd2l0aCBub3JtYWwgbm9uLUNMVUUgV2ViUlRDIGltcGxlbWVudGF0aW9ucyBtaWdo dCBnZXQgYSBkYXRhY2hhbm5lbCBidXQgbm8gQ0xVRSBncm91cC4gVGhlIHF1b3RlZCB0ZXh0IGlt cGxpZXMgdGhhdCB0aGUgcHJlc2VuY2Ugb3IgYWJzZW5jZSBvZiBhIGRhdGFjaGFubmVsIGNhbiBi ZSB1c2VkIHRvIGRldGVybWluZSBDTFVFIHN1cHBvcnQsIHdoaWNoIG1pZ2h0IGNhdXNlIGltcGxl bWVudG9ycyB0byByZWx5IG9uIHRoYXQgZXhjbHVzaXZlbHkuIFBsZWFzZSBjaGFuZ2UgdGhlIHRl eHQgdG8gaW5kaWNhdGUgdGhhdCB0aGUgQ0xVRSBncm91cCBzaG91bGQgYmUgdXNlZCBhcyB0aGUg c29sZSBkZXRlcm1pbmFudCBvZiBDTFVFIHN1cHBvcnQgKGF0IGxlYXN0LCBhcyBmYXIgYXMgU0RQ IHNpZ25hbGluZyBpcyBjb25jZXJuZWQpLg0KDQpTZWN0aW9uIDEwOiBJdCBpcyByYXRoZXIgdW51 c3VhbCB0byBpbmNsdWRlIGF1dGhvcnMgaW4gdGhlIGFja25vd2xlZGdlbWVudHMgc2VjdGlvbi4g Rm9yIGVhY2ggb2YgUm9iIEhhbnNlbiwgUGF1bCBLeXppdmF0LCBhbmQgQ2hyaXN0aWFuIEdyb3Zl cywgSSBzdWdnZXN0IHJlbW92aW5nIHRoZSBpbmRpdmlkdWFsJ3MgbmFtZSBmcm9tIGVpdGhlciB0 aGUgQWNrbm93bGVkZ2VtZW50cyBzZWN0aW9uIG9yIGZyb20gdGhlIGF1dGhvcnMgbGlzdC4NCg0K U2VjdGlvbiAxMS4yOiAiVGhpcyBzcGVjaWZpY2F0aW9uIHJlZ2lzdGVycyBhIG5ldyBtZWRpYSBm ZWF0dXJlIHRhZyBpbiB0aGUgU0lQIFtSRkMzMjY0XSB0cmVlLi4uIiBUaGlzIHNob3VsZCBjaXRl IFJGQzMyNjEgZm9yIFNJUCByYXRoZXIgdGhhbiBSRkMzMjY0Lg0KDQpTZWN0aW9uIDExLjI6IFBs ZWFzZSBpbmRpY2F0ZSAiaWVzZ0BpZXRmLm9yZyIgYXMgdGhlIGNvbnRhY3QgZm9yIHRoaXMgcmVn aXN0cmF0aW9uLg0KDQoNCkJMT0NLSU5HOiBTZWN0aW9uIDEyIGluZGljYXRlcyB0aGF0IG5vIHNl Y3VyaXR5IG1lY2hhbmlzbXMgYXJlIG1hbmRhdG9yeSANCnRvIHVzZSAiZHVlIHRvIHRoZSBpc3N1 ZXMgYWRkcmVzc2VkIGluIFtSRkM3MjAyXS4iIFRoaXMgdmFzdGx5IA0KbWlzY29uc3RydWVzIHRo ZSBpbnRlbnQgYW5kIHRleHQgb2YgUkZDNzIwMiwgd2hpY2ggKHJvdWdobHkgc3BlYWtpbmcpIA0K c2F5cyAid2UgZG9uJ3QgbWFuZGF0ZSBzZWN1cml0eSBmb3IgUlRQIGluIGdlbmVyYWwgYmVjYXVz ZSBpdCBpcyB1c2VkIGluIA0KYSB2YXN0IGFuZCB2YXJpZWQgYXJyYXkgb2YgYXBwbGljYXRpb25z LiIgQ0xVRSBpcyBhIHZlcnkgc3BlY2lmaWMsIHZlcnkgDQpuYXJyb3cgYXBwbGljYXRpb24gb2Yg UlRQIHRoYXQgZG9lcyBub3Qgc3VmZmVyIGZyb20gdGhlIGdlbmVyYWxpdHkgdGhhdCANCm1ha2Vz IGEgb25lLXNpemUtZml0cy1hbGwgc29sdXRpb24gZm9yIFJUUCBpbmZlYXNpYmxlLiBJbiBmYWN0 LCBSRkM3MjAyIA0KaXMgcXVpdGUgY2xlYXIgdGhhdCBpdHMgZ3VpZGFuY2UgYXBwbGllcyBleGNs dXNpdmVseSB0byBSVFAsIGFuZCBub3QgdG8gDQpwcm90b2NvbHMgdGhhdCAqdXNlKiBSVFA6ICJE b2N1bWVudHMgdGhhdCBkZWZpbmUgYW4gaW50ZXJvcGVyYWJsZSBjbGFzcyANCm9mIGFwcGxpY2F0 aW9ucyB1c2luZyBSVFAgYXJlIHN1YmplY3QgdG8gW1JGQzMzNjVdLCBhbmQgdGh1cyBuZWVkIHRv IA0Kc3BlY2lmeSBNVEkgc2VjdXJpdHkgbWVjaGFuaXNtcy4iIElmIHRoZXJlIGFyZSBzcGVjaWZp YyBhcmd1bWVudHMgcHV0IA0KZm9ydGggaW4gUkZDNzIwMiB0aGF0IHRoZSB3b3JraW5nIGdyb3Vw IGJlbGlldmVzIGFsc28gYXBwbHkgdG8gdGhpcyANCmRvY3VtZW50LCBwbGVhc2UgcmVpdGVyYXRl IHRoZW0gaGVyZS4gVGhlIGN1cnJlbnQgY2l0YXRpb24gdG8gUkZDNzIwMiBpcyANCnByb2JsZW1h dGljLCB0aG91Z2gsIHNpbmNlIGl0IHNheXMgdGhlIG9wcG9zaXRlIG9mIHdoYXQgdGhpcyBzZWN1 cml0eSANCnNlY3Rpb24gaW1wbGllcy4NCg0KSWYgSSB1bmRlcnN0YW5kIGl0IGNvcnJlY3RseSwg dGhvdWdoLCB0aGUgYXJndW1lbnQgdG8gcHV0IGZvcnRoIGhlcmUgaXMgDQp0aGF0IGltcGxlbWVu dGF0aW9ucyBNQVkgY2hvb3NlIG5vdCB0byBzZWN1cmUgbGVnYWN5IA0KKG5vbi1DTFVFLWNvbnRy b2xsZWQpIG1lZGlhIGxpbmVzIGJlY2F1c2UgU0lQIHdhcyBzcGVjaWZpZWQgcHJpb3IgdG8gDQpS RkMzMzY1LCBhbmQgd2FzIHRoZXJlZm9yZSBub3QgYm91bmQgYnkgaXRzIHJlcXVpcmVtZW50czsg YW5kLCBhcyBhIA0KY29uc2VxdWVuY2UsIG1hbnkgZXhpc3RpbmcgU0lQIGVuZHBvaW50cyBhcmUg aW5jYXBhYmxlIG9mIHVzaW5nIA0KRFRMUy1TUlRQLiBUaGlzIHJhdGlvbmFsZSBpcyBvcnRob2dv bmFsIHRvIHRoZSBndWlkYW5jZSBpbiBSRkM3MjAyLCBhbmQgDQpzaG91bGQgbm90IGNpdGUgaXQu DQoNClRoZSB1c2Ugb2YgIkRUTFMiIHRvIHJlZmVyIHRvICJEVExTLVNSVFAiIGlzIGFsc28gY29u ZnVzaW5nLCBhcyB0aGV5IGFyZSANCmRpZmZlcmVudCB0aGluZ3MuDQoNCkkgcHJvcG9zZSBjaGFu Z2luZyB0aGUgcGFyYWdyYXBoIGFzIGZvbGxvd3M6DQoNCiAgICBUaGlzIGF0dGFjayBjYW4gYmUg cHJldmVudGVkIGJ5IGVuc3VyaW5nIHRoYXQgdGhlIG1lZGlhIHJlY2lwaWVudCBpbnRlbmRzDQog ICAgdG8gcmVjZWl2ZSB0aGUgbWVkaWEgcGFja2V0cy4gIEFzIHN1Y2gsIGFsbCBDTFVFLWNhcGFi bGUgZGV2aWNlcyBNVVNUDQogICAgc3VwcG9ydCBrZXkgbmVnb3RpYXRpb24gYW5kIHJlY2VpdmVy IGludGVudCBhc3N1cmFuY2UgdmlhIERUTFMtU1JUUA0KICAgIFtSRkM1NzYzXSBvbiBDTFVFLWNv bnRyb2xsZWQgUlRQICJtPSIgbGluZXMuICBBcyBzcGVjaWZpZWQgaW4NCiAgICBbSS1ELmlldGYt Y2x1ZS1mcmFtZXdvcmtdLCBhbGwgQ0xVRS1jb250cm9sbGVkIFJUUCBzdHJlYW1zIG11c3QgYmUN CiAgICBzZWN1cmVkIGFuZCBpbXBsZW1lbnRlZCB1c2luZyBtZWNoYW5pc21zIHN1Y2ggYXMgU1JU UCBbUkZDMzcxMV0uICBDTFVFDQogICAgaW1wbGVtZW50YXRpb25zIE1BWSBjaG9vc2Ugbm90IHRv IHJlcXVpcmUgdGhlIHVzZSBvZiBTUlRQIHRvIHNlY3VyZSBsZWdhY3kNCiAgICAobm9uLUNMVUUt Y29udHJvbGxlZCkgbWVkaWEgZm9yIGJhY2t3YXJkcyBjb21wYXRpYmlsaXR5IHdpdGggb2xkZXIN CiAgICBTSVAgY2xpZW50cyB0aGF0IGFyZSBpbmNhcGFibGUgb2Ygc3VwcG9ydGluZyBTUlRQLg0K DQpTZWN0aW9uIDEyOiAiVG8gcHJldmVudCB0aGlzLCBTSVAgc2lnbmFsaW5nIFNIT1VMRCBhbHdh eXMgYmUgZW5jcnlwdGVkIA0KdXNpbmcgVExTLi4uIiBXaGlsZSBJIGFncmVlIHdpdGggdGhlIHN0 YXRlbWVudCwgSSB0aGluayBpdCdzIGEgYml0IA0Kb3V0c2lkZSB0aGUgcHVydmlldyBvZiB0aGlz IGRvY3VtZW50IHRvIHNwZWNpZnkgdGhpcy4gU3VnZ2VzdDogIi4uLlNJUCANCnNpZ25hbGluZyB1 c2VkIHRvIHNldCB1cCBDTFVFIHNlc3Npb25zIFNIT1VMRC4uLiINCg0KL2ENCg0K From nobody Thu Aug 24 05:53:52 2017 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB00B132937 for ; Thu, 24 Aug 2017 05:53:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] 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 85yNDpzX4qef for ; Thu, 24 Aug 2017 05:53:47 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B833D1326EC for ; Thu, 24 Aug 2017 05:53:46 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml707-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DNG26820; Thu, 24 Aug 2017 12:53:44 +0000 (GMT) Received: from DGGEMM402-HUB.china.huawei.com (10.3.20.210) by lhreml707-cah.china.huawei.com (10.201.108.48) with Microsoft SMTP Server (TLS) id 14.3.301.0; Thu, 24 Aug 2017 13:53:43 +0100 Received: from DGGEMM506-MBX.china.huawei.com ([169.254.3.138]) by DGGEMM402-HUB.china.huawei.com ([10.3.20.210]) with mapi id 14.03.0301.000; Thu, 24 Aug 2017 20:53:36 +0800 From: Roni Even To: "Rob Hansen (rohanse2)" , Adam Roach , "clue@ietf.org" Thread-Topic: AD Review: draft-ietf-clue-signaling-11 Thread-Index: AQHS2/5y7kSFmrH8ikm+frs9dJG8taKOk+JggAVdu0A= Date: Thu, 24 Aug 2017 12:53:35 +0000 Message-ID: <6E58094ECC8D8344914996DAD28F1CCD7FF837@DGGEMM506-MBX.china.huawei.com> References: <0b69d2f1-11e1-8fd1-d4a1-2faacc0a8528@nostrum.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.200.202.75] Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090206.599ECC58.0076, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.3.138, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: e06260926b25bd71c3f41f8fbe49b5d9 Archived-At: Subject: Re: [clue] AD Review: draft-ietf-clue-signaling-11 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Aug 2017 12:53:51 -0000 Hi Rob, Read your response looks good to me and agree with your analysis As for section 4.5.4.3 I think that section 6 of the protocol with the stat= e machine is the right reference Roni > -----Original Message----- > From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Rob Hansen > (rohanse2) > Sent: =E9=E5=ED=A0=E1 21 =E0=E5=E2=E5=F1=E8 2017 05:40 > To: Adam Roach; clue@ietf.org > Subject: Re: [clue] AD Review: draft-ietf-clue-signaling-11 >=20 > Hi Adam, >=20 > Thanks again for the very detailed review. In most cases I've incorporate= d > your suggestions straightforwardedly. There are a few that may warrant > further discussion in the group as a whole though, though, or where I've > failed to find something in the protocol document. >=20 >=20 > Section 4.5.4.3: "Note that this is distinct from cases where the CLUE pr= otocol > negotiation fails, or an error occurs in the CLUE protocol; see [I-D.ietf= -clue- > protocol] for details of media and state preservation in this circumstanc= e." -- I > carefully scrubbed the CLUE protocol document to try to determine what th= is > is referring to. Please change it to "see [I-D.ietf-clue-protocol] sectio= n X.Y.Z", > but replacing "X.Y.Z" with the section that provides the details you allu= de to. >=20 > [Rob] I believe when I wrote this the plan was that call preservation act= ions in > the event of a protocol error/failure would be addressed as part of the > protocol document, but that this section had not yet been written, and th= at > remains the case. Simon, is this something you have planned, or can you > point me at the relevant section? =20 >=20 > BLOCKER: Compare the normative statements in paragraph 2 of Section 5.3: >=20 > Generally, implementations that receive messages for which they have > incomplete information SHOULD wait until they have the corresponding > information they lack before sending messages to make changes related > to that information. For example, an answerer that receives a new > SDP offer with three new "a=3Dsendonly" CLUE "m=3D" lines for which i= t > has received no CLUE Advertisement providing the corresponding > capture information SHOULD include corresponding "a=3Dinactive" lines > in its answer, and SHOULD make a new SDP offer with "a=3Drecvonly" wh= en > and if a new Advertisement arrives with Captures relevant to those > Encodings. >=20 > With the normative statements in section 4.5.2.2: >=20 > If the initial offer contained "a=3Drecvonly" CLUE-controlled media > lines the recipient SHOULD include corresponding "a=3Dsendonly" CLUE- > controlled media lines for accepted Encodings > ... > If the initial offer contained "a=3Dsendonly" CLUE-controlled media > lines the recipient MAY include corresponding "a=3Drecvonly" CLUE- > controlled media lines >=20 > 5.3 says "SHOULD set a=3Dinactive" in the exact same circumstances 4.5.2.= 2 > says "SHOULD set a=3Dsendonly". Please pick one expected behavior and mak= e > sure both sections agree. Ideally, you would refactor this so that the > normative statement is made in only one location. >=20 > [Rob] I don't think these sections are in conflict - the quoted paragraph= from > section 5.3 is referring to cases where the SDP offer includes "a=3Dsendo= nly" > lines, whereas the section in 4.5.2.2 saying "SHOULD set a=3Dsendonly" is > talking about that the SDP *answer* including "a=3Dsendonly" lines in res= ponse > to the offerer's "a=3Drecvonly" lines. It's the paragraph below that corr= esponds > to the quoted 5.3 paragraph, which says that the SDP *answer* MAY include > "a=3Drecvonly" in its response or "MAY" wait, and then references section= 5.3, > which is where the quoted paragraph with recommendation that > implementations should wait and send a subsequent SDP is included. We > ended up with this approach because, even though in most cases > implementations should wait until they receive the information about the > encodings and their contents via the CLUE channel, there are some valid u= se- > cases where implementations will know this up-front and hence can avoid > the need for multiple SDP exchanges. >=20 >=20 > General, but surfaced in section 8: The procedures described in this > document virtually guarantee that every CLUE call that is established wil= l > result in glare (response code 491) behavior. This might cause the operat= ions > folks some heartburn, as it means that their error counts will spike once= CLUE > is deployed. Further, without fairly advanced analysis of the callflow, t= his will > make it impossible to distinguish "expected" CLUE-induced 491s from the > oddball actual glare conditions usually signaled by 491. Has any consider= ation > been given to avoiding this situation (e.g., by having the called party w= ait on > the order of one second before attempting to negotiate its encodings)? >=20 > [Rob] I definitely agree that glare is much more likely at the start of a= CLUE > call. There was quite a bit of discussion in the group on the pros and co= ns of > introducing an asymmetry into the call messaging to avoid (or reduce the > frequency) of glare, and how best to do so, but the final conclusion in t= he > end was not to do so and to rely on SIP's mechanisms to resolve it. >=20 >=20 > Section 10: It is rather unusual to include authors in the acknowledgemen= ts > section. For each of Rob Hansen, Paul Kyzivat, and Christian Groves, I su= ggest > removing the individual's name from either the Acknowledgements section > or from the authors list. >=20 > [Rob] The authors list hasn't really been updated since the initial stage= s. > Looking at other docs like the framework one I can see they've been revis= ed > a fair bit. For now I've left the authors as-is and removed the duplicate > names from the acknowledgements, but will reach out to Paul and Roni for > guidance here. >=20 >=20 > Section 8: "In this case Bob is the Channel Initiator..." this isn't clea= r (and, in > fact, it's counterintuitive to me) -- perhaps there should be some text > indicating *why* Bob is the Channel Initiator. >=20 > [Rob] I've made explicit that, when the SCTP over DTLS channel is negotia= ted, > Bob ends up the client and hence the Channel Initiator. However, when I > went to double-check that that was how the initiator role was assigned, I > can't actually find anything in the protocol or datachannel document that > defines who ends up with the Initiator role. That definitely seems like > something that we need to fix... (unless I've just failing to find it). S= imon, is > this something you're planning to address? >=20 >=20 >=20 > -----Original Message----- > From: Adam Roach [mailto:adam@nostrum.com] > Sent: 03 June 2017 01:15 > To: clue@ietf.org > Cc: clue-chairs@ietf.org; draft-ietf-clue-signaling@tools.ietf.org > Subject: AD Review: draft-ietf-clue-signaling-11 >=20 > CLUE working group -- >=20 > I have completed my AD review for the CLUE signaling document. The > document is generally in good shape, but I think we'll need another revis= ion > before putting it in front of the IETF for last call (especially due to t= he > apparent incomplete removal of support for specifying multiple CLUE group= s > per session). >=20 > Most of my comments below are feedback that the document authors > should treat as normal last call comments. The feedback that I consider t= o > block progressing the document, in my role as AD, is explicitly marked wi= th > the prefix "BLOCKER", and these will need to be resolved in a new version= of > the document before progressing it further. Note that it is entirely poss= ible > that something I have marked "BLOCKER" may stem from an error on my > part; so recognize that these are not demands for change, as much as a ne= ed > to have things either fixed in the document or explained to me. >=20 > Title: The rule of thumb is that all but a small handful of well-known ac= ronyms > need to be expanded in titles and abstracts. I recognize that "CLUE" is a= bit > tortured, as acronyms go, but the title of this document is, broadly spea= king, > opaque. Please change it to something meaningful, such as "Session Signal= ing > for Controlling Multiple Streams for Telepresence (CLUE)" >=20 > BLOCKER: General: It is clear from reading this version of the document t= hat > earlier versions contained the notion of multiple "a=3Dgroup:CLUE" > lines in a single SDP description. This version appears to have tried to = remove > all related text, but there are still enough mentions that talk about CLU= E > groups in a way that implies that there can be multiples so as to cause > confusion. These need to be cleaned up. I call the specific instances out= on a > section-by-section basis below. I'm mentioning it up here since it's real= ly only > one blocker issue with a bunch of instances. >=20 > General: The _protocol_ document has a host of different terms for each > kind of CLUE message (e.g., "ADVERTISEMENT," "ADV," and "advertisement" > for the same operation). This document exacerbates the situation by > introducing yet more variations, such as "Advertisement" and "Configure". > Please coordinate with draft-ietf-clue-protocol to use a consistent set o= f > names for these operations between the two documents. >=20 > Introduction: The convention I see in this document is to write defined t= erms > with initial caps; please replace "encoding group" with "Encoding Group." >=20 > Section 3: Please add a reference to RFC3840 (e.g.: 'The "sip.clue" > media feature tag [RFC3840] indicates...") >=20 > Section 4.2: "Presence of the data channel in a CLUE group..." implies th= ere > can be more than one group. Replace "a" with "the." >=20 > Section 4.3: ...its "mid" value MUST be included in a CLUE group' > implies there can be more than one group. Replace "a" with "the." >=20 > Section 4.4.1: "...in a CLUE group as defined above." implies there can b= e > more than one group. Replace "a" with "the." >=20 > Section 4.4.1: '..."m=3D" lines in the same CLUE group in the SDP message= ...' > very strongly implies there can be more than one group. > Rephrase, perhaps along the lines of "...CLUE-controlled "m=3D" lines in = the > SDP message..." >=20 > 4.4.2: 'These "m=3D" lines are CLUE-controlled and hence MUST include the= ir > "mid" in the CLUE group corresponding to the CLUE group of the Encoding > they wish to receive.' is getting pretty explicit about the presence of m= ultiple > CLUE groups. Fix. >=20 > 4.5.2.1, first sentence: Replace "If the recipient is a CLUE-capable..." > with "If the recipient of an offer is a CLUE-capable..." >=20 > BLOCKER: Section 4.5.2.2: For avoidance of doubt, this section should cle= arly > indicate what the answer should do with CLUE-controlled lines that it has= no > intention of receiving (for sendonly) or sending (for recvonly). I believ= e the > expectation here is to set the port to zero (rather than, e.g., setting t= he > direction to inactive). The document should explicitly state this behavio= r: if > implementations make different choices between port-zero and inactive and > don't expect the other behavior, you can end up with incompatibilities. >=20 > Section 4.5.3.1, paragraph 2: My recollection is that telling implementor= s not > to send media is frequently misinterpreted to mean that they don't have t= o > send/receive RTCP either. This causes all kinds of grief. It will probabl= y head > off issues if this section is phrased more like "...MAY choose not to sen= d RTP > on the non-CLUE-controlled channels (although RTCP is still sent and rece= ived > as normal) during the period..." >=20 > Section 4.5.4.1: 'Subsequent offer/answer exchanges MAY add additional > "m=3D" lines...' -- this should probably also mention "and activate inact= ive > ones." >=20 > Section 4.5.4.1: 'Subsequent offer/answer exchanges MAY also deactivate > "m=3D" lines for CLUE-controlled media.' -- again, the interpretation of > "deactivate" may be different between implementors. Please be clear about > whether this means "a=3Dinactive", port=3D0, or both. >=20 > Section 4.5.4.1: The final paragraph talks about "deactivating" non-CLUE > media. Again, this should be explicit about what is meant. >=20 > Section 4.5.4.2: 'If, in an ongoing non-CLUE call, an SDP offer/answer > exchange completes with both sides having included a data channel "m=3D" > line in their SDP and with the "mid" for that channel in corresponding CL= UE > groups..." implies that there can be more than one CLUE group. Fix. >=20 > Section 4.5.4.3: "...include the data channel in a matching CLUE group...= " > implies there can be more than one group. Replace "a matching" > with "the." >=20 > Section 4.5.4.3: "Any active "m=3D" lines still included in a CLUE group.= .." implies > there can be more than one group. Replace "a" with "the." >=20 > Section 4.5.4.3: "Note that this is distinct from cases where the CLUE pr= otocol > negotiation fails, or an error occurs in the CLUE protocol; see [I-D.ietf= -clue- > protocol] for details of media and state preservation in this circumstanc= e." -- I > carefully scrubbed the CLUE protocol document to try to determine what th= is > is referring to. Please change it to "see [I-D.ietf-clue-protocol] sectio= n X.Y.Z", > but replacing "X.Y.Z" with the section that provides the details you allu= de to. >=20 >=20 > BLOCKER: Compare the normative statements in paragraph 2 of Section 5.3: >=20 > Generally, implementations that receive messages for which they have > incomplete information SHOULD wait until they have the corresponding > information they lack before sending messages to make changes related > to that information. For example, an answerer that receives a new > SDP offer with three new "a=3Dsendonly" CLUE "m=3D" lines for which i= t > has received no CLUE Advertisement providing the corresponding > capture information SHOULD include corresponding "a=3Dinactive" lines > in its answer, and SHOULD make a new SDP offer with "a=3Drecvonly" wh= en > and if a new Advertisement arrives with Captures relevant to those > Encodings. >=20 > With the normative statements in section 4.5.2.2: >=20 > If the initial offer contained "a=3Drecvonly" CLUE-controlled media > lines the recipient SHOULD include corresponding "a=3Dsendonly" CLUE- > controlled media lines for accepted Encodings > ... > If the initial offer contained "a=3Dsendonly" CLUE-controlled media > lines the recipient MAY include corresponding "a=3Drecvonly" CLUE- > controlled media lines >=20 > 5.3 says "SHOULD set a=3Dinactive" in the exact same circumstances 4.5.2.= 2 > says "SHOULD set a=3Dsendonly". Please pick one expected behavior and mak= e > sure both sections agree. Ideally, you would refactor this so that the > normative statement is made in only one location. >=20 >=20 > Section 7 appears to be oddly silent on the use of RTCP MUX. I suspect th= at > the intention is that CLUE will generally multiplex RTCP when using BUNDL= E? I > would expect this to be called out. >=20 > Section 7 offers that the use of BUNDLE has the advantage of reducing the > number of ICE candidates that need to be collected. This is true only in = the > case that some m=3D section are marked as bundle-only; this, in turn, imp= lies > that a bundled offer is going to contain one or more m=3D sections that w= ill fail > if the remote endpoint does not implement BUNDLE. This interacts > particularly badly with the text in section 4.5.1 that allows, under cert= ain > circumstances, that 'the initial offer MAY contain "m=3D" lines for CLUE- > controlled media.', since you can end up with the whole CLUE session fall= ing > apart if the bundle-only lines are not chosen carefully. This is a relati= vely > complicated issue that I wouldn't expect impementors to get correct witho= ut > some guidance on the use of bundle-only, and in particular its interactio= n > with CLUE-controlled lines. Please add text to Section 7 that discusses t= hese > issues. >=20 > Section 8: Please insert a page break before the ladder diagram so that t= he > entity names don't appear on a page by themselves. >=20 > Section 8: "In this case Bob is the Channel Initiator..." this isn't clea= r (and, in > fact, it's counterintuitive to me) -- perhaps there should be some text > indicating *why* Bob is the Channel Initiator. >=20 > General, but surfaced in section 8: The procedures described in this > document virtually guarantee that every CLUE call that is established wil= l > result in glare (response code 491) behavior. This might cause the operat= ions > folks some heartburn, as it means that their error counts will spike once= CLUE > is deployed. Further, without fairly advanced analysis of the callflow, t= his will > make it impossible to distinguish "expected" CLUE-induced 491s from the > oddball actual glare conditions usually signaled by 491. Has any consider= ation > been given to avoiding this situation (e.g., by having the called party w= ait on > the order of one second before attempting to negotiate its encodings)? >=20 >=20 > Section 8 contains the following text: >=20 > Bob also sends his SDP answer as part of SIP 200 OK 2. Alongside his > original audio, video and CLUE "m=3D" lines he includes two active > recvonly "m=3D "lines and a zeroed "m=3D" line for the third. >=20 > This should probably be qualified to indicate that these are the same m- > sections as were present in the offer (as opposed to creating new section= s). >=20 >=20 > Section 8: Replace "Having received this Alice..." with "Having received = this > offer, Alice..." >=20 > Section 9: "From the lack of the data channel and grouping framework..." > -- it should be noted that implementations that end up in communication > with normal non-CLUE WebRTC implementations might get a datachannel > but no CLUE group. The quoted text implies that the presence or absence o= f > a datachannel can be used to determine CLUE support, which might cause > implementors to rely on that exclusively. Please change the text to indic= ate > that the CLUE group should be used as the sole determinant of CLUE suppor= t > (at least, as far as SDP signaling is concerned). >=20 > Section 10: It is rather unusual to include authors in the acknowledgemen= ts > section. For each of Rob Hansen, Paul Kyzivat, and Christian Groves, I su= ggest > removing the individual's name from either the Acknowledgements section > or from the authors list. >=20 > Section 11.2: "This specification registers a new media feature tag in th= e SIP > [RFC3264] tree..." This should cite RFC3261 for SIP rather than RFC3264. >=20 > Section 11.2: Please indicate "iesg@ietf.org" as the contact for this > registration. >=20 >=20 > BLOCKING: Section 12 indicates that no security mechanisms are mandatory > to use "due to the issues addressed in [RFC7202]." This vastly misconstru= es > the intent and text of RFC7202, which (roughly speaking) says "we don't > mandate security for RTP in general because it is used in a vast and vari= ed > array of applications." CLUE is a very specific, very narrow application = of RTP > that does not suffer from the generality that makes a one-size-fits-all > solution for RTP infeasible. In fact, RFC7202 is quite clear that its gui= dance > applies exclusively to RTP, and not to protocols that *use* RTP: "Documen= ts > that define an interoperable class of applications using RTP are subject = to > [RFC3365], and thus need to specify MTI security mechanisms." If there ar= e > specific arguments put forth in RFC7202 that the working group believes a= lso > apply to this document, please reiterate them here. The current citation = to > RFC7202 is problematic, though, since it says the opposite of what this > security section implies. >=20 > If I understand it correctly, though, the argument to put forth here is t= hat > implementations MAY choose not to secure legacy > (non-CLUE-controlled) media lines because SIP was specified prior to > RFC3365, and was therefore not bound by its requirements; and, as a > consequence, many existing SIP endpoints are incapable of using DTLS-SRTP= . > This rationale is orthogonal to the guidance in RFC7202, and should not c= ite it. >=20 > The use of "DTLS" to refer to "DTLS-SRTP" is also confusing, as they are > different things. >=20 > I propose changing the paragraph as follows: >=20 > This attack can be prevented by ensuring that the media recipient int= ends > to receive the media packets. As such, all CLUE-capable devices MUST > support key negotiation and receiver intent assurance via DTLS-SRTP > [RFC5763] on CLUE-controlled RTP "m=3D" lines. As specified in > [I-D.ietf-clue-framework], all CLUE-controlled RTP streams must be > secured and implemented using mechanisms such as SRTP [RFC3711]. > CLUE > implementations MAY choose not to require the use of SRTP to secure > legacy > (non-CLUE-controlled) media for backwards compatibility with older > SIP clients that are incapable of supporting SRTP. >=20 > Section 12: "To prevent this, SIP signaling SHOULD always be encrypted us= ing > TLS..." While I agree with the statement, I think it's a bit outside the = purview > of this document to specify this. Suggest: "...SIP signaling used to set = up CLUE > sessions SHOULD..." >=20 > /a >=20 > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From nobody Thu Aug 24 12:22:00 2017 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C3941320CF for ; Thu, 24 Aug 2017 12:21:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.88 X-Spam-Level: X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] 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 Z--l7taBauGq for ; Thu, 24 Aug 2017 12:21:57 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 45A49124207 for ; Thu, 24 Aug 2017 12:21:57 -0700 (PDT) Received: from Orochi.local (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v7OJLnHd001360 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 24 Aug 2017 14:21:50 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be Orochi.local To: Roni Even , "Rob Hansen (rohanse2)" , "clue@ietf.org" References: <0b69d2f1-11e1-8fd1-d4a1-2faacc0a8528@nostrum.com> <6E58094ECC8D8344914996DAD28F1CCD7FF837@DGGEMM506-MBX.china.huawei.com> From: Adam Roach Message-ID: <9639e320-026d-57ed-4666-bdb3245309fd@nostrum.com> Date: Thu, 24 Aug 2017 14:21:44 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <6E58094ECC8D8344914996DAD28F1CCD7FF837@DGGEMM506-MBX.china.huawei.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [clue] AD Review: draft-ietf-clue-signaling-11 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Aug 2017 19:21:58 -0000 On 8/24/17 07:53, Roni Even wrote: > Hi Rob, > Read your response looks good to me and agree with your analysis > As for section 4.5.4.3 I think that section 6 of the protocol with the state machine is the right reference > Roni > I don't see anything in section 6 of -protocol (or the state machine it contains) dealing with "media preservation" or "state preservation" in the face of CLUE protocol negotiation failures or errors. I agree that this would be a good place to discuss such things, but right now, it appears to be left ambiguous whether (e.g.) a CLUE setup failure has any impact on the media. /a From nobody Thu Aug 24 17:29:49 2017 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E66111329CD for ; Thu, 24 Aug 2017 17:29:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.879 X-Spam-Level: X-Spam-Status: No, score=-1.879 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, 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 aPTksJnMYZEv for ; Thu, 24 Aug 2017 17:29:45 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 766A6132377 for ; Thu, 24 Aug 2017 17:29:45 -0700 (PDT) Received: from Orochi.local (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v7P0TdAr053348 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 24 Aug 2017 19:29:42 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be Orochi.local From: Adam Roach To: "Rob Hansen (rohanse2)" , "clue@ietf.org" References: <0b69d2f1-11e1-8fd1-d4a1-2faacc0a8528@nostrum.com> Message-ID: Date: Thu, 24 Aug 2017 19:29:33 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [clue] AD Review: draft-ietf-clue-signaling-11 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Aug 2017 00:29:48 -0000 Thanks! Responses inline. On 8/20/17 21:40, Rob Hansen (rohanse2) wrote: > Section 4.5.4.3: "Note that this is distinct from cases where the CLUE protocol negotiation fails, or an error occurs in the CLUE protocol; see [I-D.ietf-clue-protocol] for details of media and state preservation in this circumstance." -- I carefully scrubbed the CLUE protocol document to try to determine what this is referring to. Please change it to "see [I-D.ietf-clue-protocol] section X.Y.Z", but replacing "X.Y.Z" with the section that provides the details you allude to. > > [Rob] I believe when I wrote this the plan was that call preservation actions in the event of a protocol error/failure would be addressed as part of the protocol document, but that this section had not yet been written, and that remains the case. Simon, is this something you have planned, or can you point me at the relevant section? Simon is on vacation for (I think) at least another week or so; but I agree that this may need some coordination. See also my earlier response to Roni. > BLOCKER: Compare the normative statements in paragraph 2 of Section 5.3: > > Generally, implementations that receive messages for which they have > incomplete information SHOULD wait until they have the corresponding > information they lack before sending messages to make changes related > to that information. For example, an answerer that receives a new > SDP offer with three new "a=sendonly" CLUE "m=" lines for which it > has received no CLUE Advertisement providing the corresponding > capture information SHOULD include corresponding "a=inactive" lines > in its answer, and SHOULD make a new SDP offer with "a=recvonly" when > and if a new Advertisement arrives with Captures relevant to those > Encodings. > > With the normative statements in section 4.5.2.2: > > If the initial offer contained "a=recvonly" CLUE-controlled media > lines the recipient SHOULD include corresponding "a=sendonly" CLUE- > controlled media lines for accepted Encodings > ... > If the initial offer contained "a=sendonly" CLUE-controlled media > lines the recipient MAY include corresponding "a=recvonly" CLUE- > controlled media lines > > 5.3 says "SHOULD set a=inactive" in the exact same circumstances 4.5.2.2 says "SHOULD set a=sendonly". Please pick one expected behavior and make sure both sections agree. Ideally, you would refactor this so that the normative statement is made in only one location. > > [Rob] I don't think these sections are in conflict - the quoted paragraph from section 5.3 is referring to cases where the SDP offer includes "a=sendonly" lines, whereas the section in 4.5.2.2 saying "SHOULD set a=sendonly" is talking about that the SDP *answer* including "a=sendonly" lines in response to the offerer's "a=recvonly" lines. It's the paragraph below that corresponds to the quoted 5.3 paragraph, which says that the SDP *answer* MAY include "a=recvonly" in its response or "MAY" wait, and then references section 5.3, which is where the quoted paragraph with recommendation that implementations should wait and send a subsequent SDP is included. We ended up with this approach because, even though in most cases implementations should wait until they receive the information about the encodings and their contents via the CLUE channel, there are some valid use-cases where implementations will know this up-front and hence can avoid the need for multiple SDP exchanges. Ah, okay. I see what you're getting at here. I think the problem, then, is that the language in 5.3 isn't really normative per se (or, rather, it shouldn't be normative), as much as it is illustrative. (This is reinforced by the phrasing "For example...") I would propose: For example, an answerer that receives a new SDP offer with three new "a=sendonly" CLUE "m=" lines for which it has received no CLUE Advertisement providing the corresponding capture information would typically include corresponding "a=inactive" lines in its answer, and make a new SDP offer with "a=recvonly" only when and if a new Advertisement arrives with Captures relevant to those Encodings. > General, but surfaced in section 8: The procedures described in this document virtually guarantee that every CLUE call that is established will result in glare (response code 491) behavior. This might cause the operations folks some heartburn, as it means that their error counts will spike once CLUE is deployed. Further, without fairly advanced analysis of the callflow, this will make it impossible to distinguish "expected" CLUE-induced 491s from the oddball actual glare conditions usually signaled by 491. Has any consideration been given to avoiding this situation (e.g., by having the called party wait on the order of one second before attempting to negotiate its encodings)? > > [Rob] I definitely agree that glare is much more likely at the start of a CLUE call. There was quite a bit of discussion in the group on the pros and cons of introducing an asymmetry into the call messaging to avoid (or reduce the frequency) of glare, and how best to do so, but the final conclusion in the end was not to do so and to rely on SIP's mechanisms to resolve it. Sure. What I'd like to have positive confirmation on is: did the working group specifically consider the operational aspects of this decision? I agree that it works from a protocol perspective. I'm just worried that it will give operators unnecessary difficulty. > Section 10: It is rather unusual to include authors in the acknowledgements section. For each of Rob Hansen, Paul Kyzivat, and Christian Groves, I suggest removing the individual's name from either the Acknowledgements section or from the authors list. > > [Rob] The authors list hasn't really been updated since the initial stages. Looking at other docs like the framework one I can see they've been revised a fair bit. For now I've left the authors as-is and removed the duplicate names from the acknowledgements, but will reach out to Paul and Roni for guidance here. Thanks. Either resolution makes sense to me, and I suspect that the current author list is correct. > Section 8: "In this case Bob is the Channel Initiator..." this isn't clear (and, in fact, it's counterintuitive to me) -- perhaps there should be some text indicating *why* Bob is the Channel Initiator. > > [Rob] I've made explicit that, when the SCTP over DTLS channel is negotiated, Bob ends up the client and hence the Channel Initiator. However, when I went to double-check that that was how the initiator role was assigned, I can't actually find anything in the protocol or datachannel document that defines who ends up with the Initiator role. That definitely seems like something that we need to fix... (unless I've just failing to find it). Simon, is this something you're planning to address? The reason this seems counter-intuitve to me is that it is backwards from how RTCWEB (JSEP) works in the general case. To be clear, for datachannels, the TLS client is selected by the "a=setup" attribute; and JSEP implementations are required (MUST) to put "a=setup:actpass" in their offers, and expected (SHOULD) to put "a=setup:active" in their answers. The rationale here is: the way ICE ends up working, the answerer will have the first opportunity to send a packet, so this reduces overall setup time by ~1/2-RTT. Of course, CLUE is free to do this however it wants [1]; but doing it opposite from RTCWEB is likely to confuse people beyond just me. I think you'd also need a reasonably good rationale, as a naïve analysis of CLUE is that doing it the way you currently have in your examples is generally going to impose an additional 1/2-RTT delay on datachannel establishment. But I freely admit that I haven't spent a lot of time thinking about the low-level details, and could be overlooking something. /a ____ [1] Subject to the constraints in , sections 10 - 11 From nobody Fri Aug 25 07:29:49 2017 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0AD9132BF1 for ; Fri, 25 Aug 2017 07:29:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C0HYYdoKthZv for ; Fri, 25 Aug 2017 07:29:46 -0700 (PDT) Received: from alum-mailsec-scanner-3.mit.edu (alum-mailsec-scanner-3.mit.edu [18.7.68.14]) by ietfa.amsl.com (Postfix) with ESMTP id E5F10132944 for ; Fri, 25 Aug 2017 07:29:45 -0700 (PDT) X-AuditID: 1207440e-bf9ff70000007085-68-59a03458eb4f Received: from outgoing-alum.mit.edu (OUTGOING-ALUM.MIT.EDU [18.7.68.33]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by alum-mailsec-scanner-3.mit.edu (Symantec Messaging Gateway) with SMTP id 0A.84.28805.85430A95; Fri, 25 Aug 2017 10:29:44 -0400 (EDT) Received: from PaulKyzivatsMBP.localdomain (c-24-62-227-142.hsd1.ma.comcast.net [24.62.227.142]) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.13.8/8.12.4) with ESMTP id v7PEThv8016971 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Fri, 25 Aug 2017 10:29:44 -0400 To: clue@ietf.org References: <0b69d2f1-11e1-8fd1-d4a1-2faacc0a8528@nostrum.com> From: Paul Kyzivat Message-ID: <5cdce8dc-9336-0f19-04bd-fa3430e04eef@alum.mit.edu> Date: Fri, 25 Aug 2017 10:29:43 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrPIsWRmVeSWpSXmKPExsUixO6iqBtpsiDS4PN7Rov9py4zOzB6LFny kymAMYrLJiU1J7MstUjfLoErY+/EeawF+7kqTt9bzN7AuJyji5GTQ0LAROLY7PlMXYxcHEIC O5gkXmybwArhfGWS6Jh9gR2kSljAWmLawoNACQ4OEQFBiZdXBCFq1jFK/Pw3mQWkhk1AS2LO of9gNq+AvcSDdRPAbBYBVYmu/+uZQWxRgTSJf7vPMkLUCEqcnPkErIYTqP7jg7dMIDazgJnE vM0PmSFscYlbT+ZDxeUlmrfOZp7AyD8LSfssJC2zkLTMQtKygJFlFaNcYk5prm5uYmZOcWqy bnFyYl5eapGusV5uZoleakrpJkZIWPLtYGxfL3OIUYCDUYmH98aVeZFCrIllxZW5hxglOZiU RHmtX86PFOJLyk+pzEgszogvKs1JLT7EKMHBrCTCe0V7QaQQb0piZVVqUT5MSpqDRUmcV22J up+QQHpiSWp2ampBahFMVoaDQ0mCN8UYqFGwKDU9tSItM6cEIc3EwQkynAdoOCdIDW9xQWJu cWY6RP4Uoy7Hr5lbvzAJseTl56VKifOaghQJgBRllObBzYGlk1eM4kBvCfOqglTxAFMR3KRX QEuYgJZMOjEHZElJIkJKqoExh+eA69l080NZmusVeVf/kNlpz+bxNE513/PtKRfZJjQdvOw4 mUdjKt/l3KmbBFlX7C7Ltrg3Ryx0jvXG8z7iVrd5C+qiFwXPq53x9XSbqs2hVZd5X+3Smsn0 fOpKr/zD5stZdl0L61uxYCbr+8K9OjY526fuUN5kJ9MbeCPSb5VE+6tr0/adUGIpzkg01GIu Kk4EAKXPkQACAwAA Archived-At: Subject: Re: [clue] AD Review: draft-ietf-clue-signaling-11 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Aug 2017 14:29:48 -0000 On 8/24/17 8:29 PM, Adam Roach wrote: > The reason this seems counter-intuitve to me is that it is backwards > from how RTCWEB (JSEP) works in the general case. To be clear, for > datachannels, the TLS client is selected by the "a=setup" attribute; and > JSEP implementations are required (MUST) to put "a=setup:actpass" in > their offers, and expected (SHOULD) to put "a=setup:active" in their > answers. The rationale here is: the way ICE ends up working, the > answerer will have the first opportunity to send a packet, so this > reduces overall setup time by ~1/2-RTT. > > Of course, CLUE is free to do this however it wants [1]; but doing it > opposite from RTCWEB is likely to confuse people beyond just me. I think > you'd also need a reasonably good rationale, as a naïve analysis of CLUE > is that doing it the way you currently have in your examples is > generally going to impose an additional 1/2-RTT delay on datachannel > establishment. But I freely admit that I haven't spent a lot of time > thinking about the low-level details, and could be overlooking something. It does seem to me that this needs to be carefully aligned with RTCWEB because one of our goals was that interoperation with RTCWEB be possible. (That is why we chose data channels in the first place.) Thanks, Paul