From nobody Tue Sep 1 02:39:57 2015 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24AE81B8E72; Tue, 1 Sep 2015 02:39:54 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham 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 fIXafz4LXBbC; Tue, 1 Sep 2015 02:39:49 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2822A1B6D2A; Tue, 1 Sep 2015 02:39:46 -0700 (PDT) X-AuditID: c1b4fb2d-f79626d000004282-6c-55e572617678 Received: from ESESSHC016.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 7D.17.17026.16275E55; Tue, 1 Sep 2015 11:39:45 +0200 (CEST) Received: from ESESSMB105.ericsson.se ([169.254.5.220]) by ESESSHC016.ericsson.se ([153.88.183.66]) with mapi id 14.03.0248.002; Tue, 1 Sep 2015 11:39:44 +0200 From: Bo Burman To: Spencer Dawkins at IETF Thread-Topic: Spencer Dawkins' Yes on draft-ietf-avtext-rtp-stream-pause-08: (with COMMENT) Thread-Index: AQHQ2i14cHa9zh/TA0q/GOwjYo3IwZ4fnZbwgAAWlwCAB7t5gA== Date: Tue, 1 Sep 2015 09:39:44 +0000 Message-ID: References: <20150819031636.31652.86423.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.19] Content-Type: multipart/alternative; boundary="_000_BBE9739C2C302046BD34B42713A1E2A22E70B1EDESESSMB105erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrNIsWRmVeSWpSXmKPExsUyM+JvjW5i0dNQgykrxS3az51gsfh47war xdJZXawWu29MZrHoermD2WLGn4nMFvsXn2e2WDZlD7MDh8fOWXfZPZYs+cnk0fbsDnsAcxSX TUpqTmZZapG+XQJXxv/JR9kKWtqYK+4c2MrawPjhN1MXIyeHhICJxLuD01kgbDGJC/fWs4HY QgJHGSWOfi/qYuQCshczSnybdhmsgU1AQ2L+jruMILaIgLXElr5ONpAiZoE7zBIPHi8GmyQs ECNxqeEJM0RRrMTBk7vZIGwniW1r3oDZLAIqEheb29hBbF4BX4kji7axQ2w7wyhxYMFRsCJO gUCJpsknwWxGAVmJ+9/vgS1gFhCXuPVkPtQLAhJL9pxnhrBFJV4+/scKYStKtD9tYISoz5d4 d+cME8QyQYmTM5+wTGAUnYVk1CwkZbOQlM1i5ACKa0qs36UPUaIoMaX7ITuErSHROmcuO7L4 Akb2VYyixanFxbnpRsZ6qUWZycXF+Xl6eaklmxiBsXtwy2/dHYyrXzseYhTgYFTi4V3A9jRU iDWxrLgy9xCjNAeLkjhvC9ODUCGB9MSS1OzU1ILUovii0pzU4kOMTBycUg2Mko+FXnV1/Tz3 PO+glcbM66pWMRzGxx6bsqra+rMufSLIweiSf0xsFoPOZJPcM2HOnuYzZ1s1pHSXMjxesZb7 t8aCIK8lG9f+51+bdXV26x2r76rCgZv+TK/1eeX3tO/vDJZJe6dkCBdctcvR3dKRIO8V98z3 +9nNe2Uljrbz+5zmdOX4LxqjxFKckWioxVxUnAgAAxw7qb4CAAA= Archived-At: Cc: "jonathan@vidyo.com" , "avtext@ietf.org" , "avtext-chairs@ietf.org" , "draft-ietf-avtext-rtp-stream-pause@ietf.org" , The IESG , "draft-ietf-avtext-rtp-stream-pause.ad@ietf.org" , "draft-ietf-avtext-rtp-stream-pause.shepherd@ietf.org" Subject: Re: [avtext] Spencer Dawkins' Yes on draft-ietf-avtext-rtp-stream-pause-08: (with COMMENT) X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Sep 2015 09:39:54 -0000 --_000_BBE9739C2C302046BD34B42713A1E2A22E70B1EDESESSMB105erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgU3BlbmNlciwNCg0KSSB0aGluayB5b3VyIHByb3Bvc2FscyBhcmUgZ29vZCBhbmQgd2lsbCBt YWtlIGNoYW5nZXMgYWNjb3JkaW5nbHkuIFNlZSBtb3JlIGlubGluZS4NCg0KRnJvbTogU3BlbmNl ciBEYXdraW5zIGF0IElFVEYgW21haWx0bzpzcGVuY2VyZGF3a2lucy5pZXRmQGdtYWlsLmNvbV0N ClNlbnQ6IGRlbiAyNyBhdWd1c3RpIDIwMTUgMTQ6MzcNClRvOiBCbyBCdXJtYW4NCkNjOiBUaGUg SUVTRzsgZHJhZnQtaWV0Zi1hdnRleHQtcnRwLXN0cmVhbS1wYXVzZUBpZXRmLm9yZzsgZHJhZnQt aWV0Zi1hdnRleHQtcnRwLXN0cmVhbS1wYXVzZS5hZEBpZXRmLm9yZzsgam9uYXRoYW5AdmlkeW8u Y29tOyBkcmFmdC1pZXRmLWF2dGV4dC1ydHAtc3RyZWFtLXBhdXNlLnNoZXBoZXJkQGlldGYub3Jn OyBhdnRleHQtY2hhaXJzQGlldGYub3JnOyBhdnRleHRAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBT cGVuY2VyIERhd2tpbnMnIFllcyBvbiBkcmFmdC1pZXRmLWF2dGV4dC1ydHAtc3RyZWFtLXBhdXNl LTA4OiAod2l0aCBDT01NRU5UKQ0KDQpIaSwgQm8sDQoNCk9uIFRodSwgQXVnIDI3LCAyMDE1IGF0 IDY6MjggQU0sIEJvIEJ1cm1hbiA8Ym8uYnVybWFuQGVyaWNzc29uLmNvbTxtYWlsdG86Ym8uYnVy bWFuQGVyaWNzc29uLmNvbT4+IHdyb3RlOg0KVGhhbmsgeW91IGZvciBnb29kIGFuZCBjb25zdHJ1 Y3RpdmUgY29tbWVudHMuIFBsZWFzZSBmaW5kIHJlc3BvbnNlcyB0byB5b3VyIHF1ZXN0aW9ucyBp bmxpbmUgYmVsb3cuDQpDaGVlcnMsDQpCbw0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t DQo+IEZyb206IFNwZW5jZXIgRGF3a2lucyBbbWFpbHRvOnNwZW5jZXJkYXdraW5zLmlldGZAZ21h aWwuY29tPG1haWx0bzpzcGVuY2VyZGF3a2lucy5pZXRmQGdtYWlsLmNvbT5dDQo+IFNlbnQ6IGRl biAxOSBhdWd1c3RpIDIwMTUgMDU6MTcNCj4gVG86IFRoZSBJRVNHDQo+IENjOiBkcmFmdC1pZXRm LWF2dGV4dC1ydHAtc3RyZWFtLXBhdXNlQGlldGYub3JnPG1haWx0bzpkcmFmdC1pZXRmLWF2dGV4 dC1ydHAtc3RyZWFtLXBhdXNlQGlldGYub3JnPjsgZHJhZnQtaWV0Zi1hdnRleHQtcnRwLXN0cmVh bS1wYXVzZS5hZEBpZXRmLm9yZzxtYWlsdG86ZHJhZnQtaWV0Zi1hdnRleHQtcnRwLXN0cmVhbS1w YXVzZS5hZEBpZXRmLm9yZz47IGpvbmF0aGFuQHZpZHlvLmNvbTxtYWlsdG86am9uYXRoYW5Admlk eW8uY29tPjsNCj4gZHJhZnQtaWV0Zi1hdnRleHQtcnRwLXN0cmVhbS1wYXVzZS5zaGVwaGVyZEBp ZXRmLm9yZzxtYWlsdG86ZHJhZnQtaWV0Zi1hdnRleHQtcnRwLXN0cmVhbS1wYXVzZS5zaGVwaGVy ZEBpZXRmLm9yZz47IGF2dGV4dC1jaGFpcnNAaWV0Zi5vcmc8bWFpbHRvOmF2dGV4dC1jaGFpcnNA aWV0Zi5vcmc+OyBhdnRleHRAaWV0Zi5vcmc8bWFpbHRvOmF2dGV4dEBpZXRmLm9yZz4NCj4gU3Vi amVjdDogU3BlbmNlciBEYXdraW5zJyBZZXMgb24gZHJhZnQtaWV0Zi1hdnRleHQtcnRwLXN0cmVh bS1wYXVzZS0wODogKHdpdGggQ09NTUVOVCkNCj4NCj4gU3BlbmNlciBEYXdraW5zIGhhcyBlbnRl cmVkIHRoZSBmb2xsb3dpbmcgYmFsbG90IHBvc2l0aW9uIGZvcg0KPiBkcmFmdC1pZXRmLWF2dGV4 dC1ydHAtc3RyZWFtLXBhdXNlLTA4OiBZZXMNCj4NCj4gV2hlbiByZXNwb25kaW5nLCBwbGVhc2Ug a2VlcCB0aGUgc3ViamVjdCBsaW5lIGludGFjdCBhbmQgcmVwbHkgdG8gYWxsIGVtYWlsIGFkZHJl c3NlcyBpbmNsdWRlZCBpbiB0aGUgVG8gYW5kIENDIGxpbmVzLg0KPiAoRmVlbCBmcmVlIHRvIGN1 dCB0aGlzIGludHJvZHVjdG9yeSBwYXJhZ3JhcGgsIGhvd2V2ZXIuKQ0KPg0KPg0KPiBQbGVhc2Ug cmVmZXIgdG8gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaWVzZy9zdGF0ZW1lbnQvZGlzY3Vzcy1jcml0 ZXJpYS5odG1sDQo+IGZvciBtb3JlIGluZm9ybWF0aW9uIGFib3V0IElFU0cgRElTQ1VTUyBhbmQg Q09NTUVOVCBwb3NpdGlvbnMuDQo+DQo+DQo+IFRoZSBkb2N1bWVudCwgYWxvbmcgd2l0aCBvdGhl ciBiYWxsb3QgcG9zaXRpb25zLCBjYW4gYmUgZm91bmQgaGVyZToNCj4gaHR0cHM6Ly9kYXRhdHJh Y2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1hdnRleHQtcnRwLXN0cmVhbS1wYXVzZS8NCj4N Cj4NCj4NCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiBDT01NRU5UOg0KPiAtLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+DQo+ IFRoaXMgZHJhZnQgd2FzIHJlYWxseSBlYXN5IGZvciBtZSB0byByZWFkICh3aXRoIHNvbWUgYmFj a2dyb3VuZCBpbiBSVFAvUlRDUCwgYnV0IEknbSBubyBleHBlcnQgb24gdGhlIHRvcGljKS4gVGhh bmsgeW91DQo+IGZvciB0aGUgd29yayBvbiBpdCAtIHRoZSByZXN1bHRzIHNob3cuDQo+DQo+IEkg aGF2ZSBzb21lIHF1ZXN0aW9ucywgYnV0IG5vdGhpbmcgaXMgYSBzaG93LXN0b3BwZXIuDQo+DQo+ IEluIHRoaXMgdGV4dDoNCj4NCj4gMy4zLiAgUlRQIE1peGVyIHRvIE1lZGlhIFNlbmRlciBpbiBQ b2ludC10by1NdWx0aXBvaW50DQo+DQo+ICAgIEluIHRoaXMgdXNlIGNhc2UgdGhlcmUgYXJlIHNl dmVyYWwgcmVjZWl2ZXJzIG9mIGEgc3RyZWFtIGFuZCBzcGVjaWFsDQo+ICAgIGNhcmUgbXVzdCBi ZSB0YWtlbiBhcyBub3QgdG8gcGF1c2UgYSBzdHJlYW0gdGhhdCBpcyBzdGlsbCB3YW50ZWQgYnkN Cj4gICAgc29tZSByZWNlaXZlcnMuDQo+DQo+IEknbSBhc3N1bWluZyB0aGF0IHRoZSBNaXhlciBp cyB0YWtpbmcgc3BlY2lhbCBjYXJlLCBidXQgdGhpcyBpcyBwYXNzaXZlIGVub3VnaCB0aGF0IEkn bSBmaWxsaW5nIGluIGJsYW5rcy4gSWYgeW91IGxpa2UgcGFzc2l2ZQ0KPiB2b2ljZSwgcGVyaGFw cyBzb21ldGhpbmcgbGlrZQ0KPg0KPiAgICBJbiB0aGlzIHVzZSBjYXNlIHRoZXJlIGFyZSBzZXZl cmFsIHJlY2VpdmVycyBvZiBhIHN0cmVhbSBhbmQgc3BlY2lhbA0KPiAgICBjYXJlIG11c3QgYmUg dGFrZW4gYnkgdGhlIE1peGVyIHNvIGFzIG5vdCB0byBwYXVzZSBhIHN0cmVhbSB0aGF0IGlzDQo+ ICAgICAgICAgICAgICAgICAgICAgICBeXl5eXl5eXl5eXl5eXl4NCj4gICAgc3RpbGwgd2FudGVk IGJ5IHNvbWUgcmVjZWl2ZXJzLg0KPg0KPiB3b3VsZCBiZSBlYXNpZXIgdG8gcGFyc2UuDQo+DQo+ IElmIHlvdSBjYW4gZG8gYWN0aXZlIHZvaWNlLCBwZXJoYXBzDQo+DQo+ICAgIEluIHRoaXMgdXNl IGNhc2UgdGhlcmUgYXJlIHNldmVyYWwgcmVjZWl2ZXJzIG9mIGEgc3RyZWFtIGFuZCB0aGUNCj4g ICAgTWl4ZXIgbXVzdCB0YWtlIHNwZWNpYWwgY2FyZSBzbyBhcyBub3QgdG8gcGF1c2UgYSBzdHJl YW0gdGhhdCBpcyBzdGlsbA0KPg0KPiAgICBeXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5e DQo+ICAgIHdhbnRlZCBieSBzb21lIHJlY2VpdmVycy4NCltCb0JdIFRoYW5rcywgeW91ciBhc3N1 bXB0aW9uIGlzIGNvcnJlY3QsIGFuZCBJIHRoaW5rIHRoaXMgYWN0aXZlIHZvaWNlIGlzIGVhc2ll ciB0byByZWFkLg0KDQpHcmVhdC4NCg0KPg0KPiBJbiB0aGlzIHRleHQ6DQo+DQo+IDguICBNZXNz YWdlIERldGFpbHMNCj4NCj4gICAgQW55IHJlZmVyZW5jZXMgdG8gUEFVU0UsIFBBVVNFRCwgUkVT VU1FIGFuZCBSRUZVU0VEIGluIHRoaXMgc2VjdGlvbg0KPiAgICBTSEFMTCBiZSB0YWtlbiB0byBh cHBseSB0byB0aGUgZXh0ZW50IHBvc3NpYmxlIGFsc28gd2hlbiBUTU1CUi9UTU1CTg0KPiAgICBh cmUgdXNlZCAoU2VjdGlvbiA1LjYpIGZvciB0aGlzIGZ1bmN0aW9uYWxpdHkuICBUTU1CUi9UTU1C TiBNQVkgYmUNCj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgXl5eDQo+ICAgIHVzZWQgaW5zdGVhZCBvZiB0aGUgbWVzc2FnZXMg ZGVmaW5lZCBpbiB0aGlzIHNwZWNpZmljYXRpb24gd2hlbiB0aGUNCj4gICAgZWZmZWN0aXZlIHRv cG9sb2d5IGlzIHBvaW50LXRvLXBvaW50LiAgSWYgZWl0aGVyIHNlbmRlciBvciByZWNlaXZlcg0K PiAgICBsZWFybnMgdGhhdCB0aGUgdG9wb2xvZ3kgaXMgbm90IHBvaW50LXRvLXBvaW50LCBUTU1C Ui9UTU1CTiBNVVNUIE5PVA0KPiAgICBiZSB1c2VkIGZvciBwYXVzZS9yZXN1bWUgZnVuY3Rpb25h bGl0eS4gIElmIHRoZSBtZXNzYWdlcyBkZWZpbmVkIGluDQo+ICAgIHRoaXMgc3BlY2lmaWNhdGlv biBhcmUgc3VwcG9ydGVkIGluIGFkZGl0aW9uIHRvIFRNTUJSL1RNTUJOIGJ5IGFsbA0KPiAgICBp bnZvbHZlZCBwYXJ0aWVzLCBwYXVzZS9yZXN1bWUgc2lnbmFsaW5nIE1VU1QgdXNlIG1lc3NhZ2Vz IGZyb20gdGhpcw0KPiAgICBzcGVjaWZpY2F0aW9uLiAgSWYgdGhlIHRvcG9sb2d5IGlzIG5vdCBw b2ludC10by1wb2ludCBhbmQgdGhlDQo+ICAgIG1lc3NhZ2VzIGRlZmluZWQgaW4gdGhpcyBzcGVj aWZpY2F0aW9uIGFyZSBub3Qgc3VwcG9ydGVkLCBwYXVzZS8NCj4gICAgcmVzdW1lIGZ1bmN0aW9u YWxpdHkgd2l0aCBUTU1CUi9UTU1CTiBNVVNUIE5PVCBiZSB1c2VkLg0KPg0KPiBBbGwgb2YgdGhp cyBtYWtlcyBzZW5zZSB0byBtZSwgZXhjZXB0IHRoYXQgSSdtIG5vdCB1bmRlcnN0YW5kaW5nIHdo eSBUTU1CUi9UTU1CTiBpcyBhIE1BWS4gVGhlcmUncyBhIGxvdCBvZiB0ZXh0IHRoYXQNCj4gc2F5 cyB5b3UgcmVhbGx5IG5lZWQgdG8gdXNlIHRoZSBtZXNzYWdlcyBmcm9tIHRoaXMgc3BlY2lmaWNh dGlvbiBpbiB0aGlzIGNhc2UsIGFuZCBpbiB0aGF0IGNhc2UsIGFuZCAuLi4gYnV0IGhlcmUsIHlv dSBNQVkNCj4gZG8gc29tZXRoaW5nIGVsc2UuDQo+DQo+IEkgdW5kZXJzdGFuZCB0aGF0IFRNTUJS L1RNTUJOIHdvcmtzIGluIGEgcG9pbnQtdG8tcG9pbnQgdG9wb2xvZ3ksIGJ1dCBpcyB0aGVyZSBh IHJlYXNvbiB0byBwcmVmZXIgVE1NQlIvVE1NQk4NCj4gaW4gdGhhdCB0b3BvbG9neT8gSWYgc28s IGl0IHdvdWxkIHByb2JhYmx5IGJlIGdvb2QgdG8gZXhwbGFpbiB3aHkuDQo+DQo+IEFuZCBhcyBJ IHJlYWQgZnV0aGVyLCBJIHNlZSB0aGlzLCBpbiBzZWN0aW9uIDk6DQo+DQo+ICAgICAgIE5vdGU6 IFdoZW4gVE1NQlIgMCAvIFRNTUJOIDAgYXJlIHVzZWQgdG8gaW1wbGVtZW50IHBhdXNlIGFuZA0K PiAgICAgICByZXN1bWUgZnVuY3Rpb25hbGl0eSAod2l0aCB0aGUgcmVzdHJpY3Rpb25zIGRlc2Ny aWJlZCBpbiB0aGlzDQo+ICAgICAgIHNwZWNpZmljYXRpb24pLCBzaWduYWxpbmcgcnRjcC1mYiBh dHRyaWJ1dGUgd2l0aCBjY20gdG1tYnINCj4gICAgICAgcGFyYW1ldGVyIGlzIHN1ZmZpY2llbnQg YW5kIG5vIGZ1cnRoZXIgc2lnbmFsaW5nIGlzIG5lY2Vzc2FyeS4NCj4gICAgICAgVGhlcmUgaXMg aG93ZXZlciBubyBndWFyYW50ZWUgdGhhdCBUTU1CUi9UTU1CTiBpbXBsZW1lbnRhdGlvbnMNCj4g ICAgICAgICAgICAgICAgICAgICAgICBeXl5eXl5eXl5eXl4NCj4gICAgICAgcHJlLWRhdGluZyB0 aGlzIHNwZWNpZmljYXRpb24gd29yayBleGFjdGx5IGFzIGRlc2NyaWJlZCBoZXJlIHdoZW4NCj4g ICAgICAgdXNlZCB3aXRoIGEgYml0cmF0ZSB2YWx1ZSBvZiAwLg0KPg0KPiBhbmQgdGhhdCByZWFs bHkgbWFrZXMgbWUgd29uZGVyIHdoeSB0aGlzIHNwZWNpZmljYXRpb24gaXMgYWxzbyBkZXNjcmli aW5nIFRNTUJSL1RNTUJOLiBJJ20gc3VyZSB0aGVyZSdzIGEgZ29vZA0KPiByZWFzb24sIGJ1dCBj YW4geW91IHVuZGVyc3RhbmQgbXkgY29uZnVzaW9uPw0KPg0KPiBGaW5hbGx5LCBJIHNlZSB0aGlz LCBpbiBzZWN0aW9uIDkuMSwNCj4NCj4gICAgSWYgYm90aCAicGF1c2UiIGFuZCAidG1tYnIiIGFy ZSBwcmVzZW50IGluIHRoZSBvZmZlciwgYm90aCBNQVkgYmUNCj4gICAgaW5jbHVkZWQgYWxzbyBp biB0aGUgYW5zd2VyLCBpbiB3aGljaCBjYXNlIFRNTUJSL1RNTUJOIE1VU1QgTk9UIGJlDQo+ICAg IHVzZWQgZm9yIHBhdXNlL3Jlc3VtZSBwdXJwb3NlcyAod2l0aCBhIGJpdHJhdGUgdmFsdWUgb2Yg MCksIHRvIGF2b2lkDQo+ICAgIHNpZ25hbGluZyBhbWJpZ3VpdHkuDQo+DQo+IGFuZCBpbiBzZWN0 aW9uIDkuMiwNCj4NCj4gICAgSWYgYm90aCAicGF1c2UiIGFuZCAidG1tYnIiIGFyZSBwcmVzZW50 IGluIHRoZSBTRFAsIFRNTUJSL1RNTUJOIE1VU1QNCj4gICAgTk9UIGJlIHVzZWQgZm9yIHBhdXNl L3Jlc3VtZSBwdXJwb3NlcyAod2l0aCBhIGJpdHJhdGUgdmFsdWUgb2YgMCksIHRvDQo+ICAgIGF2 b2lkIHNpZ25hbGluZyBhbWJpZ3VpdHkuDQo+DQo+IEknbSBub3cgd29uZGVyaW5nIGlmIHRoZSBk ZXNjcmlwdGlvbiBvZiBUTU1CUi9UTU1CTiBpbiB0aGlzIHNwZWNpZmljYXRpb24ganVzdCBmb3Ig aW50ZXJ3b3JraW5nIHdpdGggb2xkZXINCj4gaW1wbGVtZW50YXRpb25zIHRoYXQgZG9uJ3Qgc3Vw cG9ydCBQQVVTRS9SRVNVTUUgYnV0IGZpZ3VyZWQgb3V0IGhvdyB0byBnZXQgYSBzaW1pbGFyIGVm ZmVjdCB3aXRoIFRNTUJSL1RNTUJOPw0KPg0KPiBJJ20gZ3Vlc3NpbmcsIG9mIGNvdXJzZSA6LSkN CltCb0JdIFlvdXIgZ3Vlc3MgaXMgY29ycmVjdC4gVGhpcyBpcyBoaW50ZWQgYWxyZWFkeSB3aXRo IHRoZSBsYXN0IHR3byBzZW50ZW5jZXMgaW4gdGhlIEludHJvZHVjdGlvbiBzZWN0aW9uICJUaGUg VGVtcG9yYXJ5IE1heGltdW0gTWVkaWEgQml0cmF0ZSBSZXF1ZXN0IChUTU1CUikgbWVzc2FnZSBv ZiBDQ00gaXMgdXNlZCBieSB2aWRlbyBjb25mZXJlbmNpbmcgc3lzdGVtcyBmb3IgZmxvdyBjb250 cm9sLiBJdCBpcyBkZXNpcmFibGUgdG8gYmUgYWJsZSB0byB1c2UgdGhhdCBtZXRob2Qgd2l0aCBh IGJpdHJhdGUgdmFsdWUgb2YgemVybyBmb3IgcGF1c2UsIHdoZW5ldmVyIHBvc3NpYmxlIi4gRG8g eW91IHRoaW5rIHRoaXMgbmVlZHMgdG8gYmUgbW9yZSBleHBsaWNpdGx5IHN0YXRlZCwgbWF5YmUg aW4gc2VjdGlvbiA1LjYgb24gVE1NQlIvVE1NQk4gY29uc2lkZXJhdGlvbnM/IFNheSwgc29tZXRo aW5nIHNpbWlsYXIgdG8gd2hhdCB5b3Ugc2FpZCBhYm92ZTogIlRoaXMgdXNlIGlzIGV4cGVjdGVk IHRvIGJlIG1haW5seSBmb3IgaW50ZXJ3b3JraW5nIHdpdGggaW1wbGVtZW50YXRpb25zIHRoYXQg ZG9uJ3Qgc3VwcG9ydCBQQVVTRS9SRVNVTUUsIGJ1dCBtYWtlIHVzZSBvZiBUTU1CUi9UTU1CTiB0 byBhY2hpZXZlIGEgc2ltaWxhciBlZmZlY3QiLiBEbyB5b3UgdGhpbmsgc29tZXRoaW5nIG5lZWRz IHRvIGJlIHNhaWQgaW4gc2VjdGlvbiA4IHRvbz8NCg0KSSBkbyB0aGluayB0aGF0IHNob3J0IGV4 cGxhbmF0aW9ucyBhYm91dCBtb3RpdmF0aW9uIGFyZSBoZWxwZnVsLg0KW0JvQl0gT0suIEnigJls bCBhZGQgYSBzZW50ZW5jZSBvbiB0aGlzIGluIHNlY3Rpb24gNS42IGFuZCBpbiBzZWN0aW9uIDgu DQoNCj4NCj4gSW4gdGhpcyB0ZXh0Og0KPg0KPiA4LjUuICBUcmFuc21pc3Npb24gUnVsZXMNCj4N Cj4gICAgbyAgUEFVU0UgU0hPVUxEIHVzZSBFYXJseSBvciBJbW1lZGlhdGUgdGltaW5nLCBleGNl cHQgZm9yDQo+ICAgICAgIHJldHJhbnNtaXNzaW9ucyB0aGF0IFNIT1VMRCB1c2UgUmVndWxhciB0 aW1pbmcuDQo+DQo+IF4gSSB1bmRlcnN0YW5kIHRoaXMgb25lLg0KPg0KPiAgICBvICBUaGUgZmly c3QgdHJhbnNtaXNzaW9uIG9mIFBBVVNFRCBmb3IgZWFjaCAobm9uLXdyYXBwZWQpIFBhdXNlSUQN Cj4gICAgICAgU0hPVUxEIGJlIHNlbnQgd2l0aCBJbW1lZGlhdGUgb3IgRWFybHkgdGltaW5nLCB3 aGlsZSBzdWJzZXF1ZW50DQo+ICAgICAgIFBBVVNFRCBmb3IgdGhhdCBQYXVzZUlEIFNIT1VMRCB1 c2UgUmVndWxhciB0aW1pbmcuICBVbnNvbGljaXRlZA0KPiAgICAgICBQQVVTRUQgKHNlbnQgd2hl biBlbnRlcmluZyBMb2NhbCBQYXVzZWQgU3RhdGUgKFNlY3Rpb24gNi40KSkNCj4gICAgICAgU0hP VUxEIGFsd2F5cyB1c2UgSW1tZWRpYXRlIG9yIEVhcmx5IHRpbWluZywgdW50aWwgUEFVU0VEIGZv ciB0aGF0DQo+ICAgICAgIFBhdXNlSUQgaXMgY29uc2lkZXJlZCBkZWxpdmVyZWQgYXQgbGVhc3Qg b25jZSB0byBhbGwgcmVjZWl2ZXJzIG9mDQo+ICAgICAgIHRoZSBwYXVzZWQgUlRQIHN0cmVhbSwg YWZ0ZXIgd2hpY2ggaXQgU0hPVUxEIHVzZSBSZWd1bGFyIHRpbWluZy4NCj4NCj4gXiBJJ20gd29u ZGVyaW5nIHdoeSB0aGVzZSBhcmUgU0hPVUxEcy4gQXJlIHRoZXkgTVVTVHMgZXhjZXB0IHRoYXQg c29tZSBpbXBsZW1lbnRhdGlvbnMgZG9uJ3QgZG8gaXQsIG9yDQo+IHJlY29tbWVuZGF0aW9ucyBi dXQgbm90aGluZyBicmVha3MgaWYgeW91IGRvbid0IGRvIHRoZW0sIG9yIHNvbWV0aGluZyBlbHNl Pw0KW0JvQl0gSXQgaXMgcmVjb21tZW5kYXRpb25zLCBtZWFuaW5nIHRoYXQgaWYgeW91IGRvbid0 IGZvbGxvdyB0aGVtLCBub3RoaW5nIHdpbGwgcmVhbGx5IGJyZWFrLCBidXQgeW91J2xsIGdldCB3 b3JzZSBwZXJmb3JtYW5jZSBpbiBvbmUgd2F5IG9yIHRoZSBvdGhlci4gVGhlIFNIT1VMRHMgZm9y IEVhcmx5IG9yIEltbWVkaWF0ZSBpcyB0byBwcm92aWRlIGdvb2QgdGltZWxpbmVzcyBhbmQgcmVz cG9uc2l2ZW5lc3Mgb2YgdGhlIGFwcGxpY2F0aW9uIG1ha2luZyB1c2Ugb2YgdGhlIG1lc3NhZ2Vz LCB3aGlsZSB0aGUgU0hPVUxEcyBmb3IgUmVndWxhciBhcmUgdG8gYXZvaWQgZXhjZXNzaXZlIGJh bmR3aWR0aCBjb25zdW1wdGlvbi4NCg0KPg0KPiAgICBvICBSRVNVTUUgU0hPVUxEIGFsd2F5cyB1 c2UgSW1tZWRpYXRlIG9yIEVhcmx5IHRpbWluZy4NCj4NCj4gXiBJIHdvbmRlciB3aHkgdGhpcyBp cyBTSE9VTEQuIElzIHRoZXJlIGFueSBndWlkYW5jZSB5b3UgY2FuIHByb3ZpZGUgYWJvdXQgd2h5 IFJFU1VNRSB3b3VsZCB1c2UgUmVndWxhciB0aW1pbmc/DQpbQm9CXSBUaGUgb25seSBjYXNlIEkg Y2FuIGNvbWUgdG8gdGhpbmsgb2YgaXMgd2hlbiBvdGhlciBSVENQIG1lc3NhZ2VzIHVzZWQgYnkg dGhlIGFwcGxpY2F0aW9uIGxheWVyIChub3QgUEFVU0UvUkVTVU1FKSBhcmUgc29tZWhvdyBjb25z aWRlcmVkIG1vcmUgaW1wb3J0YW50IHRoYW4gcmVzdW1pbmcgbWVkaWEgc3RyZWFtcyBpbiB0aGF0 IHNwZWNpZmljIGFwcGxpY2F0aW9uIGNvbnRleHQuIEFnYWluLCBub3RoaW5nIHdvdWxkIHJlYWxs eSBicmVhayB3aXRoIHJlZ3VsYXIgdGltaW5nLCBidXQgcGVyZm9ybWFuY2Ugd291bGQgY2VydGFp bmx5IHN1ZmZlciBiYWRseS4gTWF5YmUgc3VjaCBhcHBsaWNhdGlvbi1sZXZlbCBjb25zaWRlcmF0 aW9uIGlzIHN1ZmZpY2llbnRseSAiZXh0cmVtZSIgdGhhdCBpdCBpcyBtb3RpdmF0ZWQgY2hhbmdp bmcgdG8gYSBNVVNULCBmb3JjaW5nIHN1Y2ggc2l0dWF0aW9ucyB0byBicmVhayBjb21wbGlhbmNl Pw0KDQo+DQo+ICAgIG8gIFRoZSBmaXJzdCB0cmFuc21pc3Npb24gb2YgUkVGVVNFRCBmb3IgZWFj aCAobm9uLXdyYXBwZWQpIFBhdXNlSUQNCj4gICAgICAgU0hPVUxEIGJlIHNlbnQgd2l0aCBJbW1l ZGlhdGUgb3IgRWFybHkgdGltaW5nLCB3aGlsZSBzdWJzZXF1ZW50DQo+ICAgICAgIFJFRlVTRUQg Zm9yIHRoYXQgUGF1c2VJRCBTSE9VTEQgdXNlIFJlZ3VsYXIgdGltaW5nLg0KPg0KPiBeIEkgYW0s IG9mIGNvdXJzZSwgd29uZGVyaW5nIGFib3V0IHRoZSBjb3JyZXNwb25kaW5nIFNIT1VMRHMgZm9y IFJFRlVTRUQuDQpbQm9CXSBUaW1lbHkgdHJhbnNtaXNzaW9uIG9mIFJFRlVTRUQgY2FuIHN0b3Ag dW5uZWNlc3NhcnkgcmVwZXRpdGlvbnMgb2YgUEFVU0Ugb3IgUkVTVU1FLCB3aGljaCBJIGJlbGll dmUgbW90aXZhdGVzIHJlY29tbWVuZGluZyBJbW1lZGlhdGUgb3IgRWFybHkgZm9yIHRoZSBmaXJz dCB0cmFuc21pc3Npb24gdG8gc2F2ZSBzb21lIFJUQ1AgYmFuZHdpZHRoLiBUaGF0IGlzIGhvd2V2 ZXIgbm90IGNvbnNpZGVyZWQgY3JpdGljYWwgZW5vdWdoIHRvIG1vdGl2YXRlIHJlY29tbWVuZGlu ZyByZXBldGl0aW9ucyBvZiB0aGUgc2FtZSBpbmRpY2F0aW9uIHRvIGJlIHNlbnQgd2l0aCBvdGhl ciB0aGFuIFJlZ3VsYXIgdGltaW5nLiBOb3RoaW5nIHdvdWxkIGJyZWFrIGlmIHJlcGV0aXRpb25z IGFyZSBzZW50IHdpdGggRWFybHkgb3IgSW1tZWRpYXRlIHRpbWluZywgYnV0IGl0IHdvdWxkIHBv dGVudGlhbGx5IHdhc3RlIHNvbWUgdHJhbnNtaXNzaW9uIG9wcG9ydHVuaXRpZXMgZm9yIG90aGVy IFJUQ1AgKEZCKSBtZXNzYWdlcy4gRG8geW91IHRoaW5rIGl0IG1vdGl2YXRlZCB0byBhZGQgbW9y ZSB0ZXh0IG9uIHN1Y2ggY29uc2lkZXJhdGlvbnM/DQoNCkknZCBoYXZlIGEgcHJlZmVyZW5jZSBm b3IgdGV4dCB0aGF0IGV4cGxhaW5zIHRoZSBzdHJhdGVneSwgcmF0aGVyIHRoYW4gdXNpbmcgUkZD IDIxMTkgbGFuZ3VhZ2Ugd2hlbiB0aGlzIGlzbid0IGFjdHVhbGx5IGFib3V0IGludGVyd29ya2lu Zy4NCltCb0JdIE9LLiBJ4oCZbGwgZGVtb3RlIHRoZSBSRkMgMjExOSBsYW5ndWFnZSBpbiB0aGF0 IHNlY3Rpb24gdG8gcHJvc2UgdGV4dCBhbmQgYWRkIGJyaWVmIGRlc2NyaXB0aXZlIG1vdGl2YXRp b25zLg0KSSBhbHNvIHRoaW5rIHRoYXQgYSBjbGF1c2Ugb24gUlRDUCB0aW1pbmcgaW4gc2VjdGlv biA4LjQgKFJFRlVTRUQpIGlzIGJvdGggbWlzcGxhY2VkIGFuZCByZWR1bmRhbnQsIGFuZCBwcm9w b3NlIHRvIHJlbW92ZSBpdDoNCiAgIElmIFJFRlVTRUQgY29udGFpbmluZyBhIGNlcnRhaW4gUGF1 c2VJRCB3YXMgYWxyZWFkeSBzZW50IGFuZCB5ZXQgbW9yZQ0KICAgUEFVU0Ugb3IgUkVTVU1FIG1l c3NhZ2VzIGFyZSByZWNlaXZlZCB0aGF0IHJlcXVpcmUgYWRkaXRpb25hbCBSRUZVU0VEDQogICB3 aXRoIHRoYXQgc3BlY2lmaWMgUGF1c2VJRCB0byBiZSBzY2hlZHVsZWQsIGZ1cnRoZXIgUkVGVVNF RCBtZXNzYWdlcw0KICAgd2l0aCB0aGF0IFBhdXNlSUQgU0hPVUxEIGJlIHNlbnQgaW4gcmVndWxh ciBSVENQIHJlcG9ydHMuICBBbg0KICAgZXhjZXB0aW9uIHRvIHRoZSBwcmV2aW91cyBydWxlIGlz IHdoZW4gdGhlIHN0cmVhbSB3YXMgcGF1c2VkIGFuZA0KICAgcmVzdW1lZCBzbyBtYW55IHRpbWVz IHRoYXQgdGhlIFBhdXNlSUQgbnVtYmVyIHNwYWNlIGhhcyB3cmFwcGVkIHNpbmNlDQogICAgUkVG VVNFRCB3YXMgbGFzdCBzZW50IHdpdGggdGhhdCBQYXVzZUlELg0KSSB0aGluayB0aGF0IGNsYXVz ZSBzaG91bGQgYmUgZnVsbHkgY292ZXJlZCBieSB0aGUgbGFzdCBidWxsZXQgaW4gOC41ICh0ZXh0 IGNvcGllZCBmcm9tIC0wODsgd2lsbCBiZSBjaGFuZ2VkKToNCiAgIG8gIFRoZSBmaXJzdCB0cmFu c21pc3Npb24gb2YgUkVGVVNFRCBmb3IgZWFjaCAobm9uLXdyYXBwZWQpIFBhdXNlSUQNCiAgICAg IFNIT1VMRCBiZSBzZW50IHdpdGggSW1tZWRpYXRlIG9yIEVhcmx5IHRpbWluZywgd2hpbGUgc3Vi c2VxdWVudA0KICAgICAgIFJFRlVTRUQgZm9yIHRoYXQgUGF1c2VJRCBTSE9VTEQgdXNlIFJlZ3Vs YXIgdGltaW5nLg0KDQo+DQo+IEluIHRoaXMgdGV4dDoNCj4NCj4gOS4gIFNpZ25hbGluZw0KPg0K PiAgICBXaGVuIHNpZ25hbGluZyBhIGNvbmZpZyB2YWx1ZSBvdGhlciB0aGFuIDEsIGFuIGltcGxl bWVudGF0aW9uIE1VU1QNCj4gICAgaWdub3JlIG5vbi1zdXBwb3J0ZWQgbWVzc2FnZXMgb24gcmVj ZXB0aW9uLCBhbmQgTUFZIG9taXQgc2VuZGluZyBub24tDQo+ICAgIHN1cHBvcnRlZCBtZXNzYWdl cy4NCj4NCj4gaXMgdGhpcyBzYXlpbmcgdGhhdCBhbiBpbXBsZW1lbnRhdGlvbiBtaWdodCBzZW5k IG5vbi1zdXBwb3J0ZWQgbWVzc2FnZXM/DQo+IEknbSBjb25mdXNlZCBoZXJlLg0KW0JvQl0gVGhh dCBzaG91bGQgaGF2ZSBiZWVuICIuLi4gTUFZIG9taXQgc2VuZGluZyBtZXNzYWdlcyBub3Qgc3Vw cG9ydGVkIGJ5IHRoZSByZW1vdGUgcGVlciIuIEkgcmVhbGl6ZSB0aGF0IGZ1cnRoZXIgZG93biBp dCBpcyBzYWlkICIuLi4gU0hPVUxEIE5PVCBiZSB1c2VkIHRvd2FyZHMgcmVjZWl2ZXJzIHRoYXQg ZGlkIG5vdCBkZWNsYXJlIGNhcGFiaWxpdHkgdG8gcmVjZWl2ZSB0aG9zZSBtZXNzYWdlcyIsIHNv IEkgZ3Vlc3MgdGhhdCBNQVkgc2hvdWxkIGJlIGNoYW5nZWQgdG8gYSBTSE9VTEQgdG8gYmUgY29u c2lzdGVudC4gSW4gYW55IGNhc2UsIG5vdCBoYXZpbmcgTVVTVHMgaGVyZSBhbGxvd3MgYSBtaXgg b2YgZGlmZmVyZW50IGNhcGFiaWxpdGllcyBhbW9uZyByZWNlaXZlcnMgaW4gYSBtdWx0aS1yZWNl aXZlciBjYXNlIHdpdGhvdXQgbGV0dGluZyB0aGUgbGVhc3QgY2FwYWJsZSByZWNlaXZlciBzZXQg dGhlIGxldmVsIG9mIFAvUiBmdW5jdGlvbmFsaXR5IGZvciBhbGwgdGhlIG90aGVycy4gV2l0aCB0 aGF0IGluIG1pbmQsIGRvIHlvdSB0aGluayAiU0hPVUxEIG9taXQiIGlzIGEgdG9vIHN0cm9uZyB3 b3JkaW5nPw0KDQpNYWtpbmcgaXQgY2xlYXIgd2hvIGlzbid0IHN1cHBvcnRpbmcgdGhlIG5vbi1z dXBwb3J0ZWQgbWVzc2FnZXMgc2VlbXMgaGVscGZ1bC4NCltCb0JdIERlZmluaXRlbHkgOikNCg0K SSdkIGJlIE9LIHdpdGggZWl0aGVyIE1BWSBvciBTSE9VTEQgaW4gYm90aCBwbGFjZXMgKHlvdSBn dXlzIGFyZSB0aGUgZXhwZXJ0cyksIGJ1dCBpdCBzb3VuZHMgbGlrZSB0aGV5IHNob3VsZCBtYXRj aC4NCltCb0JdIE9LLiBJIHN1Z2dlc3QgdG8gZ28gZm9yIFNIT1VMRCBpbiBib3RoIHBsYWNlcywg YW5kIGFsc28gYWRkIGEgc2VudGVuY2Ugb24gd2hlbiBpdCBjYW4gYmUgbW90aXZhdGVkIHRvIHZp b2xhdGUgdGhhdCAobXVsdGlwbGUgcmVjZWl2ZXJzIHdpdGggZGlmZmVyZW50IGNvbmZpZy1jYXBh YmlsaXRpZXMsIHRvIGF2b2lkIHRoYXQgdGhlIGxlYXN0IGNhcGFibGUgcmVjZWl2ZXIgc2V0cyB0 aGUgZnVuY3Rpb25hbGl0eSBkZWxpdmVyZWQgdG8gb3RoZXJzKS4NCkkgYWxzbyByZWNlaXZlZCBh biBvZmZsaW5lIGNvbW1lbnQgc3VnZ2VzdGluZyB0byBjbGFyaWZ5IHRoYXQgbm8gcGFydGlhbCBt ZXNzYWdlIHN1cHBvcnQgaXMgcG9zc2libGUgd2hlbiB1c2luZyBUTU1CUi9UTU1CTiwgd2hpY2gg c2hvdWxkIGJlIG9idmlvdXMgKHNpbmNlIHRoZXJlIGlzIG5vIHN1Y2ggc3VwcG9ydCBpbiBSRkMg NTEwNCksIGJ1dCBJIGFueXdheSB0aGluayB0aGF0IGlzIGEgcmVhc29uYWJsZSBjbGFyaWZpY2F0 aW9uIHRvIGFkZC4NCg0KVGhhbmtzIQ0KDQpTcGVuY2VyDQo= --_000_BBE9739C2C302046BD34B42713A1E2A22E70B1EDESESSMB105erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNv LXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10 eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0K QHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3MC44 NXB0IDcwLjg1cHQgNzAuODVwdCA3MC44NXB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpX b3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNo YXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRp Zl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0 Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0Pjwv eG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUi IHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5IaSBT cGVuY2VyLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+SSB0aGluayB5b3VyIHByb3Bvc2FscyBhcmUgZ29vZCBhbmQgd2ls bCBtYWtlIGNoYW5nZXMgYWNjb3JkaW5nbHkuIFNlZSBtb3JlIGlubGluZS48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHls ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBjbSAw Y20gMGNtIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9w OnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+ PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9t YSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gU3BlbmNlciBEYXdraW5zIGF0IElFVEYg W21haWx0bzpzcGVuY2VyZGF3a2lucy5pZXRmQGdtYWlsLmNvbV0NCjxicj4NCjxiPlNlbnQ6PC9i PiBkZW4gMjcgYXVndXN0aSAyMDE1IDE0OjM3PGJyPg0KPGI+VG86PC9iPiBCbyBCdXJtYW48YnI+ DQo8Yj5DYzo8L2I+IFRoZSBJRVNHOyBkcmFmdC1pZXRmLWF2dGV4dC1ydHAtc3RyZWFtLXBhdXNl QGlldGYub3JnOyBkcmFmdC1pZXRmLWF2dGV4dC1ydHAtc3RyZWFtLXBhdXNlLmFkQGlldGYub3Jn OyBqb25hdGhhbkB2aWR5by5jb207IGRyYWZ0LWlldGYtYXZ0ZXh0LXJ0cC1zdHJlYW0tcGF1c2Uu c2hlcGhlcmRAaWV0Zi5vcmc7IGF2dGV4dC1jaGFpcnNAaWV0Zi5vcmc7IGF2dGV4dEBpZXRmLm9y Zzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogU3BlbmNlciBEYXdraW5zJyBZZXMgb24gZHJhZnQt aWV0Zi1hdnRleHQtcnRwLXN0cmVhbS1wYXVzZS0wODogKHdpdGggQ09NTUVOVCk8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SGksIEJvLDxvOnA+ PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFRodSwgQXVnIDI3LCAyMDE1IGF0 IDY6MjggQU0sIEJvIEJ1cm1hbiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmJvLmJ1cm1hbkBlcmljc3Nv bi5jb20iIHRhcmdldD0iX2JsYW5rIj5iby5idXJtYW5AZXJpY3Nzb24uY29tPC9hPiZndDsgd3Jv dGU6PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGFuayB5b3UgZm9yIGdv b2QgYW5kIGNvbnN0cnVjdGl2ZSBjb21tZW50cy4gUGxlYXNlIGZpbmQgcmVzcG9uc2VzIHRvIHlv dXIgcXVlc3Rpb25zIGlubGluZSBiZWxvdy48YnI+DQpDaGVlcnMsPGJyPg0KQm88bzpwPjwvbzpw PjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KJmd0OyAtLS0t LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxicj4NCiZndDsgRnJvbTogU3BlbmNlciBEYXdraW5zIFtt YWlsdG86PGEgaHJlZj0ibWFpbHRvOnNwZW5jZXJkYXdraW5zLmlldGZAZ21haWwuY29tIj5zcGVu Y2VyZGF3a2lucy5pZXRmQGdtYWlsLmNvbTwvYT5dPGJyPg0KJmd0OyBTZW50OiBkZW4gMTkgYXVn dXN0aSAyMDE1IDA1OjE3PGJyPg0KJmd0OyBUbzogVGhlIElFU0c8YnI+DQomZ3Q7IENjOiA8YSBo cmVmPSJtYWlsdG86ZHJhZnQtaWV0Zi1hdnRleHQtcnRwLXN0cmVhbS1wYXVzZUBpZXRmLm9yZyI+ ZHJhZnQtaWV0Zi1hdnRleHQtcnRwLXN0cmVhbS1wYXVzZUBpZXRmLm9yZzwvYT47DQo8YSBocmVm PSJtYWlsdG86ZHJhZnQtaWV0Zi1hdnRleHQtcnRwLXN0cmVhbS1wYXVzZS5hZEBpZXRmLm9yZyI+ ZHJhZnQtaWV0Zi1hdnRleHQtcnRwLXN0cmVhbS1wYXVzZS5hZEBpZXRmLm9yZzwvYT47DQo8YSBo cmVmPSJtYWlsdG86am9uYXRoYW5AdmlkeW8uY29tIj5qb25hdGhhbkB2aWR5by5jb208L2E+Ozxi cj4NCiZndDsgPGEgaHJlZj0ibWFpbHRvOmRyYWZ0LWlldGYtYXZ0ZXh0LXJ0cC1zdHJlYW0tcGF1 c2Uuc2hlcGhlcmRAaWV0Zi5vcmciPmRyYWZ0LWlldGYtYXZ0ZXh0LXJ0cC1zdHJlYW0tcGF1c2Uu c2hlcGhlcmRAaWV0Zi5vcmc8L2E+Ow0KPGEgaHJlZj0ibWFpbHRvOmF2dGV4dC1jaGFpcnNAaWV0 Zi5vcmciPmF2dGV4dC1jaGFpcnNAaWV0Zi5vcmc8L2E+OyA8YSBocmVmPSJtYWlsdG86YXZ0ZXh0 QGlldGYub3JnIj4NCmF2dGV4dEBpZXRmLm9yZzwvYT48YnI+DQomZ3Q7IFN1YmplY3Q6IFNwZW5j ZXIgRGF3a2lucycgWWVzIG9uIGRyYWZ0LWlldGYtYXZ0ZXh0LXJ0cC1zdHJlYW0tcGF1c2UtMDg6 ICh3aXRoIENPTU1FTlQpPGJyPg0KJmd0Ozxicj4NCiZndDsgU3BlbmNlciBEYXdraW5zIGhhcyBl bnRlcmVkIHRoZSBmb2xsb3dpbmcgYmFsbG90IHBvc2l0aW9uIGZvcjxicj4NCiZndDsgZHJhZnQt aWV0Zi1hdnRleHQtcnRwLXN0cmVhbS1wYXVzZS0wODogWWVzPGJyPg0KJmd0Ozxicj4NCiZndDsg V2hlbiByZXNwb25kaW5nLCBwbGVhc2Uga2VlcCB0aGUgc3ViamVjdCBsaW5lIGludGFjdCBhbmQg cmVwbHkgdG8gYWxsIGVtYWlsIGFkZHJlc3NlcyBpbmNsdWRlZCBpbiB0aGUgVG8gYW5kIENDIGxp bmVzLjxicj4NCiZndDsgKEZlZWwgZnJlZSB0byBjdXQgdGhpcyBpbnRyb2R1Y3RvcnkgcGFyYWdy YXBoLCBob3dldmVyLik8YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDsgUGxlYXNlIHJlZmVy IHRvIDxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL2llc2cvc3RhdGVtZW50L2Rpc2N1c3Mt Y3JpdGVyaWEuaHRtbCIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaWVz Zy9zdGF0ZW1lbnQvZGlzY3Vzcy1jcml0ZXJpYS5odG1sPC9hPjxicj4NCiZndDsgZm9yIG1vcmUg aW5mb3JtYXRpb24gYWJvdXQgSUVTRyBESVNDVVNTIGFuZCBDT01NRU5UIHBvc2l0aW9ucy48YnI+ DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDsgVGhlIGRvY3VtZW50LCBhbG9uZyB3aXRoIG90aGVy IGJhbGxvdCBwb3NpdGlvbnMsIGNhbiBiZSBmb3VuZCBoZXJlOjxicj4NCiZndDsgPGEgaHJlZj0i aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1hdnRleHQtcnRwLXN0 cmVhbS1wYXVzZS8iIHRhcmdldD0iX2JsYW5rIj4NCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5v cmcvZG9jL2RyYWZ0LWlldGYtYXZ0ZXh0LXJ0cC1zdHJlYW0tcGF1c2UvPC9hPjxicj4NCiZndDs8 YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDsgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxicj4NCiZndDsgQ09N TUVOVDo8YnI+DQomZ3Q7IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08YnI+DQomZ3Q7PGJyPg0KJmd0OyBUaGlzIGRy YWZ0IHdhcyByZWFsbHkgZWFzeSBmb3IgbWUgdG8gcmVhZCAod2l0aCBzb21lIGJhY2tncm91bmQg aW4gUlRQL1JUQ1AsIGJ1dCBJJ20gbm8gZXhwZXJ0IG9uIHRoZSB0b3BpYykuIFRoYW5rIHlvdTxi cj4NCiZndDsgZm9yIHRoZSB3b3JrIG9uIGl0IC0gdGhlIHJlc3VsdHMgc2hvdy48YnI+DQomZ3Q7 PGJyPg0KJmd0OyBJIGhhdmUgc29tZSBxdWVzdGlvbnMsIGJ1dCBub3RoaW5nIGlzIGEgc2hvdy1z dG9wcGVyLjxicj4NCiZndDs8YnI+DQomZ3Q7IEluIHRoaXMgdGV4dDo8YnI+DQomZ3Q7PGJyPg0K Jmd0OyAzLjMuJm5ic3A7IFJUUCBNaXhlciB0byBNZWRpYSBTZW5kZXIgaW4gUG9pbnQtdG8tTXVs dGlwb2ludDxicj4NCiZndDs8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyBJbiB0aGlzIHVzZSBjYXNl IHRoZXJlIGFyZSBzZXZlcmFsIHJlY2VpdmVycyBvZiBhIHN0cmVhbSBhbmQgc3BlY2lhbDxicj4N CiZndDsmbmJzcDsgJm5ic3A7IGNhcmUgbXVzdCBiZSB0YWtlbiBhcyBub3QgdG8gcGF1c2UgYSBz dHJlYW0gdGhhdCBpcyBzdGlsbCB3YW50ZWQgYnk8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyBzb21l IHJlY2VpdmVycy48YnI+DQomZ3Q7PGJyPg0KJmd0OyBJJ20gYXNzdW1pbmcgdGhhdCB0aGUgTWl4 ZXIgaXMgdGFraW5nIHNwZWNpYWwgY2FyZSwgYnV0IHRoaXMgaXMgcGFzc2l2ZSBlbm91Z2ggdGhh dCBJJ20gZmlsbGluZyBpbiBibGFua3MuIElmIHlvdSBsaWtlIHBhc3NpdmU8YnI+DQomZ3Q7IHZv aWNlLCBwZXJoYXBzIHNvbWV0aGluZyBsaWtlPGJyPg0KJmd0Ozxicj4NCiZndDsmbmJzcDsgJm5i c3A7IEluIHRoaXMgdXNlIGNhc2UgdGhlcmUgYXJlIHNldmVyYWwgcmVjZWl2ZXJzIG9mIGEgc3Ry ZWFtIGFuZCBzcGVjaWFsPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgY2FyZSBtdXN0IGJlIHRha2Vu IGJ5IHRoZSBNaXhlciBzbyBhcyBub3QgdG8gcGF1c2UgYSBzdHJlYW0gdGhhdCBpczxicj4NCiZn dDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO15eXl5eXl5eXl5eXl5eXjxicj4NCiZndDsmbmJz cDsgJm5ic3A7IHN0aWxsIHdhbnRlZCBieSBzb21lIHJlY2VpdmVycy48YnI+DQomZ3Q7PGJyPg0K Jmd0OyB3b3VsZCBiZSBlYXNpZXIgdG8gcGFyc2UuPGJyPg0KJmd0Ozxicj4NCiZndDsgSWYgeW91 IGNhbiBkbyBhY3RpdmUgdm9pY2UsIHBlcmhhcHM8YnI+DQomZ3Q7PGJyPg0KJmd0OyZuYnNwOyAm bmJzcDsgSW4gdGhpcyB1c2UgY2FzZSB0aGVyZSBhcmUgc2V2ZXJhbCByZWNlaXZlcnMgb2YgYSBz dHJlYW0gYW5kIHRoZTxicj4NCiZndDsmbmJzcDsgJm5ic3A7IE1peGVyIG11c3QgdGFrZSBzcGVj aWFsIGNhcmUgc28gYXMgbm90IHRvIHBhdXNlIGEgc3RyZWFtIHRoYXQgaXMgc3RpbGw8YnI+DQom Z3Q7PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5e Xjxicj4NCiZndDsmbmJzcDsgJm5ic3A7IHdhbnRlZCBieSBzb21lIHJlY2VpdmVycy48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5bQm9CXSBUaGFu a3MsIHlvdXIgYXNzdW1wdGlvbiBpcyBjb3JyZWN0LCBhbmQgSSB0aGluayB0aGlzIGFjdGl2ZSB2 b2ljZSBpcyBlYXNpZXIgdG8gcmVhZC48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPkdyZWF0LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3Rl IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRp bmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZndDs8YnI+DQomZ3Q7IEluIHRo aXMgdGV4dDo8YnI+DQomZ3Q7PGJyPg0KJmd0OyA4LiZuYnNwOyBNZXNzYWdlIERldGFpbHM8YnI+ DQomZ3Q7PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgQW55IHJlZmVyZW5jZXMgdG8gUEFVU0UsIFBB VVNFRCwgUkVTVU1FIGFuZCBSRUZVU0VEIGluIHRoaXMgc2VjdGlvbjxicj4NCiZndDsmbmJzcDsg Jm5ic3A7IFNIQUxMIGJlIHRha2VuIHRvIGFwcGx5IHRvIHRoZSBleHRlbnQgcG9zc2libGUgYWxz byB3aGVuIFRNTUJSL1RNTUJOPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgYXJlIHVzZWQgKFNlY3Rp b24gNS42KSBmb3IgdGhpcyBmdW5jdGlvbmFsaXR5LiZuYnNwOyBUTU1CUi9UTU1CTiBNQVkgYmU8 YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyBeXl48YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyB1c2VkIGluc3RlYWQgb2YgdGhlIG1lc3Nh Z2VzIGRlZmluZWQgaW4gdGhpcyBzcGVjaWZpY2F0aW9uIHdoZW4gdGhlPGJyPg0KJmd0OyZuYnNw OyAmbmJzcDsgZWZmZWN0aXZlIHRvcG9sb2d5IGlzIHBvaW50LXRvLXBvaW50LiZuYnNwOyBJZiBl aXRoZXIgc2VuZGVyIG9yIHJlY2VpdmVyPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgbGVhcm5zIHRo YXQgdGhlIHRvcG9sb2d5IGlzIG5vdCBwb2ludC10by1wb2ludCwgVE1NQlIvVE1NQk4gTVVTVCBO T1Q8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyBiZSB1c2VkIGZvciBwYXVzZS9yZXN1bWUgZnVuY3Rp b25hbGl0eS4mbmJzcDsgSWYgdGhlIG1lc3NhZ2VzIGRlZmluZWQgaW48YnI+DQomZ3Q7Jm5ic3A7 ICZuYnNwOyB0aGlzIHNwZWNpZmljYXRpb24gYXJlIHN1cHBvcnRlZCBpbiBhZGRpdGlvbiB0byBU TU1CUi9UTU1CTiBieSBhbGw8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyBpbnZvbHZlZCBwYXJ0aWVz LCBwYXVzZS9yZXN1bWUgc2lnbmFsaW5nIE1VU1QgdXNlIG1lc3NhZ2VzIGZyb20gdGhpczxicj4N CiZndDsmbmJzcDsgJm5ic3A7IHNwZWNpZmljYXRpb24uJm5ic3A7IElmIHRoZSB0b3BvbG9neSBp cyBub3QgcG9pbnQtdG8tcG9pbnQgYW5kIHRoZTxicj4NCiZndDsmbmJzcDsgJm5ic3A7IG1lc3Nh Z2VzIGRlZmluZWQgaW4gdGhpcyBzcGVjaWZpY2F0aW9uIGFyZSBub3Qgc3VwcG9ydGVkLCBwYXVz ZS88YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyByZXN1bWUgZnVuY3Rpb25hbGl0eSB3aXRoIFRNTUJS L1RNTUJOIE1VU1QgTk9UIGJlIHVzZWQuPGJyPg0KJmd0Ozxicj4NCiZndDsgQWxsIG9mIHRoaXMg bWFrZXMgc2Vuc2UgdG8gbWUsIGV4Y2VwdCB0aGF0IEknbSBub3QgdW5kZXJzdGFuZGluZyB3aHkg VE1NQlIvVE1NQk4gaXMgYSBNQVkuIFRoZXJlJ3MgYSBsb3Qgb2YgdGV4dCB0aGF0PGJyPg0KJmd0 OyBzYXlzIHlvdSByZWFsbHkgbmVlZCB0byB1c2UgdGhlIG1lc3NhZ2VzIGZyb20gdGhpcyBzcGVj aWZpY2F0aW9uIGluIHRoaXMgY2FzZSwgYW5kIGluIHRoYXQgY2FzZSwgYW5kIC4uLiBidXQgaGVy ZSwgeW91IE1BWTxicj4NCiZndDsgZG8gc29tZXRoaW5nIGVsc2UuPGJyPg0KJmd0Ozxicj4NCiZn dDsgSSB1bmRlcnN0YW5kIHRoYXQgVE1NQlIvVE1NQk4gd29ya3MgaW4gYSBwb2ludC10by1wb2lu dCB0b3BvbG9neSwgYnV0IGlzIHRoZXJlIGEgcmVhc29uIHRvIHByZWZlciBUTU1CUi9UTU1CTjxi cj4NCiZndDsgaW4gdGhhdCB0b3BvbG9neT8gSWYgc28sIGl0IHdvdWxkIHByb2JhYmx5IGJlIGdv b2QgdG8gZXhwbGFpbiB3aHkuPGJyPg0KJmd0Ozxicj4NCiZndDsgQW5kIGFzIEkgcmVhZCBmdXRo ZXIsIEkgc2VlIHRoaXMsIGluIHNlY3Rpb24gOTo8YnI+DQomZ3Q7PGJyPg0KJmd0OyZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwO05vdGU6IFdoZW4gVE1NQlIgMCAvIFRNTUJOIDAgYXJlIHVzZWQg dG8gaW1wbGVtZW50IHBhdXNlIGFuZDxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDtyZXN1bWUgZnVuY3Rpb25hbGl0eSAod2l0aCB0aGUgcmVzdHJpY3Rpb25zIGRlc2NyaWJlZCBp biB0aGlzPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3NwZWNpZmljYXRpb24p LCBzaWduYWxpbmcgcnRjcC1mYiBhdHRyaWJ1dGUgd2l0aCBjY20gdG1tYnI8YnI+DQomZ3Q7Jm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7cGFyYW1ldGVyIGlzIHN1ZmZpY2llbnQgYW5kIG5vIGZ1 cnRoZXIgc2lnbmFsaW5nIGlzIG5lY2Vzc2FyeS48YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7VGhlcmUgaXMgaG93ZXZlciBubyBndWFyYW50ZWUgdGhhdCBUTU1CUi9UTU1CTiBp bXBsZW1lbnRhdGlvbnM8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgXl5eXl5e Xl5eXl5ePGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3ByZS1kYXRpbmcgdGhp cyBzcGVjaWZpY2F0aW9uIHdvcmsgZXhhY3RseSBhcyBkZXNjcmliZWQgaGVyZSB3aGVuPGJyPg0K Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3VzZWQgd2l0aCBhIGJpdHJhdGUgdmFsdWUg b2YgMC48YnI+DQomZ3Q7PGJyPg0KJmd0OyBhbmQgdGhhdCByZWFsbHkgbWFrZXMgbWUgd29uZGVy IHdoeSB0aGlzIHNwZWNpZmljYXRpb24gaXMgYWxzbyBkZXNjcmliaW5nIFRNTUJSL1RNTUJOLiBJ J20gc3VyZSB0aGVyZSdzIGEgZ29vZDxicj4NCiZndDsgcmVhc29uLCBidXQgY2FuIHlvdSB1bmRl cnN0YW5kIG15IGNvbmZ1c2lvbj88YnI+DQomZ3Q7PGJyPg0KJmd0OyBGaW5hbGx5LCBJIHNlZSB0 aGlzLCBpbiBzZWN0aW9uIDkuMSw8YnI+DQomZ3Q7PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgSWYg Ym90aCAmcXVvdDtwYXVzZSZxdW90OyBhbmQgJnF1b3Q7dG1tYnImcXVvdDsgYXJlIHByZXNlbnQg aW4gdGhlIG9mZmVyLCBib3RoIE1BWSBiZTxicj4NCiZndDsmbmJzcDsgJm5ic3A7IGluY2x1ZGVk IGFsc28gaW4gdGhlIGFuc3dlciwgaW4gd2hpY2ggY2FzZSBUTU1CUi9UTU1CTiBNVVNUIE5PVCBi ZTxicj4NCiZndDsmbmJzcDsgJm5ic3A7IHVzZWQgZm9yIHBhdXNlL3Jlc3VtZSBwdXJwb3NlcyAo d2l0aCBhIGJpdHJhdGUgdmFsdWUgb2YgMCksIHRvIGF2b2lkPGJyPg0KJmd0OyZuYnNwOyAmbmJz cDsgc2lnbmFsaW5nIGFtYmlndWl0eS48YnI+DQomZ3Q7PGJyPg0KJmd0OyBhbmQgaW4gc2VjdGlv biA5LjIsPGJyPg0KJmd0Ozxicj4NCiZndDsmbmJzcDsgJm5ic3A7IElmIGJvdGggJnF1b3Q7cGF1 c2UmcXVvdDsgYW5kICZxdW90O3RtbWJyJnF1b3Q7IGFyZSBwcmVzZW50IGluIHRoZSBTRFAsIFRN TUJSL1RNTUJOIE1VU1Q8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyBOT1QgYmUgdXNlZCBmb3IgcGF1 c2UvcmVzdW1lIHB1cnBvc2VzICh3aXRoIGEgYml0cmF0ZSB2YWx1ZSBvZiAwKSwgdG88YnI+DQom Z3Q7Jm5ic3A7ICZuYnNwOyBhdm9pZCBzaWduYWxpbmcgYW1iaWd1aXR5Ljxicj4NCiZndDs8YnI+ DQomZ3Q7IEknbSBub3cgd29uZGVyaW5nIGlmIHRoZSBkZXNjcmlwdGlvbiBvZiBUTU1CUi9UTU1C TiBpbiB0aGlzIHNwZWNpZmljYXRpb24ganVzdCBmb3IgaW50ZXJ3b3JraW5nIHdpdGggb2xkZXI8 YnI+DQomZ3Q7IGltcGxlbWVudGF0aW9ucyB0aGF0IGRvbid0IHN1cHBvcnQgUEFVU0UvUkVTVU1F IGJ1dCBmaWd1cmVkIG91dCBob3cgdG8gZ2V0IGEgc2ltaWxhciBlZmZlY3Qgd2l0aCBUTU1CUi9U TU1CTj88YnI+DQomZ3Q7PGJyPg0KJmd0OyBJJ20gZ3Vlc3NpbmcsIG9mIGNvdXJzZSA6LSk8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5bQm9CXSBZ b3VyIGd1ZXNzIGlzIGNvcnJlY3QuIFRoaXMgaXMgaGludGVkIGFscmVhZHkgd2l0aCB0aGUgbGFz dCB0d28gc2VudGVuY2VzIGluIHRoZSBJbnRyb2R1Y3Rpb24gc2VjdGlvbiAmcXVvdDtUaGUgVGVt cG9yYXJ5IE1heGltdW0gTWVkaWEgQml0cmF0ZSBSZXF1ZXN0IChUTU1CUikgbWVzc2FnZSBvZiBD Q00gaXMgdXNlZCBieSB2aWRlbyBjb25mZXJlbmNpbmcgc3lzdGVtcyBmb3IgZmxvdyBjb250cm9s LiBJdCBpcw0KIGRlc2lyYWJsZSB0byBiZSBhYmxlIHRvIHVzZSB0aGF0IG1ldGhvZCB3aXRoIGEg Yml0cmF0ZSB2YWx1ZSBvZiB6ZXJvIGZvciBwYXVzZSwgd2hlbmV2ZXIgcG9zc2libGUmcXVvdDsu IERvIHlvdSB0aGluayB0aGlzIG5lZWRzIHRvIGJlIG1vcmUgZXhwbGljaXRseSBzdGF0ZWQsIG1h eWJlIGluIHNlY3Rpb24gNS42IG9uIFRNTUJSL1RNTUJOIGNvbnNpZGVyYXRpb25zPyBTYXksIHNv bWV0aGluZyBzaW1pbGFyIHRvIHdoYXQgeW91IHNhaWQgYWJvdmU6ICZxdW90O1RoaXMNCiB1c2Ug aXMgZXhwZWN0ZWQgdG8gYmUgbWFpbmx5IGZvciBpbnRlcndvcmtpbmcgd2l0aCBpbXBsZW1lbnRh dGlvbnMgdGhhdCBkb24ndCBzdXBwb3J0IFBBVVNFL1JFU1VNRSwgYnV0IG1ha2UgdXNlIG9mIFRN TUJSL1RNTUJOIHRvIGFjaGlldmUgYSBzaW1pbGFyIGVmZmVjdCZxdW90Oy4gRG8geW91IHRoaW5r IHNvbWV0aGluZyBuZWVkcyB0byBiZSBzYWlkIGluIHNlY3Rpb24gOCB0b28/PG86cD48L286cD48 L3A+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGRvIHRo aW5rIHRoYXQgc2hvcnQgZXhwbGFuYXRpb25zIGFib3V0IG1vdGl2YXRpb24gYXJlIGhlbHBmdWwu PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48aT48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+W0JvQl0gT0suIEnigJlsbCBhZGQgYSBzZW50 ZW5jZSBvbiB0aGlzIGluIHNlY3Rpb24gNS42IGFuZCBpbiBzZWN0aW9uIDguPC9zcGFuPjwvaT48 L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y ZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21h cmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ Jmd0Ozxicj4NCiZndDsgSW4gdGhpcyB0ZXh0Ojxicj4NCiZndDs8YnI+DQomZ3Q7IDguNS4mbmJz cDsgVHJhbnNtaXNzaW9uIFJ1bGVzPGJyPg0KJmd0Ozxicj4NCiZndDsmbmJzcDsgJm5ic3A7IG8m bmJzcDsgUEFVU0UgU0hPVUxEIHVzZSBFYXJseSBvciBJbW1lZGlhdGUgdGltaW5nLCBleGNlcHQg Zm9yPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3JldHJhbnNtaXNzaW9ucyB0 aGF0IFNIT1VMRCB1c2UgUmVndWxhciB0aW1pbmcuPGJyPg0KJmd0Ozxicj4NCiZndDsgXiBJIHVu ZGVyc3RhbmQgdGhpcyBvbmUuPGJyPg0KJmd0Ozxicj4NCiZndDsmbmJzcDsgJm5ic3A7IG8mbmJz cDsgVGhlIGZpcnN0IHRyYW5zbWlzc2lvbiBvZiBQQVVTRUQgZm9yIGVhY2ggKG5vbi13cmFwcGVk KSBQYXVzZUlEPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO1NIT1VMRCBiZSBz ZW50IHdpdGggSW1tZWRpYXRlIG9yIEVhcmx5IHRpbWluZywgd2hpbGUgc3Vic2VxdWVudDxicj4N CiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtQQVVTRUQgZm9yIHRoYXQgUGF1c2VJRCBT SE9VTEQgdXNlIFJlZ3VsYXIgdGltaW5nLiZuYnNwOyBVbnNvbGljaXRlZDxicj4NCiZndDsmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtQQVVTRUQgKHNlbnQgd2hlbiBlbnRlcmluZyBMb2NhbCBQ YXVzZWQgU3RhdGUgKFNlY3Rpb24gNi40KSk8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7U0hPVUxEIGFsd2F5cyB1c2UgSW1tZWRpYXRlIG9yIEVhcmx5IHRpbWluZywgdW50aWwg UEFVU0VEIGZvciB0aGF0PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO1BhdXNl SUQgaXMgY29uc2lkZXJlZCBkZWxpdmVyZWQgYXQgbGVhc3Qgb25jZSB0byBhbGwgcmVjZWl2ZXJz IG9mPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3RoZSBwYXVzZWQgUlRQIHN0 cmVhbSwgYWZ0ZXIgd2hpY2ggaXQgU0hPVUxEIHVzZSBSZWd1bGFyIHRpbWluZy48YnI+DQomZ3Q7 PGJyPg0KJmd0OyBeIEknbSB3b25kZXJpbmcgd2h5IHRoZXNlIGFyZSBTSE9VTERzLiBBcmUgdGhl eSBNVVNUcyBleGNlcHQgdGhhdCBzb21lIGltcGxlbWVudGF0aW9ucyBkb24ndCBkbyBpdCwgb3I8 YnI+DQomZ3Q7IHJlY29tbWVuZGF0aW9ucyBidXQgbm90aGluZyBicmVha3MgaWYgeW91IGRvbid0 IGRvIHRoZW0sIG9yIHNvbWV0aGluZyBlbHNlPzxicj4NCltCb0JdIEl0IGlzIHJlY29tbWVuZGF0 aW9ucywgbWVhbmluZyB0aGF0IGlmIHlvdSBkb24ndCBmb2xsb3cgdGhlbSwgbm90aGluZyB3aWxs IHJlYWxseSBicmVhaywgYnV0IHlvdSdsbCBnZXQgd29yc2UgcGVyZm9ybWFuY2UgaW4gb25lIHdh eSBvciB0aGUgb3RoZXIuIFRoZSBTSE9VTERzIGZvciBFYXJseSBvciBJbW1lZGlhdGUgaXMgdG8g cHJvdmlkZSBnb29kIHRpbWVsaW5lc3MgYW5kIHJlc3BvbnNpdmVuZXNzIG9mIHRoZSBhcHBsaWNh dGlvbiBtYWtpbmcNCiB1c2Ugb2YgdGhlIG1lc3NhZ2VzLCB3aGlsZSB0aGUgU0hPVUxEcyBmb3Ig UmVndWxhciBhcmUgdG8gYXZvaWQgZXhjZXNzaXZlIGJhbmR3aWR0aCBjb25zdW1wdGlvbi48YnI+ DQo8YnI+DQomZ3Q7PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgbyZuYnNwOyBSRVNVTUUgU0hPVUxE IGFsd2F5cyB1c2UgSW1tZWRpYXRlIG9yIEVhcmx5IHRpbWluZy48YnI+DQomZ3Q7PGJyPg0KJmd0 OyBeIEkgd29uZGVyIHdoeSB0aGlzIGlzIFNIT1VMRC4gSXMgdGhlcmUgYW55IGd1aWRhbmNlIHlv dSBjYW4gcHJvdmlkZSBhYm91dCB3aHkgUkVTVU1FIHdvdWxkIHVzZSBSZWd1bGFyIHRpbWluZz88 YnI+DQpbQm9CXSBUaGUgb25seSBjYXNlIEkgY2FuIGNvbWUgdG8gdGhpbmsgb2YgaXMgd2hlbiBv dGhlciBSVENQIG1lc3NhZ2VzIHVzZWQgYnkgdGhlIGFwcGxpY2F0aW9uIGxheWVyIChub3QgUEFV U0UvUkVTVU1FKSBhcmUgc29tZWhvdyBjb25zaWRlcmVkIG1vcmUgaW1wb3J0YW50IHRoYW4gcmVz dW1pbmcgbWVkaWEgc3RyZWFtcyBpbiB0aGF0IHNwZWNpZmljIGFwcGxpY2F0aW9uIGNvbnRleHQu IEFnYWluLCBub3RoaW5nIHdvdWxkIHJlYWxseSBicmVhaw0KIHdpdGggcmVndWxhciB0aW1pbmcs IGJ1dCBwZXJmb3JtYW5jZSB3b3VsZCBjZXJ0YWlubHkgc3VmZmVyIGJhZGx5LiBNYXliZSBzdWNo IGFwcGxpY2F0aW9uLWxldmVsIGNvbnNpZGVyYXRpb24gaXMgc3VmZmljaWVudGx5ICZxdW90O2V4 dHJlbWUmcXVvdDsgdGhhdCBpdCBpcyBtb3RpdmF0ZWQgY2hhbmdpbmcgdG8gYSBNVVNULCBmb3Jj aW5nIHN1Y2ggc2l0dWF0aW9ucyB0byBicmVhayBjb21wbGlhbmNlPzxicj4NCjxicj4NCiZndDs8 YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyBvJm5ic3A7IFRoZSBmaXJzdCB0cmFuc21pc3Npb24gb2Yg UkVGVVNFRCBmb3IgZWFjaCAobm9uLXdyYXBwZWQpIFBhdXNlSUQ8YnI+DQomZ3Q7Jm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7U0hPVUxEIGJlIHNlbnQgd2l0aCBJbW1lZGlhdGUgb3IgRWFybHkg dGltaW5nLCB3aGlsZSBzdWJzZXF1ZW50PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwO1JFRlVTRUQgZm9yIHRoYXQgUGF1c2VJRCBTSE9VTEQgdXNlIFJlZ3VsYXIgdGltaW5nLjxi cj4NCiZndDs8YnI+DQomZ3Q7IF4gSSBhbSwgb2YgY291cnNlLCB3b25kZXJpbmcgYWJvdXQgdGhl IGNvcnJlc3BvbmRpbmcgU0hPVUxEcyBmb3IgUkVGVVNFRC48YnI+DQpbQm9CXSBUaW1lbHkgdHJh bnNtaXNzaW9uIG9mIFJFRlVTRUQgY2FuIHN0b3AgdW5uZWNlc3NhcnkgcmVwZXRpdGlvbnMgb2Yg UEFVU0Ugb3IgUkVTVU1FLCB3aGljaCBJIGJlbGlldmUgbW90aXZhdGVzIHJlY29tbWVuZGluZyBJ bW1lZGlhdGUgb3IgRWFybHkgZm9yIHRoZSBmaXJzdCB0cmFuc21pc3Npb24gdG8gc2F2ZSBzb21l IFJUQ1AgYmFuZHdpZHRoLiBUaGF0IGlzIGhvd2V2ZXIgbm90IGNvbnNpZGVyZWQgY3JpdGljYWwg ZW5vdWdoIHRvIG1vdGl2YXRlDQogcmVjb21tZW5kaW5nIHJlcGV0aXRpb25zIG9mIHRoZSBzYW1l IGluZGljYXRpb24gdG8gYmUgc2VudCB3aXRoIG90aGVyIHRoYW4gUmVndWxhciB0aW1pbmcuIE5v dGhpbmcgd291bGQgYnJlYWsgaWYgcmVwZXRpdGlvbnMgYXJlIHNlbnQgd2l0aCBFYXJseSBvciBJ bW1lZGlhdGUgdGltaW5nLCBidXQgaXQgd291bGQgcG90ZW50aWFsbHkgd2FzdGUgc29tZSB0cmFu c21pc3Npb24gb3Bwb3J0dW5pdGllcyBmb3Igb3RoZXIgUlRDUCAoRkIpIG1lc3NhZ2VzLg0KIERv IHlvdSB0aGluayBpdCBtb3RpdmF0ZWQgdG8gYWRkIG1vcmUgdGV4dCBvbiBzdWNoIGNvbnNpZGVy YXRpb25zPzxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+SSdkIGhhdmUgYSBwcmVmZXJlbmNlIGZvciB0ZXh0IHRoYXQgZXhwbGFpbnMg dGhlIHN0cmF0ZWd5LCByYXRoZXIgdGhhbiB1c2luZyBSRkMgMjExOSBsYW5ndWFnZSB3aGVuIHRo aXMgaXNuJ3QgYWN0dWFsbHkgYWJvdXQgaW50ZXJ3b3JraW5nLjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PGI+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPltCb0JdIE9LLiBJ4oCZbGwgZGVtb3RlIHRoZSBSRkMgMjExOSBsYW5ndWFnZSBp biB0aGF0IHNlY3Rpb24gdG8gcHJvc2UgdGV4dCBhbmQgYWRkIGJyaWVmIGRlc2NyaXB0aXZlIG1v dGl2YXRpb25zLjxvOnA+PC9vOnA+PC9zcGFuPjwvaT48L2I+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PGI+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkkg YWxzbyB0aGluayB0aGF0IGEgY2xhdXNlIG9uIFJUQ1AgdGltaW5nIGluIHNlY3Rpb24gOC40IChS RUZVU0VEKSBpcyBib3RoIG1pc3BsYWNlZCBhbmQgcmVkdW5kYW50LCBhbmQgcHJvcG9zZSB0byBy ZW1vdmUgaXQ6PG86cD48L286cD48L3NwYW4+PC9pPjwvYj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6NS4yNXB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjojMUY0OTdEIj4m bmJzcDsmbmJzcDsgSWYgUkVGVVNFRCBjb250YWluaW5nIGEgY2VydGFpbiBQYXVzZUlEIHdhcyBh bHJlYWR5IHNlbnQgYW5kIHlldCBtb3JlPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjUuMjVwdCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzFG NDk3RCI+Jm5ic3A7Jm5ic3A7IFBBVVNFIG9yIFJFU1VNRSBtZXNzYWdlcyBhcmUgcmVjZWl2ZWQg dGhhdCByZXF1aXJlIGFkZGl0aW9uYWwgUkVGVVNFRDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDo1LjI1cHQiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyB3aXRoIHRoYXQgc3BlY2lmaWMgUGF1c2VJRCB0byBi ZSBzY2hlZHVsZWQsIGZ1cnRoZXIgUkVGVVNFRCBtZXNzYWdlczxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDo1LjI1cHQiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyB3aXRoIHRoYXQgUGF1c2VJRCBTSE9VTEQg YmUgc2VudCBpbiByZWd1bGFyIFJUQ1AgcmVwb3J0cy4mbmJzcDsgQW48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6NS4yNXB0Ij48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l dyZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsgZXhjZXB0aW9uIHRvIHRoZSBwcmV2 aW91cyBydWxlIGlzIHdoZW4gdGhlIHN0cmVhbSB3YXMgcGF1c2VkIGFuZDxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDo1LjI1cHQi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg TmV3JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyByZXN1bWVkIHNvIG1hbnkgdGlt ZXMgdGhhdCB0aGUgUGF1c2VJRCBudW1iZXIgc3BhY2UgaGFzIHdyYXBwZWQgc2luY2U8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjojMUY0 OTdEIj4mbmJzcDsmbmJzcDsgJm5ic3A7UkVGVVNFRCB3YXMgbGFzdCBzZW50IHdpdGggdGhhdCBQ YXVzZUlELjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxp PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JIHRoaW5rIHRoYXQg Y2xhdXNlIHNob3VsZCBiZSBmdWxseSBjb3ZlcmVkIGJ5IHRoZSBsYXN0IGJ1bGxldCBpbiA4LjUg KHRleHQgY29waWVkIGZyb20gLTA4OyB3aWxsIGJlIGNoYW5nZWQpOjxvOnA+PC9vOnA+PC9zcGFu PjwvaT48L2I+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjUu MjVwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7IG8mbmJzcDsgVGhlIGZp cnN0IHRyYW5zbWlzc2lvbiBvZiBSRUZVU0VEIGZvciBlYWNoIChub24td3JhcHBlZCkgUGF1c2VJ RDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW4tbGVmdDo1LjI1cHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyBTSE9VTEQgYmUgc2VudCB3aXRoIEltbWVkaWF0ZSBvciBFYXJseSB0aW1p bmcsIHdoaWxlIHN1YnNlcXVlbnQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtD b3VyaWVyIE5ldyZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgJm5ic3A7UkVGVVNFRCBmb3IgdGhhdCBQYXVzZUlEIFNIT1VMRCB1c2UgUmVndWxhciB0 aW1pbmcuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxl PSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNt IDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj4mZ3Q7PGJyPg0KJmd0OyBJbiB0aGlzIHRleHQ6PGJyPg0KJmd0Ozxi cj4NCiZndDsgOS4mbmJzcDsgU2lnbmFsaW5nPGJyPg0KJmd0Ozxicj4NCiZndDsmbmJzcDsgJm5i c3A7IFdoZW4gc2lnbmFsaW5nIGEgY29uZmlnIHZhbHVlIG90aGVyIHRoYW4gMSwgYW4gaW1wbGVt ZW50YXRpb24gTVVTVDxicj4NCiZndDsmbmJzcDsgJm5ic3A7IGlnbm9yZSBub24tc3VwcG9ydGVk IG1lc3NhZ2VzIG9uIHJlY2VwdGlvbiwgYW5kIE1BWSBvbWl0IHNlbmRpbmcgbm9uLTxicj4NCiZn dDsmbmJzcDsgJm5ic3A7IHN1cHBvcnRlZCBtZXNzYWdlcy48YnI+DQomZ3Q7PGJyPg0KJmd0OyBp cyB0aGlzIHNheWluZyB0aGF0IGFuIGltcGxlbWVudGF0aW9uIG1pZ2h0IHNlbmQgbm9uLXN1cHBv cnRlZCBtZXNzYWdlcz88YnI+DQomZ3Q7IEknbSBjb25mdXNlZCBoZXJlLjxicj4NCltCb0JdIFRo YXQgc2hvdWxkIGhhdmUgYmVlbiAmcXVvdDsuLi4gTUFZIG9taXQgc2VuZGluZyBtZXNzYWdlcyBu b3Qgc3VwcG9ydGVkIGJ5IHRoZSByZW1vdGUgcGVlciZxdW90Oy4gSSByZWFsaXplIHRoYXQgZnVy dGhlciBkb3duIGl0IGlzIHNhaWQgJnF1b3Q7Li4uIFNIT1VMRCBOT1QgYmUgdXNlZCB0b3dhcmRz IHJlY2VpdmVycyB0aGF0IGRpZCBub3QgZGVjbGFyZSBjYXBhYmlsaXR5IHRvIHJlY2VpdmUgdGhv c2UgbWVzc2FnZXMmcXVvdDssIHNvIEkgZ3Vlc3MgdGhhdCBNQVkgc2hvdWxkDQogYmUgY2hhbmdl ZCB0byBhIFNIT1VMRCB0byBiZSBjb25zaXN0ZW50LiBJbiBhbnkgY2FzZSwgbm90IGhhdmluZyBN VVNUcyBoZXJlIGFsbG93cyBhIG1peCBvZiBkaWZmZXJlbnQgY2FwYWJpbGl0aWVzIGFtb25nIHJl Y2VpdmVycyBpbiBhIG11bHRpLXJlY2VpdmVyIGNhc2Ugd2l0aG91dCBsZXR0aW5nIHRoZSBsZWFz dCBjYXBhYmxlIHJlY2VpdmVyIHNldCB0aGUgbGV2ZWwgb2YgUC9SIGZ1bmN0aW9uYWxpdHkgZm9y IGFsbCB0aGUgb3RoZXJzLiBXaXRoDQogdGhhdCBpbiBtaW5kLCBkbyB5b3UgdGhpbmsgJnF1b3Q7 U0hPVUxEIG9taXQmcXVvdDsgaXMgYSB0b28gc3Ryb25nIHdvcmRpbmc/PG86cD48L286cD48L3A+ DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5NYWtpbmcgaXQg Y2xlYXIgd2hvIGlzbid0IHN1cHBvcnRpbmcgdGhlIG5vbi1zdXBwb3J0ZWQgbWVzc2FnZXMgc2Vl bXMgaGVscGZ1bC4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxi PjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5bQm9CXSBEZWZp bml0ZWx5IDopPC9zcGFuPjwvaT48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+SSdkIGJlIE9LIHdpdGggZWl0aGVyIE1BWSBvciBTSE9VTEQgaW4gYm90 aCBwbGFjZXMgKHlvdSBndXlzIGFyZSB0aGUgZXhwZXJ0cyksIGJ1dCBpdCBzb3VuZHMgbGlrZSB0 aGV5IHNob3VsZCBtYXRjaC4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxiPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5bQm9C XSBPSy4gSSBzdWdnZXN0IHRvIGdvIGZvciBTSE9VTEQgaW4gYm90aCBwbGFjZXMsIGFuZCBhbHNv IGFkZCBhIHNlbnRlbmNlIG9uIHdoZW4gaXQgY2FuIGJlIG1vdGl2YXRlZCB0byB2aW9sYXRlIHRo YXQgKG11bHRpcGxlIHJlY2VpdmVycyB3aXRoIGRpZmZlcmVudA0KIGNvbmZpZy1jYXBhYmlsaXRp ZXMsIHRvIGF2b2lkIHRoYXQgdGhlIGxlYXN0IGNhcGFibGUgcmVjZWl2ZXIgc2V0cyB0aGUgZnVu Y3Rpb25hbGl0eSBkZWxpdmVyZWQgdG8gb3RoZXJzKS48bzpwPjwvbzpwPjwvc3Bhbj48L2k+PC9i PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj5JIGFsc28gcmVjZWl2ZWQgYW4gb2ZmbGluZSBjb21tZW50IHN1 Z2dlc3RpbmcgdG8gY2xhcmlmeSB0aGF0IG5vIHBhcnRpYWwgbWVzc2FnZSBzdXBwb3J0IGlzIHBv c3NpYmxlIHdoZW4gdXNpbmcgVE1NQlIvVE1NQk4sIHdoaWNoIHNob3VsZCBiZSBvYnZpb3VzIChz aW5jZQ0KIHRoZXJlIGlzIG5vIHN1Y2ggc3VwcG9ydCBpbiBSRkMgNTEwNCksIGJ1dCBJIGFueXdh eSB0aGluayB0aGF0IGlzIGEgcmVhc29uYWJsZSBjbGFyaWZpY2F0aW9uIHRvIGFkZC48L3NwYW4+ PC9pPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5U aGFua3MhPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPlNwZW5jZXImbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_BBE9739C2C302046BD34B42713A1E2A22E70B1EDESESSMB105erics_-- From nobody Tue Sep 1 15:38:40 2015 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBD121A6F82; Tue, 1 Sep 2015 15:38:35 -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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 f65vD4ZjGD8n; Tue, 1 Sep 2015 15:38:31 -0700 (PDT) Received: from mail-vk0-x22d.google.com (mail-vk0-x22d.google.com [IPv6:2607:f8b0:400c:c05::22d]) (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 AAE031A8A25; Tue, 1 Sep 2015 15:38:30 -0700 (PDT) Received: by vkaw128 with SMTP id w128so65735537vka.2; Tue, 01 Sep 2015 15:38:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=8Id8jj09W+IZCjWMbrXeVUbKTNE97IXY/w1eJ9pFNjc=; b=ErY7W0RGA9JKj8VdoTG1v29ijP1tm7UQl18aghyuWc6eZsVGzH/7iNp0uGXIRjTJ01 dU20YiaGpNPXrb+mf5QEhCtig0JAa8Cmo9kF9J6Qqd5/KzL2RvVwBxRkrUOCTGEK7Ilh ARyIqw7Py8z8CiD4qv4sd2bG8+rfTASkytJ7oWWD94YISM0TwOwsqqEva6izRF6Pz+9G Bt8gTwxxO6l+ei9SFOlZ4Kx5efAS7pXbiunnQSjlc2RvlzywG+FKQH6VuEfEtoChD5PW UqxY429xBqUgjPpVUK3AaPjy2wcpQbacEaFgQHNiWbua2hunx0RZJHH0i4nEOK1tC9cQ z6Pg== MIME-Version: 1.0 X-Received: by 10.52.114.196 with SMTP id ji4mr33497972vdb.24.1441147109835; Tue, 01 Sep 2015 15:38:29 -0700 (PDT) Received: by 10.31.63.1 with HTTP; Tue, 1 Sep 2015 15:38:29 -0700 (PDT) In-Reply-To: References: <20150819031636.31652.86423.idtracker@ietfa.amsl.com> Date: Tue, 1 Sep 2015 17:38:29 -0500 Message-ID: From: Spencer Dawkins at IETF To: Bo Burman Content-Type: multipart/alternative; boundary=bcaec548a5038d0d50051eb735d6 Archived-At: Cc: "jonathan@vidyo.com" , "avtext@ietf.org" , "avtext-chairs@ietf.org" , "draft-ietf-avtext-rtp-stream-pause@ietf.org" , The IESG , "draft-ietf-avtext-rtp-stream-pause.ad@ietf.org" , "draft-ietf-avtext-rtp-stream-pause.shepherd@ietf.org" Subject: Re: [avtext] Spencer Dawkins' Yes on draft-ietf-avtext-rtp-stream-pause-08: (with COMMENT) X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Sep 2015 22:38:36 -0000 --bcaec548a5038d0d50051eb735d6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, Bo, This all seems fine to me. Thank you for catching me up! Spencer On Tue, Sep 1, 2015 at 4:39 AM, Bo Burman wrote: > Hi Spencer, > > > > I think your proposals are good and will make changes accordingly. See > more inline. > > > > *From:* Spencer Dawkins at IETF [mailto:spencerdawkins.ietf@gmail.com] > *Sent:* den 27 augusti 2015 14:37 > *To:* Bo Burman > *Cc:* The IESG; draft-ietf-avtext-rtp-stream-pause@ietf.org; > draft-ietf-avtext-rtp-stream-pause.ad@ietf.org; jonathan@vidyo.com; > draft-ietf-avtext-rtp-stream-pause.shepherd@ietf.org; > avtext-chairs@ietf.org; avtext@ietf.org > *Subject:* Re: Spencer Dawkins' Yes on > draft-ietf-avtext-rtp-stream-pause-08: (with COMMENT) > > > > Hi, Bo, > > > > On Thu, Aug 27, 2015 at 6:28 AM, Bo Burman wrote= : > > Thank you for good and constructive comments. Please find responses to > your questions inline below. > Cheers, > Bo > > > > -----Original Message----- > > From: Spencer Dawkins [mailto:spencerdawkins.ietf@gmail.com] > > Sent: den 19 augusti 2015 05:17 > > To: The IESG > > Cc: draft-ietf-avtext-rtp-stream-pause@ietf.org; > draft-ietf-avtext-rtp-stream-pause.ad@ietf.org; jonathan@vidyo.com; > > draft-ietf-avtext-rtp-stream-pause.shepherd@ietf.org; > avtext-chairs@ietf.org; avtext@ietf.org > > Subject: Spencer Dawkins' Yes on draft-ietf-avtext-rtp-stream-pause-08: > (with COMMENT) > > > > Spencer Dawkins has entered the following ballot position for > > draft-ietf-avtext-rtp-stream-pause-08: 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-avtext-rtp-stream-pause/ > > > > > > > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > > This draft was really easy for me to read (with some background in > RTP/RTCP, but I'm no expert on the topic). Thank you > > for the work on it - the results show. > > > > I have some questions, but nothing is a show-stopper. > > > > In this text: > > > > 3.3. RTP Mixer to Media Sender in Point-to-Multipoint > > > > In this use case there are several receivers of a stream and special > > care must be taken as not to pause a stream that is still wanted by > > some receivers. > > > > I'm assuming that the Mixer is taking special care, but this is passive > enough that I'm filling in blanks. If you like passive > > voice, perhaps something like > > > > In this use case there are several receivers of a stream and special > > care must be taken by the Mixer so as not to pause a stream that is > > ^^^^^^^^^^^^^^^ > > still wanted by some receivers. > > > > would be easier to parse. > > > > If you can do active voice, perhaps > > > > In this use case there are several receivers of a stream and the > > Mixer must take special care so as not to pause a stream that is sti= ll > > > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > wanted by some receivers. > > [BoB] Thanks, your assumption is correct, and I think this active voice i= s > easier to read. > > > > Great. > > > > > > > In this text: > > > > 8. Message Details > > > > Any references to PAUSE, PAUSED, RESUME and REFUSED in this section > > SHALL be taken to apply to the extent possible also when TMMBR/TMMBN > > are used (Section 5.6) for this functionality. TMMBR/TMMBN MAY be > > ^^^ > > used instead of the messages defined in this specification when the > > effective topology is point-to-point. If either sender or receiver > > learns that the topology is not point-to-point, TMMBR/TMMBN MUST NOT > > be used for pause/resume functionality. If the messages defined in > > this specification are supported in addition to TMMBR/TMMBN by all > > involved parties, pause/resume signaling MUST use messages from this > > specification. If the topology is not point-to-point and the > > messages defined in this specification are not supported, pause/ > > resume functionality with TMMBR/TMMBN MUST NOT be used. > > > > All of this makes sense to me, except that I'm not understanding why > TMMBR/TMMBN is a MAY. There's a lot of text that > > says you really need to use the messages from this specification in thi= s > case, and in that case, and ... but here, you MAY > > do something else. > > > > I understand that TMMBR/TMMBN works in a point-to-point topology, but i= s > there a reason to prefer TMMBR/TMMBN > > in that topology? If so, it would probably be good to explain why. > > > > And as I read futher, I see this, in section 9: > > > > Note: When TMMBR 0 / TMMBN 0 are used to implement pause and > > resume functionality (with the restrictions described in this > > specification), signaling rtcp-fb attribute with ccm tmmbr > > parameter is sufficient and no further signaling is necessary. > > There is however no guarantee that TMMBR/TMMBN implementations > > ^^^^^^^^^^^^ > > pre-dating this specification work exactly as described here when > > used with a bitrate value of 0. > > > > and that really makes me wonder why this specification is also > describing TMMBR/TMMBN. I'm sure there's a good > > reason, but can you understand my confusion? > > > > Finally, I see this, in section 9.1, > > > > If both "pause" and "tmmbr" are present in the offer, both MAY be > > included also in the answer, in which case TMMBR/TMMBN MUST NOT be > > used for pause/resume purposes (with a bitrate value of 0), to avoid > > signaling ambiguity. > > > > and in section 9.2, > > > > If both "pause" and "tmmbr" are present in the SDP, TMMBR/TMMBN MUST > > NOT be used for pause/resume purposes (with a bitrate value of 0), t= o > > avoid signaling ambiguity. > > > > I'm now wondering if the description of TMMBR/TMMBN in this > specification just for interworking with older > > implementations that don't support PAUSE/RESUME but figured out how to > get a similar effect with TMMBR/TMMBN? > > > > I'm guessing, of course :-) > > [BoB] Your guess is correct. This is hinted already with the last two > sentences in the Introduction section "The Temporary Maximum Media Bitrat= e > Request (TMMBR) message of CCM is used by video conferencing systems for > flow control. It is desirable to be able to use that method with a bitrat= e > value of zero for pause, whenever possible". Do you think this needs to b= e > more explicitly stated, maybe in section 5.6 on TMMBR/TMMBN consideration= s? > Say, something similar to what you said above: "This use is expected to b= e > mainly for interworking with implementations that don't support > PAUSE/RESUME, but make use of TMMBR/TMMBN to achieve a similar effect". D= o > you think something needs to be said in section 8 too? > > > > I do think that short explanations about motivation are helpful. > > *[BoB] OK. I=E2=80=99ll add a sentence on this in section 5.6 and in sect= ion 8.* > > > > > > > In this text: > > > > 8.5. Transmission Rules > > > > o PAUSE SHOULD use Early or Immediate timing, except for > > retransmissions that SHOULD use Regular timing. > > > > ^ I understand this one. > > > > o The first transmission of PAUSED for each (non-wrapped) PauseID > > SHOULD be sent with Immediate or Early timing, while subsequent > > PAUSED for that PauseID SHOULD use Regular timing. Unsolicited > > PAUSED (sent when entering Local Paused State (Section 6.4)) > > SHOULD always use Immediate or Early timing, until PAUSED for tha= t > > PauseID is considered delivered at least once to all receivers of > > the paused RTP stream, after which it SHOULD use Regular timing. > > > > ^ I'm wondering why these are SHOULDs. Are they MUSTs except that some > implementations don't do it, or > > recommendations but nothing breaks if you don't do them, or something > else? > [BoB] It is recommendations, meaning that if you don't follow them, > nothing will really break, but you'll get worse performance in one way or > the other. The SHOULDs for Early or Immediate is to provide good timeline= ss > and responsiveness of the application making use of the messages, while t= he > SHOULDs for Regular are to avoid excessive bandwidth consumption. > > > > > o RESUME SHOULD always use Immediate or Early timing. > > > > ^ I wonder why this is SHOULD. Is there any guidance you can provide > about why RESUME would use Regular timing? > [BoB] The only case I can come to think of is when other RTCP messages > used by the application layer (not PAUSE/RESUME) are somehow considered > more important than resuming media streams in that specific application > context. Again, nothing would really break with regular timing, but > performance would certainly suffer badly. Maybe such application-level > consideration is sufficiently "extreme" that it is motivated changing to = a > MUST, forcing such situations to break compliance? > > > > > o The first transmission of REFUSED for each (non-wrapped) PauseID > > SHOULD be sent with Immediate or Early timing, while subsequent > > REFUSED for that PauseID SHOULD use Regular timing. > > > > ^ I am, of course, wondering about the corresponding SHOULDs for REFUSE= D. > [BoB] Timely transmission of REFUSED can stop unnecessary repetitions of > PAUSE or RESUME, which I believe motivates recommending Immediate or Earl= y > for the first transmission to save some RTCP bandwidth. That is however n= ot > considered critical enough to motivate recommending repetitions of the sa= me > indication to be sent with other than Regular timing. Nothing would break > if repetitions are sent with Early or Immediate timing, but it would > potentially waste some transmission opportunities for other RTCP (FB) > messages. Do you think it motivated to add more text on such consideratio= ns? > > > > I'd have a preference for text that explains the strategy, rather than > using RFC 2119 language when this isn't actually about interworking. > > *[BoB] OK. I=E2=80=99ll demote the RFC 2119 language in that section to p= rose text > and add brief descriptive motivations.* > > *I also think that a clause on RTCP timing in section 8.4 (REFUSED) is > both misplaced and redundant, and propose to remove it:* > > If REFUSED containing a certain PauseID was already sent and yet more > > PAUSE or RESUME messages are received that require additional REFUSED > > with that specific PauseID to be scheduled, further REFUSED messages > > with that PauseID SHOULD be sent in regular RTCP reports. An > > exception to the previous rule is when the stream was paused and > > resumed so many times that the PauseID number space has wrapped since > > REFUSED was last sent with that PauseID. > > *I think that clause should be fully covered by the last bullet in 8.5 > (text copied from -08; will be changed):* > > o The first transmission of REFUSED for each (non-wrapped) PauseID > > SHOULD be sent with Immediate or Early timing, while subsequent > > REFUSED for that PauseID SHOULD use Regular timing. > > > > > > > In this text: > > > > 9. Signaling > > > > When signaling a config value other than 1, an implementation MUST > > ignore non-supported messages on reception, and MAY omit sending non= - > > supported messages. > > > > is this saying that an implementation might send non-supported messages= ? > > I'm confused here. > [BoB] That should have been "... MAY omit sending messages not supported > by the remote peer". I realize that further down it is said "... SHOULD N= OT > be used towards receivers that did not declare capability to receive thos= e > messages", so I guess that MAY should be changed to a SHOULD to be > consistent. In any case, not having MUSTs here allows a mix of different > capabilities among receivers in a multi-receiver case without letting the > least capable receiver set the level of P/R functionality for all the > others. With that in mind, do you think "SHOULD omit" is a too strong > wording? > > > > Making it clear who isn't supporting the non-supported messages seems > helpful. > > *[BoB] Definitely :)* > > > > I'd be OK with either MAY or SHOULD in both places (you guys are the > experts), but it sounds like they should match. > > *[BoB] OK. I suggest to go for SHOULD in both places, and also add a > sentence on when it can be motivated to violate that (multiple receivers > with different config-capabilities, to avoid that the least capable > receiver sets the functionality delivered to others).* > > *I also received an offline comment suggesting to clarify that no partial > message support is possible when using TMMBR/TMMBN, which should be obvio= us > (since there is no such support in RFC 5104), but I anyway think that is = a > reasonable clarification to add.* > > > > Thanks! > > > > Spencer > --bcaec548a5038d0d50051eb735d6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi, Bo,

This all seems fine to me. Than= k you for catching me up!

Spencer

On Tue, Sep 1, 2015 at 4:39 AM= , Bo Burman <bo.burman@ericsson.com> wrote:

Hi Spencer,=

=C2=A0

I think your proposals ar= e good and will make changes accordingly. See more inline.

=C2=A0

=C2=A0

Hi, Bo,

=C2=A0

On Thu, Aug 27, 2015 at 6:28 AM, Bo Burman <bo.burman@ericsson.c= om> wrote:

Thank you for good and constructive comments. Please= find responses to your questions inline below.
Cheers,
Bo


> -----Original Message-----
> From: Spencer Dawkins [mailto:spencerdawkins.ietf@gmail.com]
> Sent: den 19 augusti 2015 05:17
> To: The IESG
> Cc: draft-ietf-avtext-rtp-stream-pause@ietf.org; draft-ietf-avtext-rtp-stream-pause.ad@ietf.org; jonathan@vidyo.com<= /a>;
> draft-ietf-avtext-rtp-stream-pause.shepherd@ietf.org; avtext-chairs@i= etf.org; avtext@ietf.org
> Subject: Spencer Dawkins' Yes on draft-ietf-avtext-rtp-stream-paus= e-08: (with COMMENT)
>
> Spencer Dawkins has entered the following ballot position for
> draft-ietf-avtext-rtp-stream-pause-08: 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-avtext-rtp-stream-pause/ >
>
>
> ----------------------------------------------------------------------=
> COMMENT:
> ----------------------------------------------------------------------=
>
> This draft was really easy for me to read (with some background in RTP= /RTCP, but I'm no expert on the topic). Thank you
> for the work on it - the results show.
>
> I have some questions, but nothing is a show-stopper.
>
> In this text:
>
> 3.3.=C2=A0 RTP Mixer to Media Sender in Point-to-Multipoint
>
>=C2=A0 =C2=A0 In this use case there are several receivers of a stream = and special
>=C2=A0 =C2=A0 care must be taken as not to pause a stream that is still= wanted by
>=C2=A0 =C2=A0 some receivers.
>
> I'm assuming that the Mixer is taking special care, but this is pa= ssive enough that I'm filling in blanks. If you like passive
> voice, perhaps something like
>
>=C2=A0 =C2=A0 In this use case there are several receivers of a stream = and special
>=C2=A0 =C2=A0 care must be taken by the Mixer so as not to pause a stre= am that is
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0^^^^^^^^^^^^^^^
>=C2=A0 =C2=A0 still wanted by some receivers.
>
> would be easier to parse.
>
> If you can do active voice, perhaps
>
>=C2=A0 =C2=A0 In this use case there are several receivers of a stream = and the
>=C2=A0 =C2=A0 Mixer must take special care so as not to pause a stream = that is still
>
>=C2=A0 =C2=A0 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>=C2=A0 =C2=A0 wanted by some receivers.

[BoB] Thanks, your assumption is correct, and I thin= k this active voice is easier to read.

=C2=A0

Great.

=C2=A0

>
> In this text:
>
> 8.=C2=A0 Message Details
>
>=C2=A0 =C2=A0 Any references to PAUSE, PAUSED, RESUME and REFUSED in th= is section
>=C2=A0 =C2=A0 SHALL be taken to apply to the extent possible also when = TMMBR/TMMBN
>=C2=A0 =C2=A0 are used (Section 5.6) for this functionality.=C2=A0 TMMB= R/TMMBN MAY be
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 ^^^
>=C2=A0 =C2=A0 used instead of the messages defined in this specificatio= n when the
>=C2=A0 =C2=A0 effective topology is point-to-point.=C2=A0 If either sen= der or receiver
>=C2=A0 =C2=A0 learns that the topology is not point-to-point, TMMBR/TMM= BN MUST NOT
>=C2=A0 =C2=A0 be used for pause/resume functionality.=C2=A0 If the mess= ages defined in
>=C2=A0 =C2=A0 this specification are supported in addition to TMMBR/TMM= BN by all
>=C2=A0 =C2=A0 involved parties, pause/resume signaling MUST use message= s from this
>=C2=A0 =C2=A0 specification.=C2=A0 If the topology is not point-to-poin= t and the
>=C2=A0 =C2=A0 messages defined in this specification are not supported,= pause/
>=C2=A0 =C2=A0 resume functionality with TMMBR/TMMBN MUST NOT be used. >
> All of this makes sense to me, except that I'm not understanding w= hy TMMBR/TMMBN is a MAY. There's a lot of text that
> says you really need to use the messages from this specification in th= is case, and in that case, and ... but here, you MAY
> do something else.
>
> I understand that TMMBR/TMMBN works in a point-to-point topology, but = is there a reason to prefer TMMBR/TMMBN
> in that topology? If so, it would probably be good to explain why.
>
> And as I read futher, I see this, in section 9:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Note: When TMMBR 0 / TMMBN 0 are used to imp= lement pause and
>=C2=A0 =C2=A0 =C2=A0 =C2=A0resume functionality (with the restrictions = described in this
>=C2=A0 =C2=A0 =C2=A0 =C2=A0specification), signaling rtcp-fb attribute = with ccm tmmbr
>=C2=A0 =C2=A0 =C2=A0 =C2=A0parameter is sufficient and no further signa= ling is necessary.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0There is however no guarantee that TMMBR/TMM= BN implementations
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 ^^^^^^^^^^^^
>=C2=A0 =C2=A0 =C2=A0 =C2=A0pre-dating this specification work exactly a= s described here when
>=C2=A0 =C2=A0 =C2=A0 =C2=A0used with a bitrate value of 0.
>
> and that really makes me wonder why this specification is also describ= ing TMMBR/TMMBN. I'm sure there's a good
> reason, but can you understand my confusion?
>
> Finally, I see this, in section 9.1,
>
>=C2=A0 =C2=A0 If both "pause" and "tmmbr" are prese= nt in the offer, both MAY be
>=C2=A0 =C2=A0 included also in the answer, in which case TMMBR/TMMBN MU= ST NOT be
>=C2=A0 =C2=A0 used for pause/resume purposes (with a bitrate value of 0= ), to avoid
>=C2=A0 =C2=A0 signaling ambiguity.
>
> and in section 9.2,
>
>=C2=A0 =C2=A0 If both "pause" and "tmmbr" are prese= nt in the SDP, TMMBR/TMMBN MUST
>=C2=A0 =C2=A0 NOT be used for pause/resume purposes (with a bitrate val= ue of 0), to
>=C2=A0 =C2=A0 avoid signaling ambiguity.
>
> I'm now wondering if the description of TMMBR/TMMBN in this specif= ication just for interworking with older
> implementations that don't support PAUSE/RESUME but figured out ho= w to get a similar effect with TMMBR/TMMBN?
>
> I'm guessing, of course :-)

[BoB] Your guess is correct. This is hinted already = with the last two sentences in the Introduction section "The Temporary= Maximum Media Bitrate Request (TMMBR) message of CCM is used by video conf= erencing systems for flow control. It is desirable to be able to use that method with a bitrate value of zero for p= ause, whenever possible". Do you think this needs to be more explicitl= y stated, maybe in section 5.6 on TMMBR/TMMBN considerations? Say, somethin= g similar to what you said above: "This use is expected to be mainly for interworking with implementations that do= n't support PAUSE/RESUME, but make use of TMMBR/TMMBN to achieve a simi= lar effect". Do you think something needs to be said in section 8 too?=

=C2=A0

I do think that short explanations about motivation = are helpful.

[BoB] O= K. I=E2=80=99ll add a sentence on this in section 5.6 and in section 8.

=C2=A0

>
> In this text:
>
> 8.5.=C2=A0 Transmission Rules
>
>=C2=A0 =C2=A0 o=C2=A0 PAUSE SHOULD use Early or Immediate timing, excep= t for
>=C2=A0 =C2=A0 =C2=A0 =C2=A0retransmissions that SHOULD use Regular timi= ng.
>
> ^ I understand this one.
>
>=C2=A0 =C2=A0 o=C2=A0 The first transmission of PAUSED for each (non-wr= apped) PauseID
>=C2=A0 =C2=A0 =C2=A0 =C2=A0SHOULD be sent with Immediate or Early timin= g, while subsequent
>=C2=A0 =C2=A0 =C2=A0 =C2=A0PAUSED for that PauseID SHOULD use Regular t= iming.=C2=A0 Unsolicited
>=C2=A0 =C2=A0 =C2=A0 =C2=A0PAUSED (sent when entering Local Paused Stat= e (Section 6.4))
>=C2=A0 =C2=A0 =C2=A0 =C2=A0SHOULD always use Immediate or Early timing,= until PAUSED for that
>=C2=A0 =C2=A0 =C2=A0 =C2=A0PauseID is considered delivered at least onc= e to all receivers of
>=C2=A0 =C2=A0 =C2=A0 =C2=A0the paused RTP stream, after which it SHOULD= use Regular timing.
>
> ^ I'm wondering why these are SHOULDs. Are they MUSTs except that = some implementations don't do it, or
> recommendations but nothing breaks if you don't do them, or someth= ing else?
[BoB] It is recommendations, meaning that if you don't follow them, not= hing will really break, but you'll get worse performance in one way or = the other. The SHOULDs for Early or Immediate is to provide good timeliness= and responsiveness of the application making use of the messages, while the SHOULDs for Regular are to avoid excessive = bandwidth consumption.

>
>=C2=A0 =C2=A0 o=C2=A0 RESUME SHOULD always use Immediate or Early timin= g.
>
> ^ I wonder why this is SHOULD. Is there any guidance you can provide a= bout why RESUME would use Regular timing?
[BoB] The only case I can come to think of is when other RTCP messages used= by the application layer (not PAUSE/RESUME) are somehow considered more im= portant than resuming media streams in that specific application context. A= gain, nothing would really break with regular timing, but performance would certainly suffer badly. Maybe s= uch application-level consideration is sufficiently "extreme" tha= t it is motivated changing to a MUST, forcing such situations to break comp= liance?

>
>=C2=A0 =C2=A0 o=C2=A0 The first transmission of REFUSED for each (non-w= rapped) PauseID
>=C2=A0 =C2=A0 =C2=A0 =C2=A0SHOULD be sent with Immediate or Early timin= g, while subsequent
>=C2=A0 =C2=A0 =C2=A0 =C2=A0REFUSED for that PauseID SHOULD use Regular = timing.
>
> ^ I am, of course, wondering about the corresponding SHOULDs for REFUS= ED.
[BoB] Timely transmission of REFUSED can stop unnecessary repetitions of PA= USE or RESUME, which I believe motivates recommending Immediate or Early fo= r the first transmission to save some RTCP bandwidth. That is however not c= onsidered critical enough to motivate recommending repetitions of the same indication to be sent with other than= Regular timing. Nothing would break if repetitions are sent with Early or = Immediate timing, but it would potentially waste some transmission opportun= ities for other RTCP (FB) messages. Do you think it motivated to add more text on such considerations?<= u>

=C2=A0

I'd have a preference for text that explains the= strategy, rather than using RFC 2119 language when this isn't actually= about interworking.

[BoB] OK. I= =E2=80=99ll demote the RFC 2119 language in that section to prose text and = add brief descriptive motivations.

I also think that a= clause on RTCP timing in section 8.4 (REFUSED) is both misplaced and redun= dant, and propose to remove it:

=C2=A0=C2=A0 If= REFUSED containing a certain PauseID was already sent and yet more<= u>

=C2=A0=C2=A0 PA= USE or RESUME messages are received that require additional REFUSED<= u>

=C2=A0=C2=A0 wi= th that specific PauseID to be scheduled, further REFUSED messages

=C2=A0=C2=A0 wi= th that PauseID SHOULD be sent in regular RTCP reports.=C2=A0 An<= /u>

=C2=A0=C2=A0 ex= ception to the previous rule is when the stream was paused and

=C2=A0=C2=A0 re= sumed so many times that the PauseID number space has wrapped since<= u>

=C2=A0=C2=A0 =C2=A0REFUSED was last sent wit= h that PauseID.

I think that clause= should be fully covered by the last bullet in 8.5 (text copied from -08; w= ill be changed):

=C2=A0=C2=A0 o= =C2=A0 The first transmission of REFUSED for each (non-wrapped) PauseID<= /u>

=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 SHOULD be sent with Immediate or Early timing, while subseq= uent

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0REFUSED= for that PauseID SHOULD use Regular timing.

=C2=A0

>
> In this text:
>
> 9.=C2=A0 Signaling
>
>=C2=A0 =C2=A0 When signaling a config value other than 1, an implementa= tion MUST
>=C2=A0 =C2=A0 ignore non-supported messages on reception, and MAY omit = sending non-
>=C2=A0 =C2=A0 supported messages.
>
> is this saying that an implementation might send non-supported message= s?
> I'm confused here.
[BoB] That should have been "... MAY omit sending messages not support= ed by the remote peer". I realize that further down it is said ".= .. SHOULD NOT be used towards receivers that did not declare capability to = receive those messages", so I guess that MAY should be changed to a SHOULD to be consistent. In any case, not having MUSTs her= e allows a mix of different capabilities among receivers in a multi-receive= r case without letting the least capable receiver set the level of P/R func= tionality for all the others. With that in mind, do you think "SHOULD omit" is a too strong wording= ?

=C2=A0

Making it clear who isn't supporting the non-sup= ported messages seems helpful.=C2=A0

[BoB] Defini= tely :)

=C2=A0

I'd be OK with either MAY or SHOULD in both plac= es (you guys are the experts), but it sounds like they should match.=C2=A0<= u>

[BoB] OK. I = suggest to go for SHOULD in both places, and also add a sentence on when it= can be motivated to violate that (multiple receivers with different config-capabilities, to avoid that the least capable receiver sets the fun= ctionality delivered to others).

I also received an = offline comment suggesting to clarify that no partial message support is po= ssible when using TMMBR/TMMBN, which should be obvious (since there is no such support in RFC 5104), but I anyway think that is a reason= able clarification to add.=

=C2=A0

Thanks!

=C2=A0

Spencer=C2=A0


--bcaec548a5038d0d50051eb735d6-- From nobody Wed Sep 2 08:28:31 2015 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87FFC1AD0C8; Wed, 2 Sep 2015 08:28:23 -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 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 J-Vdak0epAmk; Wed, 2 Sep 2015 08:28:17 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD1711B2BAC; Wed, 2 Sep 2015 08:28:16 -0700 (PDT) X-AuditID: c1b4fb2d-f79626d000004282-6d-55e7158e9901 Received: from ESESSHC008.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 6C.7A.17026.E8517E55; Wed, 2 Sep 2015 17:28:15 +0200 (CEST) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.44) with Microsoft SMTP Server id 14.3.248.2; Wed, 2 Sep 2015 17:28:14 +0200 To: David Mandelberg , "avtext@ietf.org" , , , IESG References: <063cc84fb1eb8fbef30eda11ea7d8199@mail.mandelberg.org> From: Magnus Westerlund Message-ID: <55E7158D.5060304@ericsson.com> Date: Wed, 2 Sep 2015 17:28:13 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <063cc84fb1eb8fbef30eda11ea7d8199@mail.mandelberg.org> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrHLMWRmVeSWpSXmKPExsUyM+JvjW6/6PNQgyflFh/v3WC1uLHnDrvF io+72C1m/JnIbPFh4UMWB1aPJUt+Mnl8nPiSxePL5c9sAcxRXDYpqTmZZalF+nYJXBm7V75k K7ijUbF+4hH2BsYHCl2MnBwSAiYSy6d8ZYSwxSQu3FvP1sXIxSEkcJRR4sXJJVDOMkaJucve MINUCQs4S9w5/pIFJCEisI1RYmv3QrB2IQEniePHtjGB2GwCFhI3fzSygdi8AtoS25dMBmtm EVCReLbqI1i9qECMRM+vDVA1ghInZz5hAbE5QRZ8vQ42hxlozsz55xkhbHmJ5q2zmSF2aUs0 NHWwTmAUmIWkfRaSlllIWhYwMq9iFC1OLS7OTTcy1kstykwuLs7P08tLLdnECAzgg1t+6+5g XP3a8RCjAAejEg9vwoRnoUKsiWXFlbmHGKU5WJTEeVuYHoQKCaQnlqRmp6YWpBbFF5XmpBYf YmTi4JRqYPTd+0NU+P5NMWkOweW2e26utTu6wedy5Amjb73shSaujhcWiOl3Sex9z81c2n0l 3Kz9466q/ZMqg7LnTf/LPMl8XfM0Qbu7M7Tk7odUPbf12nRae7XT+14XK7mjCdF88Vq61ee7 K6Y/9vCr9ji6NpSP/38UE8t2VZc9C87/N+Kpe3gyjeFIvxJLcUaioRZzUXEiAFyJLhZBAgAA Archived-At: Subject: Re: [avtext] secdir review of draft-ietf-avtext-rtp-stream-pause-08 X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Sep 2015 15:28:23 -0000 Hi, Adding the WG. Back from vacation. Thanks for the good review. See inline for response. Den 2015-08-11 kl. 06:45, skrev David Mandelberg: > Hi, > > 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. > > I think this draft is Ready with issues, though the two issues are > relatively minor: > > 1. The Security Considerations section talks about protecting against > injection of PAUSE requests: > > The way of protecting the RTP session from these injections is to > perform source authentication combined with message integrity, to > prevent other than intended session participants from sending these > messages. > > I think this paragraph should also mention replay protection, which is > needed if the 16-bit PauseID wraps around and the attacker has access to > old PAUSE requests. Yes, we should mention replay attacks. I note that due to that the current PauseID starts at 0 and increments by one, it takes some time until we wrap. And also then you might have to hold onto a lot of messages to be able to attempt a replay. But, clearly we should recommend replay protection at the outer security layer. I propose that we add the following sentence in the second paragraph prior to the last sentence: The security solution should provide replay protection, otherwise an attacker could for sessions that are long lived enough to wrap the PauseID replay old messages at the appropriate time to influence the media sender state. > > 2. The next paragraph in Security Considerations talks about protecting > the multi-party use case against a single malicious participant by > individually authenticating participants. In addition to per-participant > authentication, I think there also needs to be a requirement for > attempted delivery of PAUSE requests to all participants. Without that > requirement, an attacker could cause the session to cycle through the > Playing, Pausing, and Paused states. To do that, the attacker would send > PAUSE requests only to the stream sender, instead of to the whole group. > Since no other participants receive the PAUSE request, they do not know > to send disapproving RESUMEs until after the stream sender has already > paused the stream. (I should note that I'm not particularly familiar > with multicast network operations. If it's infeasible for one > participant to send a message to another participant without the rest of > the group also receiving the message, then I apologize for bringing up a > non-issue.) Yes, you are correct that getting a malicious PAUSE message sent to multiple participants provides a mitigation in that the other participants can counter it. That I would expect to happen in multicast cases where anyone can send RTCP messages. It will fully depend on the multicast topology if an on-path attacker has any chance of getting its messages delivered to the media stream endpoint and not getting forwarded to other endpoints over the multicast tree. In the cases of the RTP middleboxes providing the multi-party functionality it will depend on the mode of operation of that middlebox. But, assuming the middlebox isn't compromised it will act on behalf of the whole session. It either works as multicast emulator and should forward it to everyone, or it will receive the request, and only forward it if fits the rest of the session state. Proposed text for the end of Paragraph three: An attacker that can send a PAUSE request without it reaching any other participant than the media sender can have its request being unopposed. This is mitigated in multi-party topologies that ensure that requests are seen by all or most of the RTP session participants, enabling these participants to send RESUME. In topologies with middleboxes that consume and process PAUSE requests, the middlebox can also mitigate such behavior as it will commonly not generate or forward a PAUSE message if it knows of another participant having use for the media stream. Comments on this? > > ----- > > I also have a few nits: > > Abstract: The RTCP initialism is used without definition. > > Section 5.4: The SR initialism is used without definition. > > Section 6.4: I'd suggest changing "As for Paused State" to "As with > Paused State". That sentence could also be split up for better readability. > Incorporated. Cheers Magnus Westerlund ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From nobody Thu Sep 3 02:05:39 2015 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E67A1B34AC; Thu, 3 Sep 2015 02:05:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 FbiSU_j9xuUD; Thu, 3 Sep 2015 02:05:36 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D9101A8996; Thu, 3 Sep 2015 02:05:36 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.4.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150903090536.31311.41848.idtracker@ietfa.amsl.com> Date: Thu, 03 Sep 2015 02:05:36 -0700 Archived-At: Cc: avtext@ietf.org Subject: [avtext] I-D Action: draft-ietf-avtext-rtp-stream-pause-09.txt X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.15 List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Sep 2015 09:05:38 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Extensions Working Group of the IETF. Title : RTP Stream Pause and Resume Authors : Bo Burman Azam Akram Roni Even Magnus Westerlund Filename : draft-ietf-avtext-rtp-stream-pause-09.txt Pages : 60 Date : 2015-09-03 Abstract: With the increased popularity of real-time multimedia applications, it is desirable to provide good control of resource usage, and users also demand more control over communication sessions. This document describes how a receiver in a multimedia conversation can pause and resume incoming data from a sender by sending real-time feedback messages when using Real-time Transport Protocol (RTP) for real time data transport. This document extends the Codec Control Messages (CCM) RTP Control Protocol (RTCP) feedback package by explicitly allowing and describing specific use of existing CCM messages and adding a group of new real-time feedback messages used to pause and resume RTP data streams. This document updates RFC 5104. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-avtext-rtp-stream-pause/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-avtext-rtp-stream-pause-09 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-avtext-rtp-stream-pause-09 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Sep 3 02:36:31 2015 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD0891B31E2; Thu, 3 Sep 2015 02:36:30 -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 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 MUpEhYPAPEWB; Thu, 3 Sep 2015 02:36:29 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B8121B356D; Thu, 3 Sep 2015 02:36:28 -0700 (PDT) X-AuditID: c1b4fb25-f79a26d00000149a-e9-55e8149abe2d Received: from ESESSHC024.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 9B.EA.05274.A9418E55; Thu, 3 Sep 2015 11:36:26 +0200 (CEST) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.92) with Microsoft SMTP Server id 14.3.248.2; Thu, 3 Sep 2015 11:36:25 +0200 References: <20150903090536.31311.41848.idtracker@ietfa.amsl.com> To: , IESG From: Magnus Westerlund Message-ID: <55E81499.30001@ericsson.com> Date: Thu, 3 Sep 2015 11:36:25 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <20150903090536.31311.41848.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprELMWRmVeSWpSXmKPExsUyM+Jvje4skRehBlOPyVt8vHeD1WLGn4nM DkweS5b8ZApgjOKySUnNySxLLdK3S+DK6Jn6lq1gvVjFm5NbGBsY5wt2MXJySAiYSLTfecYG YYtJXLi3Hsjm4hASOMoocePNLCYIZxmjxJwNL1lBqoQFvCV+rG4Es4UEHCXmvfgKZosIaEt0 X77HDmKzCVhI3PzRCDaVV0BT4tfbuSwgNouAisT8PzPBakQFYiR6fm2AqhGUODnzCVANBwen gJNE6ytmEJNZwF7iwdYykApmAXmJ5q2zmSG2aks0NHWwTmAUmIWkeRZCxywkHQsYmVcxihan FiflphsZ66UWZSYXF+fn6eWllmxiBAbiwS2/VXcwXn7jeIhRgINRiYd3wcrnoUKsiWXFlbmH GKU5WJTEeZuZHoQKCaQnlqRmp6YWpBbFF5XmpBYfYmTi4JRqYCx3q8t/e2Tddm0DdobX/0Wa Txy+6a17ht3HyLWq/VG/kOzE09bnOGXOOGk/7hD5W635f0O2frRG7oyUjcln01zfVP2LMDA/ qtcYfipyx4FP/UzSvxafmDM5dudM96nB6gcfpOjWunZON7xjKqhgrSVyfN6WP23X/3mfiTpT XPg8eOqxrpjN4UosxRmJhlrMRcWJAJD+WGwlAgAA Archived-At: Subject: Re: [avtext] I-D Action: draft-ietf-avtext-rtp-stream-pause-09.txt X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Sep 2015 09:36:30 -0000 Hi, This update should address all the issues raised in IESG review and by the Gen-art and Secdir reviewers. Please check. Cheers Magnus Westerlund Den 2015-09-03 kl. 11:05, skrev internet-drafts@ietf.org: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Audio/Video Transport Extensions Working Group of the IETF. > > Title : RTP Stream Pause and Resume > Authors : Bo Burman > Azam Akram > Roni Even > Magnus Westerlund > Filename : draft-ietf-avtext-rtp-stream-pause-09.txt > Pages : 60 > Date : 2015-09-03 > > Abstract: > With the increased popularity of real-time multimedia applications, > it is desirable to provide good control of resource usage, and users > also demand more control over communication sessions. This document > describes how a receiver in a multimedia conversation can pause and > resume incoming data from a sender by sending real-time feedback > messages when using Real-time Transport Protocol (RTP) for real time > data transport. This document extends the Codec Control Messages > (CCM) RTP Control Protocol (RTCP) feedback package by explicitly > allowing and describing specific use of existing CCM messages and > adding a group of new real-time feedback messages used to pause and > resume RTP data streams. This document updates RFC 5104. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-avtext-rtp-stream-pause/ > > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-avtext-rtp-stream-pause-09 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-avtext-rtp-stream-pause-09 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > avtext mailing list > avtext@ietf.org > https://www.ietf.org/mailman/listinfo/avtext > -- Magnus Westerlund ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From nobody Tue Sep 8 08:15:14 2015 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D8481B4E6D for ; Tue, 8 Sep 2015 08:15:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.402 X-Spam-Level: X-Spam-Status: No, score=0.402 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_WEB=0.77, SPF_PASS=-0.001] autolearn=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 EFd0D8S1MpxJ for ; Tue, 8 Sep 2015 08:15:11 -0700 (PDT) Received: from mx0b-00198e01.pphosted.com (mx0b-00198e01.pphosted.com [67.231.157.197]) (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 EAB101B4E6B for ; Tue, 8 Sep 2015 08:15:10 -0700 (PDT) Received: from pps.filterd (m0073110.ppops.net [127.0.0.1]) by mx0b-00198e01.pphosted.com (8.15.0.59/8.15.0.59) with SMTP id t88FAnZJ021065 for ; Tue, 8 Sep 2015 11:15:10 -0400 Received: from mail.vidyo.com ([162.209.16.214]) by mx0b-00198e01.pphosted.com with ESMTP id 1wk7rrcq6d-2 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Tue, 08 Sep 2015 11:15:09 -0400 Received: from 492132-EXCH1.vidyo.com ([fe80::50:56ff:fe85:4f77]) by 492133-EXCH2.vidyo.com ([fe80::250:56ff:fe85:4a71%11]) with mapi id 14.03.0195.001; Tue, 8 Sep 2015 10:15:09 -0500 From: Jonathan Lennox To: "avtext@ietf.org" Thread-Topic: draft response to SA4 liaison statement Thread-Index: AdDU5hnPZpnbT5wDRCi9ydKVbqRU8A== Date: Tue, 8 Sep 2015 15:15:08 +0000 Message-ID: References: <01f401d0d4e6$52bd03f0$f8370bd0$@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [160.79.219.114] Content-Type: multipart/mixed; boundary="_002_E5DF8D4B04B542768DAE9C9B60CF76F6vidyocom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.14.151, 1.0.33, 0.0.0000 definitions=2015-09-08_07:2015-09-08,2015-09-08,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1508030000 definitions=main-1509080222 Archived-At: Subject: [avtext] Fwd: draft response to SA4 liaison statement X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Sep 2015 15:15:12 -0000 --_002_E5DF8D4B04B542768DAE9C9B60CF76F6vidyocom_ Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 DQpIZWxsbywgQVZURXh0IG1lbWJlcnMg4oCUDQoNCkhlcmUgaXMgUm9uaSBFdmVu4oCZcyBwcm9w b3NlZCByZXNwb25zZSB0byBTQTTigJlzIGxpYWlzb24gc3RhdGVtZW50IGFib3V0IFZpZGVvIFJl Z2lvbi1vZi1JbnRlcmVzdC4gIFBsZWFzZSByZXZpZXcgYW5kIGNvbW1lbnQuDQoNCg0K --_002_E5DF8D4B04B542768DAE9C9B60CF76F6vidyocom_ Content-Type: application/msword; name="AVText response.doc" Content-Description: AVText response.doc Content-Disposition: attachment; filename="AVText response.doc"; size=40448; creation-date="Tue, 08 Sep 2015 15:15:08 GMT"; modification-date="Tue, 08 Sep 2015 15:15:08 GMT" Content-ID: <0514C695CF57E949B01A17BD314D75B9@vidyo.com> Content-Transfer-Encoding: base64 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAABAAAASgAAAAAAAAAA EAAATAAAAAEAAAD+////AAAAAEkAAAD///////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////s pcEAX8AJBAAA8BK/AAAAAAAAMAAAAAAACAAA9wsAAA4AYmpiagAVABUAAAAAAAAAAAAAAAAAAAAA AAAJBBYANBoAAGJ/AABifwAA3QMAAAAAAAAZAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD//w8AAAAA AAAAAAD//w8AAAAAAAAAAAD//w8AAAAAAAAAAAAAAAAAAAAAALcAAAAAABoRAAAAAAAAGhEAAHQe AAAAAAAAdB4AAAAAAAB0HgAAAAAAAHQeAAAAAAAAdB4AABQAAAAAAAAAAAAAAP////8AAAAAiB4A AAAAAACIHgAAAAAAAIgeAAA4AAAAwB4AACQAAADkHgAAHAAAAIgeAAAAAAAAI04AAIICAAAAHwAA AAAAAAAfAAAAAAAAAB8AAAAAAAAAHwAAAAAAAAAfAAAAAAAANCAAAAAAAAA0IAAAAAAAADQgAAAA AAAAok0AAAIAAACkTQAAAAAAAKRNAAAAAAAApE0AAAAAAACkTQAAAAAAAKRNAAAAAAAApE0AACQA AAClUAAAsgIAAFdTAAB4AAAAyE0AABUAAAAAAAAAAAAAAAAAAAAAAAAAdB4AAAAAAAA0IAAAAAAA AAAAAAAAAAAAAAAAAAAAAAA0IAAAAAAAADQgAAAAAAAANCAAAAAAAAA0IAAAAAAAAMhNAAAAAAAA AAAAAAAAAAB0HgAAAAAAAHQeAAAAAAAAAB8AAAAAAAAAAAAAAAAAAAAfAAA0AQAA3U0AABYAAACK IQAAAAAAAIohAAAAAAAAiiEAAAAAAAA0IAAAsgAAAHQeAAAAAAAAAB8AAAAAAAB0HgAAAAAAAAAf AAAAAAAAok0AAAAAAAAAAAAAAAAAAIohAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAANCAAAAAAAACiTQAAAAAAAAAAAAAAAAAAiiEAAAAAAACKIQAA wgEAABBEAACMAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAUEcAAAAAAAAAHwAAAAAAAP////8AAAAA8P8y+uXU 0AEAAAAAAAAAAP////8AAAAA5iAAAEYAAACcRQAAJgAAAAAAAAAAAAAAjk0AABQAAADzTQAAMAAA ACNOAAAAAAAAwkUAAI4BAADPUwAAAAAAACwhAABeAAAAz1MAAEwAAABQRwAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABQ RwAAtgAAAM9TAAAAAAAAAAAAAAAAAAB0HgAAAAAAAAZIAACIBQAANCAAAAAAAAA0IAAAAAAAAIoh AAAAAAAANCAAAAAAAAA0IAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAANCAA AAAAAAA0IAAAAAAAADQgAAAAAAAAyE0AAAAAAADITQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAiiEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADQgAAAA AAAANCAAAAAAAAA0IAAAAAAAACNOAAAAAAAANCAAAAAAAAA0IAAAAAAAADQgAAAAAAAANCAAAAAA AAAAAAAAAAAAAP////8AAAAA/////wAAAAD/////AAAAAAAAAAAAAAAA/////wAAAAD/////AAAA AP////8AAAAA/////wAAAAD/////AAAAAP////8AAAAA/////wAAAAD/////AAAAAP////8AAAAA /////wAAAAD/////AAAAAP////8AAAAA/////wAAAAD/////AAAAAM9TAAAAAAAANCAAAAAAAAA0 IAAAAAAAADQgAAAAAAAANCAAAAAAAAA0IAAAAAAAADQgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA0IAAAAAAAADQgAAAAAAAANCAA AAAAAAAaEQAAIAwAADodAAA6AQAABQASAQAACQQAAA0EAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAElFVEYg QVZUZXh0IFdHCQkJDQ1UaXRsZToJQVZUZXh0IFdHIHJlc3BvbnNlIHRvIExTIHRvIElFVEYgQVZU ZXh0IFdHIG9uIExTIHRvIElFVEYgb24gVmlkZW8gUmVnaW9uLW9mLUludGVyZXN0IChST0kpDQ1T b3VyY2U6CUFWVGV4dCBXRw1UbzoJM0dQUCBUU0cgU0EgV0c0IA0NQ29udGFjdCBQZXJzb246CQ1O YW1lOgkNRS1tYWlsIGFkZHJlc3M6CQ0NQXR0YWNobWVudHM6CQ0NDTEuIE92ZXJhbGwNUmVnYXJk aW5nIHRoZSBuZXcgSUVURiBkcmFmdCBpbiBkcmFmdC1odWFuZy1hdnRleHQtZmVlZGJhY2staW1h Z2UtY29udHJvbC0wMCwgM0dQUCBTQTQgd291bGQgbGlrZSB0byBpbmZvcm0gSUVURiB0aGF0IDNH UFAgaGFzIGFscmVhZHkgc3BlY2lmaWVkIGEgcmVsYXRlZCBzb2x1dGlvbiBpbiAzR1BQIFRTIDI2 LjExNCBhcyBwYXJ0IG9mIHRoZSBSZWxlYXNlIDEzIHdvcmsgaXRlbSBvbiCTVmlkZW8gRW5oYW5j ZW1lbnRzIGJ5IFJlZ2lvbi1vZi1JbnRlcmVzdCAoUk9JKSBJbmZvcm1hdGlvbiBTaWduYWxpbmeU LiANDTNHUFAgU0E0IGtpbmRseSByZXF1ZXN0cyBJRVRGIHRvIHRha2UgdGhlIGluZm9ybWF0aW9u IGFib3ZlIGludG8gYWNjb3VudCwgYW5kIG1haW50YWluIGNvb3JkaW5hdGlvbiB3aXRoIFNBNCBk dXJpbmcgdGhlIGNvdXJzZSBvZiB0aGUgZGV2ZWxvcG1lbnQgb2YgZHJhZnQtaHVhbmctYXZ0ZXh0 LWZlZWRiYWNrLWltYWdlLWNvbnRyb2wtMDAgdG93YXJkIGVuc3VyaW5nIHRoZSBhbGlnbm1lbnQg YmV0d2VlbiAzR1BQIGFuZCBJRVRGIHNwZWNpZmljYXRpb25zLg0NDQ0NMi4gQVZUZXh0IFJlc3Bv bnNlOg1BVlRleHQgV0cgbm90ZWQgdGhlIGxpYWlzb24gc3RhdGVtZW50IGFuZCBwcmVzZW50ZWQg aXQgYXQgSUVURjkyIG1lZXRpbmcuDVRoZSBBVlRleHQgV0cgd2lsbCBiZSBoYXBweSB0byBjby1v cGVyYXRlIHdpdGggM0dQUCBTQTQgdG8gYWxpZ24gdGhlIHdvcmsgb24gdGhlIHZpZGVvIHJlZ2lv biBvZiBpbnRlcmVzdC4NAw0NBA0NAw0NBA0NDQ0NDQ0NDQ0NDQ0NDQ0AAAAAAAAAAAAACAAABQgA AAsIAAAOCAAAEQgAABIIAAATCAAAGQgAABoIAAAgCAAAIQgAADAIAAA7CAAAQQgAAEIIAABICAAA dAgAAHUIAAB2CAAAfQgAAPHi8dC5qJqLfOJtX3ziX1FGmjQAAAAAACMVaM1wgAAWaDRE7wA1CIFP SgIAUUoCAF5KAgBtSAwEc0gMBBUWaNAmyQBPSgIAUUoCAFwIgV5KAgAaFmjQJskAT0oCAFFKAgBe SgIAbkgECHRIBAgAGxVo8ABnABZo6lBQAE9KAgBRSgIAXAiBXkoCAB0WaLxFlABPSgIAUUoCAFwI gV5KAgBuSAQIdEgECBwVaNAmyQAWaNAmyQBDShYAT0oCAFFKAgBeSgIAAB0WaIQe5QA1CIFPSgIA UUoCAF5KAgBuSAQIdEgECBsVaPwJjwAWaDRE7wA1CIFPSgIAUUoCAF5KAgAgFWh+AIQAFmg0RO8A T0oCAFFKAgBeSgIAbUgMDHNIDAwALRVol1R5ABZo1GH8ADUIgUNKFgBPSgIAUUoCAFwIgV5KAgBu SAQIbygBdEgECCIVaPwJjwAWaNRh/AA1CIFDShYAT0oCAFFKAgBcCIFeSgIAABwWaNAmyQA1CIFD ShYAT0oCAFFKAgBcCIFeSgIAABwWaLxFlAA1CIFDShYAT0oCAFFKAgBcCIFeSgIAEwAIAAASCAAA EwgAAHUIAAB2CAAAiAgAAJ0IAACeCAAArwgAALYIAADHCAAAyAgAANYIAADXCAAA2AgAAOMIAAD0 AAAAAAAAAAAAAAAA8gAAAAAAAAAAAAAAAOMAAAAAAAAAAAAAAADMAAAAAAAAAAAAAAAA4wAAAAAA AAAAAAAAAOMAAAAAAAAAAAAAAADAAAAAAAAAAAAAAAAAugAAAAAAAAAAAAAAAK0AAAAAAAAAAAAA AACgAAAAAAAAAAAAAAAAwAAAAAAAAAAAAAAAAJcAAAAAAAAAAAAAAACNAAAAAAAAAAAAAAAA8gAA AAAAAAAAAAAAAIgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQBAGdkygJjAAoAACZkBAEAAVDG CAAAAP8EAQEAAAgAAA3GBQABwQcAZ2S8RZQAAAwHAA3GBQAB3AgAD4Q3Al6ENwJnZNAmyQAADAQA DcYFAAHUCAAPhDcCXoQ3Amdk0CbJAAAFAAANxgUAAdwIAAALAAAPhMEHEYQ/+BSkPABehMEHYIQ/ +BcAAA3GDgAEtwdwCEALEA4AAAAAD4TBBxGEP/gUpDwAXoTBB2CEP/hnZNAmyQAADgAAD4TBBxGE P/gUpDwAXoTBB2CEP/hnZNAmyQAAAQAACw8ADcYKAXIgArAbNSYCAmdk0CbJAAAPfQgAAH4IAACE CAAAhwgAAIgIAACLCAAAjAgAAJsIAACcCAAAnQgAAJ4IAACtCAAArwgAALQIAAC1CAAAtggAAL0I AAC+CAAAxQgAAMYIAADt3s/twbOomo+zwbOGemlYR1gzAAAAJxVofgCEABZoNETvADUIgUIqAFwI gV5KAgBtSAwMcGgAAAD/c0gMDCEVaH4AhAAWaPwJjwBCKgBeSgIAbUgMDHBoAAAA/3NIDAwhFWh+ AIQAFmg0RO8AQioAXkoCAG1IDAxwaAAAAP9zSAwMIRVo/AmPABZoNETvADUIgVwIgV5KAgBuSAQI bygBdEgECBYVaPwJjwAWaDRE7wA1CIFcCIFeSgIAABAVaPwJjwAWaDRE7wBeSgIAABUWaNAmyQA1 CIFPSgIAUUoCAF5KAgAbFWj8CY8AFmjQJskANQiBT0oCAFFKAgBeSgIAFRZo0CbJAE9KAgBRSgIA XAiBXkoCABsVaPwJjwAWaDRE7wBPSgIAUUoCAFwIgV5KAgAbFWj8CY8AFmg0RO8ANQiBT0oCAFFK AgBeSgIAHRZovEWUAE9KAgBRSgIAXAiBXkoCAG1IDARzSAwEHRZo0CbJAE9KAgBRSgIAXAiBXkoC AG1IDARzSAwEIxVozXCAABZoNETvAE9KAgBRSgIAXAiBXkoCAG1IDARzSAwEABPGCAAAxwgAAMgI AADVCAAA1ggAANcIAADYCAAA4ggAAOMIAAADCQAALwkAAJ8KAADLCgAAEAsAABELAAASCwAAEwsA AObUxrapnJWRh3+HcYdgSjwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAbFWi8 RZQAFmi8RZQAT0oCAFFKAgBcCIFeSgIAKxVoNCY+ABZovEWUAE9KAgBRSgIAXkoCAG1ICQRuSAQI bygBc0gJBHRIBAggFWg0Jj4AFmg0Jj4AT0oCAFFKAgBeSgIAbUgJCHNICQgAGxZoNCY+AEIqAU9K AwBRSgMAXkoDAHBoAAAAAA8WaDQmPgBCKgFwaAAAAAASFmg0Jj4AT0oCAFFKAgBeSgIAAAYWaPha kgAADBVo/AmPABZoNETvAAAYFWj8CY8AFmg0RO8AT0oCAFFKAgBeSgIAABgVaLoL4QAWaDRE7wBP SgIAUUoCAF5KAgAAHhVofR5LABZoogbQAE9KAgBRSgIAXAiBXkoCAG8oAQAbFWgQaowAFmhlWDsA NQiBT0oCAFFKAgBeSgIAIxVofgCEABZoNETvADUIgU9KAgBRSgIAXkoCAG1IDAxzSAwMMhVofgCE ABZoNETvADUIgUIqAFwIgV5KAgBtSAwMbkgECG8oAXBoAAAA/3NIDAx0SAQIEOMIAAAJCgAACgoA ABALAAARCwAAEgsAABMLAAAUCwAAKAsAAHILAADdCwAA3wsAAOALAADiCwAA4wsAAOULAADmCwAA 6AsAAOkLAADqCwAA6wsAAOwLAADtCwAA+gAAAAAAAAAAAAAAAPUAAAAAAAAAAAAAAAD1AAAAAAAA AAAAAAAA+gAAAAAAAAAAAAAAAOgAAAAAAAAAAAAAAADhAAAAAAAAAAAAAAAA2wAAAAAAAAAAAAAA ANYAAAAAAAAAAAAAAADNAAAAAAAAAAAAAAAAxAAAAAAAAAAAAAAAAMIAAAAAAAAAAAAAAADCAAAA AAAAAAAAAAAAwgAAAAAAAAAAAAAAAMIAAAAAAAAAAAAAAADCAAAAAAAAAAAAAAAAwgAAAAAAAAAA AAAAAMIAAAAAAAAAAAAAAADCAAAAAAAAAAAAAAAAwAAAAAAAAAAAAAAAAMIAAAAAAAAAAAAAAADA AAAAAAAAAAAAAAAAwgAAAAAAAAAAAAAAAAAAAAAAAAABDwAAAQAACQ8ADcYGAjkQciAAZ2Q0Jj4A CQ8ADcYGAjkQciAAZ2QeB+wAAAQBAGdkNCY+AAYPAA3GBgI5EHIgAAAGAAAUpHgAZ2QKQRkADQ8A DcYGAjkQciAAD4TQAl6E0AJnZLxFlAAABAAAZ2Q0Jj4AAAQoAGdkNCY+AAAWEwsAABQLAAAXCwAA JgsAACgLAABxCwAAcgsAANwLAADdCwAA3gsAAN8LAADgCwAA4QsAAOILAADjCwAA5AsAAOULAADm CwAA5wsAAOgLAADpCwAA6gsAAOsLAADsCwAA7QsAAO4LAADvCwAA8AsAAPELAADyCwAA8wsAAPQL AAD1CwAA9gsAAPcLAADt5uLm1srWu7OinrOinrOinrOinpqWmpaalpqWmpaalp67AAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAABhZoSBrkAAAGFmhFPREAAAYWaGV33QAAIRVoFxbcABZoZXfdAEIqD0NKDgBPSgIAUUoCAHBo gICAAA8DagAAAAAWaGV33QBVCAEcFWgjX34AFmg0Jj4AQ0oYAGFKGABuSAQIdEgECAAWFmgeB+wA Q0oYAGFKGABuSAQIdEgECAAWFmg0Jj4AQ0oYAGFKGABuSAQIdEgECAAGFmg0Jj4AAAwVaPwJjwAW aDRE7wAAIxVo/AmPABZojyNJAE9KAgBRSgIAXkoCAG5IBAhvKAF0SAQIACLtCwAA7gsAAO8LAADw CwAA8QsAAPILAADzCwAA9AsAAPULAAD2CwAA9wsAAP0AAAAAAAAAAAAAAAD7AAAAAAAAAAAAAAAA /QAAAAAAAAAAAAAAAPsAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+wAAAAAAAAAAAAAAAP0AAAAA AAAAAAAAAAD7AAAAAAAAAAAAAAAA+wAAAAAAAAAAAAAAAPAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAJDwANxgYCORByIABnZDQmPgAAAQ8AAAEAAAABEAAACjIACjABFDASJlAJAB+w gy4gsMhBIbD9AyKw/QMjkP0DJJD9AyWwAAAXsNACGLBCAgyQ0AIAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAYgQrABIAAQALAQ8ABwAA AAQAAAAAAAQACAAAAJgAAACYAAAAmAAAAJgAAACYAAAAmAAAAJgAAACYAAAAmAAAADYGAAA2BgAA NgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAAHYCAAB2AgAAdgIAAHYCAAB2AgAAdgIAAHYCAAB2 AgAAdgIAADYGAAA2BgAANgYAAAYAAAA2BgAANgYAAD4CAAA2BgAANgYAADYGAAA2BgAABgAAADYG AAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYA ADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAACoAAAANgYAADYGAAAWAAAANgYAADYGAAA2BgAA NgYAADYGAAA2BgAANgYAADYGAAC4AAAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2 BgAANgYAADYGAAA2BgAAaAEAAEgBAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYG AAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYA ADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAA NgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2 BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAALAD AAA2BgAAMgYAABgAAADAAwAA0AMAAOADAADwAwAAAAQAABAEAAAgBAAAMAQAAEAEAABQBAAAYAQA AHAEAACABAAAkAQAAMADAADQAwAA4AMAAPADAAAABAAAEAQAADIGAAAoAgAA2AEAAOgBAAAgBAAA MAQAAEAEAABQBAAAYAQAAHAEAACABAAAkAQAAMADAADQAwAA4AMAAPADAAAABAAAEAQAACAEAAAw BAAAQAQAAFAEAABgBAAAcAQAAIAEAACQBAAAwAMAANADAADgAwAA8AMAAAAEAAAQBAAAIAQAADAE AABABAAAUAQAAGAEAABwBAAAgAQAAJAEAADAAwAA0AMAAOADAADwAwAAAAQAABAEAAAgBAAAMAQA AEAEAABQBAAAYAQAAHAEAACABAAAkAQAAMADAADQAwAA4AMAAPADAAAABAAAEAQAACAEAAAwBAAA QAQAAFAEAABgBAAAcAQAAIAEAACQBAAAwAMAANADAADgAwAA8AMAAAAEAAAQBAAAIAQAADAEAABA BAAAUAQAAGAEAABwBAAAgAQAAJAEAAA4AQAAWAEAAPgBAAAIAgAAGAIAAFYCAAB+AgAAGAAAAFBK BABfSA0EbUgJBG5ICQRzSAkEdEgJBAAAAAA4AABg8f8CADgADBAAAAAAAAAAAAYATgBvAHIAbQBh AGwAAAACAAAAEABfSAEEbUgJCHNICQh0SAkEbAABQAEAAgBsAAwQAAAAAAAAAAAPAEgAZQBhAGQA aQBuAGcAIAAxACwASAAxACwAaAAxAAAAJAABAAYkAQ6EHAEPhMEHEYQ/+BSk8ABAJgBdhBwBXoTB B2CEP/gPADUIgUNKGABPSgIAUUoCAABYAAJAAQACAFgADBAAAAAAAAAAAA8ASABlAGEAZABpAG4A ZwAgADIALABIADIALABoADIAAAAQAAIABiQBDoQcAUAmAV2EHAEPADUIgUNKGABPSgIAUUoCAABE AANAAQACAEQADBAAAAAAAAAAAA8ASABlAGEAZABpAG4AZwAgADMALABIADMALABoADMAAAAIAAMA BiQBQCYCBABDShgAVgAEQAEAAgBWAAwQAAAAAAAAAAAMAEgAZQBhAGQAaQBuAGcAIAA0ACwAaAA0 AAAAGAAEAAYkAQ3GBQABhgoAD4TEAkAmA16ExAILADUIgU9KAgBRSgIAAFYABUABAAIAVgAMEAAA AAAAAAAADABIAGUAYQBkAGkAbgBnACAANQAsAGgANQAAAA4ABQADJAEGJAFAJgRhJAEWADUIgUNK GABPSgIAUUoCAHRICQR1CABUAAZAAQACAFQADBAAAAAAAAAAAAwASABlAGEAZABpAG4AZwAgADYA LABoADYAAAAIAAYABiQBQCYFGQA1CIFCKhBDShgAT0oCAFFKAgB0SAkEdQgAAFIAB0ABAAIAUgAM EAAAAAAAAAAACQBIAGUAYQBkAGkAbgBnACAANwAAABgABwAGJAENxgUAAYYKAA+ExAJAJgZehMQC DgA1CIFCKgJPSgIAUUoCAFgACEABAAIAWAAMEAAAAAAAAAAACQBIAGUAYQBkAGkAbgBnACAAOAAA ABwACAAGJAEPhMEHEYQ/+BSkeABAJgdehMEHYIQ/+A8ANQiBQ0oWAE9KAgBRSgIAAFgACUABAAIA WAAMEAAAAAAAAAAACQBIAGUAYQBkAGkAbgBnACAAOQAAABwACQAGJAEPhMEHEYQ/+BSkeABAJghe hMEHYIQ/+A8ANQiBQ0oYAE9KAgBRSgIAAEQAQSDy/6EARAAMAQAAAAAAAAAAFgBEAGUAZgBhAHUA bAB0ACAAUABhAHIAYQBnAHIAYQBwAGgAIABGAG8AbgB0AAAAAABWAGkA8/+zAFYADA0AAAAAAAAw BgwAVABhAGIAbABlACAATgBvAHIAbQBhAGwAAAAgADpWCwAX9gMAADTWBgABBQMAADTWBgABCgNs AGH2AwAAAgALAAAAKABrIPT/wQAoAAANAAAAAAAAMAYHAE4AbwAgAEwAaQBzAHQAAAACAAwAAAAA ADQAH0ABAPIANAAMAQAAAAAAAAAABgBIAGUAYQBkAGUAcgAAAA0ADwANxggAAjkQciABAgAAADQA IEABAAIBNAAMAQAAAAAAAAAABgBGAG8AbwB0AGUAcgAAAA0AEAANxggAAjkQciABAgAAAFgAHkAB ABIBWAAMASAAAAAAAAAADABDAG8AbQBtAGUAbgB0ACAAVABlAHgAdAAAAB0AEQADJAMNxg4ABIoF RhJCF7AbAAAAABSk8ABhJAMACABPSgIAUUoCAC4AKQCiACEBLgAMAQAAAAAAAAAACwBQAGEAZwBl ACAATgB1AG0AYgBlAHIAAAAAAEYA/k8BADIBRgAMAAAAAAAAAAAAAgBCADEAAAAYABMAAyQDD4Q3 AhGEyf1ehDcCYITJ/WEkAw8AT0oCAFFKAgB0SAkEdQgAAFIA/k8BAEIBUgAMAAAAAAAAAAAACwAw ADAAIABCAG8AZAB5AFQAZQB4AHQAAAAGABQAFKTcABsAQ0oWAE9KAgBRSgIAbUgJBHNICQR0SAkE dQgAADQA/m/x/1IBNAAMAAAAAAAAAAAAAgA/AD8AAAAFABUAMSQAABAAX0gBBG1ICQRzSAkEdEgJ BDoA/k9RAVIBOgAMAAAAAAAAAAAABQA/AD8APwAgADIAAAAFABYABiQBAA8ANQiBQ0oYAE9KAgBR SgIAAD4AJ2Dy/3EBPgAMAAAAAAAAAAAAEQBDAG8AbQBtAGUAbgB0ACAAUgBlAGYAZQByAGUAbgBj AGUAAAAEAENKEABcAP5PAQCCAVwADAAAAAAAAAAAAAgARABFAEMASQBTAEkATwBOAAAAGgAYAAMk AwomAAtGAQATpHgAFKR4ADEkAGEkAxgANQiBPioBQioCT0oCAFFKAgB0SAkEdQgAugD+TwEAkgG6 AAwAAAAAAAAAAAAGAEEAQwBUAEkATwBOAAAAfgAZAAMkAwUkAQYkAQomAAtGAwANxgcBaAEBMwfA D4QzBxGEIPwTpDwAFKQ8ACRkBgEGASVkBgEGBCZkBgEGASdkBgEGBDEkAE7GCP8AAAAGAQEAT8YI /wAAAAYBBABQxgj/AAAABgEBAFHGCP8AAAAGAQQAXoQzB2CEIPxhJAMVADUIgUIqBk9KAgBRSgIA dEgJBHUIAACMAP5PkQGiAYwADAAAAAAAAAAAAAQAZABvAG4AZQAAAGUAGgAKJgALRgIADcYFAAFo AQYPhFQBEYSs/iRkBgELASVkBgELBCZkBgELASdkBgELBE7GCACAAAAGAQEAT8YIAIAAAAYBBABQ xggAgAAABgEBAFHGCACAAAAGAQQAXoRUAWCErP4AAwBCKgsAOAD+T6EBsgE4AAwAAAAAAAAAAAAI AE4AbwB0ACAARABvAG4AZQAAAAkAGwAKJgALRgQAAAMAQioGAEQAQkABAMIBRAAMAQAAAAAAAAAA CQBCAG8AZAB5ACAAVABlAHgAdAAAAAIAHAAVAEIqBk9KAgBRSgIAXkoCAHBo/wAAAABMAJlAAQDS AUwADA0eAJ9TcwAwBgwAQgBhAGwAbABvAG8AbgAgAFQAZQB4AHQAAAACAB0AGABDShAAT0oFAFFK BQBhShAAbUgAAHNIAABSAP5v8v/hAVIADAEdAJ9TcwAwBhEAQgBhAGwAbABvAG8AbgAgAFQAZQB4 AHQAIABDAGgAYQByAAAAGABDShAAT0oFAFFKBQBeSgUAYUoQAHRICQRgAGpAEQESAWAADA0AALZr 2AAwBg8AQwBvAG0AbQBlAG4AdAAgAFMAdQBiAGoAZQBjAHQAAAAZAB8AAyQADcYKBIoFRhJCF7Ab ABSkAABhJAAADgA1CIFPSgAAUUoAAFwIgU4A/m/y/wECTgAMAREAtmvYAAAAEQBDAG8AbQBtAGUA bgB0ACAAVABlAHgAdAAgAEMAaABhAHIAAAAUAE9KAgBRSgIAbUgJCHNICQh0SAkEKgD+DwICEQIq AAwAHwC2a9gAAAAJAHli6Gw7TpiYIABDAGgAYQByAAAAAAAsAP4PMQIiAiwADAAkABQQ4AAAAAIA VABGAAAADQAiAAYkABOkAAAUpPAAAAAAWAD+TwEAMgJYAAwAJQAUEOAAAAACAFQASAAAACYAIwAD JAEFJAEGJAETpDwAFKS0ADUkADckADgkADlEAgBIJABhJAETADUIgUNKGABPSgIAUUoCAHRIAAAA QgD+b/L/QQJCAAwAIgAUEOAAAAAHAFQARgAgAEMAaABhAHIAAAAbADUIAUNKGABPSgIAUUoCAG1I CQhzSAkIdEgAAABCAP5v8v9RAkIADAIjABQQ4AAAAAcAVABIACAAQwBoAGEAcgAAABsANQgBQ0oY AE9KAgBRSgIAbUgJCHNICQh0SAAAADQA/m/y/2ECNAAMAAAAIyV3AAAACwBmAG8AbgB0AC0AcwB0 AHkAbABlADEAAAAGAHBoAAAAADYAVWDy/3ECNgAMDAAAvEWUADAGCQBIAHkAcABlAHIAbABpAG4A awAAAAwAPioBQioAcGgAAP8AkABlQAEAggKQAAwJKQBBZKkAMAYRAEgAVABNAEwAIABQAHIAZQBm AG8AcgBtAGEAdAB0AGUAZAAAADcAKAANxjIAEJQDKAe8ClAO5BF4FQwZoBw0IMgjXCfwKoQuGDKs NUA5AAAAAAAAAAAAAAAAAAAAAAAcAE9KAwBQSgAAUUoDAF5KAwBfSA0EbUgJBHNICQRUAP5v8v+R AlQADAEoAEFkqQAwBhYASABUAE0ATAAgAFAAcgBlAGYAbwByAG0AYQB0AHQAZQBkACAAQwBoAGEA cgAAABAAT0oDAFBKAABRSgMAXkoDAEAAswABAKICQAAMFAAAVgUgACACDgBMAGkAcwB0ACAAUABh AHIAYQBnAHIAYQBwAGgAAAAKACoAD4TQAl6E0AIAAFBLAwQUAAYACAAAACEA6d4Pv/8AAAAcAgAA EwAAAFtDb250ZW50X1R5cGVzXS54bWyskctOwzAQRfdI/IPlLUqcskAIJemCx47HonzAyJkkFsnY sqdV+/dM0lRCqCAWbCzZM/eeO+NyvR8HtcOYnKdKr/JCKyTrG0ddpd83T9mtVomBGhg8YaUPmPS6 vrwoN4eASYmaUqV75nBnTLI9jpByH5Ck0vo4Ass1diaA/YAOzXVR3BjriZE448lD1+UDtrAdWD3u 5fmYJOKQtLo/Nk6sSkMIg7PAktTsqPlGyRZCLsq5J/UupCuJoc1ZwlT5GbDoXmU10TWo3iDyC4wS w7AMiV/PZyAZLea/O56J7NvWWWy83Y6yjnw2XsxOwf8UYPU/6BPTzH9bfwIAAP//AwBQSwMEFAAG AAgAAAAhAKXWp+fAAAAANgEAAAsAAABfcmVscy8ucmVsc4SPz2rDMAyH74W9g9F9UdLDGCV2L6WQ Qy+jfQDhKH9oIhvbG+vbT8cGCrsIhKTv96k9/q6L+eGU5yAWmqoGw+JDP8to4XY9v3+CyYWkpyUI W3hwhqN727VfvFDRozzNMRulSLYwlRIPiNlPvFKuQmTRyRDSSkXbNGIkf6eRcV/XH5ieGeA2TNP1 FlLXN2Cuj6jJ/7PDMMyeT8F/ryzlRQRuN5RMaeRioagv41O9kKhlqtQe0LW4+db9AQAA//8DAFBL AwQUAAYACAAAACEAa3mWFoMAAACKAAAAHAAAAHRoZW1lL3RoZW1lL3RoZW1lTWFuYWdlci54bWwM zE0KwyAQQOF9oXeQ2TdjuyhFYrLLrrv2AEOcGkHHoNKf29fl44M3zt8U1ZtLDVksnAcNimXNLoi3 8Hwspxuo2kgcxSxs4ccV5ul4GMm0jRPfSchzUX0j1ZCFrbXdINa1K9Uh7yzdXrkkaj2LR1fo0/cp 4kXrKyYKAjj9AQAA//8DAFBLAwQUAAYACAAAACEAMN1DKagGAACkGwAAFgAAAHRoZW1lL3RoZW1l L3RoZW1lMS54bWzsWU9v2zYUvw/YdyB0b2MndhoHdYrYsZstTRvEboceaYmW2FCiQNJJfRva44AB w7phhxXYbYdhW4EW2KX7NNk6bB3Qr7BHUpLFWF6SNtiKrT4kEvnj+/8eH6mr1+7HDB0SISlP2l79 cs1DJPF5QJOw7d0e9i+teUgqnASY8YS0vSmR3rWN99+7itdVRGKCYH0i13Hbi5RK15eWpA/DWF7m KUlgbsxFjBW8inApEPgI6MZsablWW12KMU08lOAYyN4aj6lP0FCT9DZy4j0Gr4mSesBnYqBJE2eF wQYHdY2QU9llAh1i1vaAT8CPhuS+8hDDUsFE26uZn7e0cXUJr2eLmFqwtrSub37ZumxBcLBseIpw VDCt9xutK1sFfQNgah7X6/W6vXpBzwCw74OmVpYyzUZ/rd7JaZZA9nGedrfWrDVcfIn+ypzMrU6n 02xlsliiBmQfG3P4tdpqY3PZwRuQxTfn8I3OZre76uANyOJX5/D9K63Vhos3oIjR5GAOrR3a72fU C8iYs+1K+BrA12oZfIaCaCiiS7MY80QtirUY3+OiDwANZFjRBKlpSsbYhyju4ngkKNYM8DrBpRk7 5Mu5Ic0LSV/QVLW9D1MMGTGj9+r596+eP0XHD54dP/jp+OHD4wc/WkLOqm2chOVVL7/97M/HH6M/ nn7z8tEX1XhZxv/6wye//Px5NRDSZybOiy+f/PbsyYuvPv39u0cV8E2BR2X4kMZEopvkCO3zGBQz VnElJyNxvhXDCNPyis0klDjBmksF/Z6KHPTNKWaZdxw5OsS14B0B5aMKeH1yzxF4EImJohWcd6LY Ae5yzjpcVFphR/MqmXk4ScJq5mJSxu1jfFjFu4sTx7+9SQp1Mw9LR/FuRBwx9xhOFA5JQhTSc/yA kArt7lLq2HWX+oJLPlboLkUdTCtNMqQjJ5pmi7ZpDH6ZVukM/nZss3sHdTir0nqLHLpIyArMKoQf EuaY8TqeKBxXkRzimJUNfgOrqErIwVT4ZVxPKvB0SBhHvYBIWbXmlgB9S07fwVCxKt2+y6axixSK HlTRvIE5LyO3+EE3wnFahR3QJCpjP5AHEKIY7XFVBd/lbobod/ADTha6+w4ljrtPrwa3aeiINAsQ PTMRFb68TrgTv4MpG2NiSg0UdadWxzT5u8LNKFRuy+HiCjeUyhdfP66Q+20t2Zuwe1XlzPaJQr0I d7I8d7kI6NtfnbfwJNkjkBDzW9S74vyuOHv/+eK8KJ8vviTPqjAUaN2L2EbbtN3xwq57TBkbqCkj N6RpvCXsPUEfBvU6c+IkxSksjeBRZzIwcHChwGYNElx9RFU0iHAKTXvd00RCmZEOJUq5hMOiGa6k rfHQ+Ct71GzqQ4itHBKrXR7Y4RU9nJ81CjJGqtAcaHNGK5rAWZmtXMmIgm6vw6yuhTozt7oRzRRF h1uhsjaxOZSDyQvVYLCwJjQ1CFohsPIqnPk1azjsYEYCbXfro9wtxgsX6SIZ4YBkPtJ6z/uobpyU x8qcIloPGwz64HiK1UrcWprsG3A7i5PK7BoL2OXeexMv5RE88xJQO5mOLCknJ0vQUdtrNZebHvJx 2vbGcE6GxzgFr0vdR2IWwmWTr4QN+1OT2WT5zJutXDE3Cepw9WHtPqewUwdSIdUWlpENDTOVhQBL NCcr/3ITzHpRClRUo7NJsbIGwfCvSQF2dF1LxmPiq7KzSyPadvY1K6V8oogYRMERGrGJ2Mfgfh2q oE9AJVx3mIqgX+BuTlvbTLnFOUu68o2YwdlxzNIIZ+VWp2ieyRZuClIhg3kriQe6VcpulDu/Kibl L0iVchj/z1TR+wncPqwE2gM+XA0LjHSmtD0uVMShCqUR9fsCGgdTOyBa4H4XpiGo4ILa/BfkUP+3 OWdpmLSGQ6TapyESFPYjFQlC9qAsmeg7hVg927ssSZYRMhFVElemVuwROSRsqGvgqt7bPRRBqJtq kpUBgzsZf+57lkGjUDc55XxzKlmx99oc+Kc7H5vMoJRbh01Dk9u/ELFoD2a7ql1vlud7b1kRPTFr sxp5VgCz0lbQytL+NUU451ZrK9acxsvNXDjw4rzGMFg0RCncISH9B/Y/Knxmv3boDXXI96G2Ivh4 oYlB2EBUX7KNB9IF0g6OoHGygzaYNClr2qx10lbLN+sL7nQLvieMrSU7i7/PaeyiOXPZObl4kcbO LOzY2o4tNDV49mSKwtA4P8gYx5jPZOUvWXx0Dxy9Bd8MJkxJE0zwnUpg6KEHJg8g+S1Hs3TjLwAA AP//AwBQSwMEFAAGAAgAAAAhAA3RkJ+2AAAAGwEAACcAAAB0aGVtZS90aGVtZS9fcmVscy90aGVt ZU1hbmFnZXIueG1sLnJlbHOEj00KwjAUhPeCdwhvb9O6EJEm3YjQrdQDhOQ1DTY/JFHs7Q2uLAgu h2G+mWm7l53JE2My3jFoqhoIOumVcZrBbbjsjkBSFk6J2TtksGCCjm837RVnkUsoTSYkUiguMZhy DidKk5zQilT5gK44o49W5CKjpkHIu9BI93V9oPGbAXzFJL1iEHvVABmWUJr/s/04GolnLx8WXf5R QXPZhQUoosbM4CObqkwEylu6usTfAAAA//8DAFBLAQItABQABgAIAAAAIQDp3g+//wAAABwCAAAT AAAAAAAAAAAAAAAAAAAAAABbQ29udGVudF9UeXBlc10ueG1sUEsBAi0AFAAGAAgAAAAhAKXWp+fA AAAANgEAAAsAAAAAAAAAAAAAAAAAMAEAAF9yZWxzLy5yZWxzUEsBAi0AFAAGAAgAAAAhAGt5lhaD AAAAigAAABwAAAAAAAAAAAAAAAAAGQIAAHRoZW1lL3RoZW1lL3RoZW1lTWFuYWdlci54bWxQSwEC LQAUAAYACAAAACEAMN1DKagGAACkGwAAFgAAAAAAAAAAAAAAAADWAgAAdGhlbWUvdGhlbWUvdGhl bWUxLnhtbFBLAQItABQABgAIAAAAIQAN0ZCftgAAABsBAAAnAAAAAAAAAAAAAAAAALIJAAB0aGVt ZS90aGVtZS9fcmVscy90aGVtZU1hbmFnZXIueG1sLnJlbHNQSwUGAAAAAAUABQBdAQAArQoAAAAA PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiIHN0YW5kYWxvbmU9InllcyI/Pg0K PGE6Y2xyTWFwIHhtbG5zOmE9Imh0dHA6Ly9zY2hlbWFzLm9wZW54bWxmb3JtYXRzLm9yZy9kcmF3 aW5nbWwvMjAwNi9tYWluIiBiZzE9Imx0MSIgdHgxPSJkazEiIGJnMj0ibHQyIiB0eDI9ImRrMiIg YWNjZW50MT0iYWNjZW50MSIgYWNjZW50Mj0iYWNjZW50MiIgYWNjZW50Mz0iYWNjZW50MyIgYWNj ZW50ND0iYWNjZW50NCIgYWNjZW50NT0iYWNjZW50NSIgYWNjZW50Nj0iYWNjZW50NiIgaGxpbms9 ImhsaW5rIiBmb2xIbGluaz0iZm9sSGxpbmsiLz4AAAAA9wMAAA0AABoAAAAA/////wAAAAADAAAA BgAAAAYAAAAJAAAADAAAAAwAAAAOAAAAEAAAABIAAAAUAAAAFgAAABgAAAAbAAAAAAgAAH0IAADG CAAAEwsAAPcLAAAGAAAACAAAAAkAAAALAAAAAAgAAOMIAADtCwAA9wsAAAcAAAAKAAAADAAAAA8A APBAAAAAAAAG8CAAAAABCAAAAwAAAAIAAAACAAAAAQAAAAIAAAACAAAAAQAAAEAAHvEQAAAA//8A AAAA/wCAgIAA9wAAEAEPAALwSAAAACAACPAIAAAAAQAAAAAIAAAPAAPwMAAAAA8ABPAoAAAAAQAJ 8BAAAAAAAAAAAAAAAAAAAAAAAAAAAgAK8AgAAAAACAAABQAAAAAPAALwkgAAABAACPAIAAAAAQAA AAEEAAAPAAPwMAAAAA8ABPAoAAAAAQAJ8BAAAAAAAAAAAAAAAAAAAAAAAAAAAgAK8AgAAAAABAAA BQAAAA8ABPBCAAAAEgAK8AgAAAABBAAAAA4AAFMAC/AeAAAAvwEAABAAywEAAAAA/wEAAAgABAMJ AAAAPwMBAAEAAAAR8AQAAAABAAAAAAAAAAUAAAALAAAAGgAAACAAAAA7AAAAQQAAAH4AAACEAAAA vQAAAMQAAAAXAwAAHQMAACgDAAAuAwAAdgMAAHwDAADTAwAA2wMAAN0DAADfAwAA4AMAAOIDAADj AwAA5QMAAOYDAADoAwAA6QMAAPUDAAD4AwAABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcA HAAHAAQABwAHAAIABwACAAcAAgAHAAIABwACAAAAAADdAwAA3wMAAOADAADiAwAA4wMAAOUDAADm AwAA6AMAAOkDAAD1AwAA+AMAAAcABwACAAcAAgAHAAIABwACAAcAAgAAAAAAngAAAK8AAADIAAAA 1QAAAN0DAADfAwAA4AMAAOIDAADjAwAA5QMAAOYDAADoAwAA6QMAAPUDAAD4AwAABwAFAAcABQAH AAcAAgAHAAIABwACAAcAAgAHAAIAEAAd////JPE+rv8P/w//D/8P/w//D/8P/w//DwAAhU93DTAw Psr/D/8P/w//D/8P/w//D/8P/w8QAFN6eBDM7ZIK/w//D/8P/w//D/8P/w//D/8PEAAnGzAROqSa vv8P/w//D/8P/w//D/8P/w//DxAARBMKGxz1RsArAAAAAAAAAAAAAAAAAAAAAAABAKEKyjeKs3Tb /w//D/8P/w//D/8P/w//D/8PEACtUP47oDWQkv8P/w//D/8P/w//D/8P/w//DxAAJizKQfzWzhgZ AAAAAAAAAAAAAAAAAAAAAAABAP1pmlSGXqya/w//D/8P/w//D/8P/w//D/8PAACAATZXfgyeJP8P /w//D/8P/w//D/8P/w//DwAAKUQ9WQLwzFX/D/8P/w//D/8P/w//D/8P/w8QAPwDdFl+DJ4k/w// D/8P/w//D/8P/w//D/8PEAAgF4ZdxO0Iz/8P/w//D/8P/w//D/8P/w//DxAAdCR9XmyPPnv/D/8P /w//D/8P/w//D/8P/w8QAJ4MaWO++ay6GAAAAAAAAAAAAAAAAAAAAAAAAQD0Yn1zhDRuyf8P/w// D/8P/w//D/8P/w//DxAAAQAAABcAAAAAAAAAAAAAAAAAAAAAAAAACxgAAA+EAAARhAAAFcYFAAEA AAZehAAAYIQAAE9KAQBRSgEAbygAAAABAAAAFwAAAAAAAAAAAAAAAAAAAAAAAAALGAAAD4Q4BBGE mP4VxgUAAdACBl6EOARghJj+T0oBAFFKAQBvKAABALfwAQAAABcAAAAAAAAAAAAAAAAAAAAAAAAA DxgAAA+ECAcRhJj+FcYFAAGgBQZehAgHYISY/k9KAwBRSgMAXkoDAG8oAAEAbwABAAAAFwAAAAAA AAAAAAAAAAAAAAAAAAALGAAAD4TYCRGEmP4VxgUAAXAIBl6E2AlghJj+T0oGAFFKBgBvKAABAKfw AQAAABcAAAAAAAAAAAAAAAAAAAAAAAAACxgAAA+EqAwRhJj+FcYFAAFACwZehKgMYISY/k9KBgBR SgYAbygAAQD68AEAAAAXAAAAAAAAAAAAAAAAAAAAAAAAAAsYAAAPhHgPEYSY/hXGBQABEA4GXoR4 D2CEmP5PSgEAUUoBAG8oAAEAt/ABAAAAFwAAAAAAAAAAAAAAAAAAAAAAAAAPGAAAD4RIEhGEmP4V xgUAAeAQBl6ESBJghJj+T0oDAFFKAwBeSgMAbygAAQBvAAEAAAAXAAAAAAAAAAAAAAAAAAAAAAAA AAsYAAAPhBgVEYSY/hXGBQABsBMGXoQYFWCEmP5PSgYAUUoGAG8oAAEAp/ABAAAAFwAAAAAAAAAA AAAAAAAAAAAAAAALGAAAD4ToFxGEmP4VxgUAAYAWBl6E6BdghJj+T0oGAFFKBgBvKAABAPrwAQAA ABcQAAAAAAAAAAAAAGgBAAAAAAAAFRAAAA+E0AIRhJj+XoTQAmCEmP5PSgEAUUoBAG8oAIdoAAAA AIhIAAABALfwAQAAABcQAAAAAAAAAAAAAGgBAAAAAAAAFRAAAA+EoAURhJj+XoSgBWCEmP5PSgMA UUoDAG8oAIdoAAAAAIhIAAABAG8AAQAAABeQAAAAAAAAAAAAAGgBAAAAAAAAFRAAAA+EcAgRhJj+ XoRwCGCEmP5PSgYAUUoGAG8oAIdoAAAAAIhIAAABAKfwAQAAABeQAAAAAAAAAAAAAGgBAAAAAAAA FRAAAA+EQAsRhJj+XoRAC2CEmP5PSgEAUUoBAG8oAIdoAAAAAIhIAAABALfwAQAAABeQAAAAAAAA AAAAAGgBAAAAAAAAFRAAAA+EEA4RhJj+XoQQDmCEmP5PSgMAUUoDAG8oAIdoAAAAAIhIAAABAG8A AQAAABeQAAAAAAAAAAAAAGgBAAAAAAAAFRAAAA+E4BARhJj+XoTgEGCEmP5PSgYAUUoGAG8oAIdo AAAAAIhIAAABAKfwAQAAABeQAAAAAAAAAAAAAGgBAAAAAAAAFRAAAA+EsBMRhJj+XoSwE2CEmP5P SgEAUUoBAG8oAIdoAAAAAIhIAAABALfwAQAAABeQAAAAAAAAAAAAAGgBAAAAAAAAFRAAAA+EgBYR hJj+XoSAFmCEmP5PSgMAUUoDAG8oAIdoAAAAAIhIAAABAG8AAQAAABeQAAAAAAAAAAAAAGgBAAAA AAAAFRAAAA+EUBkRhJj+XoRQGWCEmP5PSgYAUUoGAG8oAIdoAAAAAIhIAAABAKfwAQAAABcQAAAA AAAAAAAAAGgBAAAAAAAAFRAAAA+E0AIRhJj+XoTQAmCEmP5PSgEAUUoBAG8oAIdoAAAAAIhIAAAB ALfwAQAAABeQAAAAAAAAAAAAAGgBAAAAAAAAGRAAAA+EoAURhJj+XoSgBWCEmP5PSgMAUUoDAF5K AwBvKACHaAAAAACISAAAAQBvAAEAAAAXkAAAAAAAAAAAAABoAQAAAAAAABUQAAAPhHAIEYSY/l6E cAhghJj+T0oGAFFKBgBvKACHaAAAAACISAAAAQCn8AEAAAAXkAAAAAAAAAAAAABoAQAAAAAAABUQ AAAPhEALEYSY/l6EQAtghJj+T0oBAFFKAQBvKACHaAAAAACISAAAAQC38AEAAAAXkAAAAAAAAAAA AABoAQAAAAAAABkQAAAPhBAOEYSY/l6EEA5ghJj+T0oDAFFKAwBeSgMAbygAh2gAAAAAiEgAAAEA bwABAAAAF5AAAAAAAAAAAAAAaAEAAAAAAAAVEAAAD4TgEBGEmP5ehOAQYISY/k9KBgBRSgYAbygA h2gAAAAAiEgAAAEAp/ABAAAAF5AAAAAAAAAAAAAAaAEAAAAAAAAVEAAAD4SwExGEmP5ehLATYISY /k9KAQBRSgEAbygAh2gAAAAAiEgAAAEAt/ABAAAAF5AAAAAAAAAAAAAAaAEAAAAAAAAZEAAAD4SA FhGEmP5ehIAWYISY/k9KAwBRSgMAXkoDAG8oAIdoAAAAAIhIAAABAG8AAQAAABeQAAAAAAAAAAAA AGgBAAAAAAAAFRAAAA+EUBkRhJj+XoRQGWCEmP5PSgYAUUoGAG8oAIdoAAAAAIhIAAABAKfwAQAA ABcQAAAAAAAAAAAAAGgBAAAAAAAAFRAAAA+E0AIRhJj+XoTQAmCEmP5PSgEAUUoBAG8oAIdoAAAA AIhIAAABALfwAQAAABcQAAAAAAAAAAAAAGgBAAAAAAAAGRAAAA+EoAURhJj+XoSgBWCEmP5PSgMA UUoDAF5KAwBvKACHaAAAAACISAAAAQBvAAEAAAAXkAAAAAAAAAAAAABoAQAAAAAAABUQAAAPhHAI EYSY/l6EcAhghJj+T0oGAFFKBgBvKACHaAAAAACISAAAAQCn8AEAAAAXkAAAAAAAAAAAAABoAQAA AAAAABUQAAAPhEALEYSY/l6EQAtghJj+T0oBAFFKAQBvKACHaAAAAACISAAAAQC38AEAAAAXkAAA AAAAAAAAAABoAQAAAAAAABkQAAAPhBAOEYSY/l6EEA5ghJj+T0oDAFFKAwBeSgMAbygAh2gAAAAA iEgAAAEAbwABAAAAF5AAAAAAAAAAAAAAaAEAAAAAAAAVEAAAD4TgEBGEmP5ehOAQYISY/k9KBgBR SgYAbygAh2gAAAAAiEgAAAEAp/ABAAAAF5AAAAAAAAAAAAAAaAEAAAAAAAAVEAAAD4SwExGEmP5e hLATYISY/k9KAQBRSgEAbygAh2gAAAAAiEgAAAEAt/ABAAAAF5AAAAAAAAAAAAAAaAEAAAAAAAAZ EAAAD4SAFhGEmP5ehIAWYISY/k9KAwBRSgMAXkoDAG8oAIdoAAAAAIhIAAABAG8AAQAAABeQAAAA AAAAAAAAAGgBAAAAAAAAFRAAAA+EUBkRhJj+XoRQGWCEmP5PSgYAUUoGAG8oAIdoAAAAAIhIAAAB AKfwAQAAABcAAAAAAAAAAAAAAAAAAAAAAAAACxgAAA+EwAYRhOD+FcYFAAEAAAZehMAGYITg/k9K BwBRSgcAbygAAQA48AEAAAAXEAAAAAAAAAAAAABoAQAAAAAAACEQAAAPhNACEYSY/l6E0AJghJj+ QioAT0oBAFFKAQBvKABwaAAAAP+GKgCHaAAAAACISAAAAQC38AEAAAAXkAAAAAAAAAAAAABoAQAA AAAAABUQAAAPhKAFEYSY/l6EoAVghJj+T0oDAFFKAwBvKACHaAAAAACISAAAAQBvAAEAAAAXkAAA AAAAAAAAAABoAQAAAAAAABUQAAAPhHAIEYSY/l6EcAhghJj+T0oGAFFKBgBvKACHaAAAAACISAAA AQCn8AEAAAAXkAAAAAAAAAAAAABoAQAAAAAAABUQAAAPhEALEYSY/l6EQAtghJj+T0oBAFFKAQBv KACHaAAAAACISAAAAQC38AEAAAAXkAAAAAAAAAAAAABoAQAAAAAAABUQAAAPhBAOEYSY/l6EEA5g hJj+T0oDAFFKAwBvKACHaAAAAACISAAAAQBvAAEAAAAXkAAAAAAAAAAAAABoAQAAAAAAABUQAAAP hOAQEYSY/l6E4BBghJj+T0oGAFFKBgBvKACHaAAAAACISAAAAQCn8AEAAAAXkAAAAAAAAAAAAABo AQAAAAAAABUQAAAPhLATEYSY/l6EsBNghJj+T0oBAFFKAQBvKACHaAAAAACISAAAAQC38AEAAAAX kAAAAAAAAAAAAABoAQAAAAAAABUQAAAPhIAWEYSY/l6EgBZghJj+T0oDAFFKAwBvKACHaAAAAACI SAAAAQBvAAEAAAAXkAAAAAAAAAAAAABoAQAAAAAAABUQAAAPhFAZEYSY/l6EUBlghJj+T0oGAFFK BgBvKACHaAAAAACISAAAAQCn8AEAAAAXEAAAAAAAAAAAAABoAQAAAAAAABUQAAAPhNACEYSY/l6E 0AJghJj+T0oBAFFKAQBvKACHaAAAAACISAAAAQC38AEAAAAXkAAAAAAAAAAAAABoAQAAAAAAABUQ AAAPhKAFEYSY/l6EoAVghJj+T0oDAFFKAwBvKACHaAAAAACISAAAAQBvAAEAAAAXkAAAAAAAAAAA AABoAQAAAAAAABUQAAAPhHAIEYSY/l6EcAhghJj+T0oGAFFKBgBvKACHaAAAAACISAAAAQCn8AEA AAAXkAAAAAAAAAAAAABoAQAAAAAAABUQAAAPhEALEYSY/l6EQAtghJj+T0oBAFFKAQBvKACHaAAA AACISAAAAQC38AEAAAAXkAAAAAAAAAAAAABoAQAAAAAAABUQAAAPhBAOEYSY/l6EEA5ghJj+T0oD AFFKAwBvKACHaAAAAACISAAAAQBvAAEAAAAXkAAAAAAAAAAAAABoAQAAAAAAABUQAAAPhOAQEYSY /l6E4BBghJj+T0oGAFFKBgBvKACHaAAAAACISAAAAQCn8AEAAAAXkAAAAAAAAAAAAABoAQAAAAAA ABUQAAAPhLATEYSY/l6EsBNghJj+T0oBAFFKAQBvKACHaAAAAACISAAAAQC38AEAAAAXkAAAAAAA AAAAAABoAQAAAAAAABUQAAAPhIAWEYSY/l6EgBZghJj+T0oDAFFKAwBvKACHaAAAAACISAAAAQBv AAEAAAAXkAAAAAAAAAAAAABoAQAAAAAAABUQAAAPhFAZEYSY/l6EUBlghJj+T0oGAFFKBgBvKACH aAAAAACISAAAAQCn8AEAAAAXAAAAAAAAAAAAAAAAAAAAAAAAAAsYAAAPhGgBEYSY/hXGBQABaAEG XoRoAWCEmP5PSggAUUoIAG8oAAEA6vAFAAAAAAABAAAAAAAAAAAAAAAAAAAAAAADGAAAD4RlBBGE m/sVxgUAAWUEBl6EZQRghJv7bygAAQAAAAEAAAAAAAEDAAAAAAAAAAAAAAAAAAAAAAMYAAAPhNMI EYSb+xXGBQAB0wgGXoTTCGCEm/tvKAADAAAALgABAAEAAAAAAAEDBQAAAAAAAAAAAAAAAAAAAAMY AAAPhEENEYSb+xXGBQABQQ0GXoRBDWCEm/tvKAAFAAAALgABAC4AAgABAAAAAAABAwUHAAAAAAAA AAAAAAAAAAADGAAAD4SvERGEm/sVxgUAAa8RBl6ErxFghJv7bygABwAAAC4AAQAuAAIALgADAAEA AAAAAAEDBQcJAAAAAAAAAAAAAAAAAAMYAAAPhB0WEYSb+xXGBQABHRYGXoQdFmCEm/tvKAAJAAAA LgABAC4AAgAuAAMALgAEAAEAAAAAAAEDBQcJCwAAAAAAAAAAAAAAAAMYAAAPhIsaEYSb+xXGBQAB ixoGXoSLGmCEm/tvKAALAAAALgABAC4AAgAuAAMALgAEAC4ABQABAAAAAAABAwUHCQsNAAAAAAAA AAAAAAADGAAAD4Q0IBGEYPoVxgUAATQgBl6ENCBghGD6bygADQAAAC4AAQAuAAIALgADAC4ABAAu AAUALgAGAAEAAAAAAAEDBQcJCw0PAAAAAAAAAAAAAAMYAAAPhKIkEYRg+hXGBQABoiQGXoSiJGCE YPpvKAAPAAAALgABAC4AAgAuAAMALgAEAC4ABQAuAAYALgAHAAEAAAAAAAEDBQcJCw0PEQAAAAAA AAAAAAMYAAAPhBApEYRg+hXGBQABECkGXoQQKWCEYPpvKAARAAAALgABAC4AAgAuAAMALgAEAC4A BQAuAAYALgAHAC4ACAABAAAAFxAAAAAAAAAAAAAAaAEAAAAAAAAVEAAAD4TQAhGEmP5ehNACYISY /k9KAQBRSgEAbygAh2gAAAAAiEgAAAEAt/ABAAAAFxAAAAAAAAAAAAAAaAEAAAAAAAAVEAAAD4Sg BRGEmP5ehKAFYISY/k9KAwBRSgMAbygAh2gAAAAAiEgAAAEAbwABAAAAFxAAAAAAAAAAAAAAaAEA AAAAAAAVEAAAD4RwCBGEmP5ehHAIYISY/k9KBgBRSgYAbygAh2gAAAAAiEgAAAEAp/ABAAAAFxAA AAAAAAAAAAAAaAEAAAAAAAAVEAAAD4RACxGEmP5ehEALYISY/k9KAQBRSgEAbygAh2gAAAAAiEgA AAEAt/ABAAAAFxAAAAAAAAAAAAAAaAEAAAAAAAAVEAAAD4QQDhGEmP5ehBAOYISY/k9KAwBRSgMA bygAh2gAAAAAiEgAAAEAbwABAAAAFxAAAAAAAAAAAAAAaAEAAAAAAAAVEAAAD4TgEBGEmP5ehOAQ YISY/k9KBgBRSgYAbygAh2gAAAAAiEgAAAEAp/ABAAAAFxAAAAAAAAAAAAAAaAEAAAAAAAAVEAAA D4SwExGEmP5ehLATYISY/k9KAQBRSgEAbygAh2gAAAAAiEgAAAEAt/ABAAAAFxAAAAAAAAAAAAAA aAEAAAAAAAAVEAAAD4SAFhGEmP5ehIAWYISY/k9KAwBRSgMAbygAh2gAAAAAiEgAAAEAbwABAAAA FxAAAAAAAAAAAAAAaAEAAAAAAAAVEAAAD4RQGRGEmP5ehFAZYISY/k9KBgBRSgYAbygAh2gAAAAA iEgAAAEAp/ABAAAAFxAAAAAAAAAAAAAAaAEAAAAAAAAVEAAAD4TQAhGEmP5ehNACYISY/k9KAQBR SgEAbygAh2gAAAAAiEgAAAEAt/ABAAAAF5AAAAAAAAAAAAAAaAEAAAAAAAAVEAAAD4SgBRGEmP5e hKAFYISY/k9KAwBRSgMAbygAh2gAAAAAiEgAAAEAbwABAAAAF5AAAAAAAAAAAAAAaAEAAAAAAAAV EAAAD4RwCBGEmP5ehHAIYISY/k9KBgBRSgYAbygAh2gAAAAAiEgAAAEAp/ABAAAAF5AAAAAAAAAA AAAAaAEAAAAAAAAVEAAAD4RACxGEmP5ehEALYISY/k9KAQBRSgEAbygAh2gAAAAAiEgAAAEAt/AB AAAAF5AAAAAAAAAAAAAAaAEAAAAAAAAVEAAAD4QQDhGEmP5ehBAOYISY/k9KAwBRSgMAbygAh2gA AAAAiEgAAAEAbwABAAAAF5AAAAAAAAAAAAAAaAEAAAAAAAAVEAAAD4TgEBGEmP5ehOAQYISY/k9K BgBRSgYAbygAh2gAAAAAiEgAAAEAp/ABAAAAF5AAAAAAAAAAAAAAaAEAAAAAAAAVEAAAD4SwExGE mP5ehLATYISY/k9KAQBRSgEAbygAh2gAAAAAiEgAAAEAt/ABAAAAF5AAAAAAAAAAAAAAaAEAAAAA AAAVEAAAD4SAFhGEmP5ehIAWYISY/k9KAwBRSgMAbygAh2gAAAAAiEgAAAEAbwABAAAAF5AAAAAA AAAAAAAAaAEAAAAAAAAVEAAAD4RQGRGEmP5ehFAZYISY/k9KBgBRSgYAbygAh2gAAAAAiEgAAAEA p/ABAAAAFxAAAAAAAAAAAAAAaAEAAAAAAAAVEAAAD4TQAhGEmP5ehNACYISY/k9KAQBRSgEAbygA h2gAAAAAiEgAAAEAt/ABAAAAF5AAAAAAAAAAAAAAaAEAAAAAAAAVEAAAD4SgBRGEmP5ehKAFYISY /k9KAwBRSgMAbygAh2gAAAAAiEgAAAEAbwABAAAAF5AAAAAAAAAAAAAAaAEAAAAAAAAVEAAAD4Rw CBGEmP5ehHAIYISY/k9KBgBRSgYAbygAh2gAAAAAiEgAAAEAp/ABAAAAF5AAAAAAAAAAAAAAaAEA AAAAAAAVEAAAD4RACxGEmP5ehEALYISY/k9KAQBRSgEAbygAh2gAAAAAiEgAAAEAt/ABAAAAF5AA AAAAAAAAAAAAaAEAAAAAAAAVEAAAD4QQDhGEmP5ehBAOYISY/k9KAwBRSgMAbygAh2gAAAAAiEgA AAEAbwABAAAAF5AAAAAAAAAAAAAAaAEAAAAAAAAVEAAAD4TgEBGEmP5ehOAQYISY/k9KBgBRSgYA bygAh2gAAAAAiEgAAAEAp/ABAAAAF5AAAAAAAAAAAAAAaAEAAAAAAAAVEAAAD4SwExGEmP5ehLAT YISY/k9KAQBRSgEAbygAh2gAAAAAiEgAAAEAt/ABAAAAF5AAAAAAAAAAAAAAaAEAAAAAAAAVEAAA D4SAFhGEmP5ehIAWYISY/k9KAwBRSgMAbygAh2gAAAAAiEgAAAEAbwABAAAAF5AAAAAAAAAAAAAA aAEAAAAAAAAVEAAAD4RQGRGEmP5ehFAZYISY/k9KBgBRSgYAbygAh2gAAAAAiEgAAAEAp/ABAAAA FxAAAAAAAAAAAAAAaAEAAAAAAAAVEAAAD4TQAhGEmP5ehNACYISY/k9KAQBRSgEAbygAh2gAAAAA iEgAAAEAt/ABAAAAF5AAAAAAAAAAAAAAaAEAAAAAAAAZEAAAD4SgBRGEmP5ehKAFYISY/k9KAwBR SgMAXkoDAG8oAIdoAAAAAIhIAAABAG8AAQAAABeQAAAAAAAAAAAAAGgBAAAAAAAAFRAAAA+EcAgR hJj+XoRwCGCEmP5PSgYAUUoGAG8oAIdoAAAAAIhIAAABAKfwAQAAABeQAAAAAAAAAAAAAGgBAAAA AAAAFRAAAA+EQAsRhJj+XoRAC2CEmP5PSgEAUUoBAG8oAIdoAAAAAIhIAAABALfwAQAAABeQAAAA AAAAAAAAAGgBAAAAAAAAGRAAAA+EEA4RhJj+XoQQDmCEmP5PSgMAUUoDAF5KAwBvKACHaAAAAACI SAAAAQBvAAEAAAAXkAAAAAAAAAAAAABoAQAAAAAAABUQAAAPhOAQEYSY/l6E4BBghJj+T0oGAFFK BgBvKACHaAAAAACISAAAAQCn8AEAAAAXkAAAAAAAAAAAAABoAQAAAAAAABUQAAAPhLATEYSY/l6E sBNghJj+T0oBAFFKAQBvKACHaAAAAACISAAAAQC38AEAAAAXkAAAAAAAAAAAAABoAQAAAAAAABkQ AAAPhIAWEYSY/l6EgBZghJj+T0oDAFFKAwBeSgMAbygAh2gAAAAAiEgAAAEAbwABAAAAF5AAAAAA AAAAAAAAaAEAAAAAAAAVEAAAD4RQGRGEmP5ehFAZYISY/k9KBgBRSgYAbygAh2gAAAAAiEgAAAEA p/ABAAAAFwAAAAAAAAAAAAAAAAAAAAAAAAAVEAAAD4TQAhGEmP5ehNACYISY/k9KAQBRSgEAbygA h2gAAAAAiEgAAAEAt/ABAAAAFwAAAAAAAAAAAAAAAAAAAAAAAAAZEAAAD4SgBRGEmP5ehKAFYISY /k9KAwBRSgMAXkoDAG8oAIdoAAAAAIhIAAABAG8AAQAAABcAAAAAAAAAAAAAAAAAAAAAAAAAFRAA AA+EcAgRhJj+XoRwCGCEmP5PSgYAUUoGAG8oAIdoAAAAAIhIAAABAKfwAQAAABcAAAAAAAAAAAAA AAAAAAAAAAAAFRAAAA+EQAsRhJj+XoRAC2CEmP5PSgEAUUoBAG8oAIdoAAAAAIhIAAABALfwAQAA ABcAAAAAAAAAAAAAAAAAAAAAAAAAGRAAAA+EEA4RhJj+XoQQDmCEmP5PSgMAUUoDAF5KAwBvKACH aAAAAACISAAAAQBvAAEAAAAXAAAAAAAAAAAAAAAAAAAAAAAAABUQAAAPhOAQEYSY/l6E4BBghJj+ T0oGAFFKBgBvKACHaAAAAACISAAAAQCn8AEAAAAXAAAAAAAAAAAAAAAAAAAAAAAAABUQAAAPhLAT EYSY/l6EsBNghJj+T0oBAFFKAQBvKACHaAAAAACISAAAAQC38AEAAAAXAAAAAAAAAAAAAAAAAAAA AAAAABkQAAAPhIAWEYSY/l6EgBZghJj+T0oDAFFKAwBeSgMAbygAh2gAAAAAiEgAAAEAbwABAAAA FwAAAAAAAAAAAAAAAAAAAAAAAAAVEAAAD4RQGRGEmP5ehFAZYISY/k9KBgBRSgYAbygAh2gAAAAA iEgAAAEAp/ABAAAAFwAAAAAAAAAAAAAAAAAAAAAAAAALGAAAD4RoARGEmP4VxgUAAWgBBl6EaAFg hJj+T0oGAFFKBgBvKAABANjwAQAAABcQAAAAAAAAAAAAAGgBAAAAAAAAFRAAAA+E0AIRhJj+XoTQ AmCEmP5PSgEAUUoBAG8oAIdoAAAAAIhIAAABALfwAQAAABeQAAAAAAAAAAAAAGgBAAAAAAAAGRAA AA+EoAURhJj+XoSgBWCEmP5PSgMAUUoDAF5KAwBvKACHaAAAAACISAAAAQBvAAEAAAAXkAAAAAAA AAAAAABoAQAAAAAAABUQAAAPhHAIEYSY/l6EcAhghJj+T0oGAFFKBgBvKACHaAAAAACISAAAAQCn 8AEAAAAXkAAAAAAAAAAAAABoAQAAAAAAABUQAAAPhEALEYSY/l6EQAtghJj+T0oBAFFKAQBvKACH aAAAAACISAAAAQC38AEAAAAXkAAAAAAAAAAAAABoAQAAAAAAABkQAAAPhBAOEYSY/l6EEA5ghJj+ T0oDAFFKAwBeSgMAbygAh2gAAAAAiEgAAAEAbwABAAAAF5AAAAAAAAAAAAAAaAEAAAAAAAAVEAAA D4TgEBGEmP5ehOAQYISY/k9KBgBRSgYAbygAh2gAAAAAiEgAAAEAp/ABAAAAF5AAAAAAAAAAAAAA aAEAAAAAAAAVEAAAD4SwExGEmP5ehLATYISY/k9KAQBRSgEAbygAh2gAAAAAiEgAAAEAt/ABAAAA F5AAAAAAAAAAAAAAaAEAAAAAAAAZEAAAD4SAFhGEmP5ehIAWYISY/k9KAwBRSgMAXkoDAG8oAIdo AAAAAIhIAAABAG8AAQAAABeQAAAAAAAAAAAAAGgBAAAAAAAAFRAAAA+EUBkRhJj+XoRQGWCEmP5P SgYAUUoGAG8oAIdoAAAAAIhIAAABAKfwEAAAAJ4MaWMAAAAAAAAAAAAAAAD9aZpUAAAAAAAAAAAA AAAAJizKQQAAAAAAAAAAAAAAAEQTChsAAAAAAAAAAAAAAAAd////AAAAAAAAAAAAAAAAIBeGXQAA AAAAAAAAAAAAAFN6eBAAAAAAAAAAAAAAAACFT3cNAAAAAAAAAAAAAAAA9GJ9cwAAAAAAAAAAAAAA APwDdFkAAAAAAAAAAAAAAACAATZXAAAAAAAAAAAAAAAAoQrKNwAAAAAAAAAAAAAAAClEPVkAAAAA AAAAAAAAAACtUP47AAAAAAAAAAAAAAAAdCR9XgAAAAAAAAAACQD+ACcbMBEAAAAAAAAAAAAAAAD/ //////////////////////////////////////////////////////////////////////////// //8BAAAAAAAAAAEAAAABAAAAAQAAAAIAAAABAAAAAwAAAAEAAAAEAAAAAQAAAAUAAAABAAAABgAA AAEAAAAHAAAAAQAAAAgAAAD///////8QAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAD//xAAAAAAABIAAQAJBAMACQQFAAkEAQAJBAMACQQFAAkEAQAJBAMACQQFAAkEEgABAAkEAwAJ BAUACQQBAAkEAwAJBAUACQQBAAkEAwAJBAUACQQSAAEACQQDAAkEBQAJBAEACQQDAAkEBQAJBAEA CQQDAAkEBQAJBAAAEgAUIsDpAwAJBAUACQQBAAkEAwAJBAUACQQBAAkEAwAJBAUACQQSAAEACQQD AAkEBQAJBAEACQQDAAkEBQAJBAEACQQDAAkEBQAJBAAAAAAAABIAAQAJBAMACQQFAAkEAQAJBAMA CQQFAAkEAQAJBAMACQQFAAkEEgABAAkEAwAJBAUACQQBAAkEAwAJBAUACQQBAAkEAwAJBAUACQQS AAEACQQDAAkEBQAJBAEACQQDAAkEBQAJBAEACQQDAAkEBQAJBBIAAQAJCAMACQgFAAkIAQAJCAMA CQgFAAkIAQAJCAMACQgFAAkIAAASAAEACQQDAAkEBQAJBAEACQQDAAkEBQAJBAEACQQDAAkEBQAJ BAoAkjlhAAAAAAAAAAAAAAECAAIAsBThBgAAAAAAAAAAAAECAAIAwTxdFQAAAAAAAAAAAAECAAIA wDZCMwAAAAAAAAAAAAECAAIAOziAOAAAAAAAAAAAAAECAAIACWvQWAAAAAAAAAAAAAECAAIA2SSO YgAAAAAAAAAAAAECAAIA+EDjYwAAAAAAAAAAAAECAAIAhzZ1bwAAAAAAAAAAAAECAAIAWX7wfwAA AAAAAAAAAAECAAIAXAEAAAQAAAAIAAAA5QAAAAAAAABbAQAAHDsAAH93AAD8EwEA0BACAGwvAgC+ XgIAN3kCAN5DAwA4YQMAFiIEAIZCBAAmZAQAz2kEALVzBAAefwQAri8FAMNKBgC4YQYAMzgHAJVB BwBAXQgAJBELAFRyCwApCwwAfz8MAOtDDAD+fgwART0RAENAEQAqChIA1SkSAD0AFwCyLhcALmQX ADBqFwB4ORgACkEZAKguGgDcPRsASVobAFMSHQD7PB0AhyIeAJ8gHwBWBSAA0TcgADcAIQAWJyIA AEUkAEUcJgBhMScAbgYoAJxQKQCaSSoArjQrAFIVLQCLFS4AuiYuAFg5LgCVTy4ASEEvAD57LwD+ BzAASwcxAIhUMQAidTIAEGYzAMl3NAA3ZzUAH2s1AChsNgBKYDgAewY6AGVYOwDyYTsApRo8APw9 PADhBD4ANCY+AIl8PgAHJT8ATCw/AEVkPwCmBkEAZmFCAKIIRgCQDEYAxRxGAOcbRwCdb0cAtyJI AFdISACVc0gAjyNJADlaSQB9HksAaXFLANF7SwAnNUwAIFhMAOUFTQCbZE0A5G9NALRVTgA4cE4A O1tPAOpQUACkHFEAVh9SAIgqUwC2XlMAkRdUAIB8VAA4cVUAW1JXAHFhVwBVEFkA3j1ZAC0iWgB5 IloAZXhbAA0RXAD1X1wAuxlfADEuXwCqZl8AOFNgANUpYQDKAmMAEh1jAK1uZAAjQ2UA7UNlAL4B ZgBxSGYAlnNmAPAAZwC+HWcA1mRpANVZagBMX20A62tuAAI2bwAUOG8A3zlvAKBTbwB0Z28AvQRw AA02cAC5WHAAG3NyAJ9TcwAEWnMAQHZzADpkdQA7NXYApB53ACMldwCQLncAl1R5AH5neQDoC3oA eCV6AM4+fADbQHwApnd9ACNffgBOdX8AzXCAAHswgQCxMIIAsgqDAH4AhAByMYQAu0qEADZWhAC+ WYQAXGSEAD46hQDjcIYANBiHADlWhwB5N4gAbUWMAJddjAAyDI0AWheNANsojQCkFI4AsSqOAHxv jgD8CY8AxBKQAM5jkQATOJIA+FqSALxFlABVdpUAXmOXAB80mQBYdpkAZxqaAMt+mgBrHJwA4U+c AHsxnQCnC58ACH2fALwAoABVWaAAs0yhAN9JogBDFaMAlkyjAMIopAACcaUAcnelAMpVpgBBZKkA LmupAMUjqgArC6sAzSerAGBUqwAlBK0AxU2tACZTrgD/J68AOxKwADlosAAMfrAAAFKxAMlosQDY TbIAe3OyAF0yswC6SbMANkK0AFNrtADfdLQAwSe1AF8ytQAGPbUAQVW2APUTtwCRebcA5Ui4AGof ugA0YroA0Ty7APNhuwC4MbwAjSi9AGUavgAtPL4A6Vi/AL9lwABIccAAOQTBAKwfwgD+dMMANn/D AINDxADGPMYAMVPGALoAyADQJskAzEfJAB8xygBGUsoAaAjMAMwOzABrK8wA41/MAJNszABATM4A cTLPAI57zwCiBtAAAijQAOAK0QD1HtEAjE3SAMdN0gDgRdQAPW7VABFL1gC2a9gAww/ZAPIP2QBm MNoAvS3bAMk22wDHENwADjfcADA+3ADAK90AZXfdAN0S3gDoM94AdETeAC9R3gAUEOAA7BrgALoL 4QA/KOEAOR/jAEga5ABtQOQAahDlAIQe5QAJSeUAbXblACQp5gASZeYAxRroAPsy6ADsTOgA2B7q AMRb6gDnEOsAJzfrAB4H7ACjY+wANETvADIW8QBxF/EA9X/xAJ4L8wBfDfMA3CfzAM0R9QCPJvUA fgr2AC9F9gDRX/YAMHT2APd2+ACKJPkA1GH8AHd0/ABeFf0AdjD+AI8B/wD4Av8ASS7/AC1A/wCM Wf8AAAAAAN0DAADfAwAAAAAAAAEAAAD/QAOAAQDcAwAA3AMAAAAAAAABAAEA3AMAAAAAAADcAwAA AAAAAAIQAAAAAAAAAPcDAABoAAAQAEAAAP//AQAAAAcAVQBuAGsAbgBvAHcAbgD//wEACAAAAAAA AAAAAAAA//8BAAAAAAD//wAAAgD//wAAAAD//wAAAgD//wAAAAAKAAAARx6QAQAAAgIGAwUEBQID BP8qAOBBeADACQAAAAAAAAD/AQAAAAAAAFQAaQBtAGUAcwAgAE4AZQB3ACAAUgBvAG0AYQBuAAAA NR6QAQIABQUBAgEHBgIFBwAAAAAAAAAQAAAAAAAAAAAAAACAAAAAAFMAeQBtAGIAbwBsAAAAMy6Q AQAAAgsGBAICAgICBP8qAOBDeADACQAAAAAAAAD/AQAAAAAAAEEAcgBpAGEAbAAAAD89kAEAAAIH AwkCAgUCBAT/KgDgQ3gAwAkAAAAAAAAA/wEAAAAAAABDAG8AdQByAGkAZQByACAATgBlAHcAAAA7 DpABhgcCAQYAAwEBAQEBAwAAAAAAjygWAAAAAAAAAAEABAAAAAAAUwBpAG0AUwB1AG4AAACLW1NP AAA1LpABAAACCwYEAwUEBAIE/y4A4VtgAMApAAAAAAAAAP8BAQAAAAAAVABhAGgAbwBtAGEAAAA7 DpABAgAFAAAAAAAAAAAAAAAAAAAAABAAAAAAAAAAAAAAAIAAAAAAVwBpAG4AZwBkAGkAbgBnAHMA AABhBpABAg8AAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAAAAAAAAIAAAAAATQBvAG4AbwB0AHkAcABl ACAAUwBvAHIAdABzAAAAWgBhAHAAZgAgAEQAaQBuAGcAYgBhAHQAcwAAADkekAECAAUDAQIBBQkG BwMAAAAAAAAAEAAAAAAAAAAAAAAAgAAAAABXAGUAYgBkAGkAbgBnAHMAAABBHpABAAACBAUDBQQG AwIE/wIA4P8kAEIAAAAAAAAAAJ8BAAAAAAAAQwBhAG0AYgByAGkAYQAgAE0AYQB0AGgAAAAiAAQA QQiIGADw0AIAAGgBAAAAADljOGdCYzhn3LwzJwMABQAAAJMAAABKAwAAAQABAAAABACDEAcAAACT AAAASgMAAAEAAQAAAAcAAAAAAAAAIQMA8BCEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAApQbA B7QAtACAAHIwAAAAAAAAAAAAAAAAAADcAwAA3AMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIAAAAAAAAAAAANM4NxAPAQhN/f//8B AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACEhQAAAAAAnw/w8BCCRQAADkBAAA////f////3////9/ ////f////3////9/////f59TcwAABAAAMgAAAAAAAAAAAAAAAAAAAAQAAAAAACEEAAAAAAAAAAAA AAAAAAAAAAAAEBwAAAkAAAAAAAAAAAB4AAAAeAAAAAAAAAAAAAAAoAUAAAAAAAALAAAAAAAAANwA AAD//xIAAAAAAAAAEgBMAFMAIAB0AGUAbQBwAGwAYQB0AGUAIABmAG8AcgAgAE4AMwAAAAAAAAAR AEQAYQB2AGkAZAAgAEIAbwBzAHcAYQByAHQAaABpAGMAawAEAFIAbwBuAGkAAAAAAAAAAAAAAAAA AAAAAAAAAABMAAAABgAAABAAAAAAAAwAAQAMAAIADAADAAwABAAMAAUADAAGAAwABwAMAAgADAAJ AAwACgAMAAsADAAMAAwADQAMAA4ADAAPAAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD+ /wAABgECAAAAAAAAAAAAAAAAAAAAAAABAAAA4IWf8vlPaBCrkQgAKyez2TAAAABcAQAADwAAAAEA AACAAAAAAgAAAIgAAAAEAAAApAAAAAcAAADAAAAACAAAANAAAAAJAAAA4AAAABIAAADsAAAACgAA AAwBAAALAAAAGAEAAAwAAAAkAQAADQAAADABAAAOAAAAPAEAAA8AAABEAQAAEAAAAEwBAAATAAAA VAEAAAIAAADnBAAAHgAAABQAAABMUyB0ZW1wbGF0ZSBmb3IgTjMAAB4AAAAUAAAARGF2aWQgQm9z d2FydGhpY2sAAAAeAAAACAAAAE5vcm1hbAAAHgAAAAgAAABSb25pAAAAAB4AAAAEAAAAMwAAAB4A AAAYAAAATWljcm9zb2Z0IE9mZmljZSBXb3JkAAAAQAAAAABe0LIAAAAAQAAAAABo0VOGZdABQAAA AAD+OTvl1NABQAAAAABcCu7l1NABAwAAAAEAAAADAAAAkwAAAAMAAABKAwAAAwAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA/v8AAAYBAgAA AAAAAAAAAAAAAAAAAAAAAgAAAALVzdWcLhsQk5cIACss+a5EAAAABdXN1ZwuGxCTlwgAKyz5rlQB AAAQAQAADAAAAAEAAABoAAAADwAAAHAAAAAFAAAAkAAAAAYAAACYAAAAEQAAAKAAAAAXAAAAqAAA AAsAAACwAAAAEAAAALgAAAATAAAAwAAAABYAAADIAAAADQAAANAAAAAMAAAA7wAAAAIAAADnBAAA HgAAABgAAABFVFNJIFNvcGhpYSBBbnRpcG9saXMAAAADAAAABwAAAAMAAAABAAAAAwAAANwDAAAD AAAAAAAOAAsAAAAAAAAACwAAAAAAAAALAAAAAAAAAAsAAAAAAAAAHhAAAAEAAAATAAAATFMgdGVt cGxhdGUgZm9yIE4zAAwQAAACAAAAHgAAAAYAAABUaXRsZQADAAAAAQAAAAAAAGQCAAAHAAAAAAAA AEAAAAABAAAAtgAAAAIAAAC+AAAAAwAAALoBAAAEAAAA0gEAAAUAAAA2AgAABgAAAE4CAAAFAAAA AgAAAA8AAABfbXNfcElEXzcyNTM0MwADAAAAEgAAAF9tc19wSURfNzI1MzQzXzAwAAQAAAAQAAAA X21zX3BJRF83MjUzNDMxAAUAAAATAAAAX21zX3BJRF83MjUzNDMxXzAwAAYAAAAGAAAAc2ZsYWcA AgAAAOcEAAAeAAAA9AAAACgyKTdzM1R6L01MZkpNaWRQWWtXSlBzYlk3c3oyTWYrVVh6N2JaaGNo RHNFWGNRQjVheTRwUG9ORExCRFlaSVlnUWhJZmFOT1Zqaw0KNk5jSXhCSXlTd1FtWnVnVk5TRzJu SjhPNlNVNHFReUd1NWhhdnJIQkRSa25hb2NSRUtXc094SHgzTXd3MkNwaVcvd0JYN256DQplRDJB RHZjdUJ1akF4OEsxN2gzZG9lVU5OL0FZdTA5ZzYxc00rQ1JaUVB0Q2cvUUszMEs2bUdzcVk1OXNr czNCelpXV2hNYjINCnZBTUNnL2VGRWxNSDZvVXdwZAAeAAAAEAAAAF9tc19wSURfNzI1MzQzAAAe AAAAXAAAAGhZZWVqb3FlY3V2Z25yL21ybmN3VmdLVmZIb0xxQVZ4T3V5L0kyTHpuQWZCR0tLcUNp S1ZUQQ0KZzU2TURXakkxb1NOeEtvQU9FMTRJMG9iR0tBajZHVTkAAAAAHgAAABAAAABfbXNfcElE XzcyNTM0MzEAHgAAAAwAAAAxNDIyNDc2MTM2AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAACAAAAAwAAAAQAAAAF AAAABgAAAAcAAAAIAAAACQAAAAoAAAALAAAADAAAAA0AAAD+////DwAAABAAAAARAAAAEgAAABMA AAAUAAAAFQAAABYAAAAXAAAAGAAAABkAAAAaAAAAGwAAABwAAAAdAAAAHgAAAB8AAAAgAAAAIQAA ACIAAAAjAAAAJAAAACUAAAAmAAAAJwAAACgAAAApAAAAKgAAACsAAAAsAAAALQAAAC4AAAAvAAAA MAAAADEAAAAyAAAAMwAAADQAAAA1AAAANgAAADcAAAA4AAAA/v///zoAAAA7AAAAPAAAAD0AAAA+ AAAAPwAAAEAAAAD+////QgAAAEMAAABEAAAARQAAAEYAAABHAAAASAAAAP7////9////SwAAAP7/ ///+/////v////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ////////////////////////////////////////////////////UgBvAG8AdAAgAEUAbgB0AHIA eQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABYABQH///////// /wMAAAAGCQIAAAAAAMAAAAAAAABGAAAAAAAAAAAAAAAAcIs7+uXU0AFNAAAAgAAAAAAAAAAxAFQA YQBiAGwAZQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAADgACAf////8FAAAA/////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA4A AAAbVAAAAAAAAFcAbwByAGQARABvAGMAdQBtAGUAbgB0AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAaAAIBAQAAAP//////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAADQaAAAAAAAABQBTAHUAbQBtAGEAcgB5AEkAbgBmAG8AcgBtAGEAdABp AG8AbgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACgAAgECAAAABAAAAP////8AAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA5AAAAABAAAAAAAAAFAEQAbwBjAHUAbQBlAG4AdABT AHUAbQBtAGEAcgB5AEkAbgBmAG8AcgBtAGEAdABpAG8AbgAAAAAAAAAAAAAAOAACAf////////// /////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEEAAAAAEAAAAAAAAAEAQwBv AG0AcABPAGIAagAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAASAAIA////////////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AHIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAD///////////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP///////////////wAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAD+//////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ////////////////////////////////////////////////AQD+/wMKAAD/////BgkCAAAAAADA AAAAAAAARiAAAABNaWNyb3NvZnQgV29yZCA5Ny0yMDAzIERvY3VtZW50AAoAAABNU1dvcmREb2MA EAAAAFdvcmQuRG9jdW1lbnQuOAD0ObJxAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA= --_002_E5DF8D4B04B542768DAE9C9B60CF76F6vidyocom_-- From nobody Tue Sep 8 15:02:01 2015 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9DE21B332D for ; Tue, 8 Sep 2015 15:01:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.1 X-Spam-Level: X-Spam-Status: No, score=0.1 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham 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 DxGKk9wFMdDh for ; Tue, 8 Sep 2015 15:01:05 -0700 (PDT) Received: from nm9-vm2.access.bullet.mail.gq1.yahoo.com (nm9-vm2.access.bullet.mail.gq1.yahoo.com [216.39.63.37]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 12A341B3313 for ; Tue, 8 Sep 2015 15:01:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1441749664; bh=GV96YdB47kC3I2jgW3BRIL27nNTRbFv1HBBGxD9A56g=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From:Subject; b=GaXuGzoujC7pc/pEa3e4OClHtPCm2nFA9HvWCaaMnngD9VgeukhOn5vA6x9InTojBEI1UCnlo5YiPpKct9691P7whYnjmOCXGM+hVwreD+dT9F8Tj/YYBYML3OCq1qk4XOPQQux/KVj/0BiPYUJy5D54N+77Cx2HIrAolta/rSmqhrG512XdlkSxRSYGc7g0WUCEAKa50ltLAKwgvm/eAJxzJCwpEc69vSnvewwoiXa5SefmN5IkMI69H/5KzWhxncQQ2MRIeMcnrhAdAo+pUS5EMy3EBAD97haUJjqYIrdLtkIHYWsSouyYLNKOAbiVjawP/s1A9jLDYNsg4Brlig== Received: from [216.39.60.175] by nm9.access.bullet.mail.gq1.yahoo.com with NNFMP; 08 Sep 2015 22:01:04 -0000 Received: from [98.138.226.244] by tm11.access.bullet.mail.gq1.yahoo.com with NNFMP; 08 Sep 2015 22:01:04 -0000 Received: from [127.0.0.1] by smtp115.sbc.mail.ne1.yahoo.com with NNFMP; 08 Sep 2015 22:01:04 -0000 X-Yahoo-Newman-Id: 358563.59748.bm@smtp115.sbc.mail.ne1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: KRlcfQ0VM1mADaPypu2T5xkOqmaNdFnh7FohrAz7SMgdTld saYkQE..rdd.25aMOYfS6L8bl0wuNz677tc81mSHA6pnEtpBqtgC.aH2OQSt fiWGhVXaS3elOG8abWNoWUqNzOg3jAfsa39As6ZS9Ioa6IolPcv4HGKL5bPO jASi8dk9rOzz_yiZKaVk9Pd.4NsP3Iy408VUBoMK3HL_3180a8G7jlUdCDxI ZqVO5zC.lbcsIFg3KQhKOkylfJoyfrC_xdy5Ila8TF6m2GNyeFo_vFEGK2og 8_JxrBHUbd3OWXJj3yi7LVwsu.24Drh7Vqgg671AbttEvoB9U5K8dJI4terM O5wSOYob9Zq0opLlDkorkWHOqByutQFY4iWPhEn_gTtAAIqvd830yVJ9fym0 Kk8crgliMDnhC.NoltNuAaiADfIoUXJU1LkcJ58GeqfqTHZ3Lr5QDZ7Jsz.O jmeJMFQCW0n.P.z0YfJGnAC2JG6dwAimZt4giHg.rA1gLri0ISX_b9LdoZ5k 6Soy1IhwCRUyOufJLB88ik9w2kCzub.G5nZ2.kA-- X-Yahoo-SMTP: 4kJJK.qswBDPuwyc5wW.BPAQqNXdy5j09UNyeAS0pyOQ708- Received: from secure.mandelberg.org (c-76-24-31-176.hsd1.ma.comcast.net [76.24.31.176]) by uriel.mandelberg.org (Postfix) with ESMTPSA id E19FB1C6095; Tue, 8 Sep 2015 18:01:01 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Tue, 08 Sep 2015 18:01:01 -0400 From: David Mandelberg To: Magnus Westerlund In-Reply-To: <55E7158D.5060304@ericsson.com> References: <063cc84fb1eb8fbef30eda11ea7d8199@mail.mandelberg.org> <55E7158D.5060304@ericsson.com> Message-ID: <5500272170d19009fe7d7e58ffaebd50@mail.mandelberg.org> X-Sender: david@mandelberg.org User-Agent: Roundcube Webmail/0.7.2 Archived-At: X-Mailman-Approved-At: Tue, 08 Sep 2015 15:02:00 -0700 Cc: draft-ietf-avtext-rtp-stream-pause.all@tools.ietf.org, avtext@ietf.org, IESG , secdir@ietf.org Subject: Re: [avtext] secdir review of draft-ietf-avtext-rtp-stream-pause-08 X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Sep 2015 22:01:07 -0000 On 2015-09-02 11:28, Magnus Westerlund wrote: > Den 2015-08-11 kl. 06:45, skrev David Mandelberg: >> Hi, >> >> 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. >> >> I think this draft is Ready with issues, though the two issues are >> relatively minor: >> >> 1. The Security Considerations section talks about protecting >> against >> injection of PAUSE requests: >> >> The way of protecting the RTP session from these injections is >> to >> perform source authentication combined with message integrity, >> to >> prevent other than intended session participants from sending >> these >> messages. >> >> I think this paragraph should also mention replay protection, which >> is >> needed if the 16-bit PauseID wraps around and the attacker has >> access to >> old PAUSE requests. > > Yes, we should mention replay attacks. I note that due to that the > current PauseID starts at 0 and increments by one, it takes some time > until we wrap. And also then you might have to hold onto a lot of > messages to be able to attempt a replay. But, clearly we should > recommend replay protection at the outer security layer. > > I propose that we add the following sentence in the second paragraph > prior to the last sentence: > > The security solution should provide replay protection, otherwise an > attacker could for sessions that are long lived enough to wrap the > PauseID replay old messages at the appropriate time to influence the > media sender state. Looks good to me. >> 2. The next paragraph in Security Considerations talks about >> protecting >> the multi-party use case against a single malicious participant by >> individually authenticating participants. In addition to >> per-participant >> authentication, I think there also needs to be a requirement for >> attempted delivery of PAUSE requests to all participants. Without >> that >> requirement, an attacker could cause the session to cycle through >> the >> Playing, Pausing, and Paused states. To do that, the attacker would >> send >> PAUSE requests only to the stream sender, instead of to the whole >> group. >> Since no other participants receive the PAUSE request, they do not >> know >> to send disapproving RESUMEs until after the stream sender has >> already >> paused the stream. (I should note that I'm not particularly familiar >> with multicast network operations. If it's infeasible for one >> participant to send a message to another participant without the >> rest of >> the group also receiving the message, then I apologize for bringing >> up a >> non-issue.) > > Yes, you are correct that getting a malicious PAUSE message sent to > multiple participants provides a mitigation in that the other > participants can counter it. That I would expect to happen in > multicast cases where anyone can send RTCP messages. It will fully > depend on the multicast topology if an on-path attacker has any > chance > of getting its messages delivered to the media stream endpoint and > not > getting forwarded to other endpoints over the multicast tree. > > In the cases of the RTP middleboxes providing the multi-party > functionality it will depend on the mode of operation of that > middlebox. But, assuming the middlebox isn't compromised it will act > on behalf of the whole session. It either works as multicast emulator > and should forward it to everyone, or it will receive the request, > and > only forward it if fits the rest of the session state. > > Proposed text for the end of Paragraph three: > > An attacker that can send a PAUSE request without it reaching any > other participant than the media sender can have its request being > unopposed. This is mitigated in multi-party topologies that ensure > that requests are seen by all or most of the RTP session > participants, > enabling these participants to send RESUME. In topologies with > middleboxes that consume and process PAUSE requests, the middlebox > can > also mitigate such behavior as it will commonly not generate or > forward a PAUSE message if it knows of another participant having use > for the media stream. > > Comments on this? This also looks good to me. Thanks for addressing my concerns! -- David Eric Mandelberg / dseomn http://david.mandelberg.org/ From nobody Wed Sep 9 02:04:45 2015 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 965F11AC3D6 for ; Wed, 9 Sep 2015 02:04:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 GSZ1MkuwIosR for ; Wed, 9 Sep 2015 02:04:43 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (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 618481AC3C5 for ; Wed, 9 Sep 2015 02:04:42 -0700 (PDT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (unknown [135.239.2.42]) by Websense Email Security Gateway with ESMTPS id 3C140FC7030E4; Wed, 9 Sep 2015 09:04:39 +0000 (GMT) Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id t8994E49016135 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 9 Sep 2015 11:04:40 +0200 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.167]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.03.0195.001; Wed, 9 Sep 2015 11:04:28 +0200 From: "DRAGE, Keith (Keith)" To: Jonathan Lennox , "avtext@ietf.org" Thread-Topic: draft response to SA4 liaison statement Thread-Index: AdDU5hnPZpnbT5wDRCi9ydKVbqRU8AV9/s/A Date: Wed, 9 Sep 2015 09:04:28 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8BAC79DCB1@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <01f401d0d4e6$52bd03f0$f8370bd0$@gmail.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.39] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [avtext] draft response to SA4 liaison statement X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Sep 2015 09:04:44 -0000 MSkJUGxlYXNlIGFkZCBJRVRGIGluIGZyb250IG9mICJBVlRleHQgV0ciIGluIHNvdXJjZS4NCg0K MikJVGhlIHBhcmFncmFwaCBsYWJlbGxlZCAiT3ZlcmFsbCIgY29uZnVzZWQgbWUgdW50aWwgSSBy ZWFsaXplZCBpdCB3YXMgcmVwZWF0aW5nIHRoZSBpbnB1dCBwb2ludHMgZnJvbSBTQTQuIFdlIHNo b3VsZCB1c2UgYSBtb3JlIGFwcHJvcHJpYXRlIHRpdGxlIHN1Y2ggYXMgIjNHUFAgU0E0IHJlcXVl c3QiLg0KDQozKQlJIGJlbGlldmUgdGhpcyBMUyBuZWVkcyB0byBiZSBtb3JlIHNwZWNpZmljIG9u IHdoYXQgYW4gYWxpZ25lZCByZXN1bHQgaXMuIERlcGVuZGluZyBvbiBpbnRlcnByZXRhdGlvbiwg YW4gYWxpZ25lZCBzcGVjaWZpY2F0aW9uIGNhbiBzdGlsbCBmYWlsIHRvIGludGVyb3BlcmF0ZS4g RG8gd2UgcGxhbiB0aGF0IGFueSBJRVRGIHNwZWNpZmljYXRpb24gaW4gdGhpcyBhcmVhIGFuZCBh bnkgM0dQUCBzcGVjaWZpY2F0aW9uIGluIHRoaXMgYXJlYSBzaG91bGQgaW50ZXJvcGVyYXRlPw0K DQpSZWdhcmRzDQoNCktlaXRoDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBh dnRleHQgW21haWx0bzphdnRleHQtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEpvbmF0 aGFuIExlbm5veA0KU2VudDogMDggU2VwdGVtYmVyIDIwMTUgMTY6MTUNClRvOiBhdnRleHRAaWV0 Zi5vcmcNClN1YmplY3Q6IFthdnRleHRdIEZ3ZDogZHJhZnQgcmVzcG9uc2UgdG8gU0E0IGxpYWlz b24gc3RhdGVtZW50DQoNCg0KSGVsbG8sIEFWVEV4dCBtZW1iZXJzIOKAlA0KDQpIZXJlIGlzIFJv bmkgRXZlbuKAmXMgcHJvcG9zZWQgcmVzcG9uc2UgdG8gU0E04oCZcyBsaWFpc29uIHN0YXRlbWVu dCBhYm91dCBWaWRlbyBSZWdpb24tb2YtSW50ZXJlc3QuICBQbGVhc2UgcmV2aWV3IGFuZCBjb21t ZW50Lg0KDQoNCg== From nobody Wed Sep 9 07:01:08 2015 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6036B1B37AA for ; Wed, 9 Sep 2015 07:01:07 -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 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 fiAWn4DakzE0 for ; Wed, 9 Sep 2015 07:01:03 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD6B41B3795 for ; Wed, 9 Sep 2015 07:01:02 -0700 (PDT) X-AuditID: c1b4fb3a-f79136d0000071e2-e6-55f03b9c2232 Received: from ESESSHC009.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 10.E1.29154.C9B30F55; Wed, 9 Sep 2015 16:01:00 +0200 (CEST) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.47) with Microsoft SMTP Server id 14.3.248.2; Wed, 9 Sep 2015 16:00:59 +0200 To: Jonathan Lennox , "avtext@ietf.org" References: <01f401d0d4e6$52bd03f0$f8370bd0$@gmail.com> From: Magnus Westerlund Message-ID: <55F03B9B.6020008@ericsson.com> Date: Wed, 9 Sep 2015 16:00:59 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprKLMWRmVeSWpSXmKPExsUyM+Jvje4c6w+hBg8Xa1h8vHeD1WL/4vPM DkweS5b8ZPJoe3aHPYApissmJTUnsyy1SN8ugSvjz5HXbAVHeComNe1laWBs4+pi5OSQEDCR aFn6kwnCFpO4cG89WxcjF4eQwFFGiQsdsxkhnGWMEo92bGEFqRIWcJJ4/OoDSxcjB4eIgK/E /y1JIGEhgSyJRddXsoHYbAIWEjd/NILZvALaEn93z2ECKWcRUJF42p8LEhYViJHo+bUBqkRQ 4uTMJ2ATOQVsJTo7ckFMZgF7iQdby0AqmAXkJZq3zmaGWKQt0dDUwTqBUWAWkuZZCB2zkHQs YGRexShanFpcnJtuZKSXWpSZXFycn6eXl1qyiREYjge3/LbawXjwueMhRgEORiUe3gWT3ocK sSaWFVfmHmKU5mBREudtZnoQKiSQnliSmp2aWpBaFF9UmpNafIiRiYNTqoGxU6Unr+g5z9nl 5VFXRJ7HbAyNtp784Vn1W/FJEukTs1XXhq220JhxsrF1093gG14vFvpzX9pSvss+eHfHXjvf 5QaMYabrzVTOb/3yljkrJ1KlZvqsJSq6to6MRv2TZRqbRPWmtV+eUFeo2lz28yWvdSv7lOp1 /B9fa4d3OHidu3921i/RrEwlluKMREMt5qLiRABG5a+xKAIAAA== Archived-At: Subject: Re: [avtext] Fwd: draft response to SA4 liaison statement X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Sep 2015 14:01:07 -0000 Hi, I have looked at the draft LS. I think we should provide constructive feedback for what the AVTEXT participants see as shortcomings of the 3GPP proposals. I think the main reason for considering to do IETF work on this was that the proposal had shortcomings. I will note that 3GPP has already requested registration for their RTP header extensions as well as the RTCP Feedback format. I am reviewer and have had some feedback to them. They are likely to need to revise their specification to fulfil this requirement. Therefore I think they can consider to address a larger set of feedbacks if we can provide it. I personally don't see a need for an IETF specification if the 3GPP one is sufficiently good. The primary issue I saw with the feedback format is that it is unclear if the FCI format allows for multiple entries. However, I think there might be an issue with determining if a request is being received and acted on. That is clearly one difference between the I-D here in IETF and the 3GPP spec. Thus, I think we should gather such feedback and provide it. Cheers Magnus Westerlund ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From nobody Wed Sep 9 09:58:17 2015 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B7771B3308 for ; Wed, 9 Sep 2015 09:58:15 -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, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 mX2ENYpqsQml for ; Wed, 9 Sep 2015 09:58:13 -0700 (PDT) Received: from mail-wi0-x22a.google.com (mail-wi0-x22a.google.com [IPv6:2a00:1450:400c:c05::22a]) (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 BE2A41A700F for ; Wed, 9 Sep 2015 09:58:12 -0700 (PDT) Received: by wicfx3 with SMTP id fx3so164473000wic.1 for ; Wed, 09 Sep 2015 09:58:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:content-transfer-encoding:thread-index :content-language; bh=EN/veqxsLRGsVZAIF059O2ZU6HtwMuCrdBnFuxPO2Is=; b=SNQlpzdHRg3sj/URicZN2xyfSMuicPLdLzJAy/2OhSkGm/+nEzvUtMm/eg3FdLwQV+ FihO3Cl9IqaATyl83+1Ib/BBEVO7zl8bDmb7JXW9pp2Kk+DzXI+kqv9DNz1dMnV3850L Zp6W7dlWQ3dv21yv/D3lT06cKwxamZ1y0POsdJ8GLaCk3jTE2ai6LjPl6816NSP5XraL FdacJozDJ2niCvL4ZmZOOlL0pc1OPw6njZTJP/4dViauMeLIvSw1uepjZng9hdTQYaXo 083QFE6l10Nx9J9+ZpwV2c4izNp+mnE+Bk3HQXGUpWr7NexiZ5THAAwdPnMyPnHU1J2T IiCw== X-Received: by 10.180.84.225 with SMTP id c1mr20923046wiz.92.1441817891389; Wed, 09 Sep 2015 09:58:11 -0700 (PDT) Received: from RoniPC (bzq-79-180-110-132.red.bezeqint.net. [79.180.110.132]) by smtp.gmail.com with ESMTPSA id x10sm4803931wiy.6.2015.09.09.09.58.09 (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 09 Sep 2015 09:58:10 -0700 (PDT) From: "Roni Even" To: "'Magnus Westerlund'" , "'Jonathan Lennox'" , References: <01f401d0d4e6$52bd03f0$f8370bd0$@gmail.com> <55F03B9B.6020008@ericsson.com> In-Reply-To: <55F03B9B.6020008@ericsson.com> Date: Wed, 9 Sep 2015 19:58:04 +0300 Message-ID: <03a701d0eb20$b269e6b0$173db410$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQESySJSqxJaA07eLxmAsmwS8cYwJgK/YrIDAdL764ufjBlI4A== Content-Language: he Archived-At: Subject: Re: [avtext] Fwd: draft response to SA4 liaison statement X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Sep 2015 16:58:15 -0000 Hi, My understanding was that the authors of the IETF document were asked to = go to 3GPP and present their concerns over there. Since the authors do not attend 3GPP meeting and they have concerns with the proposed solution, I believe that this is what we can currently say. If you think we should raise our concerns I can point at the three major ones. 1. It is not clear what is the "original content ". Is it the first = image that was sent, how does it work for multipoint? We think that the = request can relate to the current content as the reference for the request. 2. The co-ordinates can be negative if you want to zoom out or move out = of the displayed content (this also relates to the first issue of what is = the original content) 3. The definition of pre-defined is not clear depending on the = definition of "original content". BTW: in H.281 the pre-defined are using a current = view and provide an ID for it that can be used later to return to the same = view Roni Even -----Original Message----- From: avtext [mailto:avtext-bounces@ietf.org] On Behalf Of Magnus = Westerlund Sent: Wednesday, September 09, 2015 5:01 PM To: Jonathan Lennox; avtext@ietf.org Subject: Re: [avtext] Fwd: draft response to SA4 liaison statement Hi, I have looked at the draft LS. I think we should provide constructive feedback for what the AVTEXT participants see as shortcomings of the = 3GPP proposals. I think the main reason for considering to do IETF work on = this was that the proposal had shortcomings. I will note that 3GPP has already requested registration for their RTP header extensions as well as the RTCP Feedback format. I am reviewer and have had some feedback to them. They are likely to need to revise their specification to fulfil this requirement. Therefore I think they can consider to address a larger set of feedbacks = if we can provide it. I personally don't see a need for an IETF = specification if the 3GPP one is sufficiently good. The primary issue I saw with the feedback format is that it is unclear = if the FCI format allows for multiple entries. However, I think there might be an issue with determining if a request = is being received and acted on. That is clearly one difference between the = I-D here in IETF and the 3GPP spec. Thus, I think we should gather such feedback and provide it. Cheers Magnus Westerlund ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 F=E4r=F6gatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- _______________________________________________ avtext mailing list avtext@ietf.org https://www.ietf.org/mailman/listinfo/avtext From nobody Thu Sep 10 01:13:18 2015 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCFAA1A6FB8 for ; Thu, 10 Sep 2015 01:13:17 -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 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 vxsN3mjvQrQa for ; Thu, 10 Sep 2015 01:13:16 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE09D1A03B3 for ; Thu, 10 Sep 2015 01:13:15 -0700 (PDT) X-AuditID: c1b4fb3a-f79136d0000071e2-2e-55f13b991995 Received: from ESESSHC024.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 5B.76.29154.99B31F55; Thu, 10 Sep 2015 10:13:13 +0200 (CEST) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.92) with Microsoft SMTP Server id 14.3.248.2; Thu, 10 Sep 2015 10:13:12 +0200 To: Roni Even , 'Jonathan Lennox' , References: <01f401d0d4e6$52bd03f0$f8370bd0$@gmail.com> <55F03B9B.6020008@ericsson.com> <03a701d0eb20$b269e6b0$173db410$@gmail.com> From: Magnus Westerlund Message-ID: <55F13B98.8060403@ericsson.com> Date: Thu, 10 Sep 2015 10:13:12 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <03a701d0eb20$b269e6b0$173db410$@gmail.com> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrILMWRmVeSWpSXmKPExsUyM+Jvje5M64+hBk0XzC0+3rvBarF/8Xlm i7/tzA7MHjtn3WX3WLLkJ5NH27M77AHMUVw2Kak5mWWpRfp2CVwZbyf1sBZsUq3YfWwCcwPj b9kuRk4OCQETiYNT25kgbDGJC/fWs4HYQgJHGSV+/YzpYuQCspczSvQuu84CkhAWcJJ4/OoD mC0ikCwxe89mZoiiHYwSZzd9AZvEJmAhcfNHI9gkXgFtiZ/PFoDZLAKqErM2ngarERWIkej5 tQGqRlDi5MwnYEM5gXq/PJ3N2sXIwcEsYC/xYGsZSJhZQF6ieetsZojjtCUamjpYJzAKzELS PQuhYxaSjgWMzKsYRYtTi4tz042M9FKLMpOLi/Pz9PJSSzYxAsP04JbfVjsYDz53PMQowMGo xMOr8ORDqBBrYllxZe4hRmkOFiVx3mamB6FCAumJJanZqakFqUXxRaU5qcWHGJk4OKUaGLv/ CSuFHE3/G+4x+dQHr6X8aaskNdsl9+Q5/3vqzbt736ufPU1p/7dWFArMfPrKdWpXtt5WJZXf VfcfVsdzb1klaHFggWK07In6Qiau+1E95mHHBGJfPC9X031bFPTIWnRK24oHDQ7T66JUW73E d6jfWqY/6/XU/v98jtpb2baocEvtOHJ6nRJLcUaioRZzUXEiAJHas+w0AgAA Archived-At: Subject: Re: [avtext] Fwd: draft response to SA4 liaison statement X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Sep 2015 08:13:18 -0000 Den 2015-09-09 kl. 18:58, skrev Roni Even: > Hi, > My understanding was that the authors of the IETF document were asked to go > to 3GPP and present their concerns over there. Since the authors do not > attend 3GPP meeting and they have concerns with the proposed solution, I > believe that this is what we can currently say. > If you think we should raise our concerns I can point at the three major > ones. > > 1. It is not clear what is the "original content ". Is it the first image > that was sent, how does it work for multipoint? We think that the request > can relate to the current content as the reference for the request. Yes, this is thorny and I think you will need to expand on this. It clearly need to work with switched sources, such as the ones in an RTP mixer performing source switching. I think one can also raise the issue between original capture and what is being encoded, as scaling prior to encoding for bit-rate adaptation and simulcast usage makes things more interesting. As the coordinates in pixel in these cases for a particular region changes upon the switch of resolution. > 2. The co-ordinates can be negative if you want to zoom out or move out of > the displayed content (this also relates to the first issue of what is the > original content) Given, that the coordinate system is in relation to the currently received picture. But, I do note that attempting to use "current" requires one to include some type of reference (RTP Timestamp), for what current is, due to the delay between the sender side and receiver. > 3. The definition of pre-defined is not clear depending on the definition of > "original content". BTW: in H.281 the pre-defined are using a current view > and provide an ID for it that can be used later to return to the same view Okay, this needs to be written up in an more complete argumentation. I also note that these type of issues do result in an highly likelihood that an updated specification, independently if it is in 3GPP and IETF this specification is developed. Thus, we might be forced to raise the warning that this might be the end result. Cheers Magnus Westerlund > > Roni Even > > -----Original Message----- > From: avtext [mailto:avtext-bounces@ietf.org] On Behalf Of Magnus Westerlund > Sent: Wednesday, September 09, 2015 5:01 PM > To: Jonathan Lennox; avtext@ietf.org > Subject: Re: [avtext] Fwd: draft response to SA4 liaison statement > > Hi, > > I have looked at the draft LS. I think we should provide constructive > feedback for what the AVTEXT participants see as shortcomings of the 3GPP > proposals. I think the main reason for considering to do IETF work on this > was that the proposal had shortcomings. > > I will note that 3GPP has already requested registration for their RTP > header extensions as well as the RTCP Feedback format. I am reviewer and > have had some feedback to them. They are likely to need to revise their > specification to fulfil this requirement. > > Therefore I think they can consider to address a larger set of feedbacks if > we can provide it. I personally don't see a need for an IETF specification > if the 3GPP one is sufficiently good. > > The primary issue I saw with the feedback format is that it is unclear if > the FCI format allows for multiple entries. > > However, I think there might be an issue with determining if a request is > being received and acted on. That is clearly one difference between the I-D > here in IETF and the 3GPP spec. > > Thus, I think we should gather such feedback and provide it. > > Cheers > > Magnus Westerlund > > ---------------------------------------------------------------------- > Services, Media and Network features, Ericsson Research EAB/TXM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > Färögatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- > > _______________________________________________ > avtext mailing list > avtext@ietf.org > https://www.ietf.org/mailman/listinfo/avtext > > -- Magnus Westerlund ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From nobody Thu Sep 10 07:11:14 2015 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB7F21B5509 for ; Thu, 10 Sep 2015 07:11:13 -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, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 byuWvcH80m4J for ; Thu, 10 Sep 2015 07:11:11 -0700 (PDT) Received: from mail-wi0-x22c.google.com (mail-wi0-x22c.google.com [IPv6:2a00:1450:400c:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3BDB01B67BF for ; Thu, 10 Sep 2015 07:11:11 -0700 (PDT) Received: by wicfx3 with SMTP id fx3so24796959wic.0 for ; Thu, 10 Sep 2015 07:11:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:content-transfer-encoding:thread-index :content-language; bh=PeDLahwuGL6ZTb3RJAcx/1glukk+Ew6ibO5OxmDe/vw=; b=FtH6Fq6T812b49znnZTYJBxO5bfguaK2XfXF9UVRENf0hYUI1X2lZkr6grU0CqIoAH bSA6cZBTa0W3R6PBwcktTWCZU7MxuK+kU/ekb7DwGxdrKKIETvPhFRHv+q+l3W0Hl4TZ kYb7Ml5dIaUXpUxvr8kZzr6L7I+aGWkPQM2YrWrqnYipLiubwkoUoQGrxofIfjw5UYOE dj0QAT1zkMb2jDdEnAEK/qIRafTHgWcilBQq162J0W76yg3w2vAMEZYMNd09mnSBxvxM 5mv+SpXAjjzitYequCU0GLeYue+9viMQaiODO9FzT3b3cYIAudAuuUTqZyv5Gh9EbDc8 Ke4Q== X-Received: by 10.194.121.232 with SMTP id ln8mr76190433wjb.76.1441894269612; Thu, 10 Sep 2015 07:11:09 -0700 (PDT) Received: from RoniPC (bzq-79-180-110-132.red.bezeqint.net. [79.180.110.132]) by smtp.gmail.com with ESMTPSA id i6sm15901028wje.33.2015.09.10.07.11.07 (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 10 Sep 2015 07:11:08 -0700 (PDT) From: "Roni Even" To: "'Magnus Westerlund'" , "'Jonathan Lennox'" , References: <01f401d0d4e6$52bd03f0$f8370bd0$@gmail.com> <55F03B9B.6020008@ericsson.com> <03a701d0eb20$b269e6b0$173db410$@gmail.com> <55F13B98.8060403@ericsson.com> In-Reply-To: <55F13B98.8060403@ericsson.com> Date: Thu, 10 Sep 2015 17:11:02 +0300 Message-ID: <043101d0ebd2$874bb690$95e323b0$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQESySJSqxJaA07eLxmAsmwS8cYwJgK/YrIDAdL764sCH8lXzgJrY/SBn2kk26A= Content-Language: he Archived-At: Subject: Re: [avtext] Fwd: draft response to SA4 liaison statement X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Sep 2015 14:11:14 -0000 Hi, Thanks Magnus, so the question about the Liaison will be if it should = have all these concerns. I do not think that this should be as comments to = the IANA registration request. On the other hand I am not sure what it will help by having the = particular concerns in the response to the liaison from 3GPP since they did not ask = for comments on their document and it is not clear that they will act on it. Roni -----Original Message----- From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com]=20 Sent: Thursday, September 10, 2015 11:13 AM To: Roni Even; 'Jonathan Lennox'; avtext@ietf.org Subject: Re: [avtext] Fwd: draft response to SA4 liaison statement Den 2015-09-09 kl. 18:58, skrev Roni Even: > Hi, > My understanding was that the authors of the IETF document were asked=20 > to go to 3GPP and present their concerns over there. Since the authors = > do not attend 3GPP meeting and they have concerns with the proposed=20 > solution, I believe that this is what we can currently say. > If you think we should raise our concerns I can point at the three=20 > major ones. > > 1. It is not clear what is the "original content ". Is it the first=20 > image that was sent, how does it work for multipoint? We think that=20 > the request can relate to the current content as the reference for the request. Yes, this is thorny and I think you will need to expand on this. It = clearly need to work with switched sources, such as the ones in an RTP mixer performing source switching. I think one can also raise the issue = between original capture and what is being encoded, as scaling prior to encoding = for bit-rate adaptation and simulcast usage makes things more interesting. = As the coordinates in pixel in these cases for a particular region changes = upon the switch of resolution. > 2. The co-ordinates can be negative if you want to zoom out or move=20 > out of the displayed content (this also relates to the first issue of=20 > what is the original content) Given, that the coordinate system is in relation to the currently = received picture. But, I do note that attempting to use "current"=20 requires one to include some type of reference (RTP Timestamp), for what current is, due to the delay between the sender side and receiver. > 3. The definition of pre-defined is not clear depending on the=20 > definition of "original content". BTW: in H.281 the pre-defined are=20 > using a current view and provide an ID for it that can be used later=20 > to return to the same view Okay, this needs to be written up in an more complete argumentation. I also note that these type of issues do result in an highly likelihood = that an updated specification, independently if it is in 3GPP and IETF this specification is developed. Thus, we might be forced to raise the = warning that this might be the end result. Cheers Magnus Westerlund > > Roni Even > > -----Original Message----- > From: avtext [mailto:avtext-bounces@ietf.org] On Behalf Of Magnus=20 > Westerlund > Sent: Wednesday, September 09, 2015 5:01 PM > To: Jonathan Lennox; avtext@ietf.org > Subject: Re: [avtext] Fwd: draft response to SA4 liaison statement > > Hi, > > I have looked at the draft LS. I think we should provide constructive=20 > feedback for what the AVTEXT participants see as shortcomings of the=20 > 3GPP proposals. I think the main reason for considering to do IETF=20 > work on this was that the proposal had shortcomings. > > I will note that 3GPP has already requested registration for their RTP = > header extensions as well as the RTCP Feedback format. I am reviewer=20 > and have had some feedback to them. They are likely to need to revise=20 > their specification to fulfil this requirement. > > Therefore I think they can consider to address a larger set of=20 > feedbacks if we can provide it. I personally don't see a need for an=20 > IETF specification if the 3GPP one is sufficiently good. > > The primary issue I saw with the feedback format is that it is unclear = > if the FCI format allows for multiple entries. > > However, I think there might be an issue with determining if a request = > is being received and acted on. That is clearly one difference between = > the I-D here in IETF and the 3GPP spec. > > Thus, I think we should gather such feedback and provide it. > > Cheers > > Magnus Westerlund > > ---------------------------------------------------------------------- > Services, Media and Network features, Ericsson Research EAB/TXM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > F=E4r=F6gatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- > > _______________________________________________ > avtext mailing list > avtext@ietf.org > https://www.ietf.org/mailman/listinfo/avtext > > --=20 Magnus Westerlund ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 F=E4r=F6gatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From nobody Fri Sep 11 02:12:46 2015 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18C441B4511 for ; Fri, 11 Sep 2015 02:12:45 -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 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 CPbdgNk3SBW7 for ; Fri, 11 Sep 2015 02:12:43 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 541E31B450D for ; Fri, 11 Sep 2015 02:12:42 -0700 (PDT) X-AuditID: c1b4fb3a-f79136d0000071e2-3f-55f29b08d5fd Received: from ESESSHC010.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 50.17.29154.80B92F55; Fri, 11 Sep 2015 11:12:40 +0200 (CEST) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.50) with Microsoft SMTP Server id 14.3.248.2; Fri, 11 Sep 2015 11:12:39 +0200 To: Roni Even , 'Jonathan Lennox' , References: <01f401d0d4e6$52bd03f0$f8370bd0$@gmail.com> <55F03B9B.6020008@ericsson.com> <03a701d0eb20$b269e6b0$173db410$@gmail.com> <55F13B98.8060403@ericsson.com> <043101d0ebd2$874bb690$95e323b0$@gmail.com> From: Magnus Westerlund Message-ID: <55F29B07.8010102@ericsson.com> Date: Fri, 11 Sep 2015 11:12:39 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <043101d0ebd2$874bb690$95e323b0$@gmail.com> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrALMWRmVeSWpSXmKPExsUyM+JvjS7H7E+hBo/6VS0+3rvBarF/8Xlm i7/tzA7MHjtn3WX3WLLkJ5NH27M77AHMUVw2Kak5mWWpRfp2CVwZp58fYS84aVrRs/sCWwNj q3YXIweHhICJxLeprF2MnECmmMSFe+vZuhi5OIQEjjJKNBx6xQjhLGeU6HjZwwZSJSzgJPH4 1QcWEFtEIFli9p7NzBBFbUwS73/MYARJsAlYSNz80cgGsoFXQFti9q8YkDCLgKrEwtXX2UFs UYEYiZ5fG8Bm8goISpyc+QRsJidQ67zl7xlBWpkF7CUebC0DCTMLyEs0b53NDGILAU1saOpg ncAoMAtJ9yyEjllIOhYwMq9iFC1OLS7OTTcy0kstykwuLs7P08tLLdnECAzSg1t+W+1gPPjc 8RCjAAejEg/vAtNPoUKsiWXFlbmHGKU5WJTEeZuZHoQKCaQnlqRmp6YWpBbFF5XmpBYfYmTi 4JRqYGSxf2ZZNmP/mhamtzUGcQtnpR/d1Cdwq9+3ujHpe7LkITeGZc+W/y0wbLSZIhM2W+jy NB2HfblTviXWLHmzXnXG+Qs9aSVdrbfDL744/l8r/f2bmNjavMIlucYzd06JXp5uJTxZ/OMC zr2uOx/9+XVC+Xax6fGvNn+2b9G4+TR/Z//M5Cu5x7YosRRnJBpqMRcVJwIAwfYH5TMCAAA= Archived-At: Subject: Re: [avtext] Fwd: draft response to SA4 liaison statement X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Sep 2015 09:12:45 -0000 Hi, My point is that we appear to have some significant issues with what is currently specified in 3GPP. If AVTEXT would take on ROI work it is likely that these would result in a non-backwards compatible solution. That I think is highly relevant in regards to the ACTION part of the LS: "3GPP SA4 kindly requests IETF to take the information above into account, and maintain coordination with SA4 during the course of the development of draft-huang-avtext-feedback-image-control-00 toward ensuring the alignment between 3GPP and IETF specifications." This would affect alignment. Thus, I am of the opinion that we need to raise this issue at the start to avoid future issues around divergent expectations. I do need to note that SA4 have approved some changes to their specification, which can be seen here until they are integrated in the next version of their specification: http://www.3gpp.org/ftp/tsg_sa/WG4_CODEC/TSGS4_85/Docs/S4-151080.zip This do clarify at least parts of the issues raised. In regards to the IANA registrations, these changes do result that the RTP header extension requests can go forward. Cheers Magnus Westerlund Den 2015-09-10 kl. 16:11, skrev Roni Even: > Hi, > Thanks Magnus, so the question about the Liaison will be if it should have > all these concerns. I do not think that this should be as comments to the > IANA registration request. > On the other hand I am not sure what it will help by having the particular > concerns in the response to the liaison from 3GPP since they did not ask for > comments on their document and it is not clear that they will act on it. > > Roni > > -----Original Message----- > From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] > Sent: Thursday, September 10, 2015 11:13 AM > To: Roni Even; 'Jonathan Lennox'; avtext@ietf.org > Subject: Re: [avtext] Fwd: draft response to SA4 liaison statement > > Den 2015-09-09 kl. 18:58, skrev Roni Even: >> Hi, >> My understanding was that the authors of the IETF document were asked >> to go to 3GPP and present their concerns over there. Since the authors >> do not attend 3GPP meeting and they have concerns with the proposed >> solution, I believe that this is what we can currently say. >> If you think we should raise our concerns I can point at the three >> major ones. >> >> 1. It is not clear what is the "original content ". Is it the first >> image that was sent, how does it work for multipoint? We think that >> the request can relate to the current content as the reference for the > request. > > Yes, this is thorny and I think you will need to expand on this. It clearly > need to work with switched sources, such as the ones in an RTP mixer > performing source switching. I think one can also raise the issue between > original capture and what is being encoded, as scaling prior to encoding for > bit-rate adaptation and simulcast usage makes things more interesting. As > the coordinates in pixel in these cases for a particular region changes upon > the switch of resolution. > >> 2. The co-ordinates can be negative if you want to zoom out or move >> out of the displayed content (this also relates to the first issue of >> what is the original content) > > Given, that the coordinate system is in relation to the currently received > picture. But, I do note that attempting to use "current" > requires one to include some type of reference (RTP Timestamp), for what > current is, due to the delay between the sender side and receiver. > >> 3. The definition of pre-defined is not clear depending on the >> definition of "original content". BTW: in H.281 the pre-defined are >> using a current view and provide an ID for it that can be used later >> to return to the same view > > Okay, this needs to be written up in an more complete argumentation. > > I also note that these type of issues do result in an highly likelihood that > an updated specification, independently if it is in 3GPP and IETF this > specification is developed. Thus, we might be forced to raise the warning > that this might be the end result. > > Cheers > > Magnus Westerlund > >> >> Roni Even >> >> -----Original Message----- >> From: avtext [mailto:avtext-bounces@ietf.org] On Behalf Of Magnus >> Westerlund >> Sent: Wednesday, September 09, 2015 5:01 PM >> To: Jonathan Lennox; avtext@ietf.org >> Subject: Re: [avtext] Fwd: draft response to SA4 liaison statement >> >> Hi, >> >> I have looked at the draft LS. I think we should provide constructive >> feedback for what the AVTEXT participants see as shortcomings of the >> 3GPP proposals. I think the main reason for considering to do IETF >> work on this was that the proposal had shortcomings. >> >> I will note that 3GPP has already requested registration for their RTP >> header extensions as well as the RTCP Feedback format. I am reviewer >> and have had some feedback to them. They are likely to need to revise >> their specification to fulfil this requirement. >> >> Therefore I think they can consider to address a larger set of >> feedbacks if we can provide it. I personally don't see a need for an >> IETF specification if the 3GPP one is sufficiently good. >> >> The primary issue I saw with the feedback format is that it is unclear >> if the FCI format allows for multiple entries. >> >> However, I think there might be an issue with determining if a request >> is being received and acted on. That is clearly one difference between >> the I-D here in IETF and the 3GPP spec. >> >> Thus, I think we should gather such feedback and provide it. >> >> Cheers >> >> Magnus Westerlund >> >> ---------------------------------------------------------------------- >> Services, Media and Network features, Ericsson Research EAB/TXM >> ---------------------------------------------------------------------- >> Ericsson AB | Phone +46 10 7148287 >> Färögatan 6 | Mobile +46 73 0949079 >> SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com >> ---------------------------------------------------------------------- >> >> _______________________________________________ >> avtext mailing list >> avtext@ietf.org >> https://www.ietf.org/mailman/listinfo/avtext >> >> > > -- Magnus Westerlund ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From nobody Fri Sep 11 03:24:03 2015 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0488F1A9006 for ; Fri, 11 Sep 2015 03:24:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 Mg9UpTHKeDxd for ; Fri, 11 Sep 2015 03:24:00 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpgre-esg-01.alcatel-lucent.com [135.245.210.22]) (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 222F51B2CB1 for ; Fri, 11 Sep 2015 03:24:00 -0700 (PDT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (unknown [135.239.2.122]) by Websense Email Security Gateway with ESMTPS id 891C127BAA77A; Fri, 11 Sep 2015 10:23:56 +0000 (GMT) Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id t8BANuan001714 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 11 Sep 2015 12:23:58 +0200 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.167]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.03.0195.001; Fri, 11 Sep 2015 12:23:56 +0200 From: "DRAGE, Keith (Keith)" To: Magnus Westerlund , Roni Even , "'Jonathan Lennox'" , "avtext@ietf.org" Thread-Topic: [avtext] Fwd: draft response to SA4 liaison statement Thread-Index: AQHQ7HIJTL/iAq3zM0eGblD2PJXvZp43GvxA Date: Fri, 11 Sep 2015 10:23:55 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8BAC7A042E@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <01f401d0d4e6$52bd03f0$f8370bd0$@gmail.com> <55F03B9B.6020008@ericsson.com> <03a701d0eb20$b269e6b0$173db410$@gmail.com> <55F13B98.8060403@ericsson.com> <043101d0ebd2$874bb690$95e323b0$@gmail.com> <55F29B07.8010102@ericsson.com> In-Reply-To: <55F29B07.8010102@ericsson.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.41] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [avtext] Fwd: draft response to SA4 liaison statement X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Sep 2015 10:24:03 -0000 More fundamental, it is not clear to me whether AVTEXT intend themselves to= work on this subject because they see it as of general application, or whe= ther those interested are only interested in the context of an IMS media. T= he former should generate IETF documentation. For the latter, we only need = to ensure it in accordance with the RTP documentation and coding rules. >From listening to the audio stream remotely, I do not think this was really= discussed in Prague, and it does not seem to have been addressed on the ma= iling list. If we want a general solution documented by IETF, our response to IETF need= s to be very different to Roni's original response, and address the IETF do= cumentation needs and how we would intend to do that. For information, the 3GPP work is release 13, and the release 13 freeze dat= e is the end of this year. Regards Keith -----Original Message----- From: avtext [mailto:avtext-bounces@ietf.org] On Behalf Of Magnus Westerlun= d Sent: 11 September 2015 10:13 To: Roni Even; 'Jonathan Lennox'; avtext@ietf.org Subject: Re: [avtext] Fwd: draft response to SA4 liaison statement Hi, My point is that we appear to have some significant issues with what is cur= rently specified in 3GPP. If AVTEXT would take on ROI work it is likely tha= t these would result in a non-backwards compatible solution.=20 That I think is highly relevant in regards to the ACTION part of the LS: "3GPP SA4 kindly requests IETF to take the information above into account, = and maintain coordination with SA4 during the course of the development of = draft-huang-avtext-feedback-image-control-00 toward ensuring the alignment = between 3GPP and IETF specifications." This would affect alignment. Thus, I am of the opinion that we need to rais= e this issue at the start to avoid future issues around divergent expectati= ons. I do need to note that SA4 have approved some changes to their specificatio= n, which can be seen here until they are integrated in the next version of = their specification: http://www.3gpp.org/ftp/tsg_sa/WG4_CODEC/TSGS4_85/Docs/S4-151080.zip This do clarify at least parts of the issues raised. In regards to the IANA registrations, these changes do result that the RTP = header extension requests can go forward. Cheers Magnus Westerlund Den 2015-09-10 kl. 16:11, skrev Roni Even: > Hi, > Thanks Magnus, so the question about the Liaison will be if it should=20 > have all these concerns. I do not think that this should be as=20 > comments to the IANA registration request. > On the other hand I am not sure what it will help by having the=20 > particular concerns in the response to the liaison from 3GPP since=20 > they did not ask for comments on their document and it is not clear that = they will act on it. > > Roni > > -----Original Message----- > From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] > Sent: Thursday, September 10, 2015 11:13 AM > To: Roni Even; 'Jonathan Lennox'; avtext@ietf.org > Subject: Re: [avtext] Fwd: draft response to SA4 liaison statement > > Den 2015-09-09 kl. 18:58, skrev Roni Even: >> Hi, >> My understanding was that the authors of the IETF document were asked=20 >> to go to 3GPP and present their concerns over there. Since the=20 >> authors do not attend 3GPP meeting and they have concerns with the=20 >> proposed solution, I believe that this is what we can currently say. >> If you think we should raise our concerns I can point at the three=20 >> major ones. >> >> 1. It is not clear what is the "original content ". Is it the first=20 >> image that was sent, how does it work for multipoint? We think that=20 >> the request can relate to the current content as the reference for=20 >> the > request. > > Yes, this is thorny and I think you will need to expand on this. It=20 > clearly need to work with switched sources, such as the ones in an RTP=20 > mixer performing source switching. I think one can also raise the=20 > issue between original capture and what is being encoded, as scaling=20 > prior to encoding for bit-rate adaptation and simulcast usage makes=20 > things more interesting. As the coordinates in pixel in these cases=20 > for a particular region changes upon the switch of resolution. > >> 2. The co-ordinates can be negative if you want to zoom out or move=20 >> out of the displayed content (this also relates to the first issue of=20 >> what is the original content) > > Given, that the coordinate system is in relation to the currently=20 > received picture. But, I do note that attempting to use "current" > requires one to include some type of reference (RTP Timestamp), for=20 > what current is, due to the delay between the sender side and receiver. > >> 3. The definition of pre-defined is not clear depending on the=20 >> definition of "original content". BTW: in H.281 the pre-defined are=20 >> using a current view and provide an ID for it that can be used later=20 >> to return to the same view > > Okay, this needs to be written up in an more complete argumentation. > > I also note that these type of issues do result in an highly=20 > likelihood that an updated specification, independently if it is in=20 > 3GPP and IETF this specification is developed. Thus, we might be=20 > forced to raise the warning that this might be the end result. > > Cheers > > Magnus Westerlund > >> >> Roni Even >> >> -----Original Message----- >> From: avtext [mailto:avtext-bounces@ietf.org] On Behalf Of Magnus=20 >> Westerlund >> Sent: Wednesday, September 09, 2015 5:01 PM >> To: Jonathan Lennox; avtext@ietf.org >> Subject: Re: [avtext] Fwd: draft response to SA4 liaison statement >> >> Hi, >> >> I have looked at the draft LS. I think we should provide constructive=20 >> feedback for what the AVTEXT participants see as shortcomings of the=20 >> 3GPP proposals. I think the main reason for considering to do IETF=20 >> work on this was that the proposal had shortcomings. >> >> I will note that 3GPP has already requested registration for their=20 >> RTP header extensions as well as the RTCP Feedback format. I am=20 >> reviewer and have had some feedback to them. They are likely to need=20 >> to revise their specification to fulfil this requirement. >> >> Therefore I think they can consider to address a larger set of=20 >> feedbacks if we can provide it. I personally don't see a need for an=20 >> IETF specification if the 3GPP one is sufficiently good. >> >> The primary issue I saw with the feedback format is that it is=20 >> unclear if the FCI format allows for multiple entries. >> >> However, I think there might be an issue with determining if a=20 >> request is being received and acted on. That is clearly one=20 >> difference between the I-D here in IETF and the 3GPP spec. >> >> Thus, I think we should gather such feedback and provide it. >> >> Cheers >> >> Magnus Westerlund >> >> --------------------------------------------------------------------- >> - Services, Media and Network features, Ericsson Research EAB/TXM >> ---------------------------------------------------------------------- >> Ericsson AB | Phone +46 10 7148287 >> F=E4r=F6gatan 6 | Mobile +46 73 0949079 >> SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com >> --------------------------------------------------------------------- >> - >> >> _______________________________________________ >> avtext mailing list >> avtext@ietf.org >> https://www.ietf.org/mailman/listinfo/avtext >> >> > > --=20 Magnus Westerlund ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 F=E4r=F6gatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- _______________________________________________ avtext mailing list avtext@ietf.org https://www.ietf.org/mailman/listinfo/avtext From nobody Fri Sep 11 06:47:38 2015 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7A291A6FDD for ; Fri, 11 Sep 2015 06:47:35 -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, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 S26jggsGYNk6 for ; Fri, 11 Sep 2015 06:47:33 -0700 (PDT) Received: from mail-wi0-x22a.google.com (mail-wi0-x22a.google.com [IPv6:2a00:1450:400c:c05::22a]) (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 E59871ACC88 for ; Fri, 11 Sep 2015 06:47:30 -0700 (PDT) Received: by wiclk2 with SMTP id lk2so65212908wic.0 for ; Fri, 11 Sep 2015 06:47:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:content-transfer-encoding:thread-index :content-language; bh=v9kx4TQ9TACdKmwOTQ5DMgWBO0g7G3S+d8vSEH8U1Wk=; b=v7XpeckhZGUK/csu97SqkAigTZIXAQVvFBMN8hPPJvLt/P/xshfF7Xr4bTsmJYZQji elYR+8jxW1UxOL3LarcQJQH3UWV/4IQcm2AuaVbCU8cnVPM9Z1sINkiAKnHDp4xtyLLo iQlWT3/vUr7joP5PYumiTnNBBXeYbLy910091EhnWp4yKKmDPzIGaCSZrlgnqtP/QJ13 jP3OleIaLP23ZnQM6R37a3KE+XvQ8fExo/+2OBYosSd1GY88HDT0GZPfESoX8EOgGXk1 BmTk9I1iuZIRPwhIRdmY6lpponmmHQS6R5PIYWxwYWm91MPdqaZEcI2DdcmgZP+6CjoW N2pA== X-Received: by 10.194.121.131 with SMTP id lk3mr79423060wjb.77.1441979249503; Fri, 11 Sep 2015 06:47:29 -0700 (PDT) Received: from RoniPC (bzq-79-180-110-132.red.bezeqint.net. [79.180.110.132]) by smtp.gmail.com with ESMTPSA id h9sm480728wjx.20.2015.09.11.06.47.27 (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 11 Sep 2015 06:47:28 -0700 (PDT) From: "Roni Even" To: "'Magnus Westerlund'" , "'Jonathan Lennox'" , References: <01f401d0d4e6$52bd03f0$f8370bd0$@gmail.com> <55F03B9B.6020008@ericsson.com> <03a701d0eb20$b269e6b0$173db410$@gmail.com> <55F13B98.8060403@ericsson.com> <043101d0ebd2$874bb690$95e323b0$@gmail.com> <55F29B07.8010102@ericsson.com> In-Reply-To: <55F29B07.8010102@ericsson.com> Date: Fri, 11 Sep 2015 16:47:21 +0300 Message-ID: <04cf01d0ec98$62e9d4a0$28bd7de0$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQESySJSqxJaA07eLxmAsmwS8cYwJgK/YrIDAdL764sCH8lXzgJrY/SBAXYFMjcBvXxZiZ9REo0g Content-Language: he Archived-At: Subject: Re: [avtext] Fwd: draft response to SA4 liaison statement X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Sep 2015 13:47:35 -0000 Hi Magnus, I looked at the changes and I am not sure they clarify the issues.=20 For example : Position_X - specifies the x-coordinate for the upper left corner of the ROI area covered in the original content (i.e., = uncompressed captured content) in units of pixels - this is still not clear. Two = points: 1. Uncompressed capture content - is not clear, it does not say at which zoom the camera was using for the uncompressed and when it was taken 2. In this case the units should not be pixels but arbitrary = co-ordinates - I think that comment was made by Randell Jesup in Prague. I think that one of the major issues is that the design does not look at = the way ROI application will work which in my view may typically be based on = the video receiver select an area of interest on the current screen or use = the mouse to drag the image (left right, up, down) and ask for refresh for = pan for example, so it will be better to base the request on a current view (maybe using RTP time stamp) instead to some "original content". =20 Roni -----Original Message----- From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com]=20 Sent: Friday, September 11, 2015 12:13 PM To: Roni Even; 'Jonathan Lennox'; avtext@ietf.org Subject: Re: [avtext] Fwd: draft response to SA4 liaison statement Hi, My point is that we appear to have some significant issues with what is currently specified in 3GPP. If AVTEXT would take on ROI work it is = likely that these would result in a non-backwards compatible solution.=20 That I think is highly relevant in regards to the ACTION part of the LS: "3GPP SA4 kindly requests IETF to take the information above into = account, and maintain coordination with SA4 during the course of the development = of draft-huang-avtext-feedback-image-control-00 toward ensuring the = alignment between 3GPP and IETF specifications." This would affect alignment. Thus, I am of the opinion that we need to = raise this issue at the start to avoid future issues around divergent expectations. I do need to note that SA4 have approved some changes to their specification, which can be seen here until they are integrated in the = next version of their specification: http://www.3gpp.org/ftp/tsg_sa/WG4_CODEC/TSGS4_85/Docs/S4-151080.zip This do clarify at least parts of the issues raised. In regards to the IANA registrations, these changes do result that the = RTP header extension requests can go forward. Cheers Magnus Westerlund Den 2015-09-10 kl. 16:11, skrev Roni Even: > Hi, > Thanks Magnus, so the question about the Liaison will be if it should=20 > have all these concerns. I do not think that this should be as=20 > comments to the IANA registration request. > On the other hand I am not sure what it will help by having the=20 > particular concerns in the response to the liaison from 3GPP since=20 > they did not ask for comments on their document and it is not clear = that they will act on it. > > Roni > > -----Original Message----- > From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] > Sent: Thursday, September 10, 2015 11:13 AM > To: Roni Even; 'Jonathan Lennox'; avtext@ietf.org > Subject: Re: [avtext] Fwd: draft response to SA4 liaison statement > > Den 2015-09-09 kl. 18:58, skrev Roni Even: >> Hi, >> My understanding was that the authors of the IETF document were asked = >> to go to 3GPP and present their concerns over there. Since the=20 >> authors do not attend 3GPP meeting and they have concerns with the=20 >> proposed solution, I believe that this is what we can currently say. >> If you think we should raise our concerns I can point at the three=20 >> major ones. >> >> 1. It is not clear what is the "original content ". Is it the first=20 >> image that was sent, how does it work for multipoint? We think that=20 >> the request can relate to the current content as the reference for=20 >> the > request. > > Yes, this is thorny and I think you will need to expand on this. It=20 > clearly need to work with switched sources, such as the ones in an RTP = > mixer performing source switching. I think one can also raise the=20 > issue between original capture and what is being encoded, as scaling=20 > prior to encoding for bit-rate adaptation and simulcast usage makes=20 > things more interesting. As the coordinates in pixel in these cases=20 > for a particular region changes upon the switch of resolution. > >> 2. The co-ordinates can be negative if you want to zoom out or move=20 >> out of the displayed content (this also relates to the first issue of = >> what is the original content) > > Given, that the coordinate system is in relation to the currently=20 > received picture. But, I do note that attempting to use "current" > requires one to include some type of reference (RTP Timestamp), for=20 > what current is, due to the delay between the sender side and = receiver. > >> 3. The definition of pre-defined is not clear depending on the=20 >> definition of "original content". BTW: in H.281 the pre-defined are=20 >> using a current view and provide an ID for it that can be used later=20 >> to return to the same view > > Okay, this needs to be written up in an more complete argumentation. > > I also note that these type of issues do result in an highly=20 > likelihood that an updated specification, independently if it is in=20 > 3GPP and IETF this specification is developed. Thus, we might be=20 > forced to raise the warning that this might be the end result. > > Cheers > > Magnus Westerlund > >> >> Roni Even >> >> -----Original Message----- >> From: avtext [mailto:avtext-bounces@ietf.org] On Behalf Of Magnus=20 >> Westerlund >> Sent: Wednesday, September 09, 2015 5:01 PM >> To: Jonathan Lennox; avtext@ietf.org >> Subject: Re: [avtext] Fwd: draft response to SA4 liaison statement >> >> Hi, >> >> I have looked at the draft LS. I think we should provide constructive = >> feedback for what the AVTEXT participants see as shortcomings of the=20 >> 3GPP proposals. I think the main reason for considering to do IETF=20 >> work on this was that the proposal had shortcomings. >> >> I will note that 3GPP has already requested registration for their=20 >> RTP header extensions as well as the RTCP Feedback format. I am=20 >> reviewer and have had some feedback to them. They are likely to need=20 >> to revise their specification to fulfil this requirement. >> >> Therefore I think they can consider to address a larger set of=20 >> feedbacks if we can provide it. I personally don't see a need for an=20 >> IETF specification if the 3GPP one is sufficiently good. >> >> The primary issue I saw with the feedback format is that it is=20 >> unclear if the FCI format allows for multiple entries. >> >> However, I think there might be an issue with determining if a=20 >> request is being received and acted on. That is clearly one=20 >> difference between the I-D here in IETF and the 3GPP spec. >> >> Thus, I think we should gather such feedback and provide it. >> >> Cheers >> >> Magnus Westerlund >> >> --------------------------------------------------------------------- >> - Services, Media and Network features, Ericsson Research EAB/TXM >> = ---------------------------------------------------------------------- >> Ericsson AB | Phone +46 10 7148287 >> F=E4r=F6gatan 6 | Mobile +46 73 0949079 >> SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com >> --------------------------------------------------------------------- >> - >> >> _______________________________________________ >> avtext mailing list >> avtext@ietf.org >> https://www.ietf.org/mailman/listinfo/avtext >> >> > > --=20 Magnus Westerlund ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 F=E4r=F6gatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From nobody Fri Sep 11 06:50:58 2015 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 207221B4BDC; Fri, 11 Sep 2015 06:50:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 JWhktcg_TFMd; Fri, 11 Sep 2015 06:50:55 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D43F91B3A0D; Fri, 11 Sep 2015 06:50:55 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.4.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150911135055.14346.74865.idtracker@ietfa.amsl.com> Date: Fri, 11 Sep 2015 06:50:55 -0700 Archived-At: Cc: avtext@ietf.org Subject: [avtext] I-D Action: draft-ietf-avtext-rtp-stream-pause-10.txt X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.15 List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Sep 2015 13:50:57 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Extensions Working Group of the IETF. Title : RTP Stream Pause and Resume Authors : Bo Burman Azam Akram Roni Even Magnus Westerlund Filename : draft-ietf-avtext-rtp-stream-pause-10.txt Pages : 60 Date : 2015-09-11 Abstract: With the increased popularity of real-time multimedia applications, it is desirable to provide good control of resource usage, and users also demand more control over communication sessions. This document describes how a receiver in a multimedia conversation can pause and resume incoming data from a sender by sending real-time feedback messages when using Real-time Transport Protocol (RTP) for real time data transport. This document extends the Codec Control Messages (CCM) RTP Control Protocol (RTCP) feedback package by explicitly allowing and describing specific use of existing CCM messages and adding a group of new real-time feedback messages used to pause and resume RTP data streams. This document updates RFC 5104. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-avtext-rtp-stream-pause/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-avtext-rtp-stream-pause-10 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-avtext-rtp-stream-pause-10 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 Sep 11 06:56:47 2015 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91A841B4C4D for ; Fri, 11 Sep 2015 06:56:45 -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 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 BFqNcjs6ir69 for ; Fri, 11 Sep 2015 06:56:43 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8763F1B4C4E for ; Fri, 11 Sep 2015 06:56:42 -0700 (PDT) X-AuditID: c1b4fb3a-f79136d0000071e2-b3-55f2dd9824c5 Received: from ESESSHC001.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id C9.B5.29154.89DD2F55; Fri, 11 Sep 2015 15:56:40 +0200 (CEST) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.23) with Microsoft SMTP Server id 14.3.248.2; Fri, 11 Sep 2015 15:56:39 +0200 To: References: <20150911135055.14346.74865.idtracker@ietfa.amsl.com> From: Magnus Westerlund Message-ID: <55F2DD98.1010201@ericsson.com> Date: Fri, 11 Sep 2015 15:56:40 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <20150911135055.14346.74865.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFuplluLIzCtJLcpLzFFi42KZGfG3RnfG3U+hBj2nFSw+3rvB6sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujAtvj7MVLBWr2H3LuoFxmmAXIyeHhICJxM07h9kgbDGJC/fW A9lcHEICRxklGte8Z4RwljNKrDoxFaxKWMBb4vjBPYwgtoiAqMT13efYQWwhAUeJRbeOs4LY bAIWEjd/NILV8wpoSyxu7mUBsVkEVCX2r/0JVi8qECPR82sDVI2gxMmZT8BqOAWcJB6vvQ80 n4ODWcBe4sHWMpAws4C8RPPW2cwQq7QlGpo6WCcwCsxC0j0LoWMWko4FjMyrGEWLU4uLc9ON jPRSizKTi4vz8/TyUks2MQLD7+CW31Y7GA8+dzzEKMDBqMTDu8D0U6gQa2JZcWXuIUZpDhYl cd5mpgehQgLpiSWp2ampBalF8UWlOanFhxiZODilGhgD/Y/XuHlw3NhVEVl/tlzk+mvPvzUM /MvkvfU7ll3+N7V/dWdo8RuOd985itdbtc37ot239Irnkhsc0Rdybuhrn0j1ndqyjfnW7avR liaLHuadXx3as53TNuJ2S7P7Lv/neieZq0y/nKsKtWo8JvpKbMHa5TuOifst5kk6yLe1e4Np 6JGlvwuVWIozEg21mIuKEwGZxc1CIAIAAA== Archived-At: Subject: Re: [avtext] I-D Action: draft-ietf-avtext-rtp-stream-pause-10.txt X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Sep 2015 13:56:45 -0000 WG, This is a very minor update to resolve some editorial improvements on the new text added in the security consideration. Cheers Magnus Den 2015-09-11 kl. 15:50, skrev internet-drafts@ietf.org: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Audio/Video Transport Extensions Working Group of the IETF. > > Title : RTP Stream Pause and Resume > Authors : Bo Burman > Azam Akram > Roni Even > Magnus Westerlund > Filename : draft-ietf-avtext-rtp-stream-pause-10.txt > Pages : 60 > Date : 2015-09-11 > > Abstract: > With the increased popularity of real-time multimedia applications, > it is desirable to provide good control of resource usage, and users > also demand more control over communication sessions. This document > describes how a receiver in a multimedia conversation can pause and > resume incoming data from a sender by sending real-time feedback > messages when using Real-time Transport Protocol (RTP) for real time > data transport. This document extends the Codec Control Messages > (CCM) RTP Control Protocol (RTCP) feedback package by explicitly > allowing and describing specific use of existing CCM messages and > adding a group of new real-time feedback messages used to pause and > resume RTP data streams. This document updates RFC 5104. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-avtext-rtp-stream-pause/ > > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-avtext-rtp-stream-pause-10 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-avtext-rtp-stream-pause-10 > > > 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/ > > _______________________________________________ > avtext mailing list > avtext@ietf.org > https://www.ietf.org/mailman/listinfo/avtext > -- Magnus Westerlund ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From nobody Fri Sep 11 07:06:12 2015 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A40F91A1B4A; Fri, 11 Sep 2015 07:06:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 TDNkD9jwymZN; Fri, 11 Sep 2015 07:06:04 -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 0B11D1B4CDA; Fri, 11 Sep 2015 07:06:03 -0700 (PDT) Received: from [10.0.1.23] (cpe-70-119-203-4.tx.res.rr.com [70.119.203.4]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id t8BE5qGk046124 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Fri, 11 Sep 2015 09:06:03 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-70-119-203-4.tx.res.rr.com [70.119.203.4] claimed to be [10.0.1.23] From: "Ben Campbell" To: IESG Date: Fri, 11 Sep 2015 09:05:52 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.2r5107) Archived-At: Cc: draft-ietf-avtext-rtp-stream-pause@ietf.org, avtext@ietf.org, avtext-chairs@ietf.org Subject: [avtext] Approved: draft-ietf-avtext-rtp-stream-pause-10 X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Sep 2015 14:06:09 -0000 Hi IESG Secretary, draft-ietf-avtext-rtp-stream-pause-10 is approved. There are no RFC Editor notes. Thanks! Ben. From nobody Fri Sep 11 07:19:03 2015 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4DEA1ACE5B; Fri, 11 Sep 2015 07:19:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham 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 CLtUY5-_Ctvx; Fri, 11 Sep 2015 07:18:59 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E39891B356A; Fri, 11 Sep 2015 07:18:56 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.4.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150911141856.26062.16048.idtracker@ietfa.amsl.com> Date: Fri, 11 Sep 2015 07:18:56 -0700 Archived-At: Cc: avtext chair , avtext mailing list , RFC Editor Subject: [avtext] Protocol Action: 'RTP Stream Pause and Resume' to Proposed Standard (draft-ietf-avtext-rtp-stream-pause-10.txt) X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.15 List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Sep 2015 14:19:01 -0000 The IESG has approved the following document: - 'RTP Stream Pause and Resume' (draft-ietf-avtext-rtp-stream-pause-10.txt) as Proposed Standard This document is the product of the Audio/Video Transport Extensions Working Group. The IESG contact persons are Barry Leiba, Ben Campbell and Alissa Cooper. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-avtext-rtp-stream-pause/ Technical Summary This document provides a mechanism to use existing RTCP Feedback Codec Control Messages (RFC 5104), as well as a group of new messages, to pause and resume RTP media streams. The document defines two separate mechanism for pausing and resuming RTP streams. One mechanism codifies existing practice of how to use RFC 5104 messages to pause and resume streams, but is only applicable to a subset of possible RTP topologies. The other is a new mechanism and is generally applicable. Guidance is provided as to when one or the other mechanism should be used. Working Group Summary The two protocol mechanisms were the result of two separate proposals as to how to solve the requirement; once the proposals were merged into a single document, there were no objections to WG consensus. Document Quality There are existing deployed implementations of the RFC 5104-based mechanisms to pause and resume RTP streams. Paul Kyzivat performed an SDP directorate review. The review expressed concerns about the complexity of configuration. The WG had already considered the suggested alternatives and selected the documented method. The authors added additional text discussing the interoperability considerations of the various supported configurations. Personnel The Document Shepherd is Jonathan Lennox; the Responsible Area Director is Ben Campbell. From nobody Tue Sep 15 08:07:36 2015 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D99F31B3D76 for ; Tue, 15 Sep 2015 08:07:35 -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 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 c18G1p8ZU9uq for ; Tue, 15 Sep 2015 08:07:29 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5EDAD1B4FF3 for ; Tue, 15 Sep 2015 08:07:27 -0700 (PDT) X-AuditID: c1b4fb2d-f79626d000004282-94-55f8342d5131 Received: from ESESSHC019.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id A2.13.17026.D2438F55; Tue, 15 Sep 2015 17:07:25 +0200 (CEST) Received: from ESESSMB105.ericsson.se ([169.254.5.35]) by ESESSHC019.ericsson.se ([153.88.183.75]) with mapi id 14.03.0248.002; Tue, 15 Sep 2015 17:07:25 +0200 From: Bo Burman To: Roni Even , Magnus Westerlund , 'Jonathan Lennox' , "avtext@ietf.org" Thread-Topic: [avtext] Fwd: draft response to SA4 liaison statement Thread-Index: AdDU5hnPZpnbT5wDRCi9ydKVbqRU8AWERb6AAAYvPwAAH/XuAAAMf0gAACfe2YAACZgCgADM4WDw Date: Tue, 15 Sep 2015 15:07:24 +0000 Message-ID: References: <01f401d0d4e6$52bd03f0$f8370bd0$@gmail.com> <55F03B9B.6020008@ericsson.com> <03a701d0eb20$b269e6b0$173db410$@gmail.com> <55F13B98.8060403@ericsson.com> <043101d0ebd2$874bb690$95e323b0$@gmail.com> <55F29B07.8010102@ericsson.com> <04cf01d0ec98$62e9d4a0$28bd7de0$@gmail.com> In-Reply-To: <04cf01d0ec98$62e9d4a0$28bd7de0$@gmail.com> Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.18] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrBLMWRmVeSWpSXmKPExsUyM+Jvja6uyY9Qg48X1S0+3rvBarF/8Xlm i7/tzA7MHjtn3WX3WLLkJ5NH27M77AHMUVw2Kak5mWWpRfp2CVwZF+Y3sBW8S6849+wEawNj c3AXIyeHhICJxLaJO5ghbDGJC/fWs4HYQgJHGSUe7jToYuQCshczShzuOACWYBPQkJi/4y4j SEJEYDWjxNHn89i7GDk4hAWcJB5sVwMxRQScJSb+EIMwoySefDQD6WQRUJW4caqPESTMK+Ar sWa+L8T0K0wSj1sOMYHUcApYSPyZu4cRxGYUkJW4//0eC4jNLCAucevJfCaIMwUkluw5D3Wy qMTLx/9YIWxFiY+v9jFC1OtJ3Jg6hQ3C1pZYtvA1WD2vgKDEyZlPWCYwis5CMnYWkpZZSFpm IWlZwMiyilG0OLW4ODfdyFgvtSgzubg4P08vL7VkEyMwag5u+a27g3H1a8dDjAIcjEo8vA82 fw8VYk0sK67MPcQozcGiJM7bwvQgVEggPbEkNTs1tSC1KL6oNCe1+BAjEwenVAPjnGOyRuKz 434fip9XtG6uj4m+3/X5Upq/2A/mlvxc/9Xu8uxn6ye2elw7HZD458jRVn5PrzjPjlmNeuXz FpUcX2fRZMel3zzLoNdbs8/Ay/r/inPZErL81YY1he3pt5PEdniteLN5ztqQHfsWJMeU/32/ KPXyKvuw9csCru7ZI+h8Qc3zE3ezEktxRqKhFnNRcSIAVRCXIXsCAAA= Archived-At: Subject: Re: [avtext] Fwd: draft response to SA4 liaison statement X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Sep 2015 15:07:36 -0000 Roni, Magnus, I agree that there are likely flaws and/or incompleteness in the ROI specif= ication in 3GPP. I would however expect that 3GPP welcomes constructive fee= dback from IETF. I think neither IETF nor 3GPP will benefit from having con= flicting ROI specifications. Please find my comments inline below (including comments to Roni's original= list of issues). Cheers, Bo > -----Original Message----- > From: avtext [mailto:avtext-bounces@ietf.org] On Behalf Of Roni Even > Sent: den 11 september 2015 15:47 > To: Magnus Westerlund; 'Jonathan Lennox'; avtext@ietf.org > Subject: Re: [avtext] Fwd: draft response to SA4 liaison statement >=20 > Hi Magnus, > I looked at the changes and I am not sure they clarify the issues. > For example : Position_X - specifies the x-coordinate for the upper left = corner of the ROI area covered in the original > content (i.e., uncompressed captured content) in units of pixels - this i= s still not clear. Two points: > 1. Uncompressed capture content - is not clear, it does not say at which = zoom the camera was using for the > uncompressed and when it was taken=20 [BoB] I don't think there is any issue here. The latest agreed update in th= e document Magnus provided a link to includes the following statement: "The SDP offer with a=3Dpredefined_ROI parameter shall contain the full-siz= e view of the video indicated via ROI_ID=3D0." That is, ID 0 always provides the frame of reference by providing a fully = zoomed-out view of the area referred by other ROI definitions. Note that this is only applicable to the pre-defined ROI mode, where the vi= deo receiver chooses a pre-defined area by name, not by coordinates. It is = the video sender that provides the coordinates of the pre-defined areas, no= t the video receiver. That is fully clear from the existing 3GPP text. 2. In this case the units should not be pixels but arbitrary co-ordinates -= I think that > comment was made by Randell Jesup in Prague. [BoB] Since the frame of reference is always provided, it does not matter w= hat units are used, and can coordinates very well be considered to be "arbi= trary co-ordinates". >=20 > I think that one of the major issues is that the design does not look at = the way ROI application will work which in my view > may typically be based on the video receiver select an area of interest = on the current screen or use the mouse to drag > the image (left right, up, down) and ask for refresh for pan for example,= so it will be better to base the request on a > current view (maybe using RTP time stamp) instead to some "original conte= nt". [BoB] I don't understand that objection. The "Arbitrary ROI" mode describes= exactly, or at least something very similar to that mode of operation. It = makes use of a new rtcp-fb format ("3gpp-roi-arbitrary") allowing the video= receiver to request a selected area of the video to be sent, in conjunctio= n with an RTP Header Extension ("urn:3gpp:roi-sent") from the video sender = describing what area that is currently included in the RTP payload. The coo= rdinates in both the request and the announcement express upper left corner= and a size, and I don't understand "original content" to be directly relat= ed to any fixed reference frame. Instead, the video receiver is expected to= look at what is region is actually sent in the RTP HE and construct the RT= CP feedback from that. Zooming out would simply involve increasing the size= values in the RTCP feedback. I expect that 16 bits per size component is p= lenty in that aspect. Panning involves moving the upper left corner referen= ce in the request compared to what is received in the RTP HE. >=20 >=20 > Roni >=20 > -----Original Message----- > From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] > Sent: Friday, September 11, 2015 12:13 PM > To: Roni Even; 'Jonathan Lennox'; avtext@ietf.org > Subject: Re: [avtext] Fwd: draft response to SA4 liaison statement >=20 > Hi, >=20 > My point is that we appear to have some significant issues with what is c= urrently specified in 3GPP. If AVTEXT would take > on ROI work it is likely that these would result in a non-backwards compa= tible solution. > That I think is highly relevant in regards to the ACTION part of the LS: >=20 > "3GPP SA4 kindly requests IETF to take the information above into account= , and maintain coordination with SA4 during > the course of the development of > draft-huang-avtext-feedback-image-control-00 toward ensuring the alignmen= t between 3GPP and IETF specifications." >=20 > This would affect alignment. Thus, I am of the opinion that we need to ra= ise this issue at the start to avoid future issues > around divergent expectations. >=20 > I do need to note that SA4 have approved some changes to their specificat= ion, which can be seen here until they are > integrated in the next version of their specification: >=20 > http://www.3gpp.org/ftp/tsg_sa/WG4_CODEC/TSGS4_85/Docs/S4-151080.zip >=20 > This do clarify at least parts of the issues raised. >=20 > In regards to the IANA registrations, these changes do result that the RT= P header extension requests can go forward. >=20 > Cheers >=20 > Magnus Westerlund >=20 >=20 > Den 2015-09-10 kl. 16:11, skrev Roni Even: > > Hi, > > Thanks Magnus, so the question about the Liaison will be if it should > > have all these concerns. I do not think that this should be as > > comments to the IANA registration request. > > On the other hand I am not sure what it will help by having the > > particular concerns in the response to the liaison from 3GPP since > > they did not ask for comments on their document and it is not clear > > that > they will act on it. [BoB] I do think that 3GPP will act on constructive feedback. > > > > Roni > > > > -----Original Message----- > > From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] > > Sent: Thursday, September 10, 2015 11:13 AM > > To: Roni Even; 'Jonathan Lennox'; avtext@ietf.org > > Subject: Re: [avtext] Fwd: draft response to SA4 liaison statement > > > > Den 2015-09-09 kl. 18:58, skrev Roni Even: > >> Hi, > >> My understanding was that the authors of the IETF document were asked > >> to go to 3GPP and present their concerns over there. Since the > >> authors do not attend 3GPP meeting and they have concerns with the > >> proposed solution, I believe that this is what we can currently say. > >> If you think we should raise our concerns I can point at the three > >> major ones. > >> > >> 1. It is not clear what is the "original content ". Is it the first > >> image that was sent, how does it work for multipoint? We think that > >> the request can relate to the current content as the reference for > >> the > > request. > > > > Yes, this is thorny and I think you will need to expand on this. It > > clearly need to work with switched sources, such as the ones in an RTP > > mixer performing source switching. I think one can also raise the > > issue between original capture and what is being encoded, as scaling > > prior to encoding for bit-rate adaptation and simulcast usage makes > > things more interesting. As the coordinates in pixel in these cases > > for a particular region changes upon the switch of resolution. [BoB] See my comments above. "Original content" basically apply only to pre= -defined ROI, in which case the "full" reference frame is given by the pre-= defined ID 0. I do agree that the 3GPP text lacks considerations related to= ROI use in conferencing situations, but lack of explicit descriptions rela= ted to conferencing / multiparty situations is true for that entire specifi= cation (not only the ROI part). I think you must read and understand the cu= rrent text as basically applicable only for point-to-point. I believe parts= of Magnus' concerns are handled by relating the RTCP FB request to what is= actually sent, which can be learnt through the RTP HE. It however seems to= me that ROI requests on content received from an RTP Mixer is not covered = by and thus likely not in scope for the current 3GPP text. > > > >> 2. The co-ordinates can be negative if you want to zoom out or move > >> out of the displayed content (this also relates to the first issue of > >> what is the original content) > > > > Given, that the coordinate system is in relation to the currently > > received picture. But, I do note that attempting to use "current" > > requires one to include some type of reference (RTP Timestamp), for > > what current is, due to the delay between the sender side and receiver. [BoB] I don't expect that precision of reference is necessary. Remember tha= t 3GPP mainly deals with mobile terminals and thus a non-fixed camera. I do= n't expect that the terminal in general can or will track and save the capt= ure area dynamically, so even if it receives a request for "give me this vi= deo area relative to what you sent 785 ms ago", it will hardly be able to c= omply (at least not with any precision). Zooming out does not require negative coordinates, just increasing the size= in the request compared to what is announced as received. Moving out of th= e displayed content will work fine, as long as it does not reach the upper = or left edge, that is agreed. This can be counter-acted by the video sender= by announcing an upper and left edge in the RTP HE that is some way off th= e value 0. > > > >> 3. The definition of pre-defined is not clear depending on the > >> definition of "original content". BTW: in H.281 the pre-defined are > >> using a current view and provide an ID for it that can be used later > >> to return to the same view > > > > Okay, this needs to be written up in an more complete argumentation. [BoB] As said above, I don't think this is an issue, considering the latest= updates in the document linked by Magnus. > > > > I also note that these type of issues do result in an highly > > likelihood that an updated specification, independently if it is in > > 3GPP and IETF this specification is developed. Thus, we might be > > forced to raise the warning that this might be the end result. > > > > Cheers > > > > Magnus Westerlund > > > >> > >> Roni Even > >> > >> -----Original Message----- > >> From: avtext [mailto:avtext-bounces@ietf.org] On Behalf Of Magnus > >> Westerlund > >> Sent: Wednesday, September 09, 2015 5:01 PM > >> To: Jonathan Lennox; avtext@ietf.org > >> Subject: Re: [avtext] Fwd: draft response to SA4 liaison statement > >> > >> Hi, > >> > >> I have looked at the draft LS. I think we should provide constructive > >> feedback for what the AVTEXT participants see as shortcomings of the > >> 3GPP proposals. I think the main reason for considering to do IETF > >> work on this was that the proposal had shortcomings. > >> > >> I will note that 3GPP has already requested registration for their > >> RTP header extensions as well as the RTCP Feedback format. I am > >> reviewer and have had some feedback to them. They are likely to need > >> to revise their specification to fulfil this requirement. > >> > >> Therefore I think they can consider to address a larger set of > >> feedbacks if we can provide it. I personally don't see a need for an > >> IETF specification if the 3GPP one is sufficiently good. > >> > >> The primary issue I saw with the feedback format is that it is > >> unclear if the FCI format allows for multiple entries. > >> > >> However, I think there might be an issue with determining if a > >> request is being received and acted on. That is clearly one > >> difference between the I-D here in IETF and the 3GPP spec. > >> > >> Thus, I think we should gather such feedback and provide it. > >> > >> Cheers > >> > >> Magnus Westerlund > >> > >> --------------------------------------------------------------------- > >> - Services, Media and Network features, Ericsson Research EAB/TXM > >> ---------------------------------------------------------------------- > >> Ericsson AB | Phone +46 10 7148287 > >> F=E4r=F6gatan 6 | Mobile +46 73 0949079 > >> SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > >> --------------------------------------------------------------------- > >> - > >> > >> _______________________________________________ > >> avtext mailing list > >> avtext@ietf.org > >> https://www.ietf.org/mailman/listinfo/avtext > >> > >> > > > > >=20 >=20 > -- >=20 > Magnus Westerlund >=20 > ---------------------------------------------------------------------- > Services, Media and Network features, Ericsson Research EAB/TXM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > F=E4r=F6gatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- >=20 > _______________________________________________ > avtext mailing list > avtext@ietf.org > https://www.ietf.org/mailman/listinfo/avtext From nobody Tue Sep 15 11:17:32 2015 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A51C71A8AE6 for ; Tue, 15 Sep 2015 11:17:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.07 X-Spam-Level: * X-Spam-Status: No, score=1.07 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, MANGLED_HERE=2.3, RCVD_IN_SORBS_WEB=0.77, SPF_PASS=-0.001] autolearn=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 9cIMSpKT4UKr for ; Tue, 15 Sep 2015 11:17:28 -0700 (PDT) Received: from mail-wi0-x230.google.com (mail-wi0-x230.google.com [IPv6:2a00:1450:400c:c05::230]) (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 AEB6E1A8AF7 for ; Tue, 15 Sep 2015 11:17:22 -0700 (PDT) Received: by wicgb1 with SMTP id gb1so40711315wic.1 for ; Tue, 15 Sep 2015 11:17:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:content-transfer-encoding:thread-index :content-language; bh=DXvOwT5vIzXyrktr4P7p80gF0UfYYHqKmvh91DazQPY=; b=WGcr3+gP/O27+rh0g64jEUnOhfU0w0njy6bZLOs8VXNv9bpUWgMHNKLkBSldyqG6lj 5OO9zTzLtYO8YBP4NrQa2cmIjzmYsjW2h9Q2jtZXJ7hOPVdsvwHtXJHnLMumFYMz4nfc yXuaZD/l97mA3cZSAyGbUWsYHCdtoKtYPjTS+ioyU4bv29MXxc+j/nYyKwzYhNO8liky dCO5DxYtyF//yoRHL2spF5/ZkMqj7pbDqrdKGS6LUXD2YFL0vhb1Re+fxeEhPPiyfum2 12Vy/OwiGnFp2gHzLN6R5cD+giTb3/Hf9xiQAx29C3qZbEfQRBHXuUJFCoFOmntqEz5o eZzA== X-Received: by 10.194.110.37 with SMTP id hx5mr42621661wjb.149.1442341041186; Tue, 15 Sep 2015 11:17:21 -0700 (PDT) Received: from RoniPC (bzq-79-176-23-173.red.bezeqint.net. [79.176.23.173]) by smtp.gmail.com with ESMTPSA id jc9sm300042wic.6.2015.09.15.11.17.18 (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 15 Sep 2015 11:17:20 -0700 (PDT) From: "Roni Even" To: "'Bo Burman'" , "'Magnus Westerlund'" , "'Jonathan Lennox'" , References: <01f401d0d4e6$52bd03f0$f8370bd0$@gmail.com> <55F03B9B.6020008@ericsson.com> <03a701d0eb20$b269e6b0$173db410$@gmail.com> <55F13B98.8060403@ericsson.com> <043101d0ebd2$874bb690$95e323b0$@gmail.com> <55F29B07.8010102@ericsson.com> <04cf01d0ec98$62e9d4a0$28bd7de0$@gmail.com> In-Reply-To: Date: Tue, 15 Sep 2015 21:17:16 +0300 Message-ID: <060301d0efe2$c1b2c3f0$45184bd0$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQESySJSqxJaA07eLxmAsmwS8cYwJgK/YrIDAdL764sCH8lXzgJrY/SBAXYFMjcBvXxZiQFwfsBvAm5Vu+6fOLEE8A== Content-Language: he Archived-At: Subject: Re: [avtext] Fwd: draft response to SA4 liaison statement X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Sep 2015 18:17:30 -0000 Hi Bo, Inline Roni -----Original Message----- From: Bo Burman [mailto:bo.burman@ericsson.com]=20 Sent: Tuesday, September 15, 2015 6:07 PM To: Roni Even; Magnus Westerlund; 'Jonathan Lennox'; avtext@ietf.org Subject: RE: [avtext] Fwd: draft response to SA4 liaison statement Roni, Magnus, I agree that there are likely flaws and/or incompleteness in the ROI specification in 3GPP. I would however expect that 3GPP welcomes constructive feedback from IETF. I think neither IETF nor 3GPP will = benefit from having conflicting ROI specifications. Please find my comments inline below (including comments to Roni's = original list of issues). Cheers, Bo > -----Original Message----- > From: avtext [mailto:avtext-bounces@ietf.org] On Behalf Of Roni Even > Sent: den 11 september 2015 15:47 > To: Magnus Westerlund; 'Jonathan Lennox'; avtext@ietf.org > Subject: Re: [avtext] Fwd: draft response to SA4 liaison statement >=20 > Hi Magnus, > I looked at the changes and I am not sure they clarify the issues. > For example : Position_X - specifies the x-coordinate for the upper=20 > left corner of the ROI area covered in the original content (i.e., uncompressed captured content) in units of pixels - this is still not = clear. Two points: > 1. Uncompressed capture content - is not clear, it does not say at=20 > which zoom the camera was using for the uncompressed and when it was=20 > taken [BoB] I don't think there is any issue here. The latest agreed update in = the document Magnus provided a link to includes the following statement: "The SDP offer with a=3Dpredefined_ROI parameter shall contain the = full-size view of the video indicated via ROI_ID=3D0." That is, ID 0 always provides the frame of reference by providing a = fully zoomed-out view of the area referred by other ROI definitions. [RE] this is not feasible since you assume that the camera is capturing = a full view. This may not be the case always since camera initial zoom may depends on user interaction or some setting. Even more, the full view = does not mean that the camera is pointing at the relevant picture, again it = is user dependent. The only way it will work is if the user sending the = video will set the correct view and only after will use the UI to make this = the original picture. BTW: the whole text is confusing using server client sender and receiver terms for the same thing. Note that this is only applicable to the pre-defined ROI mode, where the video receiver chooses a pre-defined area by name, not by coordinates. = It is the video sender that provides the coordinates of the pre-defined areas, = not the video receiver. That is fully clear from the existing 3GPP text. 2. In this case the units should not be pixels but arbitrary = co-ordinates - I think that > comment was made by Randell Jesup in Prague. [BoB] Since the frame of reference is always provided, it does not = matter what units are used, and can coordinates very well be considered to be "arbitrary co-ordinates". [RE] this had to do with SVC or simulcast when the user can receive = lower resolution >=20 > I think that one of the major issues is that the design does not look=20 > at the way ROI application will work which in my view may typically be = > based on the video receiver select an area of interest on the current = > screen or use the mouse to drag the image (left right, up, down) and = ask for refresh for pan for example, so it will be better to base the = request on a current view (maybe using RTP time stamp) instead to some "original content". [BoB] I don't understand that objection. The "Arbitrary ROI" mode = describes exactly, or at least something very similar to that mode of operation. = It makes use of a new rtcp-fb format ("3gpp-roi-arbitrary") allowing the = video receiver to request a selected area of the video to be sent, in = conjunction with an RTP Header Extension ("urn:3gpp:roi-sent") from the video sender describing what area that is currently included in the RTP payload. The coordinates in both the request and the announcement express upper left corner and a size, and I don't understand "original content" to be = directly related to any fixed reference frame. Instead, the video receiver is expected to look at what is region is actually sent in the RTP HE and construct the RTCP feedback from that. Zooming out would simply involve increasing the size values in the RTCP feedback. I expect that 16 bits = per size component is plenty in that aspect. Panning involves moving the = upper left corner reference in the request compared to what is received in the = RTP HE. [RE] I was saying that in this case the co-ordinate may be negative and = not only positive if the reverence is to the current view for the pan. As = for zooming, is it a zoom factor or the new coordinates to be displayed. = Using co-ordinates is more flexible than using zoom factor (two or one = dimension information) >=20 >=20 > Roni >=20 > -----Original Message----- > From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] > Sent: Friday, September 11, 2015 12:13 PM > To: Roni Even; 'Jonathan Lennox'; avtext@ietf.org > Subject: Re: [avtext] Fwd: draft response to SA4 liaison statement >=20 > Hi, >=20 > My point is that we appear to have some significant issues with what=20 > is currently specified in 3GPP. If AVTEXT would take on ROI work it is likely that these would result in a non-backwards compatible solution. > That I think is highly relevant in regards to the ACTION part of the = LS: >=20 > "3GPP SA4 kindly requests IETF to take the information above into=20 > account, and maintain coordination with SA4 during the course of the=20 > development of > draft-huang-avtext-feedback-image-control-00 toward ensuring the = alignment between 3GPP and IETF specifications." >=20 > This would affect alignment. Thus, I am of the opinion that we need to = > raise this issue at the start to avoid future issues around divergent expectations. >=20 > I do need to note that SA4 have approved some changes to their=20 > specification, which can be seen here until they are integrated in the next version of their specification: >=20 > http://www.3gpp.org/ftp/tsg_sa/WG4_CODEC/TSGS4_85/Docs/S4-151080.zip >=20 > This do clarify at least parts of the issues raised. >=20 > In regards to the IANA registrations, these changes do result that the = RTP header extension requests can go forward. >=20 > Cheers >=20 > Magnus Westerlund >=20 >=20 > Den 2015-09-10 kl. 16:11, skrev Roni Even: > > Hi, > > Thanks Magnus, so the question about the Liaison will be if it=20 > > should have all these concerns. I do not think that this should be=20 > > as comments to the IANA registration request. > > On the other hand I am not sure what it will help by having the=20 > > particular concerns in the response to the liaison from 3GPP since=20 > > they did not ask for comments on their document and it is not clear=20 > > that > they will act on it. [BoB] I do think that 3GPP will act on constructive feedback. > > > > Roni > > > > -----Original Message----- > > From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] > > Sent: Thursday, September 10, 2015 11:13 AM > > To: Roni Even; 'Jonathan Lennox'; avtext@ietf.org > > Subject: Re: [avtext] Fwd: draft response to SA4 liaison statement > > > > Den 2015-09-09 kl. 18:58, skrev Roni Even: > >> Hi, > >> My understanding was that the authors of the IETF document were=20 > >> asked to go to 3GPP and present their concerns over there. Since=20 > >> the authors do not attend 3GPP meeting and they have concerns with=20 > >> the proposed solution, I believe that this is what we can currently say. > >> If you think we should raise our concerns I can point at the three=20 > >> major ones. > >> > >> 1. It is not clear what is the "original content ". Is it the first = > >> image that was sent, how does it work for multipoint? We think that = > >> the request can relate to the current content as the reference for=20 > >> the > > request. > > > > Yes, this is thorny and I think you will need to expand on this. It=20 > > clearly need to work with switched sources, such as the ones in an=20 > > RTP mixer performing source switching. I think one can also raise=20 > > the issue between original capture and what is being encoded, as=20 > > scaling prior to encoding for bit-rate adaptation and simulcast=20 > > usage makes things more interesting. As the coordinates in pixel in=20 > > these cases for a particular region changes upon the switch of resolution. [BoB] See my comments above. "Original content" basically apply only to pre-defined ROI, in which case the "full" reference frame is given by = the pre-defined ID 0. I do agree that the 3GPP text lacks considerations = related to ROI use in conferencing situations, but lack of explicit descriptions related to conferencing / multiparty situations is true for that entire specification (not only the ROI part). I think you must read and = understand the current text as basically applicable only for point-to-point. I = believe parts of Magnus' concerns are handled by relating the RTCP FB request to what is actually sent, which can be learnt through the RTP HE. It = however seems to me that ROI requests on content received from an RTP Mixer is = not covered by and thus likely not in scope for the current 3GPP text. > > > >> 2. The co-ordinates can be negative if you want to zoom out or move = > >> out of the displayed content (this also relates to the first issue=20 > >> of what is the original content) > > > > Given, that the coordinate system is in relation to the currently=20 > > received picture. But, I do note that attempting to use "current" > > requires one to include some type of reference (RTP Timestamp), for=20 > > what current is, due to the delay between the sender side and = receiver. [BoB] I don't expect that precision of reference is necessary. Remember = that 3GPP mainly deals with mobile terminals and thus a non-fixed camera. I = don't expect that the terminal in general can or will track and save the = capture area dynamically, so even if it receives a request for "give me this = video area relative to what you sent 785 ms ago", it will hardly be able to = comply (at least not with any precision). Zooming out does not require negative coordinates, just increasing the = size in the request compared to what is announced as received. Moving out of = the displayed content will work fine, as long as it does not reach the upper = or left edge, that is agreed. This can be counter-acted by the video sender = by announcing an upper and left edge in the RTP HE that is some way off the value 0. > > > >> 3. The definition of pre-defined is not clear depending on the=20 > >> definition of "original content". BTW: in H.281 the pre-defined are = > >> using a current view and provide an ID for it that can be used=20 > >> later to return to the same view > > > > Okay, this needs to be written up in an more complete argumentation. [BoB] As said above, I don't think this is an issue, considering the = latest updates in the document linked by Magnus. > > > > I also note that these type of issues do result in an highly=20 > > likelihood that an updated specification, independently if it is in=20 > > 3GPP and IETF this specification is developed. Thus, we might be=20 > > forced to raise the warning that this might be the end result. > > > > Cheers > > > > Magnus Westerlund > > > >> > >> Roni Even > >> > >> -----Original Message----- > >> From: avtext [mailto:avtext-bounces@ietf.org] On Behalf Of Magnus=20 > >> Westerlund > >> Sent: Wednesday, September 09, 2015 5:01 PM > >> To: Jonathan Lennox; avtext@ietf.org > >> Subject: Re: [avtext] Fwd: draft response to SA4 liaison statement > >> > >> Hi, > >> > >> I have looked at the draft LS. I think we should provide=20 > >> constructive feedback for what the AVTEXT participants see as=20 > >> shortcomings of the 3GPP proposals. I think the main reason for=20 > >> considering to do IETF work on this was that the proposal had shortcomings. > >> > >> I will note that 3GPP has already requested registration for their=20 > >> RTP header extensions as well as the RTCP Feedback format. I am=20 > >> reviewer and have had some feedback to them. They are likely to=20 > >> need to revise their specification to fulfil this requirement. > >> > >> Therefore I think they can consider to address a larger set of=20 > >> feedbacks if we can provide it. I personally don't see a need for=20 > >> an IETF specification if the 3GPP one is sufficiently good. > >> > >> The primary issue I saw with the feedback format is that it is=20 > >> unclear if the FCI format allows for multiple entries. > >> > >> However, I think there might be an issue with determining if a=20 > >> request is being received and acted on. That is clearly one=20 > >> difference between the I-D here in IETF and the 3GPP spec. > >> > >> Thus, I think we should gather such feedback and provide it. > >> > >> Cheers > >> > >> Magnus Westerlund > >> > >> ------------------------------------------------------------------- > >> -- > >> - Services, Media and Network features, Ericsson Research EAB/TXM > >> = ---------------------------------------------------------------------- > >> Ericsson AB | Phone +46 10 7148287 > >> F=E4r=F6gatan 6 | Mobile +46 73 0949079 > >> SE-164 80 Stockholm, Sweden | mailto:=20 > >> magnus.westerlund@ericsson.com > >> ------------------------------------------------------------------- > >> -- > >> - > >> > >> _______________________________________________ > >> avtext mailing list > >> avtext@ietf.org > >> https://www.ietf.org/mailman/listinfo/avtext > >> > >> > > > > >=20 >=20 > -- >=20 > Magnus Westerlund >=20 > ---------------------------------------------------------------------- > Services, Media and Network features, Ericsson Research EAB/TXM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > F=E4r=F6gatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- >=20 > _______________________________________________ > avtext mailing list > avtext@ietf.org > https://www.ietf.org/mailman/listinfo/avtext From nobody Tue Sep 15 13:05:17 2015 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 749DE1ACE2E for ; Tue, 15 Sep 2015 13:05:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.497 X-Spam-Level: X-Spam-Status: No, score=-1.497 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_WEB=0.77, SPF_PASS=-0.001] autolearn=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 zFo1WknggGWZ for ; Tue, 15 Sep 2015 13:05:14 -0700 (PDT) Received: from mx0a-00198e01.pphosted.com (mx0a-00198e01.pphosted.com [67.231.149.202]) (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 E05601ACE25 for ; Tue, 15 Sep 2015 13:05:14 -0700 (PDT) Received: from pps.filterd (m0073109.ppops.net [127.0.0.1]) by mx0a-00198e01.pphosted.com (8.15.0.59/8.15.0.59) with SMTP id t8FK4oaH025149; Tue, 15 Sep 2015 16:05:12 -0400 Received: from mail.vidyo.com ([162.209.16.214]) by mx0a-00198e01.pphosted.com with ESMTP id 1wxp3084yv-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 15 Sep 2015 16:05:12 -0400 Received: from 492132-EXCH1.vidyo.com ([fe80::50:56ff:fe85:4f77]) by 492133-EXCH2.vidyo.com ([fe80::250:56ff:fe85:4a71%11]) with mapi id 14.03.0195.001; Tue, 15 Sep 2015 15:05:10 -0500 From: Jonathan Lennox To: "avtext@ietf.org" Thread-Topic: Please let the chairs know if you want discussion time at AVTEXT at IETF 94 Thread-Index: AQHQ7/HTtxJKUstPYEWx4rIb6Tc8Ig== Date: Tue, 15 Sep 2015 20:05:10 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [160.79.219.114] Content-Type: text/plain; charset="utf-8" Content-ID: <792AE3487942E54C868127F0A8C9C0A4@vidyo.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.14.151, 1.0.33, 0.0.0000 definitions=2015-09-15_08:2015-09-15,2015-09-15,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=3 spamscore=3 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1508030000 definitions=main-1509150249 Archived-At: Subject: [avtext] Please let the chairs know if you want discussion time at AVTEXT at IETF 94 X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Sep 2015 20:05:16 -0000 SGVsbG8sIGFsbCDigJQNCg0KSW4gb3JkZXIgdG8gcHV0IGluIG91ciBhZ2VuZGEgdGltZSByZXF1 ZXN0LCBwbGVhc2UgbGV0IEtlaXRoIGFuZCBtZSBrbm93IGlmIHlvdSBwbGFuIHRvIHJlcXVlc3Qg dGltZSBhdCB0aGUgQVZURVhUIG1lZXRpbmcgYXQgSUVURiA5NC4gIChFdmVuIGlmIHlvdeKAmXJl IG5vdCAxMDAlIHN1cmUgeW914oCZbGwgd2FudCB0byBkaXNjdXNzIHNvbWV0aGluZywgcGxlYXNl IGxldCB1cyBrbm93IHNvIHdlIGNhbiBzY2hlZHVsZSBhIHJlYXNvbmFibGUgYW1vdW50IG9mIHRp bWUgZm9yIHRoZSBtZWV0aW5nLik= From nobody Tue Sep 15 13:25:36 2015 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C1731ACECD for ; Tue, 15 Sep 2015 13:25:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.497 X-Spam-Level: X-Spam-Status: No, score=-1.497 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_WEB=0.77, SPF_PASS=-0.001] autolearn=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 hBj9O8wkf9Kh for ; Tue, 15 Sep 2015 13:25:34 -0700 (PDT) Received: from mx0b-00198e01.pphosted.com (mx0b-00198e01.pphosted.com [67.231.157.197]) (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 DDE021ACEB4 for ; Tue, 15 Sep 2015 13:25:33 -0700 (PDT) Received: from pps.filterd (m0073110.ppops.net [127.0.0.1]) by mx0b-00198e01.pphosted.com (8.15.0.59/8.15.0.59) with SMTP id t8FKPPxV017683 for ; Tue, 15 Sep 2015 16:25:33 -0400 Received: from mail.vidyo.com ([162.209.16.214]) by mx0b-00198e01.pphosted.com with ESMTP id 1wxp1w856m-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Tue, 15 Sep 2015 16:25:33 -0400 Received: from 492132-EXCH1.vidyo.com ([fe80::50:56ff:fe85:4f77]) by 492133-EXCH2.vidyo.com ([fe80::250:56ff:fe85:4a71%11]) with mapi id 14.03.0195.001; Tue, 15 Sep 2015 15:25:31 -0500 From: Jonathan Lennox To: "avtext@ietf.org" Thread-Topic: Confirming adoption of frame marking as an AVTEXT WG item Thread-Index: AQHQ7/Sqf3+2GZ4qA0+o6dlQgxpXmA== Date: Tue, 15 Sep 2015 20:25:31 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [160.79.219.114] Content-Type: text/plain; charset="utf-8" Content-ID: <588E3B000C06254C90A06D6DBAD5913C@vidyo.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.14.151, 1.0.33, 0.0.0000 definitions=2015-09-15_08:2015-09-15,2015-09-15,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1508030000 definitions=main-1509150254 Archived-At: Subject: [avtext] Confirming adoption of frame marking as an AVTEXT WG item X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Sep 2015 20:25:34 -0000 SGVsbG8sIGFsbCDigJQNCg0KSW4gdGhlIFByYWd1ZSBBVlRFWFQgbWVldGluZywgd2UgaGFkIGNv bnNlbnN1cyBpbiB0aGUgcm9vbSB0byBhZGQgYSBtaWxlc3RvbmUgYW5kIGFkb3B0IHRoZSBWaWRl byBGcmFtZSBJbmZvIFJUUCBoZWFkZXIgZXh0ZW5zaW9uIGRvY3VtZW50IChkcmFmdC1iZXJnZXIt YXZ0ZXh0LWZyYW1lbWFya2luZykgYXMgYSB3b3JraW5nIGdyb3VwIGl0ZW0gb2YgdGhlIEFWVEVY VCB3b3JraW5nIGdyb3VwLg0KDQpUaGlzIGUtbWFpbCBpcyB0byBjb25maXJtIHRoaXMgY29uc2Vu c3VzIG9uIHRoZSBtYWlsaW5nIGxpc3QuICBJZiB5b3Ugd2VyZW7igJl0IGluIFByYWd1ZSDigJQg b3IgaWYgeW91ciBvcGluaW9uIGhhcyBjaGFuZ2VkIOKAlCBwbGVhc2UgaW5kaWNhdGUgeW91ciBv cGluaW9uIG5vdy4NCg0KVGhhbmsgeW91IQ0KDQpKb25hdGhhbiBMZW5ub3gNCkFWVEVYVCBjaGFp cg0KDQo= From nobody Tue Sep 15 15:52:57 2015 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 583881B2D3F for ; Tue, 15 Sep 2015 15:52:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.61 X-Spam-Level: X-Spam-Status: No, score=-4.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MANGLED_HERE=2.3, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 JOMOe_0WtYHa for ; Tue, 15 Sep 2015 15:52:52 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpgre-esg-01.alcatel-lucent.com [135.245.210.22]) (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 673E81B2D3E for ; Tue, 15 Sep 2015 15:52:52 -0700 (PDT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (unknown [135.239.2.122]) by Websense Email Security Gateway with ESMTPS id 5D22776923D07; Tue, 15 Sep 2015 22:52:46 +0000 (GMT) Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id t8FMqiN3022393 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 16 Sep 2015 00:52:45 +0200 Received: from FR712WXCHMBA10.zeu.alcatel-lucent.com ([169.254.6.161]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.03.0195.001; Wed, 16 Sep 2015 00:52:44 +0200 From: "DRAGE, Keith (Keith)" To: Roni Even , "'Bo Burman'" , "'Magnus Westerlund'" , "'Jonathan Lennox'" , "avtext@ietf.org" Thread-Topic: [avtext] Fwd: draft response to SA4 liaison statement Thread-Index: AdDU5hnPZpnbT5wDRCi9ydKVbqRU8AWERb6AAAYvPwAAH/XuAAAMf0gAACfe2YAACZgCgADM4WDwAAW2SAAADcFXUA== Date: Tue, 15 Sep 2015 22:52:44 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8BADDCBA28@FR712WXCHMBA10.zeu.alcatel-lucent.com> References: <01f401d0d4e6$52bd03f0$f8370bd0$@gmail.com> <55F03B9B.6020008@ericsson.com> <03a701d0eb20$b269e6b0$173db410$@gmail.com> <55F13B98.8060403@ericsson.com> <043101d0ebd2$874bb690$95e323b0$@gmail.com> <55F29B07.8010102@ericsson.com> <04cf01d0ec98$62e9d4a0$28bd7de0$@gmail.com> <060301d0efe2$c1b2c3f0$45184bd0$@gmail.com> In-Reply-To: <060301d0efe2$c1b2c3f0$45184bd0$@gmail.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.41] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [avtext] Fwd: draft response to SA4 liaison statement X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Sep 2015 22:52:56 -0000 Your comments are assuming there will be a parallel IETF specification. Noone has responded to my earlier question as to whether IETF (and therefor= e AVTEXT) should produce a specification. I do not think this aspect was di= scussed in Prague. If IETF does produce a specification, what is the hoped for relationship to= the 3GPP specification. Regards Keith -----Original Message----- From: avtext [mailto:avtext-bounces@ietf.org] On Behalf Of Roni Even Sent: 15 September 2015 19:17 To: 'Bo Burman'; 'Magnus Westerlund'; 'Jonathan Lennox'; avtext@ietf.org Subject: Re: [avtext] Fwd: draft response to SA4 liaison statement Hi Bo, Inline Roni -----Original Message----- From: Bo Burman [mailto:bo.burman@ericsson.com] Sent: Tuesday, September 15, 2015 6:07 PM To: Roni Even; Magnus Westerlund; 'Jonathan Lennox'; avtext@ietf.org Subject: RE: [avtext] Fwd: draft response to SA4 liaison statement Roni, Magnus, I agree that there are likely flaws and/or incompleteness in the ROI specif= ication in 3GPP. I would however expect that 3GPP welcomes constructive fee= dback from IETF. I think neither IETF nor 3GPP will benefit from having con= flicting ROI specifications. Please find my comments inline below (including comments to Roni's original= list of issues). Cheers, Bo > -----Original Message----- > From: avtext [mailto:avtext-bounces@ietf.org] On Behalf Of Roni Even > Sent: den 11 september 2015 15:47 > To: Magnus Westerlund; 'Jonathan Lennox'; avtext@ietf.org > Subject: Re: [avtext] Fwd: draft response to SA4 liaison statement >=20 > Hi Magnus, > I looked at the changes and I am not sure they clarify the issues. > For example : Position_X - specifies the x-coordinate for the upper=20 > left corner of the ROI area covered in the original content (i.e., uncompressed captured content) in units of pixels - this is still not clear= . Two points: > 1. Uncompressed capture content - is not clear, it does not say at=20 > which zoom the camera was using for the uncompressed and when it was=20 > taken [BoB] I don't think there is any issue here. The latest agreed update in th= e document Magnus provided a link to includes the following statement: "The SDP offer with a=3Dpredefined_ROI parameter shall contain the full-siz= e view of the video indicated via ROI_ID=3D0." That is, ID 0 always provides the frame of reference by providing a fully = zoomed-out view of the area referred by other ROI definitions. [RE] this is not feasible since you assume that the camera is capturing a f= ull view. This may not be the case always since camera initial zoom may dep= ends on user interaction or some setting. Even more, the full view does not= mean that the camera is pointing at the relevant picture, again it is user= dependent. The only way it will work is if the user sending the video will= set the correct view and only after will use the UI to make this the origi= nal picture. BTW: the whole text is confusing using server client sender an= d receiver terms for the same thing. Note that this is only applicable to the pre-defined ROI mode, where the vi= deo receiver chooses a pre-defined area by name, not by coordinates. It is = the video sender that provides the coordinates of the pre-defined areas, no= t the video receiver. That is fully clear from the existing 3GPP text. 2. In this case the units should not be pixels but arbitrary co-ordinates -= I think that > comment was made by Randell Jesup in Prague. [BoB] Since the frame of reference is always provided, it does not matter w= hat units are used, and can coordinates very well be considered to be "arbi= trary co-ordinates". [RE] this had to do with SVC or simulcast when the user can receive lower r= esolution >=20 > I think that one of the major issues is that the design does not look=20 > at the way ROI application will work which in my view may typically be=20 > based on the video receiver select an area of interest on the current=20 > screen or use the mouse to drag the image (left right, up, down) and=20 > ask for refresh for pan for example, so it will be better to base the request o= n a current view (maybe using RTP time stamp) instead to some "original con= tent". [BoB] I don't understand that objection. The "Arbitrary ROI" mode describes= exactly, or at least something very similar to that mode of operation. It = makes use of a new rtcp-fb format ("3gpp-roi-arbitrary") allowing the video= receiver to request a selected area of the video to be sent, in conjunctio= n with an RTP Header Extension ("urn:3gpp:roi-sent") from the video sender = describing what area that is currently included in the RTP payload. The coo= rdinates in both the request and the announcement express upper left corner= and a size, and I don't understand "original content" to be directly relat= ed to any fixed reference frame. Instead, the video receiver is expected to= look at what is region is actually sent in the RTP HE and construct the RT= CP feedback from that. Zooming out would simply involve increasing the size= values in the RTCP feedback. I expect that 16 bits per size component is p= lenty in that aspect. Panning involves moving the upper left corner referen= ce in the request compared to what is received in the RTP HE. [RE] I was saying that in this case the co-ordinate may be negative and not= only positive if the reverence is to the current view for the pan. As for = zooming, is it a zoom factor or the new coordinates to be displayed. Using = co-ordinates is more flexible than using zoom factor (two or one dimension information) >=20 >=20 > Roni >=20 > -----Original Message----- > From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] > Sent: Friday, September 11, 2015 12:13 PM > To: Roni Even; 'Jonathan Lennox'; avtext@ietf.org > Subject: Re: [avtext] Fwd: draft response to SA4 liaison statement >=20 > Hi, >=20 > My point is that we appear to have some significant issues with what=20 > is currently specified in 3GPP. If AVTEXT would take on ROI work it is likely that these would result in a non-backwards compatible solution. > That I think is highly relevant in regards to the ACTION part of the LS: >=20 > "3GPP SA4 kindly requests IETF to take the information above into=20 > account, and maintain coordination with SA4 during the course of the=20 > development of > draft-huang-avtext-feedback-image-control-00 toward ensuring the=20 > alignment between 3GPP and IETF specifications." >=20 > This would affect alignment. Thus, I am of the opinion that we need to=20 > raise this issue at the start to avoid future issues around divergent expectations. >=20 > I do need to note that SA4 have approved some changes to their=20 > specification, which can be seen here until they are integrated in the next version of their specification: >=20 > http://www.3gpp.org/ftp/tsg_sa/WG4_CODEC/TSGS4_85/Docs/S4-151080.zip >=20 > This do clarify at least parts of the issues raised. >=20 > In regards to the IANA registrations, these changes do result that the=20 > RTP header extension requests can go forward. >=20 > Cheers >=20 > Magnus Westerlund >=20 >=20 > Den 2015-09-10 kl. 16:11, skrev Roni Even: > > Hi, > > Thanks Magnus, so the question about the Liaison will be if it=20 > > should have all these concerns. I do not think that this should be=20 > > as comments to the IANA registration request. > > On the other hand I am not sure what it will help by having the=20 > > particular concerns in the response to the liaison from 3GPP since=20 > > they did not ask for comments on their document and it is not clear=20 > > that > they will act on it. [BoB] I do think that 3GPP will act on constructive feedback. > > > > Roni > > > > -----Original Message----- > > From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] > > Sent: Thursday, September 10, 2015 11:13 AM > > To: Roni Even; 'Jonathan Lennox'; avtext@ietf.org > > Subject: Re: [avtext] Fwd: draft response to SA4 liaison statement > > > > Den 2015-09-09 kl. 18:58, skrev Roni Even: > >> Hi, > >> My understanding was that the authors of the IETF document were=20 > >> asked to go to 3GPP and present their concerns over there. Since=20 > >> the authors do not attend 3GPP meeting and they have concerns with=20 > >> the proposed solution, I believe that this is what we can currently say. > >> If you think we should raise our concerns I can point at the three=20 > >> major ones. > >> > >> 1. It is not clear what is the "original content ". Is it the first=20 > >> image that was sent, how does it work for multipoint? We think that=20 > >> the request can relate to the current content as the reference for=20 > >> the > > request. > > > > Yes, this is thorny and I think you will need to expand on this. It=20 > > clearly need to work with switched sources, such as the ones in an=20 > > RTP mixer performing source switching. I think one can also raise=20 > > the issue between original capture and what is being encoded, as=20 > > scaling prior to encoding for bit-rate adaptation and simulcast=20 > > usage makes things more interesting. As the coordinates in pixel in=20 > > these cases for a particular region changes upon the switch of resolution. [BoB] See my comments above. "Original content" basically apply only to pre= -defined ROI, in which case the "full" reference frame is given by the pre-= defined ID 0. I do agree that the 3GPP text lacks considerations related to= ROI use in conferencing situations, but lack of explicit descriptions rela= ted to conferencing / multiparty situations is true for that entire specifi= cation (not only the ROI part). I think you must read and understand the cu= rrent text as basically applicable only for point-to-point. I believe parts= of Magnus' concerns are handled by relating the RTCP FB request to what is= actually sent, which can be learnt through the RTP HE. It however seems to= me that ROI requests on content received from an RTP Mixer is not covered = by and thus likely not in scope for the current 3GPP text. > > > >> 2. The co-ordinates can be negative if you want to zoom out or move=20 > >> out of the displayed content (this also relates to the first issue=20 > >> of what is the original content) > > > > Given, that the coordinate system is in relation to the currently=20 > > received picture. But, I do note that attempting to use "current" > > requires one to include some type of reference (RTP Timestamp), for=20 > > what current is, due to the delay between the sender side and receiver. [BoB] I don't expect that precision of reference is necessary. Remember tha= t 3GPP mainly deals with mobile terminals and thus a non-fixed camera. I do= n't expect that the terminal in general can or will track and save the capt= ure area dynamically, so even if it receives a request for "give me this vi= deo area relative to what you sent 785 ms ago", it will hardly be able to c= omply (at least not with any precision). Zooming out does not require negative coordinates, just increasing the size= in the request compared to what is announced as received. Moving out of th= e displayed content will work fine, as long as it does not reach the upper = or left edge, that is agreed. This can be counter-acted by the video sender= by announcing an upper and left edge in the RTP HE that is some way off th= e value 0. > > > >> 3. The definition of pre-defined is not clear depending on the=20 > >> definition of "original content". BTW: in H.281 the pre-defined are=20 > >> using a current view and provide an ID for it that can be used=20 > >> later to return to the same view > > > > Okay, this needs to be written up in an more complete argumentation. [BoB] As said above, I don't think this is an issue, considering the latest= updates in the document linked by Magnus. > > > > I also note that these type of issues do result in an highly=20 > > likelihood that an updated specification, independently if it is in=20 > > 3GPP and IETF this specification is developed. Thus, we might be=20 > > forced to raise the warning that this might be the end result. > > > > Cheers > > > > Magnus Westerlund > > > >> > >> Roni Even > >> > >> -----Original Message----- > >> From: avtext [mailto:avtext-bounces@ietf.org] On Behalf Of Magnus=20 > >> Westerlund > >> Sent: Wednesday, September 09, 2015 5:01 PM > >> To: Jonathan Lennox; avtext@ietf.org > >> Subject: Re: [avtext] Fwd: draft response to SA4 liaison statement > >> > >> Hi, > >> > >> I have looked at the draft LS. I think we should provide=20 > >> constructive feedback for what the AVTEXT participants see as=20 > >> shortcomings of the 3GPP proposals. I think the main reason for=20 > >> considering to do IETF work on this was that the proposal had shortcomings. > >> > >> I will note that 3GPP has already requested registration for their=20 > >> RTP header extensions as well as the RTCP Feedback format. I am=20 > >> reviewer and have had some feedback to them. They are likely to=20 > >> need to revise their specification to fulfil this requirement. > >> > >> Therefore I think they can consider to address a larger set of=20 > >> feedbacks if we can provide it. I personally don't see a need for=20 > >> an IETF specification if the 3GPP one is sufficiently good. > >> > >> The primary issue I saw with the feedback format is that it is=20 > >> unclear if the FCI format allows for multiple entries. > >> > >> However, I think there might be an issue with determining if a=20 > >> request is being received and acted on. That is clearly one=20 > >> difference between the I-D here in IETF and the 3GPP spec. > >> > >> Thus, I think we should gather such feedback and provide it. > >> > >> Cheers > >> > >> Magnus Westerlund > >> > >> ------------------------------------------------------------------- > >> -- > >> - Services, Media and Network features, Ericsson Research EAB/TXM > >> ---------------------------------------------------------------------- > >> Ericsson AB | Phone +46 10 7148287 > >> F=E4r=F6gatan 6 | Mobile +46 73 0949079 > >> SE-164 80 Stockholm, Sweden | mailto:=20 > >> magnus.westerlund@ericsson.com > >> ------------------------------------------------------------------- > >> -- > >> - > >> > >> _______________________________________________ > >> avtext mailing list > >> avtext@ietf.org > >> https://www.ietf.org/mailman/listinfo/avtext > >> > >> > > > > >=20 >=20 > -- >=20 > Magnus Westerlund >=20 > ---------------------------------------------------------------------- > Services, Media and Network features, Ericsson Research EAB/TXM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > F=E4r=F6gatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- >=20 > _______________________________________________ > avtext mailing list > avtext@ietf.org > https://www.ietf.org/mailman/listinfo/avtext _______________________________________________ avtext mailing list avtext@ietf.org https://www.ietf.org/mailman/listinfo/avtext From nobody Tue Sep 15 18:18:58 2015 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EA9D1A0113 for ; Tue, 15 Sep 2015 18:18:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.498 X-Spam-Level: X-Spam-Status: No, score=-0.498 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_NEUTRAL=0.779] autolearn=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 F2sNBwy8DSqR for ; Tue, 15 Sep 2015 18:18:53 -0700 (PDT) Received: from resqmta-po-07v.sys.comcast.net (resqmta-po-07v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:166]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5CC8F1A00C6 for ; Tue, 15 Sep 2015 18:18:53 -0700 (PDT) Received: from resomta-po-13v.sys.comcast.net ([96.114.154.237]) by resqmta-po-07v.sys.comcast.net with comcast id HdJX1r00457bBgG01dJtbA; Wed, 16 Sep 2015 01:18:53 +0000 Received: from mail-wi0-f177.google.com ([209.85.212.177]) by resomta-po-13v.sys.comcast.net with comcast id HdGs1r00G3qCRDt01dGtJa; Wed, 16 Sep 2015 01:16:53 +0000 Received: by wicgb1 with SMTP id gb1so52054279wic.1 for ; Tue, 15 Sep 2015 18:16:52 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.194.10.165 with SMTP id j5mr48756781wjb.147.1442366212215; Tue, 15 Sep 2015 18:16:52 -0700 (PDT) Received: by 10.28.20.209 with HTTP; Tue, 15 Sep 2015 18:16:52 -0700 (PDT) In-Reply-To: References: Date: Tue, 15 Sep 2015 19:16:52 -0600 Message-ID: From: Kevin Gross To: "avtext@ietf.org" Content-Type: multipart/alternative; boundary=e89a8f642b06b71b54051fd30d65 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1442366333; bh=pO+DVbE2wIcVywG/ZV+HG6DBoXEf+9Uge6hE8qW956c=; h=Received:Received:Received:MIME-Version:Received:Date:Message-ID: Subject:From:To:Content-Type; b=fZeHR/i/USLSTqZwR78P5z04eAkJ160lbFXM8C1OMrZIAezqGL9VLclyvq/uBpOWm nrLVVGqA9/3/CQ8sVzeH1cpgbdMFUQaidvd6/jpioz+IzWnT6BxYWcKe9E4W5hVrvO YCm6ieG08L/9psbNbSQYGZIgwCiA3gXGy5I+o3UCz54lMsbcVBmM+x4C2BAcwfgp1q U/l6RgrwXBRj7qB+5n3v5OC2639KjONaXi+jgF0I4TJ7FaUjRN5A6rME+MvHpAeoSS tOmLeBrnaAMDrcMRysqkU3mAhaZjDXYat74si62SMKutpYGNGs/MdWlhICQ6d9ZAyY peIBv0+pTlVNQ== Archived-At: Subject: Re: [avtext] Confirming adoption of frame marking as an AVTEXT WG item X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Sep 2015 01:18:56 -0000 --e89a8f642b06b71b54051fd30d65 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I was not in Prague but this looks like a useful extension. I support adding a milestone. Kevin Gross - AVA Networks On Tue, Sep 15, 2015 at 2:25 PM, Jonathan Lennox wrote= : > Hello, all =E2=80=94 > > In the Prague AVTEXT meeting, we had consensus in the room to add a > milestone and adopt the Video Frame Info RTP header extension document > (draft-berger-avtext-framemarking) as a working group item of the AVTEXT > working group. > > This e-mail is to confirm this consensus on the mailing list. If you > weren=E2=80=99t in Prague =E2=80=94 or if your opinion has changed =E2=80= =94 please indicate your > opinion now. > > Thank you! > > Jonathan Lennox > AVTEXT chair > > _______________________________________________ > avtext mailing list > avtext@ietf.org > https://www.ietf.org/mailman/listinfo/avtext > --e89a8f642b06b71b54051fd30d65 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I was not in Prague but this looks like a useful extension= . I support adding a milestone.

Kevin Gross -= AVA Networks

On Tue, Sep 15, 2015 at 2:25 PM, Jonathan Le= nnox <jonathan@vidyo.com> wrote:
Hello, all =E2=80=94

In the Prague AVTEXT meeting, we had consensus in the room to add a milesto= ne and adopt the Video Frame Info RTP header extension document (draft-berg= er-avtext-framemarking) as a working group item of the AVTEXT working group= .

This e-mail is to confirm this consensus on the mailing list.=C2=A0 If you = weren=E2=80=99t in Prague =E2=80=94 or if your opinion has changed =E2=80= =94 please indicate your opinion now.

Thank you!

Jonathan Lennox
AVTEXT chair

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

--e89a8f642b06b71b54051fd30d65-- From nobody Wed Sep 16 00:26:22 2015 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 019AE1B3824 for ; Wed, 16 Sep 2015 00:26:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MANGLED_HERE=2.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham 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 HVxZu7tQMxkO for ; Wed, 16 Sep 2015 00:26:17 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B328A1B382D for ; Wed, 16 Sep 2015 00:26:16 -0700 (PDT) X-AuditID: c1b4fb30-f79626d000006adf-ca-55f91995f36a Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id F3.CE.27359.59919F55; Wed, 16 Sep 2015 09:26:14 +0200 (CEST) Received: from ESESSMB105.ericsson.se ([169.254.5.35]) by ESESSHC007.ericsson.se ([153.88.183.39]) with mapi id 14.03.0248.002; Wed, 16 Sep 2015 09:26:13 +0200 From: Bo Burman To: "DRAGE, Keith (Keith)" , Roni Even , Magnus Westerlund , 'Jonathan Lennox' , "avtext@ietf.org" Thread-Topic: [avtext] Fwd: draft response to SA4 liaison statement Thread-Index: AdDU5hnPZpnbT5wDRCi9ydKVbqRU8AWERb6AAAYvPwAAH/XuAAAMf0gAACfe2YAACZgCgADM4WDwAAW2SAAADcFXUAARib4g Date: Wed, 16 Sep 2015 07:26:12 +0000 Message-ID: References: <01f401d0d4e6$52bd03f0$f8370bd0$@gmail.com> <55F03B9B.6020008@ericsson.com> <03a701d0eb20$b269e6b0$173db410$@gmail.com> <55F13B98.8060403@ericsson.com> <043101d0ebd2$874bb690$95e323b0$@gmail.com> <55F29B07.8010102@ericsson.com> <04cf01d0ec98$62e9d4a0$28bd7de0$@gmail.com> <060301d0efe2$c1b2c3f0$45184bd0$@gmail.com> <949EF20990823C4C85C18D59AA11AD8BADDCBA28@FR712WXCHMBA10.zeu.alcatel-lucent.com> In-Reply-To: <949EF20990823C4C85C18D59AA11AD8BADDCBA28@FR712WXCHMBA10.zeu.alcatel-lucent.com> Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.17] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrKLMWRmVeSWpSXmKPExsUyM+Jvje40yZ+hBqsvcll8vHeD1WL/4vPM Fk8bzzJa/G1ndmDxaH22l9Vj56y77B5Llvxk8mh7doc9gCWKyyYlNSezLLVI3y6BK2NV6yzm gt/NjBUvF/axNjCuzuhi5OSQEDCRuHWghQ3CFpO4cG89kM3FISRwlFHi081pUM5iRomFVxYy glSxCWhIzN9xlxEkISLwhFHi++WHrF2MHBzCAk4SD7argZgiAs4SE3+IgZSLCORJ9D09BbaA RUBV4vC2G8wgNq+Ar0Tn9TdQ82eySHQ9/s4EkuAUiJVoPnMJbBejgKzE/e/3WEBsZgFxiVtP 5jNBXCogsWTPeWYIW1Ti5eN/YCdICChKLO+XgyjXk7gxdQobhK0tsWzha6i9ghInZz5hmcAo OgvJ1FlIWmYhaZmFpGUBI8sqRtHi1OKk3HQjI73Uoszk4uL8PL281JJNjMB4Orjlt8EOxpfP HQ8xCnAwKvHwJrD+DBViTSwrrsw9xCjNwaIkztvM9CBUSCA9sSQ1OzW1ILUovqg0J7X4ECMT B6dUA2McQ/vWi2mi/I80NExemh9qvyzTuidYznjfsRznlXqOzlc1lR5u/fPd+OB18XBH2/3L +KQzw+9MXi8XOJPLySJbPba7pNbXrC/qQufNn/86gtmnrlGx9MxPLJs8ewHHnSTdqJTQ6rqw vZatN+1i1i2I3PkhMqFJyH/+rsV7BRd2WG4qODx5sRJLcUaioRZzUXEiAHh5jMmIAgAA Archived-At: Subject: Re: [avtext] Fwd: draft response to SA4 liaison statement X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Sep 2015 07:26:21 -0000 As my first preference, I would hope is not necessary with an IETF specific= ation. If IETF does produce a specification, I would like it to be directly applic= able to what 3GPP requires. That way, when the IETF spec is ready, 3GPP can= remove a large chunk of text in their specification and replace it with a = reference to the IETF spec. This would in my view keep alignment on a reaso= nable level. It would however likely still introduce a compatibility problem, since I ex= pect an IETF spec to end up rather different than what 3GPP specified (even= if it is for good reasons). > -----Original Message----- > From: DRAGE, Keith (Keith) [mailto:keith.drage@alcatel-lucent.com] > Sent: den 16 september 2015 00:53 > To: Roni Even; Bo Burman; Magnus Westerlund; 'Jonathan Lennox'; avtext@ie= tf.org > Subject: RE: [avtext] Fwd: draft response to SA4 liaison statement >=20 > Your comments are assuming there will be a parallel IETF specification. >=20 > Noone has responded to my earlier question as to whether IETF (and theref= ore AVTEXT) should produce a specification. I > do not think this aspect was discussed in Prague. >=20 > If IETF does produce a specification, what is the hoped for relationship = to the 3GPP specification. >=20 > Regards >=20 > Keith >=20 > -----Original Message----- > From: avtext [mailto:avtext-bounces@ietf.org] On Behalf Of Roni Even > Sent: 15 September 2015 19:17 > To: 'Bo Burman'; 'Magnus Westerlund'; 'Jonathan Lennox'; avtext@ietf.org > Subject: Re: [avtext] Fwd: draft response to SA4 liaison statement >=20 > Hi Bo, > Inline > Roni >=20 > -----Original Message----- > From: Bo Burman [mailto:bo.burman@ericsson.com] > Sent: Tuesday, September 15, 2015 6:07 PM > To: Roni Even; Magnus Westerlund; 'Jonathan Lennox'; avtext@ietf.org > Subject: RE: [avtext] Fwd: draft response to SA4 liaison statement >=20 > Roni, Magnus, >=20 > I agree that there are likely flaws and/or incompleteness in the ROI spec= ification in 3GPP. I would however expect that > 3GPP welcomes constructive feedback from IETF. I think neither IETF nor 3= GPP will benefit from having conflicting ROI > specifications. >=20 > Please find my comments inline below (including comments to Roni's origin= al list of issues). >=20 > Cheers, > Bo >=20 > > -----Original Message----- > > From: avtext [mailto:avtext-bounces@ietf.org] On Behalf Of Roni Even > > Sent: den 11 september 2015 15:47 > > To: Magnus Westerlund; 'Jonathan Lennox'; avtext@ietf.org > > Subject: Re: [avtext] Fwd: draft response to SA4 liaison statement > > > > Hi Magnus, > > I looked at the changes and I am not sure they clarify the issues. > > For example : Position_X - specifies the x-coordinate for the upper > > left corner of the ROI area covered in the original content (i.e., > uncompressed captured content) in units of pixels - this is still not cle= ar. > Two points: > > 1. Uncompressed capture content - is not clear, it does not say at > > which zoom the camera was using for the uncompressed and when it was > > taken > [BoB] I don't think there is any issue here. The latest agreed update in = the document Magnus provided a link to includes > the following statement: > "The SDP offer with a=3Dpredefined_ROI parameter shall contain the full-s= ize view of the video indicated via ROI_ID=3D0." > That is, ID 0 always provides the frame of reference by providing a full= y zoomed-out view of the area referred by other > ROI definitions. >=20 > [RE] this is not feasible since you assume that the camera is capturing a= full view. This may not be the case always since > camera initial zoom may depends on user interaction or some setting. Even= more, the full view does not mean that the > camera is pointing at the relevant picture, again it is user dependent. T= he only way it will work is if the user sending the > video will set the correct view and only after will use the UI to make th= is the original picture. BTW: the whole text is > confusing using server client sender and receiver terms for the same thin= g. >=20 > Note that this is only applicable to the pre-defined ROI mode, where the = video receiver chooses a pre-defined area by > name, not by coordinates. It is the video sender that provides the coordi= nates of the pre-defined areas, not the video > receiver. That is fully clear from the existing 3GPP text. >=20 > 2. In this case the units should not be pixels but arbitrary co-ordinates= - I think that > > comment was made by Randell Jesup in Prague. > [BoB] Since the frame of reference is always provided, it does not matter= what units are used, and can coordinates very > well be considered to be "arbitrary co-ordinates". >=20 > [RE] this had to do with SVC or simulcast when the user can receive lower= resolution >=20 > > > > I think that one of the major issues is that the design does not look > > at the way ROI application will work which in my view may typically be > > based on the video receiver select an area of interest on the current > > screen or use the mouse to drag the image (left right, up, down) and > > ask > for refresh for pan for example, so it will be better to base the request= on a current view (maybe using RTP time stamp) > instead to some "original content". >=20 >=20 > [BoB] I don't understand that objection. The "Arbitrary ROI" mode describ= es exactly, or at least something very similar to > that mode of operation. It makes use of a new rtcp-fb format ("3gpp-roi-a= rbitrary") allowing the video receiver to > request a selected area of the video to be sent, in conjunction with an R= TP Header Extension ("urn:3gpp:roi-sent") from > the video sender describing what area that is currently included in the R= TP payload. The coordinates in both the request > and the announcement express upper left corner and a size, and I don't un= derstand "original content" to be directly > related to any fixed reference frame. Instead, the video receiver is expe= cted to look at what is region is actually sent in > the RTP HE and construct the RTCP feedback from that. Zooming out would s= imply involve increasing the size values in > the RTCP feedback. I expect that 16 bits per size component is plenty in = that aspect. Panning involves moving the upper > left corner reference in the request compared to what is received in the = RTP HE. > [RE] I was saying that in this case the co-ordinate may be negative and n= ot only positive if the reverence is to the current > view for the pan. As for zooming, is it a zoom factor or the new coordina= tes to be displayed. Using co-ordinates is more > flexible than using zoom factor (two or one dimension > information) >=20 > > > > > > Roni > > > > -----Original Message----- > > From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] > > Sent: Friday, September 11, 2015 12:13 PM > > To: Roni Even; 'Jonathan Lennox'; avtext@ietf.org > > Subject: Re: [avtext] Fwd: draft response to SA4 liaison statement > > > > Hi, > > > > My point is that we appear to have some significant issues with what > > is currently specified in 3GPP. If AVTEXT would take on ROI work it is > likely that these would result in a non-backwards compatible solution. > > That I think is highly relevant in regards to the ACTION part of the LS= : > > > > "3GPP SA4 kindly requests IETF to take the information above into > > account, and maintain coordination with SA4 during the course of the > > development of > > draft-huang-avtext-feedback-image-control-00 toward ensuring the > > alignment > between 3GPP and IETF specifications." > > > > This would affect alignment. Thus, I am of the opinion that we need to > > raise this issue at the start to avoid future issues around divergent > expectations. > > > > I do need to note that SA4 have approved some changes to their > > specification, which can be seen here until they are integrated in the > next version of their specification: > > > > http://www.3gpp.org/ftp/tsg_sa/WG4_CODEC/TSGS4_85/Docs/S4-151080.zip > > > > This do clarify at least parts of the issues raised. > > > > In regards to the IANA registrations, these changes do result that the > > RTP > header extension requests can go forward. > > > > Cheers > > > > Magnus Westerlund > > > > > > Den 2015-09-10 kl. 16:11, skrev Roni Even: > > > Hi, > > > Thanks Magnus, so the question about the Liaison will be if it > > > should have all these concerns. I do not think that this should be > > > as comments to the IANA registration request. > > > On the other hand I am not sure what it will help by having the > > > particular concerns in the response to the liaison from 3GPP since > > > they did not ask for comments on their document and it is not clear > > > that > > they will act on it. > [BoB] I do think that 3GPP will act on constructive feedback. >=20 > > > > > > Roni > > > > > > -----Original Message----- > > > From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] > > > Sent: Thursday, September 10, 2015 11:13 AM > > > To: Roni Even; 'Jonathan Lennox'; avtext@ietf.org > > > Subject: Re: [avtext] Fwd: draft response to SA4 liaison statement > > > > > > Den 2015-09-09 kl. 18:58, skrev Roni Even: > > >> Hi, > > >> My understanding was that the authors of the IETF document were > > >> asked to go to 3GPP and present their concerns over there. Since > > >> the authors do not attend 3GPP meeting and they have concerns with > > >> the proposed solution, I believe that this is what we can currently > say. > > >> If you think we should raise our concerns I can point at the three > > >> major ones. > > >> > > >> 1. It is not clear what is the "original content ". Is it the first > > >> image that was sent, how does it work for multipoint? We think that > > >> the request can relate to the current content as the reference for > > >> the > > > request. > > > > > > Yes, this is thorny and I think you will need to expand on this. It > > > clearly need to work with switched sources, such as the ones in an > > > RTP mixer performing source switching. I think one can also raise > > > the issue between original capture and what is being encoded, as > > > scaling prior to encoding for bit-rate adaptation and simulcast > > > usage makes things more interesting. As the coordinates in pixel in > > > these cases for a particular region changes upon the switch of > resolution. > [BoB] See my comments above. "Original content" basically apply only to p= re-defined ROI, in which case the "full" > reference frame is given by the pre-defined ID 0. I do agree that the 3GP= P text lacks considerations related to ROI use in > conferencing situations, but lack of explicit descriptions related to con= ferencing / multiparty situations is true for that > entire specification (not only the ROI part). I think you must read and u= nderstand the current text as basically applicable > only for point-to-point. I believe parts of Magnus' concerns are handled = by relating the RTCP FB request to what is > actually sent, which can be learnt through the RTP HE. It however seems t= o me that ROI requests on content received > from an RTP Mixer is not covered by and thus likely not in scope for the = current 3GPP text. >=20 > > > > > >> 2. The co-ordinates can be negative if you want to zoom out or move > > >> out of the displayed content (this also relates to the first issue > > >> of what is the original content) > > > > > > Given, that the coordinate system is in relation to the currently > > > received picture. But, I do note that attempting to use "current" > > > requires one to include some type of reference (RTP Timestamp), for > > > what current is, due to the delay between the sender side and receive= r. > [BoB] I don't expect that precision of reference is necessary. Remember t= hat 3GPP mainly deals with mobile terminals > and thus a non-fixed camera. I don't expect that the terminal in general = can or will track and save the capture area > dynamically, so even if it receives a request for "give me this video are= a relative to what you sent 785 ms ago", it will > hardly be able to comply (at least not with any precision). > Zooming out does not require negative coordinates, just increasing the si= ze in the request compared to what is > announced as received. Moving out of the displayed content will work fine= , as long as it does not reach the upper or left > edge, that is agreed. This can be counter-acted by the video sender by an= nouncing an upper and left edge in the RTP HE > that is some way off the value 0. >=20 > > > > > >> 3. The definition of pre-defined is not clear depending on the > > >> definition of "original content". BTW: in H.281 the pre-defined are > > >> using a current view and provide an ID for it that can be used > > >> later to return to the same view > > > > > > Okay, this needs to be written up in an more complete argumentation. > [BoB] As said above, I don't think this is an issue, considering the late= st updates in the document linked by Magnus. >=20 > > > > > > I also note that these type of issues do result in an highly > > > likelihood that an updated specification, independently if it is in > > > 3GPP and IETF this specification is developed. Thus, we might be > > > forced to raise the warning that this might be the end result. > > > > > > Cheers > > > > > > Magnus Westerlund > > > > > >> > > >> Roni Even > > >> > > >> -----Original Message----- > > >> From: avtext [mailto:avtext-bounces@ietf.org] On Behalf Of Magnus > > >> Westerlund > > >> Sent: Wednesday, September 09, 2015 5:01 PM > > >> To: Jonathan Lennox; avtext@ietf.org > > >> Subject: Re: [avtext] Fwd: draft response to SA4 liaison statement > > >> > > >> Hi, > > >> > > >> I have looked at the draft LS. I think we should provide > > >> constructive feedback for what the AVTEXT participants see as > > >> shortcomings of the 3GPP proposals. I think the main reason for > > >> considering to do IETF work on this was that the proposal had > shortcomings. > > >> > > >> I will note that 3GPP has already requested registration for their > > >> RTP header extensions as well as the RTCP Feedback format. I am > > >> reviewer and have had some feedback to them. They are likely to > > >> need to revise their specification to fulfil this requirement. > > >> > > >> Therefore I think they can consider to address a larger set of > > >> feedbacks if we can provide it. I personally don't see a need for > > >> an IETF specification if the 3GPP one is sufficiently good. > > >> > > >> The primary issue I saw with the feedback format is that it is > > >> unclear if the FCI format allows for multiple entries. > > >> > > >> However, I think there might be an issue with determining if a > > >> request is being received and acted on. That is clearly one > > >> difference between the I-D here in IETF and the 3GPP spec. > > >> > > >> Thus, I think we should gather such feedback and provide it. > > >> > > >> Cheers > > >> > > >> Magnus Westerlund > > >> > > >> ------------------------------------------------------------------- > > >> -- > > >> - Services, Media and Network features, Ericsson Research EAB/TXM > > >> --------------------------------------------------------------------= -- > > >> Ericsson AB | Phone +46 10 7148287 > > >> F=E4r=F6gatan 6 | Mobile +46 73 0949079 > > >> SE-164 80 Stockholm, Sweden | mailto: > > >> magnus.westerlund@ericsson.com > > >> ------------------------------------------------------------------- > > >> -- > > >> - > > >> > > >> _______________________________________________ > > >> avtext mailing list > > >> avtext@ietf.org > > >> https://www.ietf.org/mailman/listinfo/avtext > > >> > > >> > > > > > > > > > > > > -- > > > > Magnus Westerlund > > > > ---------------------------------------------------------------------- > > Services, Media and Network features, Ericsson Research EAB/TXM > > ---------------------------------------------------------------------- > > Ericsson AB | Phone +46 10 7148287 > > F=E4r=F6gatan 6 | Mobile +46 73 0949079 > > SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > > ---------------------------------------------------------------------- > > > > _______________________________________________ > > avtext mailing list > > avtext@ietf.org > > https://www.ietf.org/mailman/listinfo/avtext >=20 > _______________________________________________ > avtext mailing list > avtext@ietf.org > https://www.ietf.org/mailman/listinfo/avtext From nobody Wed Sep 16 01:02:42 2015 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C43B1B2C91 for ; Wed, 16 Sep 2015 01:02:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MANGLED_HERE=2.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham 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 p58PGw-0ECbM for ; Wed, 16 Sep 2015 01:02:36 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF4B71B386A for ; Wed, 16 Sep 2015 01:02:35 -0700 (PDT) X-AuditID: c1b4fb3a-f79136d0000071e2-ce-55f92219718a Received: from ESESSHC004.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 54.A2.29154.91229F55; Wed, 16 Sep 2015 10:02:33 +0200 (CEST) Received: from ESESSMB105.ericsson.se ([169.254.5.35]) by ESESSHC004.ericsson.se ([153.88.183.30]) with mapi id 14.03.0248.002; Wed, 16 Sep 2015 10:02:32 +0200 From: Bo Burman To: Roni Even , Magnus Westerlund , 'Jonathan Lennox' , "avtext@ietf.org" Thread-Topic: [avtext] Fwd: draft response to SA4 liaison statement Thread-Index: AdDU5hnPZpnbT5wDRCi9ydKVbqRU8AWERb6AAAYvPwAAH/XuAAAMf0gAACfe2YAACZgCgADM4WDwAAW2SAAAICal4A== Date: Wed, 16 Sep 2015 08:02:32 +0000 Message-ID: References: <01f401d0d4e6$52bd03f0$f8370bd0$@gmail.com> <55F03B9B.6020008@ericsson.com> <03a701d0eb20$b269e6b0$173db410$@gmail.com> <55F13B98.8060403@ericsson.com> <043101d0ebd2$874bb690$95e323b0$@gmail.com> <55F29B07.8010102@ericsson.com> <04cf01d0ec98$62e9d4a0$28bd7de0$@gmail.com> <060301d0efe2$c1b2c3f0$45184bd0$@gmail.com> In-Reply-To: <060301d0efe2$c1b2c3f0$45184bd0$@gmail.com> Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.17] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrJLMWRmVeSWpSXmKPExsUyM+Jvja6k0s9Qgy0zNS0+3rvBarF/8Xlm i7/tzA7MHjtn3WX3WLLkJ5NH27M77AHMUVw2Kak5mWWpRfp2CVwZn/b8ZSw43MRYcf3uX6YG xm9pXYycHBICJhIXlnQzQdhiEhfurWfrYuTiEBI4yijx+uM+KGcxo8SmrpnsIFVsAhoS83fc ZQRJiAisZpQ4+nweUIKDQ1jASeLBdjUQU0TAWWLiDzGQchGBLIk7ezaxgYRZBFQlpuyqAjF5 BXwlrj4sgJh+jFnixZvrjCDlnAIWEhvf7wGzGQVkJe5/v8cCYjMLiEvcejIf6k4BiSV7zjND 2KISLx//YwWZKSGgKLG8Xw6iXE/ixtQpbBC2tsSyha/BynkFBCVOznzCMoFRdBaSqbOQtMxC 0jILScsCRpZVjKLFqcXFuelGRnqpRZnJxcX5eXp5qSWbGIFxc3DLb6sdjAefOx5iFOBgVOLh TWT9GSrEmlhWXJl7iFGag0VJnLeZ6UGokEB6YklqdmpqQWpRfFFpTmrxIUYmDk6pBkaPN4of 9qxI2ep7/3nhhKaczedOrGuu264o+NNGdI3wSSsp6SudT0zTrgaaq1wquTfv4fqNFQ7sEoqT +E6Wce0++drjcIHUrQKXgEWbJhouY0/0e129tWDVzf15uac+FhsH31kQlidy7unn53Zz4p68 MVz3yUlAQn7z9M4Lafcu/3Cx89MJtfBSYinOSDTUYi4qTgQACbpCYnwCAAA= Archived-At: Subject: Re: [avtext] Fwd: draft response to SA4 liaison statement X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Sep 2015 08:02:40 -0000 Hi Roni, more inline (with [BoB2]). /Bo > -----Original Message----- > From: Roni Even [mailto:ron.even.tlv@gmail.com] > Sent: den 15 september 2015 20:17 > To: Bo Burman; Magnus Westerlund; 'Jonathan Lennox'; avtext@ietf.org > Subject: RE: [avtext] Fwd: draft response to SA4 liaison statement >=20 > Hi Bo, > Inline > Roni >=20 > -----Original Message----- > From: Bo Burman [mailto:bo.burman@ericsson.com] > Sent: Tuesday, September 15, 2015 6:07 PM > To: Roni Even; Magnus Westerlund; 'Jonathan Lennox'; avtext@ietf.org > Subject: RE: [avtext] Fwd: draft response to SA4 liaison statement >=20 > Roni, Magnus, >=20 > I agree that there are likely flaws and/or incompleteness in the ROI spec= ification in 3GPP. I would however expect that > 3GPP welcomes constructive feedback from IETF. I think neither IETF nor 3= GPP will benefit from having conflicting ROI > specifications. >=20 > Please find my comments inline below (including comments to Roni's origin= al list of issues). >=20 > Cheers, > Bo >=20 > > -----Original Message----- > > From: avtext [mailto:avtext-bounces@ietf.org] On Behalf Of Roni Even > > Sent: den 11 september 2015 15:47 > > To: Magnus Westerlund; 'Jonathan Lennox'; avtext@ietf.org > > Subject: Re: [avtext] Fwd: draft response to SA4 liaison statement > > > > Hi Magnus, > > I looked at the changes and I am not sure they clarify the issues. > > For example : Position_X - specifies the x-coordinate for the upper > > left corner of the ROI area covered in the original content (i.e., > uncompressed captured content) in units of pixels - this is still not cle= ar. > Two points: > > 1. Uncompressed capture content - is not clear, it does not say at > > which zoom the camera was using for the uncompressed and when it was > > taken > [BoB] I don't think there is any issue here. The latest agreed update in = the document Magnus provided a link to includes > the following statement: > "The SDP offer with a=3Dpredefined_ROI parameter shall contain the full-s= ize view of the video indicated via ROI_ID=3D0." > That is, ID 0 always provides the frame of reference by providing a full= y zoomed-out view of the area referred by other > ROI definitions. >=20 > [RE] this is not feasible since you assume that the camera is capturing a= full view. This may not be the case always since > camera initial zoom may depends on user interaction or some setting. Even= more, the full view does not mean that the > camera is pointing at the relevant picture, again it is user dependent. T= he only way it will work is if the user sending the > video will set the correct view and only after will use the UI to make th= is the original picture. BTW: the whole text is > confusing using server client sender and receiver terms for the same thin= g. [BoB2] Why is that not feasible? This is only for the "pre-defined ROI" mod= e, where the pre-condition is that the sender has defined a set of regions = that can be addressed by a type of "shortcut" ID, and where the lowest ID 0= is, per definition, the full view (whatever that is). I can agree that thi= s mode is viable only when the sending user has a fixed camera, or at least= temporarily put the camera in a fixed position _and_ somehow manually defi= ned what ROI areas should be offered. The scenario you are advocating for i= s instead dealt with in the "arbitrary ROI" description. >=20 > Note that this is only applicable to the pre-defined ROI mode, where the = video receiver chooses a pre-defined area by > name, not by coordinates. It is the video sender that provides the coordi= nates of the pre-defined areas, not the video > receiver. That is fully clear from the existing 3GPP text. >=20 > 2. In this case the units should not be pixels but arbitrary co-ordinates= - I think that > > comment was made by Randell Jesup in Prague. > [BoB] Since the frame of reference is always provided, it does not matter= what units are used, and can coordinates very > well be considered to be "arbitrary co-ordinates". >=20 > [RE] this had to do with SVC or simulcast when the user can receive lower= resolution [BoB2] OK. In the latest 3GPP text, the actual resolution of the sent video= is said to be independent of the chosen ROI area, so I don't see any major= issue even in the case of SVC or simulcast. >=20 > > > > I think that one of the major issues is that the design does not look > > at the way ROI application will work which in my view may typically be > > based on the video receiver select an area of interest on the current > > screen or use the mouse to drag the image (left right, up, down) and > > ask > for refresh for pan for example, so it will be better to base the request= on a current view (maybe using RTP time stamp) > instead to some "original content". >=20 >=20 > [BoB] I don't understand that objection. The "Arbitrary ROI" mode describ= es exactly, or at least something very similar to > that mode of operation. It makes use of a new rtcp-fb format ("3gpp-roi-a= rbitrary") allowing the video receiver to > request a selected area of the video to be sent, in conjunction with an R= TP Header Extension ("urn:3gpp:roi-sent") from > the video sender describing what area that is currently included in the R= TP payload. The coordinates in both the request > and the announcement express upper left corner and a size, and I don't un= derstand "original content" to be directly > related to any fixed reference frame. Instead, the video receiver is expe= cted to look at what is region is actually sent in > the RTP HE and construct the RTCP feedback from that. Zooming out would s= imply involve increasing the size values in > the RTCP feedback. I expect that 16 bits per size component is plenty in = that aspect. Panning involves moving the upper > left corner reference in the request compared to what is received in the = RTP HE. > [RE] I was saying that in this case the co-ordinate may be negative and n= ot only positive if the reverence is to the current > view for the pan. As for zooming, is it a zoom factor or the new coordina= tes to be displayed. Using co-ordinates is more > flexible than using zoom factor (two or one dimension > information) [BoB2] It is coordinates, a size, not a zoom factor. Panning up and/or to t= he left could potentially require negative coordinates for upper left corne= r. This can be mitigated if the RTP HE does not set the "normal" view upper= left corner to (0, 0), but starts at a positive offset. That will however = at some point run into the situation that it reaches an "edge" in that it i= s no longer possible to request pan up or left. >=20 > > > > > > Roni > > > > -----Original Message----- > > From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] > > Sent: Friday, September 11, 2015 12:13 PM > > To: Roni Even; 'Jonathan Lennox'; avtext@ietf.org > > Subject: Re: [avtext] Fwd: draft response to SA4 liaison statement > > > > Hi, > > > > My point is that we appear to have some significant issues with what > > is currently specified in 3GPP. If AVTEXT would take on ROI work it is > likely that these would result in a non-backwards compatible solution. > > That I think is highly relevant in regards to the ACTION part of the LS= : > > > > "3GPP SA4 kindly requests IETF to take the information above into > > account, and maintain coordination with SA4 during the course of the > > development of > > draft-huang-avtext-feedback-image-control-00 toward ensuring the > > alignment > between 3GPP and IETF specifications." > > > > This would affect alignment. Thus, I am of the opinion that we need to > > raise this issue at the start to avoid future issues around divergent > expectations. > > > > I do need to note that SA4 have approved some changes to their > > specification, which can be seen here until they are integrated in the > next version of their specification: > > > > http://www.3gpp.org/ftp/tsg_sa/WG4_CODEC/TSGS4_85/Docs/S4-151080.zip > > > > This do clarify at least parts of the issues raised. > > > > In regards to the IANA registrations, these changes do result that the > > RTP > header extension requests can go forward. > > > > Cheers > > > > Magnus Westerlund > > > > > > Den 2015-09-10 kl. 16:11, skrev Roni Even: > > > Hi, > > > Thanks Magnus, so the question about the Liaison will be if it > > > should have all these concerns. I do not think that this should be > > > as comments to the IANA registration request. > > > On the other hand I am not sure what it will help by having the > > > particular concerns in the response to the liaison from 3GPP since > > > they did not ask for comments on their document and it is not clear > > > that > > they will act on it. > [BoB] I do think that 3GPP will act on constructive feedback. >=20 > > > > > > Roni > > > > > > -----Original Message----- > > > From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] > > > Sent: Thursday, September 10, 2015 11:13 AM > > > To: Roni Even; 'Jonathan Lennox'; avtext@ietf.org > > > Subject: Re: [avtext] Fwd: draft response to SA4 liaison statement > > > > > > Den 2015-09-09 kl. 18:58, skrev Roni Even: > > >> Hi, > > >> My understanding was that the authors of the IETF document were > > >> asked to go to 3GPP and present their concerns over there. Since > > >> the authors do not attend 3GPP meeting and they have concerns with > > >> the proposed solution, I believe that this is what we can currently > say. > > >> If you think we should raise our concerns I can point at the three > > >> major ones. > > >> > > >> 1. It is not clear what is the "original content ". Is it the first > > >> image that was sent, how does it work for multipoint? We think that > > >> the request can relate to the current content as the reference for > > >> the > > > request. > > > > > > Yes, this is thorny and I think you will need to expand on this. It > > > clearly need to work with switched sources, such as the ones in an > > > RTP mixer performing source switching. I think one can also raise > > > the issue between original capture and what is being encoded, as > > > scaling prior to encoding for bit-rate adaptation and simulcast > > > usage makes things more interesting. As the coordinates in pixel in > > > these cases for a particular region changes upon the switch of > resolution. > [BoB] See my comments above. "Original content" basically apply only to p= re-defined ROI, in which case the "full" > reference frame is given by the pre-defined ID 0. I do agree that the 3GP= P text lacks considerations related to ROI use in > conferencing situations, but lack of explicit descriptions related to con= ferencing / multiparty situations is true for that > entire specification (not only the ROI part). I think you must read and u= nderstand the current text as basically applicable > only for point-to-point. I believe parts of Magnus' concerns are handled = by relating the RTCP FB request to what is > actually sent, which can be learnt through the RTP HE. It however seems t= o me that ROI requests on content received > from an RTP Mixer is not covered by and thus likely not in scope for the = current 3GPP text. >=20 > > > > > >> 2. The co-ordinates can be negative if you want to zoom out or move > > >> out of the displayed content (this also relates to the first issue > > >> of what is the original content) > > > > > > Given, that the coordinate system is in relation to the currently > > > received picture. But, I do note that attempting to use "current" > > > requires one to include some type of reference (RTP Timestamp), for > > > what current is, due to the delay between the sender side and receive= r. > [BoB] I don't expect that precision of reference is necessary. Remember t= hat 3GPP mainly deals with mobile terminals > and thus a non-fixed camera. I don't expect that the terminal in general = can or will track and save the capture area > dynamically, so even if it receives a request for "give me this video are= a relative to what you sent 785 ms ago", it will > hardly be able to comply (at least not with any precision). > Zooming out does not require negative coordinates, just increasing the si= ze in the request compared to what is > announced as received. Moving out of the displayed content will work fine= , as long as it does not reach the upper or left > edge, that is agreed. This can be counter-acted by the video sender by an= nouncing an upper and left edge in the RTP HE > that is some way off the value 0. >=20 > > > > > >> 3. The definition of pre-defined is not clear depending on the > > >> definition of "original content". BTW: in H.281 the pre-defined are > > >> using a current view and provide an ID for it that can be used > > >> later to return to the same view > > > > > > Okay, this needs to be written up in an more complete argumentation. > [BoB] As said above, I don't think this is an issue, considering the late= st updates in the document linked by Magnus. >=20 > > > > > > I also note that these type of issues do result in an highly > > > likelihood that an updated specification, independently if it is in > > > 3GPP and IETF this specification is developed. Thus, we might be > > > forced to raise the warning that this might be the end result. > > > > > > Cheers > > > > > > Magnus Westerlund > > > > > >> > > >> Roni Even > > >> > > >> -----Original Message----- > > >> From: avtext [mailto:avtext-bounces@ietf.org] On Behalf Of Magnus > > >> Westerlund > > >> Sent: Wednesday, September 09, 2015 5:01 PM > > >> To: Jonathan Lennox; avtext@ietf.org > > >> Subject: Re: [avtext] Fwd: draft response to SA4 liaison statement > > >> > > >> Hi, > > >> > > >> I have looked at the draft LS. I think we should provide > > >> constructive feedback for what the AVTEXT participants see as > > >> shortcomings of the 3GPP proposals. I think the main reason for > > >> considering to do IETF work on this was that the proposal had > shortcomings. > > >> > > >> I will note that 3GPP has already requested registration for their > > >> RTP header extensions as well as the RTCP Feedback format. I am > > >> reviewer and have had some feedback to them. They are likely to > > >> need to revise their specification to fulfil this requirement. > > >> > > >> Therefore I think they can consider to address a larger set of > > >> feedbacks if we can provide it. I personally don't see a need for > > >> an IETF specification if the 3GPP one is sufficiently good. > > >> > > >> The primary issue I saw with the feedback format is that it is > > >> unclear if the FCI format allows for multiple entries. > > >> > > >> However, I think there might be an issue with determining if a > > >> request is being received and acted on. That is clearly one > > >> difference between the I-D here in IETF and the 3GPP spec. > > >> > > >> Thus, I think we should gather such feedback and provide it. > > >> > > >> Cheers > > >> > > >> Magnus Westerlund > > >> > > >> ------------------------------------------------------------------- > > >> -- > > >> - Services, Media and Network features, Ericsson Research EAB/TXM > > >> --------------------------------------------------------------------= -- > > >> Ericsson AB | Phone +46 10 7148287 > > >> F=E4r=F6gatan 6 | Mobile +46 73 0949079 > > >> SE-164 80 Stockholm, Sweden | mailto: > > >> magnus.westerlund@ericsson.com > > >> ------------------------------------------------------------------- > > >> -- > > >> - > > >> > > >> _______________________________________________ > > >> avtext mailing list > > >> avtext@ietf.org > > >> https://www.ietf.org/mailman/listinfo/avtext > > >> > > >> > > > > > > > > > > > > -- > > > > Magnus Westerlund > > > > ---------------------------------------------------------------------- > > Services, Media and Network features, Ericsson Research EAB/TXM > > ---------------------------------------------------------------------- > > Ericsson AB | Phone +46 10 7148287 > > F=E4r=F6gatan 6 | Mobile +46 73 0949079 > > SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > > ---------------------------------------------------------------------- > > > > _______________________________________________ > > avtext mailing list > > avtext@ietf.org > > https://www.ietf.org/mailman/listinfo/avtext From nobody Wed Sep 23 14:05:12 2015 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 549CB1B2D2F; Wed, 23 Sep 2015 14:05:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.497 X-Spam-Level: X-Spam-Status: No, score=-1.497 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_WEB=0.77, SPF_PASS=-0.001] autolearn=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 FxfrkcYV4OKH; Wed, 23 Sep 2015 14:05:10 -0700 (PDT) Received: from mx0a-00198e01.pphosted.com (mx0a-00198e01.pphosted.com [67.231.149.202]) (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 3016E1B2D21; Wed, 23 Sep 2015 14:05:07 -0700 (PDT) Received: from pps.filterd (m0073109.ppops.net [127.0.0.1]) by mx0a-00198e01.pphosted.com (8.15.0.59/8.15.0.59) with SMTP id t8NL56H6019221; Wed, 23 Sep 2015 17:05:06 -0400 Received: from mail.vidyo.com ([162.209.16.214]) by mx0a-00198e01.pphosted.com with ESMTP id 1wxp30cbdd-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 23 Sep 2015 17:05:06 -0400 Received: from 492132-EXCH1.vidyo.com ([fe80::50:56ff:fe85:4f77]) by 492133-EXCH2.vidyo.com ([fe80::50:56ff:fe85:6b62%13]) with mapi id 14.03.0195.001; Wed, 23 Sep 2015 16:05:05 -0500 From: Jonathan Lennox To: "avtext@ietf.org" Thread-Topic: WGLC for draft-ietf-avtext-sdes-hdr-ext Thread-Index: AQHQ9kOFETZLoDfvvUyNyRCQkKWbZA== Date: Wed, 23 Sep 2015 21:05:05 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [160.79.219.114] Content-Type: text/plain; charset="us-ascii" Content-ID: <760D026D50C2A042ADB659E562FF2646@vidyo.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.14.151, 1.0.33, 0.0.0000 definitions=2015-09-23_09:2015-09-23,2015-09-23,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1508030000 definitions=main-1509230281 Archived-At: Cc: "draft-ietf-avtext-sdes-hdr-ext.all@ietf.org" Subject: [avtext] WGLC for draft-ietf-avtext-sdes-hdr-ext X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Sep 2015 21:05:11 -0000 This is to announce a 2 week Working Group Last Call for draft-ietf-avtext-sdes-hdr-ext-02 as proposed standard. Please review and provide any comments you may have on the document by Wedn= esday, October 7, 2015. Comments should be sent to the document authors and= the AVTEXT WG list. If you review the document but do not have any comment= s, please send a note to that effect as well. Please also forward this WGLC call to any other interested parties who may = be able to review the draft, asking them to also direct their comments to t= he authors and the list as above. Thank you! Jonathan (AVTEXT co-chair) Draft information: This draft is a work item of the Audio/Video Transport Extensions Working G= roup of the IETF. Title : RTP Header Extension for RTCP Source Description = Items Authors : Magnus Westerlund Bo Burman Roni Even Mo Zanaty Filename : draft-ietf-avtext-sdes-hdr-ext-02.txt Pages : 14 Date : 2015-07-06 Abstract: Source Description (SDES) items are normally transported in RTP control protocol (RTCP). In some cases it can be beneficial to speed up the delivery of these items. Mainly when a new source (SSRC) joins an RTP session and the receivers needs this source's identity, relation to other sources, or its synchronization context, all of which may be fully or partially identified using SDES items. To enable this optimization, this document specifies a new RTP header extension that can carry SDES items. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-avtext-sdes-hdr-ext/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-avtext-sdes-hdr-ext-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-avtext-sdes-hdr-ext-02 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/ From nobody Mon Sep 28 01:35:23 2015 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 221811B3258 for ; Mon, 28 Sep 2015 01:35:22 -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 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 chdrA46M911b for ; Mon, 28 Sep 2015 01:35:21 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B53471B3257 for ; Mon, 28 Sep 2015 01:35:20 -0700 (PDT) X-AuditID: c1b4fb30-f79626d000006adf-3e-5608fbc674f1 Received: from ESESSHC002.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 4A.90.27359.6CBF8065; Mon, 28 Sep 2015 10:35:18 +0200 (CEST) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.26) with Microsoft SMTP Server id 14.3.248.2; Mon, 28 Sep 2015 10:35:17 +0200 To: Jonathan Lennox , "avtext@ietf.org" References: From: Magnus Westerlund Message-ID: <5608FBC5.4020705@ericsson.com> Date: Mon, 28 Sep 2015 10:35:17 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprBLMWRmVeSWpSXmKPExsUyM+Jvje6x3xxhBr93mlt8vHeD1WL/4vPM DkweS5b8ZPJoe3aHPYApissmJTUnsyy1SN8ugStj5ueFTAW9HBVHTqxmbWA8wdbFyMkhIWAi cXTaYiYIW0ziwr31QHEuDiGBo4wSP76vhHKWM0p8+7SDHaRKWCBZYvaSu0AdHBwiAr4S/7ck gYSFBGwkej7sBBvEJmAhcfNHI9gCXgFtiW//XoG1sgioShx+egnMFhWIkej5tQGqRlDi5Mwn LCAjOQVsJaZ88QcJMwONmTn/PCOELS/RvHU2M8QqbYmGpg7WCYwCs5B0z0LSMgtJywJG5lWM osWpxUm56UZGeqlFmcnFxfl5enmpJZsYgUF5cMtvgx2ML587HmIU4GBU4uFdoMcRJsSaWFZc mXuIUZqDRUmct5npQaiQQHpiSWp2ampBalF8UWlOavEhRiYOTqkGxoLbmdWSC+IW39uxdaqh +4+AX69V12Qfvi1/xOPD6VKOFvkXxuUvJzgXfVpttcRvlr73P2HFtXWHBO/uFmAWarbl3pDZ mvZg3b6XIRdybuixrk6RfPD+28Qla5ZfTN/V/Mr38aNv1fEPJVjWCybea7PNs5z+wKh0V0aI hmDP+w3LH7QWiDy83K7EUpyRaKjFXFScCABy3qEoKwIAAA== Archived-At: Subject: Re: [avtext] Please let the chairs know if you want discussion time at AVTEXT at IETF 94 X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Sep 2015 08:35:22 -0000 Den 2015-09-15 kl. 22:05, skrev Jonathan Lennox: > Hello, all — > > In order to put in our agenda time request, please let Keith and me > know if you plan to request time at the AVTEXT meeting at IETF 94. > (Even if you’re not 100% sure you’ll want to discuss something, > please let us know so we can schedule a reasonable amount of time for > the meeting.) Lets put a tentative request in for dealing with any WG last call comments for draft-ietf-avtext-sdes-hdr-ext. We can cancel if there is nothing worth discussing. Cheers Magnus Westerlund ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ----------------------------------------------------------------------