From nobody Mon Mar 4 02:35:03 2019 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1616E131106 for ; Mon, 4 Mar 2019 02:35:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gHAU8Ol-TQ15 for ; Mon, 4 Mar 2019 02:34:58 -0800 (PST) Received: from mailout0.telhc.bbc.co.uk (mailout0.telhc.bbc.co.uk [132.185.161.179]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5FEEE13110E for ; Mon, 4 Mar 2019 02:34:58 -0800 (PST) Received: from BGB01XI1008.national.core.bbc.co.uk (bgb01xi1008.national.core.bbc.co.uk [10.161.14.22]) by mailout0.telhc.bbc.co.uk (8.15.2/8.15.2) with ESMTP id x24AXDbY013835; Mon, 4 Mar 2019 10:33:13 GMT Received: from BGB01XUD1001.national.core.bbc.co.uk ([10.184.52.80]) by BGB01XI1008.national.core.bbc.co.uk ([10.161.14.22]) with mapi id 14.03.0408.000; Mon, 4 Mar 2019 10:33:12 +0000 From: James Sandford To: "Roni Even (A)" , Nigel Megitt , "payload@ietf.org" Thread-Topic: [payload] new draft - RTP Payload for TTML Timed Text Thread-Index: AQHUww3IJnvrFU1bhEuuuCEhNcSFAKXddXxVgAFc9JCADQ2ZFoAPhPxG Date: Mon, 4 Mar 2019 10:33:11 +0000 Message-ID: <734752AF0E88364D983373FE5CEFED57594DAEB9@bgb01xud1001> References: , <6E58094ECC8D8344914996DAD28F1CCD18CB3E04@dggemm526-mbx.china.huawei.com> <734752AF0E88364D983373FE5CEFED57594B9E61@bgb01xud1001>, <6E58094ECC8D8344914996DAD28F1CCD18CB45C7@dggemm526-mbx.china.huawei.com>, <734752AF0E88364D983373FE5CEFED57594C8CB8@bgb01xud1001> In-Reply-To: <734752AF0E88364D983373FE5CEFED57594C8CB8@bgb01xud1001> Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.19.161.212] x-exclaimer-md-config: 1cd3ac1c-62e5-43f2-8404-6b688271c769 Content-Type: multipart/alternative; boundary="_000_734752AF0E88364D983373FE5CEFED57594DAEB9bgb01xud1001_" MIME-Version: 1.0 Archived-At: Subject: Re: [payload] new draft - RTP Payload for TTML Timed Text X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Mar 2019 10:35:02 -0000 --_000_734752AF0E88364D983373FE5CEFED57594DAEB9bgb01xud1001_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGVsbG8sDQpBcmUgdGhlcmUgYW55IG1vcmUgYmxvY2tlcnMgaW4gdGhlIHdheSBvZiBwcm9ncmVz c2luZyB0aGlzIGRvY3VtZW50Pw0KDQpSZWdhcmRzLA0KSmFtZXMNCg0KDQo9PT09PT09PT09DQpK YW1lcyBTYW5kZm9yZA0KUiZEIEVuZ2luZWVyDQoNCkJCQyBSZXNlYXJjaCBhbmQgRGV2ZWxvcG1l bnQNCjV0aCBGbG9vcg0KRG9jayBIb3VzZQ0KTWVkaWFDaXR5VUsNClNhbGZvcmQNCk01MCAyTEgN Cg0KVGVsOiAwMzAzMDQgKDA5NTQ5KQ0KV2ViOiBodHRwOi8vd3d3LmJiYy5jby51ay9yZA0KX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkZyb206IHBheWxvYWQgW3BheWxvYWQtYm91 bmNlc0BpZXRmLm9yZ10gb24gYmVoYWxmIG9mIEphbWVzIFNhbmRmb3JkIFtqYW1lcy5zYW5kZm9y ZEBiYmMuY28udWtdDQpTZW50OiAyMiBGZWJydWFyeSAyMDE5IDEzOjM0DQpUbzogUm9uaSBFdmVu IChBKTsgTmlnZWwgTWVnaXR0OyBwYXlsb2FkQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW3BheWxv YWRdIG5ldyBkcmFmdCAtIFJUUCBQYXlsb2FkIGZvciBUVE1MIFRpbWVkIFRleHQNCg0KDQpIZWxs bywNCk5ldyB2ZXJzaW9uIHVwbG9hZGVkIHRoYXQgYWRkcmVzc2VzIHRoZSBjb25jZXJucyByYWlz ZWQgYnkgdGhlIFczQyBUVFdHLg0KDQpodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9k cmFmdC1zYW5kZm9yZC1wYXlsb2FkLXJ0cC10dG1sLzAzLw0KDQpSZWdhcmRzLA0KSmFtZXMNCg0K DQo9PT09PT09PT09DQpKYW1lcyBTYW5kZm9yZA0KUiZEIEVuZ2luZWVyDQoNCkJCQyBSZXNlYXJj aCBhbmQgRGV2ZWxvcG1lbnQNCjV0aCBGbG9vcg0KRG9jayBIb3VzZQ0KTWVkaWFDaXR5VUsNClNh bGZvcmQNCk01MCAyTEgNCg0KVGVsOiAwMzAzMDQgKDA5NTQ5KQ0KV2ViOiBodHRwOi8vd3d3LmJi Yy5jby51ay9yZA0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkZyb206IFJvbmkg RXZlbiAoQSkgW3JvbmkuZXZlbkBodWF3ZWkuY29tXQ0KU2VudDogMTQgRmVicnVhcnkgMjAxOSAw NjoxNA0KVG86IEphbWVzIFNhbmRmb3JkOyBOaWdlbCBNZWdpdHQ7IHBheWxvYWRAaWV0Zi5vcmcN ClN1YmplY3Q6IFJFOiBbcGF5bG9hZF0gbmV3IGRyYWZ0IC0gUlRQIFBheWxvYWQgZm9yIFRUTUwg VGltZWQgVGV4dA0KDQpIaSBKYW1lcywNClBsZWFzZSBjaGFuZ2UgdGhlIGluZGl2aWR1YWwgZHJh ZnQuICBJdCB3aWxsIGJlIGdvb2QgdG8gZ2V0IGFncmVlbWVudCBmcm9tIE5pZ2VsIG9yIG90aGVy cyBmcm9tIDNHUFAgYmFzZWQgb24gdGhlc2UgY2hhbmdlcyBiZWZvcmUgcHJvZ3Jlc3NpbmcgdGhl IHdvcmsgaW4gdGhlIElFVEYNCg0KUmVnYXJkcw0KUm9uaSBFdmVuDQpQYXlsb2FkIFdHIGNvLWNo YWlyDQoNCkZyb206IEphbWVzIFNhbmRmb3JkIFttYWlsdG86amFtZXMuc2FuZGZvcmRAYmJjLmNv LnVrXQ0KU2VudDogV2VkbmVzZGF5LCBGZWJydWFyeSAxMywgMjAxOSAxMToyNSBBTQ0KVG86IFJv bmkgRXZlbiAoQSk7IE5pZ2VsIE1lZ2l0dDsgcGF5bG9hZEBpZXRmLm9yZw0KU3ViamVjdDogUkU6 IFtwYXlsb2FkXSBuZXcgZHJhZnQgLSBSVFAgUGF5bG9hZCBmb3IgVFRNTCBUaW1lZCBUZXh0DQoN ClRoYW5rcywgUm9uaS4gU2hvdWxkIEkgbWFrZSB0aGVzZSBjaGFuZ2VzIG5vdyBvciB3YWl0IHVu dGlsIHRoZSBjYWxsIGZvciB0aGUgV0cgdG8gYWRvcHQgdjAyIGhhcyBsYXBzZWQ/DQoNClJlZ2Fy ZHMsDQpKYW1lcw0KDQoNCj09PT09PT09PT0NCkphbWVzIFNhbmRmb3JkDQpSJkQgRW5naW5lZXIN Cg0KQkJDIFJlc2VhcmNoIGFuZCBEZXZlbG9wbWVudA0KNXRoIEZsb29yDQpEb2NrIEhvdXNlDQpN ZWRpYUNpdHlVSw0KU2FsZm9yZA0KTTUwIDJMSA0KDQpUZWw6IDAzMDMwNCAoMDk1NDkpDQpXZWI6 IGh0dHA6Ly93d3cuYmJjLmNvLnVrL3JkDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KRnJvbTogUm9uaSBFdmVuIChBKSBbcm9uaS5ldmVuQGh1YXdlaS5jb21dDQpTZW50OiAxMiBG ZWJydWFyeSAyMDE5IDA3OjUyDQpUbzogTmlnZWwgTWVnaXR0OyBwYXlsb2FkQGlldGYub3JnPG1h aWx0bzpwYXlsb2FkQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtwYXlsb2FkXSBuZXcgZHJhZnQg LSBSVFAgUGF5bG9hZCBmb3IgVFRNTCBUaW1lZCBUZXh0DQpIaSwNClRoYW5rcyBmb3IgdGhlIGlu Zm9ybWF0aW9uLg0KVGhlIHdheSBJIHNlZSBpdCBpcyB0aGF0IHRoaXMgZG9jdW1lbnQgb25seSB3 YW50cyB0byBzcGVjaWZ5IGhvdyB0byBzZW5kIFRUTSB0aW1lIHRleHQgdXNpbmcgUlRQIHdoaWNo IGlzIG5vdCBzcGVjaWZpZWQgYnkgVzNDDQoNCkkgdGhpbmsgdGhhdCB0aGUgdGV4dCBleHBsYWlu cyBpdCBidXQgbWF5YmUgd2UgbmVlZCBiZXR0ZXIgY2xhcmlmaWNhdGlvbiwgYW55IGlucHV0IGlz IHdlbGNvbWUuIEkgdGhpbmsgdGhhdCBhdCBsZWFzdCBpdCBzaG91bGQgc2F5IHRoYXQgdGhpcyBk b2N1bWVudCBvbmx5IGRlZmluZSBob3cgdG8gY2FycnkgVFRNTCB0aW1lIHRleHQgb3ZlciBSVFAg dXNpbmcgdGhlIG1lZGlhIHN1YnR5cGUgZGVmaW5lZCBieSBXM0MgYW5kIHJlZmVyZW5jZSB0aGUg cmVsZXZhbnQgVzNDIGRvY3VtZW50Lg0KDQpJIGFncmVlIHRoYXQgd2UgZG8gbm90IG5lZWQgdGhl IHJlZ2lzdHJhdGlvbiB0ZW1wbGF0ZSBzaW5jZSB0aGUgZG9jdW1lbnQgc3VnZ2VzdCB1c2luZyB0 aGUgY3VycmVudCByZWdpc3RyYXRpb24gaW4gdGhlIElBTkEgbWVkaWEgIHR5cGUsIHNvIHRoZSBJ QU5BIGNvbnNpZGVyYXRpb24gc2hvdWxkIG9ubHkgYXNrIGZvciBhZGRpbmcgdGhlIHJlZmVyZW5j ZSB0byB0aGlzIGRvY3VtZW50IGluIHRoZSBjdXJyZW50IHJlZ2lzdHJhdGlvbi4gVGhpcyBhc3N1 bWVzIHRoYXQgdGhlcmUgYXJlIG5vIGNoYW5nZXMgaW4gdGhlIHJlZ2lzdHJhdGlvbiByZXF1aXJl ZC4gICBBbm90aGVyIGRpcmVjdGlvbiBpcyB0byBoYXZlIGEgZGlmZmVyZW50IG1lZGlhIHN1YnR5 cGUgbmFtZSBmb3IgdGhlIFJUUCB1c2FnZSBidXQgSW4gc2VlIG5vIHJlYWwgcmVhc29uIGlmIHRo ZSBkb2N1bWVudCBvbmx5IHNwZWNpZnkgaG93IHRvIHVzZSB0aGlzIHBheWxvYWQgb3ZlciBSVFAg YW5kIGNoYW5nZSBub3RoaW5nIGluIHRoZSBjdXJyZW50IHJlZ2lzdHJhdGlvbi4NCg0KVGhlIG9u bHkgb3RoZXIgY29tbWVudCBJIG5vdGljZWQgaXMg4oCcQSByZXF1ZXN0IHRvIG1ha2Ugc3VyZSB0 aGF0IHRoZSBsYW5ndWFnZSBhYm91dCBwcm9maWxlIHNpZ25hbGxpbmcgZG9lcyBub3QgaW1wbHkg dGhhdCB0aGUgY29kZWNzIHBhcmFtZXRlciBjYW4gZGVub3RlIGFsbCBwcm9maWxlcywgZXNwZWNp YWxseSBpbiB0aGUgY2FzZSB0aGF0IHRoZSBwYXlsb2FkIGRvY3VtZW50IGNvbnRhaW5zIGFuIGVt YmVkZGVkIHByb2ZpbGUu4oCcICBUaGlzIHNob3VsZCBiZSBhZGRyZXNzZWQgYnkgdGhlIGF1dGhv cnMNCg0KTGV0IHRoZSBXRyBrbm93IGlmIHRoaXMgc291bmRzIHJlYXNvbmFibGUNClJvbmkgRXZl bg0KUGF5bG9hZCBXRyBjby1jaGFpcg0KDQoNCg0KDQpGcm9tOiBwYXlsb2FkIFttYWlsdG86cGF5 bG9hZC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgTmlnZWwgTWVnaXR0DQpTZW50OiBN b25kYXksIEZlYnJ1YXJ5IDExLCAyMDE5IDU6MTYgUE0NClRvOiBwYXlsb2FkQGlldGYub3JnPG1h aWx0bzpwYXlsb2FkQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtwYXlsb2FkXSBuZXcgZHJhZnQg LSBSVFAgUGF5bG9hZCBmb3IgVFRNTCBUaW1lZCBUZXh0DQoNCkRlYXIgSUVURiBQYXlsb2FkIGdy b3VwLA0KDQpUaGlzIGRyYWZ0IHdhcyBkaXNjdXNzZWQgYnkgdGhlIFczQyBUaW1lZCBUZXh0IFdv cmtpbmcgR3JvdXAgKFRUV0cpIG9uIDIwMTktMDItMDcgWzFdLg0KDQpbMV0gTWludXRlcyBvZiBX M0MgVFRXRyBtZWV0aW5nIDIwMTktMDItMDc6IGh0dHBzOi8vd3d3LnczLm9yZy8yMDE5LzAyLzA3 LXR0LW1pbnV0ZXMuaHRtbCNpdGVtMDMNCg0KRHVyaW5nIHRoZSBtZWV0aW5nIGNvbmNlcm4gd2Fz IHJhaXNlZCBhYm91dCB0aGUgYXBwcm9hY2ggdG8gdGhlIElBTkEgcmVnaXN0ZXJlZCBtZWRpYSB0 eXBlLCBzcGVjaWZpY2FsbHkgdGhlIG1lYW5pbmcgb2Ygc2VjdGlvbiA4LiBJQU5BIENvbnNpZGVy YXRpb25zLg0KDQpUaGVyZSB3YXMgY29uc2Vuc3VzIGFtb25nc3QgdGhlIGdyb3VwIHRoYXQgdGhl IHRleHQgc3BlY2lmeWluZyB0aGF0IHRoaXMgdGV4dDoNCg0K4oCcVGhlIG1lZGlhIHR5cGVzIHJl Z2lzdHJ5IFNIT1VMRCBiZSB1cGRhdGVkIHRvIG1ha2UgcmVmZXJlbmNlIHRvIHRoaXMgZG9jdW1l bnQgZm9yIHRoZSBhcHBsaWNhdGlvbi90dG1sK3htbCBtZWRpYSB0eXBlLuKAnQ0KDQppcyBpbmNv cnJlY3QgYW5kIG5lZWRzIHRvIGJlIGNoYW5nZWQuIFRoZSBtZWRpYSB0eXBlIHJlZ2lzdHJhdGlv biBmb3IgVFRNTCBpcyBvd25lZCBieSBXM0MgYW5kIHNob3VsZCBub3QgYmUgY2hhbmdlZCBieSBJ RVRGIOKAkyB3ZSBub3RlIHRoYXQgdGhlIGNoYW5nZSBjb250cm9sIGlzIGNsZWFybHkgbWFya2Vk IGFzIGJlaW5nIG93bmVkIGJ5IFczQyBzbyBpbiB0aGF0IHNlbnNlIHRoaXMgdGV4dCBpcyBpbmNv bnNpc3RlbnQuDQoNClRoZSBJQU5BIG1lZGlhIHR5cGUgcmVnaXN0cmF0aW9uIGl0c2VsZiBkZWZl cnMgdG8gdGhlIFRUV0cgZG9jdW1lbnQg4oCcVFRNTCBNZWRpYSBUeXBlIERlZmluaXRpb24gYW5k IFByb2ZpbGUgUmVnaXN0cnnigJ0gWzJdIHdoaWNoIGlzIGFscmVhZHkgcmVmZXJlbmNlZCBieSB0 aGUgUlRQIFBheWxvYWQgZHJhZnQuIEFuIGltcHJvdmVtZW50IHdvdWxkIHRoZXJlZm9yZSBiZSB0 byB1cGRhdGUgdGhlIHRleHQgaW4gc2VjdGlvbiA4IHRvIHN1Z2dlc3QgdGhhdCBbMl0gY2FuIGJl IHVwZGF0ZWQgdG8gaW5jbHVkZSB0aGUgcHJvZmlsZXMgZGVmaW5lZCB3aXRoaW4gdGhlIHBheWxv YWQgZG9jdW1lbnQuIEluZGVlZCBkb2luZyBzbyB3b3VsZCByZXN1bHQgaW4gdGhlIGNyZWF0aW9u IG9mIGEgc2hvcnQgY29kZSBmb3IgdGhlIHByb2ZpbGUgcHJvY2Vzc29yIG1lbnRpb25lZCBpbiBz ZWN0aW9uIDQuMi4xLjIuMS4zIFByb2Nlc3NvciBwcm9maWxlIHNpZ25hbGxpbmcuDQoNClsyXSBU VE1MIE1lZGlhIFR5cGUgRGVmaW5pdGlvbiBhbmQgUHJvZmlsZSBSZWdpc3RyeSBodHRwczovL3d3 dy53My5vcmcvVFIvdHRtbC1wcm9maWxlLXJlZ2lzdHJ5Lw0KDQoNClRoZSBUVFdHIGFsc28gZGlz Y3Vzc2VkIHR3byBhZGRpdGlvbmFsIGNvbmNlcm5zIHdpdGhvdXQgY2xvc2luZyBvbiBhIHBvc2l0 aW9uIGF0IHRoaXMgdGltZToNCg0KICAxLiAgQSBxdWVyeSB3aGV0aGVyIHRoZSBtZWRpYSB0eXBl IHJlZ2lzdHJhdGlvbiBpbmZvcm1hdGlvbiByZWFsbHkgbmVlZHMgdG8gYmUgY29waWVkIGluIGF0 IGFsbCBoZXJlIG9yIGlmIGl0IGNhbiBiZSByZWZlcmVuY2VkOw0KICAyLiAgQSByZXF1ZXN0IHRv IG1ha2Ugc3VyZSB0aGF0IHRoZSBsYW5ndWFnZSBhYm91dCBwcm9maWxlIHNpZ25hbGxpbmcgZG9l cyBub3QgaW1wbHkgdGhhdCB0aGUgY29kZWNzIHBhcmFtZXRlciBjYW4gZGVub3RlIGFsbCBwcm9m aWxlcywgZXNwZWNpYWxseSBpbiB0aGUgY2FzZSB0aGF0IHRoZSBwYXlsb2FkIGRvY3VtZW50IGNv bnRhaW5zIGFuIGVtYmVkZGVkIHByb2ZpbGUuDQpUVFdHIG1heSBwcm92aWRlIGZ1cnRoZXIgaW5w dXQgb24gdGhvc2UgdHdvIHBvaW50cyBidXQgd291bGQgd2VsY29tZSBmdXJ0aGVyIGlucHV0IGVz cGVjaWFsbHkgb24gdGhlIGZpcnN0Lg0KDQpLaW5kIHJlZ2FyZHMsDQoNCk5pZ2VsIE1lZ2l0dCBh cyBDaGFpciBvZiBXM0MgVFRXRw0KDQoNCg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t DQoNCmh0dHA6Ly93d3cuYmJjLmNvLnVrDQpUaGlzIGUtbWFpbCAoYW5kIGFueSBhdHRhY2htZW50 cykgaXMgY29uZmlkZW50aWFsIGFuZCBtYXkgY29udGFpbiBwZXJzb25hbCB2aWV3cyB3aGljaCBh cmUgbm90IHRoZSB2aWV3cyBvZiB0aGUgQkJDIHVubGVzcyBzcGVjaWZpY2FsbHkgc3RhdGVkLg0K SWYgeW91IGhhdmUgcmVjZWl2ZWQgaXQgaW4gZXJyb3IsIHBsZWFzZSBkZWxldGUgaXQgZnJvbSB5 b3VyIHN5c3RlbS4NCkRvIG5vdCB1c2UsIGNvcHkgb3IgZGlzY2xvc2UgdGhlIGluZm9ybWF0aW9u IGluIGFueSB3YXkgbm9yIGFjdCBpbiByZWxpYW5jZSBvbiBpdCBhbmQgbm90aWZ5IHRoZSBzZW5k ZXIgaW1tZWRpYXRlbHkuDQpQbGVhc2Ugbm90ZSB0aGF0IHRoZSBCQkMgbW9uaXRvcnMgZS1tYWls cyBzZW50IG9yIHJlY2VpdmVkLg0KRnVydGhlciBjb21tdW5pY2F0aW9uIHdpbGwgc2lnbmlmeSB5 b3VyIGNvbnNlbnQgdG8gdGhpcy4NCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNCg0KDQotLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNCmh0dHA6Ly93d3cuYmJjLmNvLnVrDQpUaGlzIGUt bWFpbCAoYW5kIGFueSBhdHRhY2htZW50cykgaXMgY29uZmlkZW50aWFsIGFuZCBtYXkgY29udGFp biBwZXJzb25hbCB2aWV3cyB3aGljaCBhcmUgbm90IHRoZSB2aWV3cyBvZiB0aGUgQkJDIHVubGVz cyBzcGVjaWZpY2FsbHkgc3RhdGVkLg0KSWYgeW91IGhhdmUgcmVjZWl2ZWQgaXQgaW4gZXJyb3Is IHBsZWFzZSBkZWxldGUgaXQgZnJvbSB5b3VyIHN5c3RlbS4NCkRvIG5vdCB1c2UsIGNvcHkgb3Ig ZGlzY2xvc2UgdGhlIGluZm9ybWF0aW9uIGluIGFueSB3YXkgbm9yIGFjdCBpbiByZWxpYW5jZSBv biBpdCBhbmQgbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHkuDQpQbGVhc2Ugbm90ZSB0aGF0 IHRoZSBCQkMgbW9uaXRvcnMgZS1tYWlscyBzZW50IG9yIHJlY2VpdmVkLg0KRnVydGhlciBjb21t dW5pY2F0aW9uIHdpbGwgc2lnbmlmeSB5b3VyIGNvbnNlbnQgdG8gdGhpcy4NCg0KLS0tLS0tLS0t LS0tLS0tLS0tLS0tDQoNCg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNCmh0dHA6 Ly93d3cuYmJjLmNvLnVrDQpUaGlzIGUtbWFpbCAoYW5kIGFueSBhdHRhY2htZW50cykgaXMgY29u ZmlkZW50aWFsIGFuZCBtYXkgY29udGFpbiBwZXJzb25hbCB2aWV3cyB3aGljaCBhcmUgbm90IHRo ZSB2aWV3cyBvZiB0aGUgQkJDIHVubGVzcyBzcGVjaWZpY2FsbHkgc3RhdGVkLg0KSWYgeW91IGhh dmUgcmVjZWl2ZWQgaXQgaW4gZXJyb3IsIHBsZWFzZSBkZWxldGUgaXQgZnJvbSB5b3VyIHN5c3Rl bS4NCkRvIG5vdCB1c2UsIGNvcHkgb3IgZGlzY2xvc2UgdGhlIGluZm9ybWF0aW9uIGluIGFueSB3 YXkgbm9yIGFjdCBpbiByZWxpYW5jZSBvbiBpdCBhbmQgbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRp YXRlbHkuDQpQbGVhc2Ugbm90ZSB0aGF0IHRoZSBCQkMgbW9uaXRvcnMgZS1tYWlscyBzZW50IG9y IHJlY2VpdmVkLg0KRnVydGhlciBjb21tdW5pY2F0aW9uIHdpbGwgc2lnbmlmeSB5b3VyIGNvbnNl bnQgdG8gdGhpcy4NCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNCg0KDQotLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tDQoNCmh0dHA6Ly93d3cuYmJjLmNvLnVrDQpUaGlzIGUtbWFpbCAoYW5k IGFueSBhdHRhY2htZW50cykgaXMgY29uZmlkZW50aWFsIGFuZCBtYXkgY29udGFpbiBwZXJzb25h bCB2aWV3cyB3aGljaCBhcmUgbm90IHRoZSB2aWV3cyBvZiB0aGUgQkJDIHVubGVzcyBzcGVjaWZp Y2FsbHkgc3RhdGVkLg0KSWYgeW91IGhhdmUgcmVjZWl2ZWQgaXQgaW4gZXJyb3IsIHBsZWFzZSBk ZWxldGUgaXQgZnJvbSB5b3VyIHN5c3RlbS4NCkRvIG5vdCB1c2UsIGNvcHkgb3IgZGlzY2xvc2Ug dGhlIGluZm9ybWF0aW9uIGluIGFueSB3YXkgbm9yIGFjdCBpbiByZWxpYW5jZSBvbiBpdCBhbmQg bm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHkuDQpQbGVhc2Ugbm90ZSB0aGF0IHRoZSBCQkMg bW9uaXRvcnMgZS1tYWlscyBzZW50IG9yIHJlY2VpdmVkLg0KRnVydGhlciBjb21tdW5pY2F0aW9u IHdpbGwgc2lnbmlmeSB5b3VyIGNvbnNlbnQgdG8gdGhpcy4NCg0KLS0tLS0tLS0tLS0tLS0tLS0t LS0tDQo= --_000_734752AF0E88364D983373FE5CEFED57594DAEB9bgb01xud1001_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgZGlyPSJsdHIiPg0KPGhlYWQ+DQo8IS0tIFRlbXBsYXRlIGdlbmVyYXRlZCBieSBFeGNs YWltZXIgTWFpbCBEaXNjbGFpbWVycyBvbiAxMDozMzoxMyBNb25kYXksIDQgTWFyY2ggMjAxOSAt LT4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0idGV4dC9odG1sOyBj aGFyc2V0PXV0Zi04Ij4NCjxzdHlsZSB0eXBlPSJ0ZXh0L2NzcyI+UC5mOTZmMmE4Zi04Y2FkLTQ3 ZDMtOTEwNi1kZmZiZjc4MDkwYjIgew0KCU1BUkdJTjogMGNtIDBjbSAwcHQNCn0NCkxJLmY5NmYy YThmLThjYWQtNDdkMy05MTA2LWRmZmJmNzgwOTBiMiB7DQoJTUFSR0lOOiAwY20gMGNtIDBwdA0K fQ0KRElWLmY5NmYyYThmLThjYWQtNDdkMy05MTA2LWRmZmJmNzgwOTBiMiB7DQoJTUFSR0lOOiAw Y20gMGNtIDBwdA0KfQ0KVEFCTEUuZjk2ZjJhOGYtOGNhZC00N2QzLTkxMDYtZGZmYmY3ODA5MGIy VGFibGUgew0KCU1BUkdJTjogMGNtIDBjbSAwcHQNCn0NCkRJVi5TZWN0aW9uMSB7DQoJcGFnZTog U2VjdGlvbjENCn0NCjwvc3R5bGU+PHN0eWxlIHR5cGU9InRleHQvY3NzIj4KPCEtLQotLT4KPC9z dHlsZT48c3R5bGU+CjwhLS0KQGZvbnQtZmFjZQoJe2ZvbnQtZmFtaWx5OkNhbGlicml9CkBmb250 LWZhY2UKCXtmb250LWZhbWlseTpUYWhvbWF9CnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRp di5Nc29Ob3JtYWwKCXttYXJnaW46MGluOwoJbWFyZ2luLWJvdHRvbTouMDAwMXB0OwoJZm9udC1z aXplOjEyLjBwdDsKCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiJ9CmE6bGlu aywgc3Bhbi5Nc29IeXBlcmxpbmsKCXtjb2xvcjpibHVlOwoJdGV4dC1kZWNvcmF0aW9uOnVuZGVy bGluZX0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkCgl7Y29sb3I6cHVycGxl OwoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZX0KcAoJe21hcmdpbi1yaWdodDowaW47CgltYXJn aW4tbGVmdDowaW47Cglmb250LXNpemU6MTIuMHB0OwoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBS b21hbiIsInNlcmlmIn0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0YXRlLCBkaXYuTXNvQWNldGF0 ZQoJe21hcmdpbjowaW47CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7Cglmb250LXNpemU6OC4wcHQ7 Cglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiJ9CnAubXNvY2hwZGVmYXVsdCwgbGku bXNvY2hwZGVmYXVsdCwgZGl2Lm1zb2NocGRlZmF1bHQKCXttYXJnaW4tcmlnaHQ6MGluOwoJbWFy Z2luLWxlZnQ6MGluOwoJZm9udC1zaXplOjEwLjBwdDsKCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg Um9tYW4iLCJzZXJpZiJ9CnNwYW4uZW1haWxzdHlsZTIxCgl7Zm9udC1mYW1pbHk6IkNhbGlicmki LCJzYW5zLXNlcmlmIjsKCWNvbG9yOiMxRjQ5N0R9CnNwYW4uQmFsbG9vblRleHRDaGFyCgl7Zm9u dC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYifQpzcGFuLkVtYWlsU3R5bGUyNQoJe2ZvbnQt ZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Cgljb2xvcjojMUY0OTdEfQouTXNvQ2hwRGVm YXVsdAoJe2ZvbnQtc2l6ZToxMC4wcHR9CkBwYWdlIFdvcmRTZWN0aW9uMQoJe21hcmdpbjoxLjBp biAxLjBpbiAxLjBpbiAxLjBpbn0Kb2wKCXttYXJnaW4tYm90dG9tOjBpbn0KdWwKCXttYXJnaW4t Ym90dG9tOjBpbn0KLS0+Cjwvc3R5bGU+PHN0eWxlIHR5cGU9InRleHQvY3NzIiBpZD0ib3dhUGFy YVN0eWxlIj4KPCEtLQotLT4KPC9zdHlsZT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBs aW5rPSJibHVlIiB2bGluaz0icHVycGxlIiBmcHN0eWxlPSIxIiBvY3NpPSIwIj4NCjxwIGNsYXNz PSJmOTZmMmE4Zi04Y2FkLTQ3ZDMtOTEwNi1kZmZiZjc4MDkwYjIiPjwvcD4NCjxkaXYgc3R5bGU9 ImRpcmVjdGlvbjogbHRyO2ZvbnQtZmFtaWx5OiBUYWhvbWE7Y29sb3I6ICMwMDAwMDA7Zm9udC1z aXplOiAxMHB0OyI+SGVsbG8sDQo8ZGl2PkFyZSB0aGVyZSBhbnkgbW9yZSBibG9ja2VycyBpbiB0 aGUgd2F5IG9mIHByb2dyZXNzaW5nIHRoaXMgZG9jdW1lbnQ/PC9kaXY+DQo8ZGl2Pjxicj4NCjwv ZGl2Pg0KPGRpdj5SZWdhcmRzLDwvZGl2Pg0KPGRpdj5KYW1lczxicj4NCjxkaXY+PGJyPg0KPGRp diBzdHlsZT0iZm9udC1mYW1pbHk6VGFob21hOyBmb250LXNpemU6MTNweCI+DQo8ZGl2IGNsYXNz PSJCb2R5RnJhZ21lbnQiPjxmb250IHNpemU9IjIiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTBw dCI+DQo8ZGl2IGNsYXNzPSJQbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyA8YnI+DQo9PT09PT09PT09PGJyPg0KSmFtZXMgU2FuZGZvcmQ8YnI+DQpSJmFtcDtEIEVu Z2luZWVyPGJyPg0KPGJyPg0KQkJDIFJlc2VhcmNoIGFuZCBEZXZlbG9wbWVudDxicj4NCjV0aCBG bG9vcjxicj4NCkRvY2sgSG91c2U8YnI+DQpNZWRpYUNpdHlVSzxicj4NClNhbGZvcmQ8YnI+DQpN NTAgMkxIPGJyPg0KPGJyPg0KVGVsOiAwMzAzMDQgKDA5NTQ5KTxicj4NCldlYjogaHR0cDovL3d3 dy5iYmMuY28udWsvcmQ8L2Rpdj4NCjwvc3Bhbj48L2ZvbnQ+PC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IFRpbWVzIE5ldyBSb21hbjsgY29sb3I6ICMwMDAw MDA7IGZvbnQtc2l6ZTogMTZweCI+DQo8aHIgdGFiaW5kZXg9Ii0xIj4NCjxkaXYgaWQ9ImRpdlJw RjYzODU5NCIgc3R5bGU9ImRpcmVjdGlvbjogbHRyOyI+PGZvbnQgZmFjZT0iVGFob21hIiBzaXpl PSIyIiBjb2xvcj0iIzAwMDAwMCI+PGI+RnJvbTo8L2I+IHBheWxvYWQgW3BheWxvYWQtYm91bmNl c0BpZXRmLm9yZ10gb24gYmVoYWxmIG9mIEphbWVzIFNhbmRmb3JkIFtqYW1lcy5zYW5kZm9yZEBi YmMuY28udWtdPGJyPg0KPGI+U2VudDo8L2I+IDIyIEZlYnJ1YXJ5IDIwMTkgMTM6MzQ8YnI+DQo8 Yj5Ubzo8L2I+IFJvbmkgRXZlbiAoQSk7IE5pZ2VsIE1lZ2l0dDsgcGF5bG9hZEBpZXRmLm9yZzxi cj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW3BheWxvYWRdIG5ldyBkcmFmdCAtIFJUUCBQYXlsb2Fk IGZvciBUVE1MIFRpbWVkIFRleHQ8YnI+DQo8L2ZvbnQ+PGJyPg0KPC9kaXY+DQo8ZGl2PjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSI1ZjIwMmY4MS03MzEwLTRjNjEtYmQxOS03M2VhMzUyODRmM2Ei PjwvcD4NCjxkaXYgc3R5bGU9ImRpcmVjdGlvbjpsdHI7IGZvbnQtZmFtaWx5OlRhaG9tYTsgY29s b3I6IzAwMDAwMDsgZm9udC1zaXplOjEwcHQiPkhlbGxvLA0KPGRpdj5OZXcgdmVyc2lvbiB1cGxv YWRlZCB0aGF0IGFkZHJlc3NlcyB0aGUgY29uY2VybnMgcmFpc2VkIGJ5IHRoZSBXM0MgVFRXRy48 L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PjxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNr ZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXNhbmRmb3JkLXBheWxvYWQtcnRwLXR0bWwvMDMvIiB0YXJn ZXQ9Il9ibGFuayIgcmVsPSJub29wZW5lciBub3JlZmVycmVyIj5odHRwczovL2RhdGF0cmFja2Vy LmlldGYub3JnL2RvYy9kcmFmdC1zYW5kZm9yZC1wYXlsb2FkLXJ0cC10dG1sLzAzLzwvYT48L2Rp dj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PlJlZ2FyZHMsPC9kaXY+DQo8ZGl2PkphbWVzPGJy Pg0KPGRpdj48YnI+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTpUYWhvbWE7IGZvbnQtc2l6ZTox M3B4Ij4NCjxkaXYgY2xhc3M9IkJvZHlGcmFnbWVudCI+PGZvbnQgc2l6ZT0iMiI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMHB0Ij4NCjxkaXYgY2xhc3M9IlBsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDxicj4NCj09PT09PT09PT08YnI+DQpKYW1lcyBTYW5kZm9y ZDxicj4NClImYW1wO0QgRW5naW5lZXI8YnI+DQo8YnI+DQpCQkMgUmVzZWFyY2ggYW5kIERldmVs b3BtZW50PGJyPg0KNXRoIEZsb29yPGJyPg0KRG9jayBIb3VzZTxicj4NCk1lZGlhQ2l0eVVLPGJy Pg0KU2FsZm9yZDxicj4NCk01MCAyTEg8YnI+DQo8YnI+DQpUZWw6IDAzMDMwNCAoMDk1NDkpPGJy Pg0KV2ViOiBodHRwOi8vd3d3LmJiYy5jby51ay9yZDwvZGl2Pg0KPC9zcGFuPjwvZm9udD48L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTpUaW1lcyBOZXcgUm9t YW47IGNvbG9yOiMwMDAwMDA7IGZvbnQtc2l6ZToxNnB4Ij4NCjxociB0YWJpbmRleD0iLTEiPg0K PGRpdiBpZD0iZGl2UnBGMzUzNTIzIiBzdHlsZT0iZGlyZWN0aW9uOmx0ciI+PGZvbnQgZmFjZT0i VGFob21hIiBzaXplPSIyIiBjb2xvcj0iIzAwMDAwMCI+PGI+RnJvbTo8L2I+IFJvbmkgRXZlbiAo QSkgW3JvbmkuZXZlbkBodWF3ZWkuY29tXTxicj4NCjxiPlNlbnQ6PC9iPiAxNCBGZWJydWFyeSAy MDE5IDA2OjE0PGJyPg0KPGI+VG86PC9iPiBKYW1lcyBTYW5kZm9yZDsgTmlnZWwgTWVnaXR0OyBw YXlsb2FkQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJFOiBbcGF5bG9hZF0gbmV3IGRy YWZ0IC0gUlRQIFBheWxvYWQgZm9yIFRUTUwgVGltZWQgVGV4dDxicj4NCjwvZm9udD48YnI+DQo8 L2Rpdj4NCjxkaXY+PC9kaXY+DQo8ZGl2Pg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0OyBmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7IGNvbG9yOiMx RjQ5N0QiPkhpIEphbWVzLDwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDsgZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7OyBjb2xvcjojMUY0OTdEIj5QbGVhc2UgY2hhbmdlIHRoZSBp bmRpdmlkdWFsIGRyYWZ0LiAmbmJzcDtJdCB3aWxsIGJlIGdvb2QgdG8gZ2V0IGFncmVlbWVudCBm cm9tIE5pZ2VsIG9yIG90aGVycyBmcm9tIDNHUFAgYmFzZWQgb24gdGhlc2UgY2hhbmdlcyBiZWZv cmUgcHJvZ3Jlc3NpbmcgdGhlIHdvcmsgaW4NCiB0aGUgSUVURjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDsgZm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7OyBjb2xvcjojMUY0OTdE Ij4mbmJzcDs8L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7IGZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90OzsgY29sb3I6IzFGNDk3RCI+UmVnYXJkczwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDsgZm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7OyBjb2xvcjojMUY0OTdE Ij5Sb25pIEV2ZW4NCjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDsgZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7OyBjb2xvcjojMUY0OTdEIj5QYXlsb2FkIFdHIGNvLWNoYWlyPC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0OyBmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7IGNvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0i Ym9yZGVyOm5vbmU7IGJvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDsgcGFkZGluZzozLjBw dCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDsgZm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDsgZm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsi PiBKYW1lcyBTYW5kZm9yZCBbbWFpbHRvOmphbWVzLnNhbmRmb3JkQGJiYy5jby51a10NCjxicj4N CjxiPlNlbnQ6PC9iPiBXZWRuZXNkYXksIEZlYnJ1YXJ5IDEzLCAyMDE5IDExOjI1IEFNPGJyPg0K PGI+VG86PC9iPiBSb25pIEV2ZW4gKEEpOyBOaWdlbCBNZWdpdHQ7IHBheWxvYWRAaWV0Zi5vcmc8 YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUkU6IFtwYXlsb2FkXSBuZXcgZHJhZnQgLSBSVFAgUGF5bG9h ZCBmb3IgVFRNTCBUaW1lZCBUZXh0PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj4mbmJzcDs8L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7IGZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7OyBjb2xvcjpibGFjayI+VGhhbmtzLCBSb25pLiBTaG91 bGQgSSBtYWtlIHRoZXNlIGNoYW5nZXMgbm93IG9yIHdhaXQgdW50aWwgdGhlIGNhbGwgZm9yIHRo ZSBXRyB0byBhZG9wdCB2MDIgaGFzIGxhcHNlZD8NCjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7IGZvbnQtZmFtaWx5 OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7OyBjb2xvcjpibGFjayI+ Jm5ic3A7PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0OyBmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OzsgY29sb3I6YmxhY2siPlJlZ2FyZHMsPC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0OyBmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90OzsgY29sb3I6YmxhY2siPkphbWVzPC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDsgZm9udC1mYW1pbHk6 JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7IGNvbG9yOmJsYWNrIj4m bmJzcDs8L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7IGZvbnQtZmFtaWx5OiZxdW90O1RhaG9t YSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7OyBjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8YnI+DQo9PT09PT09PT09PGJyPg0KSmFtZXMgU2FuZGZv cmQ8YnI+DQpSJmFtcDtEIEVuZ2luZWVyPGJyPg0KPGJyPg0KQkJDIFJlc2VhcmNoIGFuZCBEZXZl bG9wbWVudDxicj4NCjV0aCBGbG9vcjxicj4NCkRvY2sgSG91c2U8YnI+DQpNZWRpYUNpdHlVSzxi cj4NClNhbGZvcmQ8YnI+DQpNNTAgMkxIPGJyPg0KPGJyPg0KVGVsOiAwMzAzMDQgKDA5NTQ5KTxi cj4NCldlYjogPGEgaHJlZj0iaHR0cDovL3d3dy5iYmMuY28udWsvcmQiIHJlbD0ibm9vcGVuZXIg bm9yZWZlcnJlciIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0cDovL3d3dy5iYmMuY28udWsvcmQ8L2E+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYg Y2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImNlbnRlciIgc3R5bGU9InRleHQtYWxpZ246Y2VudGVy Ij48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPg0KPGhyIHNpemU9IjIiIHdpZHRoPSIxMDAlIiBh bGlnbj0iY2VudGVyIj4NCjwvc3Bhbj48L2Rpdj4NCjxkaXYgaWQ9ImRpdlJwRjI4MTY0OSI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0OyBmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90OzsgY29sb3I6YmxhY2siPkZyb206PC9zcGFuPjwvYj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDsgZm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7IGNvbG9yOmJsYWNrIj4gUm9uaSBFdmVuIChBKSBbcm9u aS5ldmVuQGh1YXdlaS5jb21dPGJyPg0KPGI+U2VudDo8L2I+IDEyIEZlYnJ1YXJ5IDIwMTkgMDc6 NTI8YnI+DQo8Yj5Ubzo8L2I+IE5pZ2VsIE1lZ2l0dDsgPGEgaHJlZj0ibWFpbHRvOnBheWxvYWRA aWV0Zi5vcmciIHJlbD0ibm9vcGVuZXIgbm9yZWZlcnJlciIgdGFyZ2V0PSJfYmxhbmsiPg0KcGF5 bG9hZEBpZXRmLm9yZzwvYT48YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtwYXlsb2FkXSBuZXcg ZHJhZnQgLSBSVFAgUGF5bG9hZCBmb3IgVFRNTCBUaW1lZCBUZXh0PC9zcGFuPjxzcGFuIHN0eWxl PSJjb2xvcjpibGFjayI+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDsgZm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7OyBjb2xvcjojMUY0OTdE Ij5IaSw8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7IGZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OzsgY29sb3I6IzFGNDk3 RCI+VGhhbmtzIGZvciB0aGUgaW5mb3JtYXRpb24uPC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpi bGFjayI+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0OyBmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7IGNvbG9yOiMxRjQ5N0QiPlRoZSB3YXkgSSBzZWUgaXQgaXMgdGhhdCB0aGlz IGRvY3VtZW50IG9ubHkgd2FudHMgdG8gc3BlY2lmeSBob3cgdG8gc2VuZCBUVE0gdGltZSB0ZXh0 IHVzaW5nIFJUUCB3aGljaCBpcyBub3Qgc3BlY2lmaWVkIGJ5IFczQzwvc3Bhbj48c3BhbiBzdHls ZT0iY29sb3I6YmxhY2siPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDsgZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7OyBjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4g c3R5bGU9ImNvbG9yOmJsYWNrIj48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7IGZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OzsgY29sb3I6IzFGNDk3RCI+SSB0aGluayB0aGF0IHRo ZSB0ZXh0IGV4cGxhaW5zIGl0IGJ1dCBtYXliZSB3ZSBuZWVkIGJldHRlciBjbGFyaWZpY2F0aW9u LCBhbnkgaW5wdXQgaXMgd2VsY29tZS4gSSB0aGluayB0aGF0IGF0IGxlYXN0IGl0IHNob3VsZCBz YXkgdGhhdCB0aGlzIGRvY3VtZW50IG9ubHkNCiBkZWZpbmUgaG93IHRvIGNhcnJ5IFRUTUwgdGlt ZSB0ZXh0IG92ZXIgUlRQIHVzaW5nIHRoZSBtZWRpYSBzdWJ0eXBlIGRlZmluZWQgYnkgVzNDIGFu ZCByZWZlcmVuY2UgdGhlIHJlbGV2YW50IFczQyBkb2N1bWVudC48L3NwYW4+PHNwYW4gc3R5bGU9 ImNvbG9yOmJsYWNrIj48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7IGZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90OzsgY29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0 eWxlPSJjb2xvcjpibGFjayI+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0OyBmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7IGNvbG9yOiMxRjQ5N0QiPkkgYWdyZWUgdGhhdCB3ZSBk byBub3QgbmVlZCB0aGUgcmVnaXN0cmF0aW9uIHRlbXBsYXRlIHNpbmNlIHRoZSBkb2N1bWVudCBz dWdnZXN0IHVzaW5nIHRoZSBjdXJyZW50IHJlZ2lzdHJhdGlvbiBpbiB0aGUgSUFOQSBtZWRpYSZu YnNwOyB0eXBlLCBzbyB0aGUgSUFOQSBjb25zaWRlcmF0aW9uDQogc2hvdWxkIG9ubHkgYXNrIGZv ciBhZGRpbmcgdGhlIHJlZmVyZW5jZSB0byB0aGlzIGRvY3VtZW50IGluIHRoZSBjdXJyZW50IHJl Z2lzdHJhdGlvbi4gVGhpcyBhc3N1bWVzIHRoYXQgdGhlcmUgYXJlIG5vIGNoYW5nZXMgaW4gdGhl IHJlZ2lzdHJhdGlvbiByZXF1aXJlZC4mbmJzcDsgJm5ic3A7QW5vdGhlciBkaXJlY3Rpb24gaXMg dG8gaGF2ZSBhIGRpZmZlcmVudCBtZWRpYSBzdWJ0eXBlIG5hbWUgZm9yIHRoZSBSVFAgdXNhZ2Ug YnV0IEluIHNlZSBubyByZWFsIHJlYXNvbg0KIGlmIHRoZSBkb2N1bWVudCBvbmx5IHNwZWNpZnkg aG93IHRvIHVzZSB0aGlzIHBheWxvYWQgb3ZlciBSVFAgYW5kIGNoYW5nZSBub3RoaW5nIGluIHRo ZSBjdXJyZW50IHJlZ2lzdHJhdGlvbi48L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7IGZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90OzsgY29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFj ayI+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0OyBmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7IGNvbG9yOiMxRjQ5N0QiPlRoZSBvbmx5IG90aGVyIGNvbW1lbnQgSSBub3RpY2Vk IGlzIOKAnDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDsgZm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7OyBjb2xvcjpibGFjayI+ QSByZXF1ZXN0IHRvIG1ha2Ugc3VyZSB0aGF0IHRoZQ0KIGxhbmd1YWdlIGFib3V0IHByb2ZpbGUg c2lnbmFsbGluZyBkb2VzIG5vdCBpbXBseSB0aGF0IHRoZSBjb2RlY3MgcGFyYW1ldGVyIGNhbiBk ZW5vdGUgYWxsIHByb2ZpbGVzLCBlc3BlY2lhbGx5IGluIHRoZSBjYXNlIHRoYXQgdGhlIHBheWxv YWQgZG9jdW1lbnQgY29udGFpbnMgYW4gZW1iZWRkZWQgcHJvZmlsZS48L3NwYW4+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7IGZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90OzsgY29sb3I6IzFGNDk3RCI+4oCcJm5ic3A7DQogVGhpcyBzaG91 bGQgYmUgYWRkcmVzc2VkIGJ5IHRoZSBhdXRob3JzPC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpi bGFjayI+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0OyBmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7IGNvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iY29s b3I6YmxhY2siPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDsgZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7OyBjb2xvcjojMUY0OTdEIj5MZXQgdGhlIFdHIGtub3cgaWYgdGhpcyBz b3VuZHMgcmVhc29uYWJsZTwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDsg Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7OyBj b2xvcjojMUY0OTdEIj5Sb25pIEV2ZW4NCjwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2si Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDsgZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7OyBjb2xvcjojMUY0OTdEIj5QYXlsb2FkIFdHIGNvLWNoYWlyPC9zcGFuPjxzcGFuIHN0 eWxlPSJjb2xvcjpibGFjayI+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0OyBmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7IGNvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3Bh biBzdHlsZT0iY29sb3I6YmxhY2siPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDsgZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7OyBjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+ PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7IGZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OzsgY29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9z cGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0OyBmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7IGNvbG9yOiMxRjQ5N0QiPiZuYnNw Ozwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRp diBzdHlsZT0iYm9yZGVyOm5vbmU7IGJvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDsgcGFk ZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDsgZm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7IGNvbG9yOmJsYWNrIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7IGZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7OyBjb2xvcjpibGFjayI+IHBheWxvYWQgWzxhIGhyZWY9Im1h aWx0bzpwYXlsb2FkLWJvdW5jZXNAaWV0Zi5vcmciIHJlbD0ibm9vcGVuZXIgbm9yZWZlcnJlciIg dGFyZ2V0PSJfYmxhbmsiPm1haWx0bzpwYXlsb2FkLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XQ0KPGI+ T24gQmVoYWxmIE9mIDwvYj5OaWdlbCBNZWdpdHQ8YnI+DQo8Yj5TZW50OjwvYj4gTW9uZGF5LCBG ZWJydWFyeSAxMSwgMjAxOSA1OjE2IFBNPGJyPg0KPGI+VG86PC9iPiA8YSBocmVmPSJtYWlsdG86 cGF5bG9hZEBpZXRmLm9yZyIgcmVsPSJub29wZW5lciBub3JlZmVycmVyIiB0YXJnZXQ9Il9ibGFu ayI+DQpwYXlsb2FkQGlldGYub3JnPC9hPjxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW3BheWxv YWRdIG5ldyBkcmFmdCAtIFJUUCBQYXlsb2FkIGZvciBUVE1MIFRpbWVkIFRleHQ8L3NwYW4+PHNw YW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjwv cD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjVwdDsgZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7OyBjb2xvcjpibGFjayI+RGVhciBJRVRGIFBheWxvYWQgZ3JvdXAsPC9zcGFuPjxzcGFuIHN0 eWxlPSJjb2xvcjpibGFjayI+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0OyBmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7IGNvbG9yOmJsYWNrIj4mbmJz cDs8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7 IGZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Ozsg Y29sb3I6YmxhY2siPlRoaXMgZHJhZnQgd2FzIGRpc2N1c3NlZCBieSB0aGUgVzNDIFRpbWVkIFRl eHQgV29ya2luZyBHcm91cCAoVFRXRykgb24gMjAxOS0wMi0wNyBbMV0uPC9zcGFuPjxzcGFuIHN0 eWxlPSJjb2xvcjpibGFjayI+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7IGZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OzsgY29sb3I6YmxhY2siPiZuYnNwOzwvc3Bh bj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7IGZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OzsgY29sb3I6YmxhY2siPlsx XSBNaW51dGVzIG9mIFczQyBUVFdHIG1lZXRpbmcgMjAxOS0wMi0wNzombmJzcDs8YSBocmVmPSJo dHRwczovL3d3dy53My5vcmcvMjAxOS8wMi8wNy10dC1taW51dGVzLmh0bWwjaXRlbTAzIiByZWw9 Im5vb3BlbmVyIG5vcmVmZXJyZXIiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy53My5vcmcv MjAxOS8wMi8wNy10dC1taW51dGVzLmh0bWwjaXRlbTAzPC9hPjwvc3Bhbj48c3BhbiBzdHlsZT0i Y29sb3I6YmxhY2siPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDsgZm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7OyBjb2xvcjpibGFjayI+Jm5ic3A7PC9z cGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0OyBmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7IGNvbG9y OmJsYWNrIj5EdXJpbmcgdGhlIG1lZXRpbmcgY29uY2VybiB3YXMgcmFpc2VkIGFib3V0IHRoZSBh cHByb2FjaCB0byB0aGUgSUFOQSByZWdpc3RlcmVkIG1lZGlhIHR5cGUsIHNwZWNpZmljYWxseSB0 aGUgbWVhbmluZyBvZiBzZWN0aW9uIDguIElBTkEgQ29uc2lkZXJhdGlvbnMuPC9zcGFuPjxzcGFu IHN0eWxlPSJjb2xvcjpibGFjayI+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0OyBmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7IGNvbG9yOmJsYWNrIj4m bmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41 cHQ7IGZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 OzsgY29sb3I6YmxhY2siPlRoZXJlIHdhcyBjb25zZW5zdXMgYW1vbmdzdCB0aGUgZ3JvdXAgdGhh dCB0aGUgdGV4dCBzcGVjaWZ5aW5nIHRoYXQgdGhpcyB0ZXh0Ojwvc3Bhbj48c3BhbiBzdHlsZT0i Y29sb3I6YmxhY2siPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDsgZm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7OyBjb2xvcjpibGFjayI+Jm5ic3A7PC9z cGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0OyBmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7IGNvbG9y OmJsYWNrIj7igJxUaGUgbWVkaWEgdHlwZXMgcmVnaXN0cnkgU0hPVUxEIGJlIHVwZGF0ZWQgdG8g bWFrZSByZWZlcmVuY2UgdG8gdGhpcyBkb2N1bWVudCBmb3IgdGhlIGFwcGxpY2F0aW9uL3R0bWwm IzQzO3htbCBtZWRpYSB0eXBlLuKAnSZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6Ymxh Y2siPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDsgZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7OyBjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxzcGFu IHN0eWxlPSJjb2xvcjpibGFjayI+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0OyBmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7IGNvbG9yOmJsYWNrIj5p cyBpbmNvcnJlY3QgYW5kIG5lZWRzIHRvIGJlIGNoYW5nZWQuIFRoZSBtZWRpYSB0eXBlIHJlZ2lz dHJhdGlvbiBmb3IgVFRNTCBpcyBvd25lZCBieSBXM0MgYW5kIHNob3VsZCBub3QgYmUgY2hhbmdl ZCBieSBJRVRGIOKAkyB3ZSBub3RlIHRoYXQgdGhlIGNoYW5nZSBjb250cm9sDQogaXMgY2xlYXJs eSBtYXJrZWQgYXMgYmVpbmcgb3duZWQgYnkgVzNDIHNvIGluIHRoYXQgc2Vuc2UgdGhpcyB0ZXh0 IGlzIGluY29uc2lzdGVudC48L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC41cHQ7IGZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90OzsgY29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iY29s b3I6YmxhY2siPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDsgZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7OyBjb2xvcjpibGFjayI+VGhlIElBTkEgbWVk aWEgdHlwZSByZWdpc3RyYXRpb24gaXRzZWxmIGRlZmVycyB0byB0aGUgVFRXRyBkb2N1bWVudCDi gJxUVE1MIE1lZGlhIFR5cGUgRGVmaW5pdGlvbiBhbmQgUHJvZmlsZSBSZWdpc3RyeeKAnSBbMl0g d2hpY2ggaXMgYWxyZWFkeSByZWZlcmVuY2VkIGJ5IHRoZQ0KIFJUUCBQYXlsb2FkIGRyYWZ0LiBB biBpbXByb3ZlbWVudCB3b3VsZCB0aGVyZWZvcmUgYmUgdG8gdXBkYXRlIHRoZSB0ZXh0IGluIHNl Y3Rpb24gOCB0byBzdWdnZXN0IHRoYXQgWzJdIGNhbiBiZSB1cGRhdGVkIHRvIGluY2x1ZGUgdGhl IHByb2ZpbGVzIGRlZmluZWQgd2l0aGluIHRoZSBwYXlsb2FkIGRvY3VtZW50LiBJbmRlZWQgZG9p bmcgc28gd291bGQgcmVzdWx0IGluIHRoZSBjcmVhdGlvbiBvZiBhIHNob3J0IGNvZGUgZm9yIHRo ZSBwcm9maWxlDQogcHJvY2Vzc29yIG1lbnRpb25lZCBpbiBzZWN0aW9uJm5ic3A7NC4yLjEuMi4x LjMgUHJvY2Vzc29yIHByb2ZpbGUgc2lnbmFsbGluZy48L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9y OmJsYWNrIj48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7IGZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OzsgY29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48 c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDsgZm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7OyBjb2xvcjpibGFj ayI+WzJdIFRUTUwgTWVkaWEgVHlwZSBEZWZpbml0aW9uIGFuZCBQcm9maWxlIFJlZ2lzdHJ5Jm5i c3A7PGEgaHJlZj0iaHR0cHM6Ly93d3cudzMub3JnL1RSL3R0bWwtcHJvZmlsZS1yZWdpc3RyeSIg cmVsPSJub29wZW5lciBub3JlZmVycmVyIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cudzMu b3JnL1RSL3R0bWwtcHJvZmlsZS1yZWdpc3RyeTwvYT4vPC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xv cjpibGFjayI+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0OyBmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7IGNvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+ PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7IGZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OzsgY29sb3I6Ymxh Y2siPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjVwdDsgZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7OyBjb2xvcjpibGFjayI+VGhlIFRUV0cgYWxzbyBkaXNjdXNzZWQgdHdvIGFkZGl0aW9u YWwgY29uY2VybnMgd2l0aG91dCBjbG9zaW5nIG9uIGEgcG9zaXRpb24gYXQgdGhpcyB0aW1lOjwv c3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxvbCBz dGFydD0iMSIgdHlwZT0iMSIgc3R5bGU9Im1hcmdpbi10b3A6MGluIj4NCjxsaSBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0iY29sb3I6YmxhY2siPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0 OyBmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsi PkEgcXVlcnkgd2hldGhlciB0aGUgbWVkaWEgdHlwZSByZWdpc3RyYXRpb24gaW5mb3JtYXRpb24g cmVhbGx5IG5lZWRzIHRvIGJlIGNvcGllZCBpbiBhdCBhbGwgaGVyZSBvciBpZiBpdCBjYW4gYmUg cmVmZXJlbmNlZDs8L3NwYW4+PC9saT48bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImNvbG9y OmJsYWNrIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDsgZm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5BIHJlcXVlc3QgdG8gbWFrZSBz dXJlIHRoYXQgdGhlIGxhbmd1YWdlIGFib3V0IHByb2ZpbGUgc2lnbmFsbGluZyBkb2VzIG5vdCBp bXBseSB0aGF0IHRoZSBjb2RlY3MgcGFyYW1ldGVyIGNhbiBkZW5vdGUgYWxsIHByb2ZpbGVzLCBl c3BlY2lhbGx5IGluIHRoZQ0KIGNhc2UgdGhhdCB0aGUgcGF5bG9hZCBkb2N1bWVudCBjb250YWlu cyBhbiBlbWJlZGRlZCBwcm9maWxlLjwvc3Bhbj48L2xpPjwvb2w+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7IGZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OzsgY29sb3I6YmxhY2siPlRU V0cgbWF5IHByb3ZpZGUgZnVydGhlciBpbnB1dCBvbiB0aG9zZSB0d28gcG9pbnRzIGJ1dCB3b3Vs ZCB3ZWxjb21lIGZ1cnRoZXIgaW5wdXQgZXNwZWNpYWxseSBvbiB0aGUgZmlyc3QuPC9zcGFuPjxz cGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0OyBmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7IGNvbG9yOmJsYWNr Ij4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC41cHQ7IGZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90OzsgY29sb3I6YmxhY2siPktpbmQgcmVnYXJkcyw8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9y OmJsYWNrIj48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7IGZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OzsgY29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48 c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDsgZm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7OyBjb2xvcjpibGFj ayI+TmlnZWwgTWVnaXR0IGFzIENoYWlyIG9mIFczQyBUVFdHPC9zcGFuPjxzcGFuIHN0eWxlPSJj b2xvcjpibGFjayI+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0OyBmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7IGNvbG9yOmJsYWNrIj4mbmJzcDs8L3Nw YW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFz cz0iMTc5YjI1YTItMzJjYi00OWQ3LWI5Y2ItNzg3MTQyNGQ5OWU5Ij48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjVwdDsgZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7OyBjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xv cjpibGFjayI+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSIxNzliMjVhMi0zMmNiLTQ5ZDctYjljYi03 ODcxNDI0ZDk5ZTkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0OyBmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7IGNvbG9yOmJsYWNrIj4t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPGJyPg0KPC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xv cjpibGFjayI+PGJyPg0KPGEgaHJlZj0iaHR0cDovL3d3dy5iYmMuY28udWsiIHJlbD0ibm9vcGVu ZXIgbm9yZWZlcnJlciIgdGFyZ2V0PSJfYmxhbmsiPmh0dHA6Ly93d3cuPHNwYW4gY2xhc3M9Imls Ij5iYmM8L3NwYW4+LjxzcGFuIGNsYXNzPSJpbCI+Y288L3NwYW4+LjxzcGFuIGNsYXNzPSJpbCI+ dWs8L3NwYW4+PC9hPjxicj4NClRoaXMgZS1tYWlsIChhbmQgYW55IGF0dGFjaG1lbnRzKSBpcyBj b25maWRlbnRpYWwgYW5kIG1heSBjb250YWluIHBlcnNvbmFsIHZpZXdzIHdoaWNoIGFyZSBub3Qg dGhlIHZpZXdzIG9mIHRoZQ0KPHNwYW4gY2xhc3M9ImlsIj5CQkM8L3NwYW4+IHVubGVzcyBzcGVj aWZpY2FsbHkgc3RhdGVkLjxicj4NCklmIHlvdSBoYXZlIHJlY2VpdmVkIGl0IGluIGVycm9yLCBw bGVhc2UgZGVsZXRlIGl0IGZyb20geW91ciBzeXN0ZW0uPGJyPg0KRG8gbm90IHVzZSwgY29weSBv ciBkaXNjbG9zZSB0aGUgaW5mb3JtYXRpb24gaW4gYW55IHdheSBub3IgYWN0IGluIHJlbGlhbmNl IG9uIGl0IGFuZCBub3RpZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVseS48YnI+DQpQbGVhc2Ugbm90 ZSB0aGF0IHRoZSA8c3BhbiBjbGFzcz0iaWwiPkJCQzwvc3Bhbj4gbW9uaXRvcnMgZS1tYWlscyBz ZW50IG9yIHJlY2VpdmVkLjxicj4NCkZ1cnRoZXIgY29tbXVuaWNhdGlvbiB3aWxsIHNpZ25pZnkg eW91ciBjb25zZW50IHRvIHRoaXMuPC9zcGFuPjwvcD4NCjxwIGNsYXNzPSIxNzliMjVhMi0zMmNi LTQ5ZDctYjljYi03ODcxNDI0ZDk5ZTkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0OyBm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7IGNv bG9yOmJsYWNrIj4tLS0tLS0tLS0tLS0tLS0tLS0tLS08L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9y OmJsYWNrIj48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjxwIGNsYXNzPSI5OGJlMDc0Yi02OTI0LTQ1ODktOWRkNy1mOWQ0ZWU2NGFhYjgiPiZuYnNw OzwvcD4NCjxwIGNsYXNzPSI5OGJlMDc0Yi02OTI0LTQ1ODktOWRkNy1mOWQ0ZWU2NGFhYjgiPi0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08YnI+DQo8YnI+DQo8YSBocmVmPSJodHRwOi8vd3d3 LmJiYy5jby51ayIgcmVsPSJub29wZW5lciBub3JlZmVycmVyIiB0YXJnZXQ9Il9ibGFuayI+aHR0 cDovL3d3dy48c3BhbiBjbGFzcz0iaWwiPmJiYzwvc3Bhbj4uPHNwYW4gY2xhc3M9ImlsIj5jbzwv c3Bhbj4uPHNwYW4gY2xhc3M9ImlsIj51azwvc3Bhbj48L2E+PGJyPg0KVGhpcyBlLW1haWwgKGFu ZCBhbnkgYXR0YWNobWVudHMpIGlzIGNvbmZpZGVudGlhbCBhbmQgbWF5IGNvbnRhaW4gcGVyc29u YWwgdmlld3Mgd2hpY2ggYXJlIG5vdCB0aGUgdmlld3Mgb2YgdGhlDQo8c3BhbiBjbGFzcz0iaWwi PkJCQzwvc3Bhbj4gdW5sZXNzIHNwZWNpZmljYWxseSBzdGF0ZWQuPGJyPg0KSWYgeW91IGhhdmUg cmVjZWl2ZWQgaXQgaW4gZXJyb3IsIHBsZWFzZSBkZWxldGUgaXQgZnJvbSB5b3VyIHN5c3RlbS48 YnI+DQpEbyBub3QgdXNlLCBjb3B5IG9yIGRpc2Nsb3NlIHRoZSBpbmZvcm1hdGlvbiBpbiBhbnkg d2F5IG5vciBhY3QgaW4gcmVsaWFuY2Ugb24gaXQgYW5kIG5vdGlmeSB0aGUgc2VuZGVyIGltbWVk aWF0ZWx5Ljxicj4NClBsZWFzZSBub3RlIHRoYXQgdGhlIDxzcGFuIGNsYXNzPSJpbCI+QkJDPC9z cGFuPiBtb25pdG9ycyBlLW1haWxzIHNlbnQgb3IgcmVjZWl2ZWQuPGJyPg0KRnVydGhlciBjb21t dW5pY2F0aW9uIHdpbGwgc2lnbmlmeSB5b3VyIGNvbnNlbnQgdG8gdGhpcy48L3A+DQo8cCBjbGFz cz0iOThiZTA3NGItNjkyNC00NTg5LTlkZDctZjlkNGVlNjRhYWI4Ij4tLS0tLS0tLS0tLS0tLS0t LS0tLS08L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHA+PC9w Pg0KPHAgY2xhc3M9IjVmMjAyZjgxLTczMTAtNGM2MS1iZDE5LTczZWEzNTI4NGYzYSI+Jm5ic3A7 PC9wPg0KPHAgY2xhc3M9IjVmMjAyZjgxLTczMTAtNGM2MS1iZDE5LTczZWEzNTI4NGYzYSI+LS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxicj4NCjxmb250IHNpemU9IjMiIGZhY2U9IlRpbWVz IE5ldyBSb21hbiI+PGZvbnQgc2l6ZT0iMyIgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48Zm9udCBz aXplPSIzIiBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxicj4NCjxmb250IHNpemU9IjMiIGZhY2U9 IlRpbWVzIE5ldyBSb21hbiI+PGEgaHJlZj0iaHR0cDovL3d3dy5iYmMuY28udWsiIHRhcmdldD0i X2JsYW5rIiByZWw9Im5vb3BlbmVyIG5vcmVmZXJyZXIiPmh0dHA6Ly93d3cuPHNwYW4gY2xhc3M9 ImlsIj5iYmM8L3NwYW4+LjxzcGFuIGNsYXNzPSJpbCI+Y288L3NwYW4+LjxzcGFuIGNsYXNzPSJp bCI+dWs8L3NwYW4+PC9hPjxicj4NClRoaXMgZS1tYWlsIChhbmQgYW55IGF0dGFjaG1lbnRzKSBp cyBjb25maWRlbnRpYWwgYW5kIG1heSBjb250YWluIHBlcnNvbmFsIHZpZXdzIHdoaWNoIGFyZSBu b3QgdGhlIHZpZXdzIG9mIHRoZQ0KPHNwYW4gY2xhc3M9ImlsIj5CQkM8L3NwYW4+IHVubGVzcyBz cGVjaWZpY2FsbHkgc3RhdGVkLjxicj4NCklmIHlvdSBoYXZlIHJlY2VpdmVkIGl0IGluIGVycm9y LCBwbGVhc2UgZGVsZXRlIGl0IGZyb20geW91ciBzeXN0ZW0uPGJyPg0KRG8gbm90IHVzZSwgY29w eSBvciBkaXNjbG9zZSB0aGUgaW5mb3JtYXRpb24gaW4gYW55IHdheSBub3IgYWN0IGluIHJlbGlh bmNlIG9uIGl0IGFuZCBub3RpZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVseS48YnI+DQpQbGVhc2Ug bm90ZSB0aGF0IHRoZSA8c3BhbiBjbGFzcz0iaWwiPkJCQzwvc3Bhbj4gbW9uaXRvcnMgZS1tYWls cyBzZW50IG9yIHJlY2VpdmVkLjxicj4NCkZ1cnRoZXIgY29tbXVuaWNhdGlvbiB3aWxsIHNpZ25p ZnkgeW91ciBjb25zZW50IHRvIHRoaXMuPC9mb250PjwvZm9udD48L2ZvbnQ+PC9mb250PjwvcD4N CjxwIGNsYXNzPSI1ZjIwMmY4MS03MzEwLTRjNjEtYmQxOS03M2VhMzUyODRmM2EiPi0tLS0tLS0t LS0tLS0tLS0tLS0tLTwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHA+PC9w Pg0KPHAgY2xhc3M9ImY5NmYyYThmLThjYWQtNDdkMy05MTA2LWRmZmJmNzgwOTBiMiI+Jm5ic3A7 PC9wPg0KPHAgY2xhc3M9ImY5NmYyYThmLThjYWQtNDdkMy05MTA2LWRmZmJmNzgwOTBiMiI+LS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxicj4NCjxmb250IHNpemU9IjMiIGZhY2U9IlRpbWVz IE5ldyBSb21hbiI+PGZvbnQgc2l6ZT0iMyIgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48Zm9udCBz aXplPSIzIiBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxicj4NCjxmb250IHNpemU9IjMiIGZhY2U9 IlRpbWVzIE5ldyBSb21hbiI+PGEgaHJlZj0iaHR0cDovL3d3dy5iYmMuY28udWsiIHRhcmdldD0i X2JsYW5rIj5odHRwOi8vd3d3LjxzcGFuIGNsYXNzPSJpbCI+YmJjPC9zcGFuPi48c3BhbiBjbGFz cz0iaWwiPmNvPC9zcGFuPi48c3BhbiBjbGFzcz0iaWwiPnVrPC9zcGFuPjwvYT48YnI+DQpUaGlz IGUtbWFpbCAoYW5kIGFueSBhdHRhY2htZW50cykgaXMgY29uZmlkZW50aWFsIGFuZCBtYXkgY29u dGFpbiBwZXJzb25hbCB2aWV3cyB3aGljaCBhcmUgbm90IHRoZSB2aWV3cyBvZiB0aGUNCjxzcGFu IGNsYXNzPSJpbCI+QkJDPC9zcGFuPiB1bmxlc3Mgc3BlY2lmaWNhbGx5IHN0YXRlZC48YnI+DQpJ ZiB5b3UgaGF2ZSByZWNlaXZlZCBpdCBpbiBlcnJvciwgcGxlYXNlIGRlbGV0ZSBpdCBmcm9tIHlv dXIgc3lzdGVtLjxicj4NCkRvIG5vdCB1c2UsIGNvcHkgb3IgZGlzY2xvc2UgdGhlIGluZm9ybWF0 aW9uIGluIGFueSB3YXkgbm9yIGFjdCBpbiByZWxpYW5jZSBvbiBpdCBhbmQgbm90aWZ5IHRoZSBz ZW5kZXIgaW1tZWRpYXRlbHkuPGJyPg0KUGxlYXNlIG5vdGUgdGhhdCB0aGUgPHNwYW4gY2xhc3M9 ImlsIj5CQkM8L3NwYW4+IG1vbml0b3JzIGUtbWFpbHMgc2VudCBvciByZWNlaXZlZC48YnI+DQpG dXJ0aGVyIGNvbW11bmljYXRpb24gd2lsbCBzaWduaWZ5IHlvdXIgY29uc2VudCB0byB0aGlzLjwv Zm9udD48L2ZvbnQ+PC9mb250PjwvZm9udD48L3A+DQo8cCBjbGFzcz0iZjk2ZjJhOGYtOGNhZC00 N2QzLTkxMDYtZGZmYmY3ODA5MGIyIj4tLS0tLS0tLS0tLS0tLS0tLS0tLS08L3A+DQo8L2JvZHk+ DQo8L2h0bWw+DQo= --_000_734752AF0E88364D983373FE5CEFED57594DAEB9bgb01xud1001_-- From nobody Mon Mar 4 02:59:37 2019 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B98D713112C for ; Mon, 4 Mar 2019 02:59:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KtL_p8Ha9BuE for ; Mon, 4 Mar 2019 02:59:32 -0800 (PST) Received: from mailout0.telhc.bbc.co.uk (mailout0.telhc.bbc.co.uk [132.185.161.179]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2EF0713114C for ; Mon, 4 Mar 2019 02:59:24 -0800 (PST) Received: from BGB01XI1012.national.core.bbc.co.uk (bgb01xi1012.national.core.bbc.co.uk [10.161.14.16]) by mailout0.telhc.bbc.co.uk (8.15.2/8.15.2) with ESMTP id x24AwxtW000688; Mon, 4 Mar 2019 10:58:59 GMT Received: from BGB01XUD1012.national.core.bbc.co.uk ([10.161.14.10]) by BGB01XI1012.national.core.bbc.co.uk ([10.161.14.16]) with mapi id 14.03.0408.000; Mon, 4 Mar 2019 10:58:59 +0000 From: Nigel Megitt To: James Sandford , "Roni Even (A)" , "payload@ietf.org" Thread-Topic: [payload] new draft - RTP Payload for TTML Timed Text Thread-Index: AQHUwhy5JnvrFU1bhEuuuCEhNcSFAKXbw/vwgAGzqYCAAV03AIANDYGAgA+Ev4CAAAcOAA== Date: Mon, 4 Mar 2019 10:58:58 +0000 Message-ID: References: <6E58094ECC8D8344914996DAD28F1CCD18CB3E04@dggemm526-mbx.china.huawei.com> <734752AF0E88364D983373FE5CEFED57594B9E61@bgb01xud1001> <6E58094ECC8D8344914996DAD28F1CCD18CB45C7@dggemm526-mbx.china.huawei.com> <734752AF0E88364D983373FE5CEFED57594C8CB8@bgb01xud1001> <734752AF0E88364D983373FE5CEFED57594DAEB9@bgb01xud1001> In-Reply-To: <734752AF0E88364D983373FE5CEFED57594DAEB9@bgb01xud1001> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.7.170905 x-originating-ip: [10.10.48.249] x-exclaimer-md-config: 1cd3ac1c-62e5-43f2-8404-6b688271c769 x-tm-as-product-ver: SMEX-12.5.0.1300-8.2.1013-24054.007 x-tm-as-result: No-23.436200-8.000000-10 x-tmase-matchedrid: TxtdI7DxMqo7iuZ/mdYYtgeLCIX046iBHX7XD4ho1lMdVxdNlp+7NSOa DLF/8wACgqRVCh9m0SeKC6Im4I1RFzK1/qdbjc7QKzMXWgba/W+tR4swQGFXPh72DTGItWXMklP OPDP4bOjaVScbiljcbLqQyAveNtg6h+w9Wz/xXDo6iP0NczjR0vMxs+ucp3ZMHhHOWX59VuGlun lFejkyc5Hy7oM4lvOneUyVZX4ivruMUoj7yLheDMO/l0Ny5PZ5wIZsltUXDSOFNXznDVhjDehtG qwS0XNjj70gIXVFPYlmNCKOCsW/OhmyTBaqiJvcZ5yuplze9psuNQII8z2B4FDiQOAeu2tPR8vJ NavlzQ3k8Xg3A5uPcmOILin78AgWj8zDV2lLxOmLUsfAPth3inFD0I0jlEDd+tm1t2m+G9oWDug zMDK8nBadv+F8ucSIwrUhv0kAAvFAkxQSMQ88CgLO3+bb7Ofo0S1EDOcLk/mVdvMmeQZCdzdRcz D5cstvr9Xz9yCPONLAJnGRMfFxydLzZBb+sVAj47E6rstCUYsgPoMwpIOZ2N6AnFMt0ON7vnMTA cbQeTbjRkIaedgaCI3NgkEqAN0R0Hrt1MF4ROaNTnqOMBIJ4VOLNIaYmKl84y6qlouf80Qd6Ad6 u6QQsH7iereGMC/oTQh9A4m9EtEhHWssEmb8zs7EPIkVcg+OgiZxW8zUgATOBZOqF12u2MO3mqa xjOvaWRvimDXUAqrCDMQhoerulylayzmQ9QV021it1MEktDd+DNkCAl6R40M71OfBpbjivbDIGU TC689iZyE2UOy4HPOHbIp2eXtYwkzmVqNbwpVHQgtCTJ1arKPFjJEFr+olSlnU38LCY8uJT2b0W wU7Y7JRBnLixjoqpfzLa08EuFCmxhmbMINgS2G5OCeLS+48MUlQQtZGM+l8aB83CS3pxLc6cJ4u YUQo x-tm-as-user-approved-sender: Yes x-tm-as-user-blocked-sender: No x-tmase-result: 10--23.436200-8.000000 x-tmase-version: SMEX-12.5.0.1300-8.2.1013-24054.007 Content-Type: multipart/alternative; boundary="_000_D8A2B50A3E3B9nigelmegittbbccouk_" MIME-Version: 1.0 Archived-At: Subject: Re: [payload] new draft - RTP Payload for TTML Timed Text X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Mar 2019 10:59:35 -0000 --_000_D8A2B50A3E3B9nigelmegittbbccouk_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Tm90IGFzIGZhciBhcyBJIGFtIGF3YXJlOiBJIHNoYXJlZCB0aGUgbGF0ZXN0IGRyYWZ0IHdpdGgg VzNDIFRUV0cgYW5kLCB0aG91Z2ggdGhlcmUgbWF5IHN0aWxsIGJlIHJldmlldyBjb21tZW50cyB0 byBjb21lLCBJIGJlbGlldmUgdGhlIGNvbmNlcm5zIHJhaXNlZCBwcmV2aW91c2x5IHdlcmUgYWRk cmVzc2VkLg0KDQpLaW5kIHJlZ2FyZHMsDQoNCk5pZ2VsDQoNCg0KRnJvbTogSmFtZXMgU2FuZGZv cmQgPGphbWVzLnNhbmRmb3JkQGJiYy5jby51azxtYWlsdG86amFtZXMuc2FuZGZvcmRAYmJjLmNv LnVrPj4NCkRhdGU6IE1vbmRheSwgNCBNYXJjaCAyMDE5IGF0IDEwOjMzDQpUbzogIlJvbmkgRXZl biAoQSkiIDxyb25pLmV2ZW5AaHVhd2VpLmNvbTxtYWlsdG86cm9uaS5ldmVuQGh1YXdlaS5jb20+ PiwgTmlnZWwgTWVnaXR0IDxuaWdlbC5tZWdpdHRAYmJjLmNvLnVrPG1haWx0bzpuaWdlbC5tZWdp dHRAYmJjLmNvLnVrPj4sICJwYXlsb2FkQGlldGYub3JnPG1haWx0bzpwYXlsb2FkQGlldGYub3Jn PiIgPHBheWxvYWRAaWV0Zi5vcmc8bWFpbHRvOnBheWxvYWRAaWV0Zi5vcmc+Pg0KU3ViamVjdDog UkU6IFtwYXlsb2FkXSBuZXcgZHJhZnQgLSBSVFAgUGF5bG9hZCBmb3IgVFRNTCBUaW1lZCBUZXh0 DQoNCkhlbGxvLA0KQXJlIHRoZXJlIGFueSBtb3JlIGJsb2NrZXJzIGluIHRoZSB3YXkgb2YgcHJv Z3Jlc3NpbmcgdGhpcyBkb2N1bWVudD8NCg0KUmVnYXJkcywNCkphbWVzDQoNCg0KPT09PT09PT09 PQ0KSmFtZXMgU2FuZGZvcmQNClImRCBFbmdpbmVlcg0KDQpCQkMgUmVzZWFyY2ggYW5kIERldmVs b3BtZW50DQo1dGggRmxvb3INCkRvY2sgSG91c2UNCk1lZGlhQ2l0eVVLDQpTYWxmb3JkDQpNNTAg MkxIDQoNClRlbDogMDMwMzA0ICgwOTU0OSkNCldlYjogaHR0cDovL3d3dy5iYmMuY28udWsvcmQN Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpGcm9tOiBwYXlsb2FkIFtwYXlsb2Fk LWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOnBheWxvYWQtYm91bmNlc0BpZXRmLm9yZz5dIG9uIGJl aGFsZiBvZiBKYW1lcyBTYW5kZm9yZCBbamFtZXMuc2FuZGZvcmRAYmJjLmNvLnVrPG1haWx0bzpq YW1lcy5zYW5kZm9yZEBiYmMuY28udWs+XQ0KU2VudDogMjIgRmVicnVhcnkgMjAxOSAxMzozNA0K VG86IFJvbmkgRXZlbiAoQSk7IE5pZ2VsIE1lZ2l0dDsgcGF5bG9hZEBpZXRmLm9yZzxtYWlsdG86 cGF5bG9hZEBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbcGF5bG9hZF0gbmV3IGRyYWZ0IC0gUlRQ IFBheWxvYWQgZm9yIFRUTUwgVGltZWQgVGV4dA0KDQoNCkhlbGxvLA0KTmV3IHZlcnNpb24gdXBs b2FkZWQgdGhhdCBhZGRyZXNzZXMgdGhlIGNvbmNlcm5zIHJhaXNlZCBieSB0aGUgVzNDIFRUV0cu DQoNCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXNhbmRmb3JkLXBheWxv YWQtcnRwLXR0bWwvMDMvDQoNClJlZ2FyZHMsDQpKYW1lcw0KDQoNCj09PT09PT09PT0NCkphbWVz IFNhbmRmb3JkDQpSJkQgRW5naW5lZXINCg0KQkJDIFJlc2VhcmNoIGFuZCBEZXZlbG9wbWVudA0K NXRoIEZsb29yDQpEb2NrIEhvdXNlDQpNZWRpYUNpdHlVSw0KU2FsZm9yZA0KTTUwIDJMSA0KDQpU ZWw6IDAzMDMwNCAoMDk1NDkpDQpXZWI6IGh0dHA6Ly93d3cuYmJjLmNvLnVrL3JkDQpfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KRnJvbTogUm9uaSBFdmVuIChBKSBbcm9uaS5ldmVu QGh1YXdlaS5jb208bWFpbHRvOnJvbmkuZXZlbkBodWF3ZWkuY29tPl0NClNlbnQ6IDE0IEZlYnJ1 YXJ5IDIwMTkgMDY6MTQNClRvOiBKYW1lcyBTYW5kZm9yZDsgTmlnZWwgTWVnaXR0OyBwYXlsb2Fk QGlldGYub3JnPG1haWx0bzpwYXlsb2FkQGlldGYub3JnPg0KU3ViamVjdDogUkU6IFtwYXlsb2Fk XSBuZXcgZHJhZnQgLSBSVFAgUGF5bG9hZCBmb3IgVFRNTCBUaW1lZCBUZXh0DQoNCkhpIEphbWVz LA0KUGxlYXNlIGNoYW5nZSB0aGUgaW5kaXZpZHVhbCBkcmFmdC4gIEl0IHdpbGwgYmUgZ29vZCB0 byBnZXQgYWdyZWVtZW50IGZyb20gTmlnZWwgb3Igb3RoZXJzIGZyb20gM0dQUCBiYXNlZCBvbiB0 aGVzZSBjaGFuZ2VzIGJlZm9yZSBwcm9ncmVzc2luZyB0aGUgd29yayBpbiB0aGUgSUVURg0KDQpS ZWdhcmRzDQpSb25pIEV2ZW4NClBheWxvYWQgV0cgY28tY2hhaXINCg0KRnJvbTogSmFtZXMgU2Fu ZGZvcmQgW21haWx0bzpqYW1lcy5zYW5kZm9yZEBiYmMuY28udWtdDQpTZW50OiBXZWRuZXNkYXks IEZlYnJ1YXJ5IDEzLCAyMDE5IDExOjI1IEFNDQpUbzogUm9uaSBFdmVuIChBKTsgTmlnZWwgTWVn aXR0OyBwYXlsb2FkQGlldGYub3JnPG1haWx0bzpwYXlsb2FkQGlldGYub3JnPg0KU3ViamVjdDog UkU6IFtwYXlsb2FkXSBuZXcgZHJhZnQgLSBSVFAgUGF5bG9hZCBmb3IgVFRNTCBUaW1lZCBUZXh0 DQoNClRoYW5rcywgUm9uaS4gU2hvdWxkIEkgbWFrZSB0aGVzZSBjaGFuZ2VzIG5vdyBvciB3YWl0 IHVudGlsIHRoZSBjYWxsIGZvciB0aGUgV0cgdG8gYWRvcHQgdjAyIGhhcyBsYXBzZWQ/DQoNClJl Z2FyZHMsDQpKYW1lcw0KDQoNCj09PT09PT09PT0NCkphbWVzIFNhbmRmb3JkDQpSJkQgRW5naW5l ZXINCg0KQkJDIFJlc2VhcmNoIGFuZCBEZXZlbG9wbWVudA0KNXRoIEZsb29yDQpEb2NrIEhvdXNl DQpNZWRpYUNpdHlVSw0KU2FsZm9yZA0KTTUwIDJMSA0KDQpUZWw6IDAzMDMwNCAoMDk1NDkpDQpX ZWI6IGh0dHA6Ly93d3cuYmJjLmNvLnVrL3JkDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KRnJvbTogUm9uaSBFdmVuIChBKSBbcm9uaS5ldmVuQGh1YXdlaS5jb208bWFpbHRvOnJv bmkuZXZlbkBodWF3ZWkuY29tPl0NClNlbnQ6IDEyIEZlYnJ1YXJ5IDIwMTkgMDc6NTINClRvOiBO aWdlbCBNZWdpdHQ7IHBheWxvYWRAaWV0Zi5vcmc8bWFpbHRvOnBheWxvYWRAaWV0Zi5vcmc+DQpT dWJqZWN0OiBSZTogW3BheWxvYWRdIG5ldyBkcmFmdCAtIFJUUCBQYXlsb2FkIGZvciBUVE1MIFRp bWVkIFRleHQNCkhpLA0KVGhhbmtzIGZvciB0aGUgaW5mb3JtYXRpb24uDQpUaGUgd2F5IEkgc2Vl IGl0IGlzIHRoYXQgdGhpcyBkb2N1bWVudCBvbmx5IHdhbnRzIHRvIHNwZWNpZnkgaG93IHRvIHNl bmQgVFRNIHRpbWUgdGV4dCB1c2luZyBSVFAgd2hpY2ggaXMgbm90IHNwZWNpZmllZCBieSBXM0MN Cg0KSSB0aGluayB0aGF0IHRoZSB0ZXh0IGV4cGxhaW5zIGl0IGJ1dCBtYXliZSB3ZSBuZWVkIGJl dHRlciBjbGFyaWZpY2F0aW9uLCBhbnkgaW5wdXQgaXMgd2VsY29tZS4gSSB0aGluayB0aGF0IGF0 IGxlYXN0IGl0IHNob3VsZCBzYXkgdGhhdCB0aGlzIGRvY3VtZW50IG9ubHkgZGVmaW5lIGhvdyB0 byBjYXJyeSBUVE1MIHRpbWUgdGV4dCBvdmVyIFJUUCB1c2luZyB0aGUgbWVkaWEgc3VidHlwZSBk ZWZpbmVkIGJ5IFczQyBhbmQgcmVmZXJlbmNlIHRoZSByZWxldmFudCBXM0MgZG9jdW1lbnQuDQoN CkkgYWdyZWUgdGhhdCB3ZSBkbyBub3QgbmVlZCB0aGUgcmVnaXN0cmF0aW9uIHRlbXBsYXRlIHNp bmNlIHRoZSBkb2N1bWVudCBzdWdnZXN0IHVzaW5nIHRoZSBjdXJyZW50IHJlZ2lzdHJhdGlvbiBp biB0aGUgSUFOQSBtZWRpYSAgdHlwZSwgc28gdGhlIElBTkEgY29uc2lkZXJhdGlvbiBzaG91bGQg b25seSBhc2sgZm9yIGFkZGluZyB0aGUgcmVmZXJlbmNlIHRvIHRoaXMgZG9jdW1lbnQgaW4gdGhl IGN1cnJlbnQgcmVnaXN0cmF0aW9uLiBUaGlzIGFzc3VtZXMgdGhhdCB0aGVyZSBhcmUgbm8gY2hh bmdlcyBpbiB0aGUgcmVnaXN0cmF0aW9uIHJlcXVpcmVkLiAgIEFub3RoZXIgZGlyZWN0aW9uIGlz IHRvIGhhdmUgYSBkaWZmZXJlbnQgbWVkaWEgc3VidHlwZSBuYW1lIGZvciB0aGUgUlRQIHVzYWdl IGJ1dCBJbiBzZWUgbm8gcmVhbCByZWFzb24gaWYgdGhlIGRvY3VtZW50IG9ubHkgc3BlY2lmeSBo b3cgdG8gdXNlIHRoaXMgcGF5bG9hZCBvdmVyIFJUUCBhbmQgY2hhbmdlIG5vdGhpbmcgaW4gdGhl IGN1cnJlbnQgcmVnaXN0cmF0aW9uLg0KDQpUaGUgb25seSBvdGhlciBjb21tZW50IEkgbm90aWNl ZCBpcyDigJxBIHJlcXVlc3QgdG8gbWFrZSBzdXJlIHRoYXQgdGhlIGxhbmd1YWdlIGFib3V0IHBy b2ZpbGUgc2lnbmFsbGluZyBkb2VzIG5vdCBpbXBseSB0aGF0IHRoZSBjb2RlY3MgcGFyYW1ldGVy IGNhbiBkZW5vdGUgYWxsIHByb2ZpbGVzLCBlc3BlY2lhbGx5IGluIHRoZSBjYXNlIHRoYXQgdGhl IHBheWxvYWQgZG9jdW1lbnQgY29udGFpbnMgYW4gZW1iZWRkZWQgcHJvZmlsZS7igJwgIFRoaXMg c2hvdWxkIGJlIGFkZHJlc3NlZCBieSB0aGUgYXV0aG9ycw0KDQpMZXQgdGhlIFdHIGtub3cgaWYg dGhpcyBzb3VuZHMgcmVhc29uYWJsZQ0KUm9uaSBFdmVuDQpQYXlsb2FkIFdHIGNvLWNoYWlyDQoN Cg0KDQoNCkZyb206IHBheWxvYWQgW21haWx0bzpwYXlsb2FkLWJvdW5jZXNAaWV0Zi5vcmddIE9u IEJlaGFsZiBPZiBOaWdlbCBNZWdpdHQNClNlbnQ6IE1vbmRheSwgRmVicnVhcnkgMTEsIDIwMTkg NToxNiBQTQ0KVG86IHBheWxvYWRAaWV0Zi5vcmc8bWFpbHRvOnBheWxvYWRAaWV0Zi5vcmc+DQpT dWJqZWN0OiBSZTogW3BheWxvYWRdIG5ldyBkcmFmdCAtIFJUUCBQYXlsb2FkIGZvciBUVE1MIFRp bWVkIFRleHQNCg0KRGVhciBJRVRGIFBheWxvYWQgZ3JvdXAsDQoNClRoaXMgZHJhZnQgd2FzIGRp c2N1c3NlZCBieSB0aGUgVzNDIFRpbWVkIFRleHQgV29ya2luZyBHcm91cCAoVFRXRykgb24gMjAx OS0wMi0wNyBbMV0uDQoNClsxXSBNaW51dGVzIG9mIFczQyBUVFdHIG1lZXRpbmcgMjAxOS0wMi0w NzogaHR0cHM6Ly93d3cudzMub3JnLzIwMTkvMDIvMDctdHQtbWludXRlcy5odG1sI2l0ZW0wMw0K DQpEdXJpbmcgdGhlIG1lZXRpbmcgY29uY2VybiB3YXMgcmFpc2VkIGFib3V0IHRoZSBhcHByb2Fj aCB0byB0aGUgSUFOQSByZWdpc3RlcmVkIG1lZGlhIHR5cGUsIHNwZWNpZmljYWxseSB0aGUgbWVh bmluZyBvZiBzZWN0aW9uIDguIElBTkEgQ29uc2lkZXJhdGlvbnMuDQoNClRoZXJlIHdhcyBjb25z ZW5zdXMgYW1vbmdzdCB0aGUgZ3JvdXAgdGhhdCB0aGUgdGV4dCBzcGVjaWZ5aW5nIHRoYXQgdGhp cyB0ZXh0Og0KDQrigJxUaGUgbWVkaWEgdHlwZXMgcmVnaXN0cnkgU0hPVUxEIGJlIHVwZGF0ZWQg dG8gbWFrZSByZWZlcmVuY2UgdG8gdGhpcyBkb2N1bWVudCBmb3IgdGhlIGFwcGxpY2F0aW9uL3R0 bWwreG1sIG1lZGlhIHR5cGUu4oCdDQoNCmlzIGluY29ycmVjdCBhbmQgbmVlZHMgdG8gYmUgY2hh bmdlZC4gVGhlIG1lZGlhIHR5cGUgcmVnaXN0cmF0aW9uIGZvciBUVE1MIGlzIG93bmVkIGJ5IFcz QyBhbmQgc2hvdWxkIG5vdCBiZSBjaGFuZ2VkIGJ5IElFVEYg4oCTIHdlIG5vdGUgdGhhdCB0aGUg Y2hhbmdlIGNvbnRyb2wgaXMgY2xlYXJseSBtYXJrZWQgYXMgYmVpbmcgb3duZWQgYnkgVzNDIHNv IGluIHRoYXQgc2Vuc2UgdGhpcyB0ZXh0IGlzIGluY29uc2lzdGVudC4NCg0KVGhlIElBTkEgbWVk aWEgdHlwZSByZWdpc3RyYXRpb24gaXRzZWxmIGRlZmVycyB0byB0aGUgVFRXRyBkb2N1bWVudCDi gJxUVE1MIE1lZGlhIFR5cGUgRGVmaW5pdGlvbiBhbmQgUHJvZmlsZSBSZWdpc3RyeeKAnSBbMl0g d2hpY2ggaXMgYWxyZWFkeSByZWZlcmVuY2VkIGJ5IHRoZSBSVFAgUGF5bG9hZCBkcmFmdC4gQW4g aW1wcm92ZW1lbnQgd291bGQgdGhlcmVmb3JlIGJlIHRvIHVwZGF0ZSB0aGUgdGV4dCBpbiBzZWN0 aW9uIDggdG8gc3VnZ2VzdCB0aGF0IFsyXSBjYW4gYmUgdXBkYXRlZCB0byBpbmNsdWRlIHRoZSBw cm9maWxlcyBkZWZpbmVkIHdpdGhpbiB0aGUgcGF5bG9hZCBkb2N1bWVudC4gSW5kZWVkIGRvaW5n IHNvIHdvdWxkIHJlc3VsdCBpbiB0aGUgY3JlYXRpb24gb2YgYSBzaG9ydCBjb2RlIGZvciB0aGUg cHJvZmlsZSBwcm9jZXNzb3IgbWVudGlvbmVkIGluIHNlY3Rpb24gNC4yLjEuMi4xLjMgUHJvY2Vz c29yIHByb2ZpbGUgc2lnbmFsbGluZy4NCg0KWzJdIFRUTUwgTWVkaWEgVHlwZSBEZWZpbml0aW9u IGFuZCBQcm9maWxlIFJlZ2lzdHJ5IGh0dHBzOi8vd3d3LnczLm9yZy9UUi90dG1sLXByb2ZpbGUt cmVnaXN0cnkvDQoNCg0KVGhlIFRUV0cgYWxzbyBkaXNjdXNzZWQgdHdvIGFkZGl0aW9uYWwgY29u Y2VybnMgd2l0aG91dCBjbG9zaW5nIG9uIGEgcG9zaXRpb24gYXQgdGhpcyB0aW1lOg0KDQogIDEu ICBBIHF1ZXJ5IHdoZXRoZXIgdGhlIG1lZGlhIHR5cGUgcmVnaXN0cmF0aW9uIGluZm9ybWF0aW9u IHJlYWxseSBuZWVkcyB0byBiZSBjb3BpZWQgaW4gYXQgYWxsIGhlcmUgb3IgaWYgaXQgY2FuIGJl IHJlZmVyZW5jZWQ7DQogIDIuICBBIHJlcXVlc3QgdG8gbWFrZSBzdXJlIHRoYXQgdGhlIGxhbmd1 YWdlIGFib3V0IHByb2ZpbGUgc2lnbmFsbGluZyBkb2VzIG5vdCBpbXBseSB0aGF0IHRoZSBjb2Rl Y3MgcGFyYW1ldGVyIGNhbiBkZW5vdGUgYWxsIHByb2ZpbGVzLCBlc3BlY2lhbGx5IGluIHRoZSBj YXNlIHRoYXQgdGhlIHBheWxvYWQgZG9jdW1lbnQgY29udGFpbnMgYW4gZW1iZWRkZWQgcHJvZmls ZS4NClRUV0cgbWF5IHByb3ZpZGUgZnVydGhlciBpbnB1dCBvbiB0aG9zZSB0d28gcG9pbnRzIGJ1 dCB3b3VsZCB3ZWxjb21lIGZ1cnRoZXIgaW5wdXQgZXNwZWNpYWxseSBvbiB0aGUgZmlyc3QuDQoN CktpbmQgcmVnYXJkcywNCg0KTmlnZWwgTWVnaXR0IGFzIENoYWlyIG9mIFczQyBUVFdHDQoNCg0K DQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KaHR0cDovL3d3dy5iYmMuY28udWsN ClRoaXMgZS1tYWlsIChhbmQgYW55IGF0dGFjaG1lbnRzKSBpcyBjb25maWRlbnRpYWwgYW5kIG1h eSBjb250YWluIHBlcnNvbmFsIHZpZXdzIHdoaWNoIGFyZSBub3QgdGhlIHZpZXdzIG9mIHRoZSBC QkMgdW5sZXNzIHNwZWNpZmljYWxseSBzdGF0ZWQuDQpJZiB5b3UgaGF2ZSByZWNlaXZlZCBpdCBp biBlcnJvciwgcGxlYXNlIGRlbGV0ZSBpdCBmcm9tIHlvdXIgc3lzdGVtLg0KRG8gbm90IHVzZSwg Y29weSBvciBkaXNjbG9zZSB0aGUgaW5mb3JtYXRpb24gaW4gYW55IHdheSBub3IgYWN0IGluIHJl bGlhbmNlIG9uIGl0IGFuZCBub3RpZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVseS4NClBsZWFzZSBu b3RlIHRoYXQgdGhlIEJCQyBtb25pdG9ycyBlLW1haWxzIHNlbnQgb3IgcmVjZWl2ZWQuDQpGdXJ0 aGVyIGNvbW11bmljYXRpb24gd2lsbCBzaWduaWZ5IHlvdXIgY29uc2VudCB0byB0aGlzLg0KDQot LS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0N Cg0KaHR0cDovL3d3dy5iYmMuY28udWsNClRoaXMgZS1tYWlsIChhbmQgYW55IGF0dGFjaG1lbnRz KSBpcyBjb25maWRlbnRpYWwgYW5kIG1heSBjb250YWluIHBlcnNvbmFsIHZpZXdzIHdoaWNoIGFy ZSBub3QgdGhlIHZpZXdzIG9mIHRoZSBCQkMgdW5sZXNzIHNwZWNpZmljYWxseSBzdGF0ZWQuDQpJ ZiB5b3UgaGF2ZSByZWNlaXZlZCBpdCBpbiBlcnJvciwgcGxlYXNlIGRlbGV0ZSBpdCBmcm9tIHlv dXIgc3lzdGVtLg0KRG8gbm90IHVzZSwgY29weSBvciBkaXNjbG9zZSB0aGUgaW5mb3JtYXRpb24g aW4gYW55IHdheSBub3IgYWN0IGluIHJlbGlhbmNlIG9uIGl0IGFuZCBub3RpZnkgdGhlIHNlbmRl ciBpbW1lZGlhdGVseS4NClBsZWFzZSBub3RlIHRoYXQgdGhlIEJCQyBtb25pdG9ycyBlLW1haWxz IHNlbnQgb3IgcmVjZWl2ZWQuDQpGdXJ0aGVyIGNvbW11bmljYXRpb24gd2lsbCBzaWduaWZ5IHlv dXIgY29uc2VudCB0byB0aGlzLg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KDQoNCi0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KaHR0cDovL3d3dy5iYmMuY28udWsNClRoaXMgZS1t YWlsIChhbmQgYW55IGF0dGFjaG1lbnRzKSBpcyBjb25maWRlbnRpYWwgYW5kIG1heSBjb250YWlu IHBlcnNvbmFsIHZpZXdzIHdoaWNoIGFyZSBub3QgdGhlIHZpZXdzIG9mIHRoZSBCQkMgdW5sZXNz IHNwZWNpZmljYWxseSBzdGF0ZWQuDQpJZiB5b3UgaGF2ZSByZWNlaXZlZCBpdCBpbiBlcnJvciwg cGxlYXNlIGRlbGV0ZSBpdCBmcm9tIHlvdXIgc3lzdGVtLg0KRG8gbm90IHVzZSwgY29weSBvciBk aXNjbG9zZSB0aGUgaW5mb3JtYXRpb24gaW4gYW55IHdheSBub3IgYWN0IGluIHJlbGlhbmNlIG9u IGl0IGFuZCBub3RpZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVseS4NClBsZWFzZSBub3RlIHRoYXQg dGhlIEJCQyBtb25pdG9ycyBlLW1haWxzIHNlbnQgb3IgcmVjZWl2ZWQuDQpGdXJ0aGVyIGNvbW11 bmljYXRpb24gd2lsbCBzaWduaWZ5IHlvdXIgY29uc2VudCB0byB0aGlzLg0KDQotLS0tLS0tLS0t LS0tLS0tLS0tLS0NCg0KDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KaHR0cDov L3d3dy5iYmMuY28udWsNClRoaXMgZS1tYWlsIChhbmQgYW55IGF0dGFjaG1lbnRzKSBpcyBjb25m aWRlbnRpYWwgYW5kIG1heSBjb250YWluIHBlcnNvbmFsIHZpZXdzIHdoaWNoIGFyZSBub3QgdGhl IHZpZXdzIG9mIHRoZSBCQkMgdW5sZXNzIHNwZWNpZmljYWxseSBzdGF0ZWQuDQpJZiB5b3UgaGF2 ZSByZWNlaXZlZCBpdCBpbiBlcnJvciwgcGxlYXNlIGRlbGV0ZSBpdCBmcm9tIHlvdXIgc3lzdGVt Lg0KRG8gbm90IHVzZSwgY29weSBvciBkaXNjbG9zZSB0aGUgaW5mb3JtYXRpb24gaW4gYW55IHdh eSBub3IgYWN0IGluIHJlbGlhbmNlIG9uIGl0IGFuZCBub3RpZnkgdGhlIHNlbmRlciBpbW1lZGlh dGVseS4NClBsZWFzZSBub3RlIHRoYXQgdGhlIEJCQyBtb25pdG9ycyBlLW1haWxzIHNlbnQgb3Ig cmVjZWl2ZWQuDQpGdXJ0aGVyIGNvbW11bmljYXRpb24gd2lsbCBzaWduaWZ5IHlvdXIgY29uc2Vu dCB0byB0aGlzLg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg== --_000_D8A2B50A3E3B9nigelmegittbbccouk_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjwhLS0gVGVtcGxhdGUgZ2VuZXJhdGVkIGJ5IEV4Y2xhaW1lciBNYWls IERpc2NsYWltZXJzIG9uIDEwOjU4OjU5IE1vbmRheSwgNCBNYXJjaCAyMDE5IC0tPg0KPG1ldGEg aHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRm LTgiPg0KPHN0eWxlIHR5cGU9InRleHQvY3NzIj5QLjJlYTFjYmMwLTk3YWItNGFmMy1hYzAxLTg0 YjA5NDk2ODU5ZCB7DQoJTUFSR0lOOiAwY20gMGNtIDBwdA0KfQ0KTEkuMmVhMWNiYzAtOTdhYi00 YWYzLWFjMDEtODRiMDk0OTY4NTlkIHsNCglNQVJHSU46IDBjbSAwY20gMHB0DQp9DQpESVYuMmVh MWNiYzAtOTdhYi00YWYzLWFjMDEtODRiMDk0OTY4NTlkIHsNCglNQVJHSU46IDBjbSAwY20gMHB0 DQp9DQpUQUJMRS4yZWExY2JjMC05N2FiLTRhZjMtYWMwMS04NGIwOTQ5Njg1OWRUYWJsZSB7DQoJ TUFSR0lOOiAwY20gMGNtIDBwdA0KfQ0KRElWLlNlY3Rpb24xIHsNCglwYWdlOiBTZWN0aW9uMQ0K fQ0KPC9zdHlsZT4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7 IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgbGluZS1icmVhazogYWZ0ZXItd2hpdGUtc3BhY2U7 IGNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtc2l6ZTogMTRweDsgZm9udC1mYW1pbHk6IENhbGli cmksIHNhbnMtc2VyaWY7Ij4NCjxwIGNsYXNzPSIyZWExY2JjMC05N2FiLTRhZjMtYWMwMS04NGIw OTQ5Njg1OWQiPjwvcD4NCjxkaXY+Tm90IGFzIGZhciBhcyBJIGFtIGF3YXJlOiBJIHNoYXJlZCB0 aGUgbGF0ZXN0IGRyYWZ0IHdpdGggVzNDIFRUV0cgYW5kLCB0aG91Z2ggdGhlcmUgbWF5IHN0aWxs IGJlIHJldmlldyBjb21tZW50cyB0byBjb21lLCBJIGJlbGlldmUgdGhlIGNvbmNlcm5zIHJhaXNl ZCBwcmV2aW91c2x5IHdlcmUgYWRkcmVzc2VkLjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxk aXY+S2luZCByZWdhcmRzLDwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+TmlnZWw8L2Rp dj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPHNwYW4gaWQ9Ik9MS19T UkNfQk9EWV9TRUNUSU9OIj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmk7IGZvbnQt c2l6ZToxMXB0OyB0ZXh0LWFsaWduOmxlZnQ7IGNvbG9yOmJsYWNrOyBCT1JERVItQk9UVE9NOiBt ZWRpdW0gbm9uZTsgQk9SREVSLUxFRlQ6IG1lZGl1bSBub25lOyBQQURESU5HLUJPVFRPTTogMGlu OyBQQURESU5HLUxFRlQ6IDBpbjsgUEFERElORy1SSUdIVDogMGluOyBCT1JERVItVE9QOiAjYjVj NGRmIDFwdCBzb2xpZDsgQk9SREVSLVJJR0hUOiBtZWRpdW0gbm9uZTsgUEFERElORy1UT1A6IDNw dCI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+RnJvbTogPC9zcGFuPkphbWVzIFNh bmRmb3JkICZsdDs8YSBocmVmPSJtYWlsdG86amFtZXMuc2FuZGZvcmRAYmJjLmNvLnVrIj5qYW1l cy5zYW5kZm9yZEBiYmMuY28udWs8L2E+Jmd0Ozxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdo dDpib2xkIj5EYXRlOiA8L3NwYW4+TW9uZGF5LCA0IE1hcmNoIDIwMTkgYXQgMTA6MzM8YnI+DQo8 c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+VG86IDwvc3Bhbj4mcXVvdDtSb25pIEV2ZW4g KEEpJnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86cm9uaS5ldmVuQGh1YXdlaS5jb20iPnJvbmku ZXZlbkBodWF3ZWkuY29tPC9hPiZndDssIE5pZ2VsIE1lZ2l0dCAmbHQ7PGEgaHJlZj0ibWFpbHRv Om5pZ2VsLm1lZ2l0dEBiYmMuY28udWsiPm5pZ2VsLm1lZ2l0dEBiYmMuY28udWs8L2E+Jmd0Oywg JnF1b3Q7PGEgaHJlZj0ibWFpbHRvOnBheWxvYWRAaWV0Zi5vcmciPnBheWxvYWRAaWV0Zi5vcmc8 L2E+JnF1b3Q7DQogJmx0OzxhIGhyZWY9Im1haWx0bzpwYXlsb2FkQGlldGYub3JnIj5wYXlsb2Fk QGlldGYub3JnPC9hPiZndDs8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+U3Vi amVjdDogPC9zcGFuPlJFOiBbcGF5bG9hZF0gbmV3IGRyYWZ0IC0gUlRQIFBheWxvYWQgZm9yIFRU TUwgVGltZWQgVGV4dDxicj4NCjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxibG9ja3F1b3Rl IGlkPSJNQUNfT1VUTE9PS19BVFRSSUJVVElPTl9CTE9DS1FVT1RFIiBzdHlsZT0iQk9SREVSLUxF RlQ6ICNiNWM0ZGYgNSBzb2xpZDsgUEFERElORzowIDAgMCA1OyBNQVJHSU46MCAwIDAgNTsiPg0K PGRpdiBkaXI9Imx0ciI+PHN0eWxlIHR5cGU9InRleHQvY3NzIj4NCjwhLS0NCi0tPg0KPC9zdHls ZT48c3R5bGU+DQo8IS0tDQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicml9DQpAZm9u dC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYX0NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYi fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXtjb2xvcjpibHVlOw0KCXRleHQtZGVjb3Jh dGlvbjp1bmRlcmxpbmV9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7 Y29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmV9DQpwDQoJe21hcmdpbi1y aWdodDowaW47DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1m YW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIn0NCnAuTXNvQWNldGF0ZSwgbGkuTXNvQWNl dGF0ZSwgZGl2Lk1zb0FjZXRhdGUNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAx cHQ7DQoJZm9udC1zaXplOjguMHB0Ow0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlm In0NCnAubXNvY2hwZGVmYXVsdCwgbGkubXNvY2hwZGVmYXVsdCwgZGl2Lm1zb2NocGRlZmF1bHQN Cgl7bWFyZ2luLXJpZ2h0OjBpbjsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjEwLjBw dDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYifQ0Kc3Bhbi5lbWFpbHN0 eWxlMjENCgl7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0 OTdEfQ0Kc3Bhbi5CYWxsb29uVGV4dENoYXINCgl7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMt c2VyaWYifQ0Kc3Bhbi5FbWFpbFN0eWxlMjUNCgl7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjsNCgljb2xvcjojMUY0OTdEfQ0KLk1zb0NocERlZmF1bHQNCgl7Zm9udC1zaXplOjEw LjBwdH0NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXttYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4w aW59DQpvbA0KCXttYXJnaW4tYm90dG9tOjBpbn0NCnVsDQoJe21hcmdpbi1ib3R0b206MGlufQ0K LS0+DQo8L3N0eWxlPjxzdHlsZSB0eXBlPSJ0ZXh0L2NzcyIgaWQ9Im93YVBhcmFTdHlsZSI+DQo8 IS0tDQotLT4NCjwvc3R5bGU+DQo8ZGl2IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0i cHVycGxlIiBmcHN0eWxlPSIxIiBvY3NpPSIwIj4NCjxkaXYgc3R5bGU9ImRpcmVjdGlvbjogbHRy O2ZvbnQtZmFtaWx5OiBUYWhvbWE7Y29sb3I6ICMwMDAwMDA7Zm9udC1zaXplOiAxMHB0OyI+SGVs bG8sDQo8ZGl2PkFyZSB0aGVyZSBhbnkgbW9yZSBibG9ja2VycyBpbiB0aGUgd2F5IG9mIHByb2dy ZXNzaW5nIHRoaXMgZG9jdW1lbnQ/PC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5SZWdh cmRzLDwvZGl2Pg0KPGRpdj5KYW1lczxicj4NCjxkaXY+PGJyPg0KPGRpdiBzdHlsZT0iZm9udC1m YW1pbHk6VGFob21hOyBmb250LXNpemU6MTNweCI+DQo8ZGl2IGNsYXNzPSJCb2R5RnJhZ21lbnQi Pjxmb250IHNpemU9IjIiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTBwdCI+DQo8ZGl2IGNsYXNz PSJQbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8YnI+DQo9PT09 PT09PT09PGJyPg0KSmFtZXMgU2FuZGZvcmQ8YnI+DQpSJmFtcDtEIEVuZ2luZWVyPGJyPg0KPGJy Pg0KQkJDIFJlc2VhcmNoIGFuZCBEZXZlbG9wbWVudDxicj4NCjV0aCBGbG9vcjxicj4NCkRvY2sg SG91c2U8YnI+DQpNZWRpYUNpdHlVSzxicj4NClNhbGZvcmQ8YnI+DQpNNTAgMkxIPGJyPg0KPGJy Pg0KVGVsOiAwMzAzMDQgKDA5NTQ5KTxicj4NCldlYjogPGEgaHJlZj0iaHR0cDovL3d3dy5iYmMu Y28udWsvcmQiPmh0dHA6Ly93d3cuYmJjLmNvLnVrL3JkPC9hPjwvZGl2Pg0KPC9zcGFuPjwvZm9u dD48L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTogVGltZXMg TmV3IFJvbWFuOyBjb2xvcjogIzAwMDAwMDsgZm9udC1zaXplOiAxNnB4Ij4NCjxociB0YWJpbmRl eD0iLTEiPg0KPGRpdiBpZD0iZGl2UnBGNjM4NTk0IiBzdHlsZT0iZGlyZWN0aW9uOiBsdHI7Ij48 Zm9udCBmYWNlPSJUYWhvbWEiIHNpemU9IjIiIGNvbG9yPSIjMDAwMDAwIj48Yj5Gcm9tOjwvYj4g cGF5bG9hZCBbPGEgaHJlZj0ibWFpbHRvOnBheWxvYWQtYm91bmNlc0BpZXRmLm9yZyI+cGF5bG9h ZC1ib3VuY2VzQGlldGYub3JnPC9hPl0gb24gYmVoYWxmIG9mIEphbWVzIFNhbmRmb3JkIFs8YSBo cmVmPSJtYWlsdG86amFtZXMuc2FuZGZvcmRAYmJjLmNvLnVrIj5qYW1lcy5zYW5kZm9yZEBiYmMu Y28udWs8L2E+XTxicj4NCjxiPlNlbnQ6PC9iPiAyMiBGZWJydWFyeSAyMDE5IDEzOjM0PGJyPg0K PGI+VG86PC9iPiBSb25pIEV2ZW4gKEEpOyBOaWdlbCBNZWdpdHQ7IDxhIGhyZWY9Im1haWx0bzpw YXlsb2FkQGlldGYub3JnIj5wYXlsb2FkQGlldGYub3JnPC9hPjxicj4NCjxiPlN1YmplY3Q6PC9i PiBSZTogW3BheWxvYWRdIG5ldyBkcmFmdCAtIFJUUCBQYXlsb2FkIGZvciBUVE1MIFRpbWVkIFRl eHQ8YnI+DQo8L2ZvbnQ+PGJyPg0KPC9kaXY+DQo8ZGl2PjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSI1ZjIwMmY4MS03MzEwLTRjNjEtYmQxOS03M2VhMzUyODRmM2EiPjwvcD4NCjxkaXYgc3R5bGU9 ImRpcmVjdGlvbjpsdHI7IGZvbnQtZmFtaWx5OlRhaG9tYTsgY29sb3I6IzAwMDAwMDsgZm9udC1z aXplOjEwcHQiPkhlbGxvLA0KPGRpdj5OZXcgdmVyc2lvbiB1cGxvYWRlZCB0aGF0IGFkZHJlc3Nl cyB0aGUgY29uY2VybnMgcmFpc2VkIGJ5IHRoZSBXM0MgVFRXRy48L2Rpdj4NCjxkaXY+PGJyPg0K PC9kaXY+DQo8ZGl2PjxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2Ry YWZ0LXNhbmRmb3JkLXBheWxvYWQtcnRwLXR0bWwvMDMvIiB0YXJnZXQ9Il9ibGFuayIgcmVsPSJu b29wZW5lciBub3JlZmVycmVyIj5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFm dC1zYW5kZm9yZC1wYXlsb2FkLXJ0cC10dG1sLzAzLzwvYT48L2Rpdj4NCjxkaXY+PGJyPg0KPC9k aXY+DQo8ZGl2PlJlZ2FyZHMsPC9kaXY+DQo8ZGl2PkphbWVzPGJyPg0KPGRpdj48YnI+DQo8ZGl2 IHN0eWxlPSJmb250LWZhbWlseTpUYWhvbWE7IGZvbnQtc2l6ZToxM3B4Ij4NCjxkaXYgY2xhc3M9 IkJvZHlGcmFnbWVudCI+PGZvbnQgc2l6ZT0iMiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMHB0 Ij4NCjxkaXYgY2xhc3M9IlBsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IDxicj4NCj09PT09PT09PT08YnI+DQpKYW1lcyBTYW5kZm9yZDxicj4NClImYW1wO0QgRW5n aW5lZXI8YnI+DQo8YnI+DQpCQkMgUmVzZWFyY2ggYW5kIERldmVsb3BtZW50PGJyPg0KNXRoIEZs b29yPGJyPg0KRG9jayBIb3VzZTxicj4NCk1lZGlhQ2l0eVVLPGJyPg0KU2FsZm9yZDxicj4NCk01 MCAyTEg8YnI+DQo8YnI+DQpUZWw6IDAzMDMwNCAoMDk1NDkpPGJyPg0KV2ViOiA8YSBocmVmPSJo dHRwOi8vd3d3LmJiYy5jby51ay9yZCI+aHR0cDovL3d3dy5iYmMuY28udWsvcmQ8L2E+PC9kaXY+ DQo8L3NwYW4+PC9mb250PjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQt ZmFtaWx5OlRpbWVzIE5ldyBSb21hbjsgY29sb3I6IzAwMDAwMDsgZm9udC1zaXplOjE2cHgiPg0K PGhyIHRhYmluZGV4PSItMSI+DQo8ZGl2IGlkPSJkaXZScEYzNTM1MjMiIHN0eWxlPSJkaXJlY3Rp b246bHRyIj48Zm9udCBmYWNlPSJUYWhvbWEiIHNpemU9IjIiIGNvbG9yPSIjMDAwMDAwIj48Yj5G cm9tOjwvYj4gUm9uaSBFdmVuIChBKSBbPGEgaHJlZj0ibWFpbHRvOnJvbmkuZXZlbkBodWF3ZWku Y29tIj5yb25pLmV2ZW5AaHVhd2VpLmNvbTwvYT5dPGJyPg0KPGI+U2VudDo8L2I+IDE0IEZlYnJ1 YXJ5IDIwMTkgMDY6MTQ8YnI+DQo8Yj5Ubzo8L2I+IEphbWVzIFNhbmRmb3JkOyBOaWdlbCBNZWdp dHQ7IDxhIGhyZWY9Im1haWx0bzpwYXlsb2FkQGlldGYub3JnIj5wYXlsb2FkQGlldGYub3JnPC9h Pjxicj4NCjxiPlN1YmplY3Q6PC9iPiBSRTogW3BheWxvYWRdIG5ldyBkcmFmdCAtIFJUUCBQYXls b2FkIGZvciBUVE1MIFRpbWVkIFRleHQ8YnI+DQo8L2ZvbnQ+PGJyPg0KPC9kaXY+DQo8ZGl2Pjwv ZGl2Pg0KPGRpdj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwg c2Fucy1zZXJpZjsgY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7Ij5IaSBKYW1lcyw8L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsgZm9u dC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyI+ UGxlYXNlIGNoYW5nZSB0aGUgaW5kaXZpZHVhbCBkcmFmdC4gJm5ic3A7SXQgd2lsbCBiZSBnb29k IHRvIGdldCBhZ3JlZW1lbnQgZnJvbSBOaWdlbCBvciBvdGhlcnMgZnJvbSAzR1BQIGJhc2VkIG9u IHRoZXNlIGNoYW5nZXMgYmVmb3JlIHByb2dyZXNzaW5nIHRoZQ0KIHdvcmsgaW4gdGhlIElFVEY8 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTog MTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGNvbG9yOiByZ2IoMzEsIDcz LCAxMjUpOyI+Jm5ic3A7PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBj b2xvcjogcmdiKDMxLCA3MywgMTI1KTsiPlJlZ2FyZHM8L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGli cmksIHNhbnMtc2VyaWY7IGNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyI+Um9uaSBFdmVuDQo8L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTFw dDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGNvbG9yOiByZ2IoMzEsIDczLCAx MjUpOyI+UGF5bG9hZCBXRyBjby1jaGFpcjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fu cy1zZXJpZjsgY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7Ij4mbmJzcDs8L3NwYW4+PC9wPg0KPGRp dj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lOyBib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4w cHQ7IHBhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTBwdDsgZm9udC1mYW1pbHk6IFRhaG9tYSwgc2Fucy1z ZXJpZjsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMHB0OyBmb250 LWZhbWlseTogVGFob21hLCBzYW5zLXNlcmlmOyI+IEphbWVzIFNhbmRmb3JkIFs8YSBocmVmPSJt YWlsdG86amFtZXMuc2FuZGZvcmRAYmJjLmNvLnVrIj5tYWlsdG86amFtZXMuc2FuZGZvcmRAYmJj LmNvLnVrPC9hPl0NCjxicj4NCjxiPlNlbnQ6PC9iPiBXZWRuZXNkYXksIEZlYnJ1YXJ5IDEzLCAy MDE5IDExOjI1IEFNPGJyPg0KPGI+VG86PC9iPiBSb25pIEV2ZW4gKEEpOyBOaWdlbCBNZWdpdHQ7 IDxhIGhyZWY9Im1haWx0bzpwYXlsb2FkQGlldGYub3JnIj5wYXlsb2FkQGlldGYub3JnPC9hPjxi cj4NCjxiPlN1YmplY3Q6PC9iPiBSRTogW3BheWxvYWRdIG5ldyBkcmFmdCAtIFJUUCBQYXlsb2Fk IGZvciBUVE1MIFRpbWVkIFRleHQ8L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPiZuYnNwOzwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOiAxMHB0OyBmb250LWZhbWlseTogVGFob21hLCBzYW5zLXNlcmlm OyBjb2xvcjogYmxhY2s7Ij5UaGFua3MsIFJvbmkuIFNob3VsZCBJIG1ha2UgdGhlc2UgY2hhbmdl cyBub3cgb3Igd2FpdCB1bnRpbCB0aGUgY2FsbCBmb3IgdGhlIFdHIHRvIGFkb3B0IHYwMiBoYXMg bGFwc2VkPw0KPC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOiAxMHB0OyBmb250LWZhbWlseTogVGFob21hLCBzYW5zLXNlcmlmOyBj b2xvcjogYmxhY2s7Ij4mbmJzcDs8L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTBwdDsgZm9udC1mYW1pbHk6IFRh aG9tYSwgc2Fucy1zZXJpZjsgY29sb3I6IGJsYWNrOyI+UmVnYXJkcyw8L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTog MTBwdDsgZm9udC1mYW1pbHk6IFRhaG9tYSwgc2Fucy1zZXJpZjsgY29sb3I6IGJsYWNrOyI+SmFt ZXM8L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6IDEwcHQ7IGZvbnQtZmFtaWx5OiBUYWhvbWEsIHNhbnMtc2VyaWY7IGNvbG9yOiBi bGFjazsiPiZuYnNwOzwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMHB0OyBmb250LWZhbWlseTogVGFo b21hLCBzYW5zLXNlcmlmOyBjb2xvcjogYmxhY2s7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsNCjxicj4NCj09PT09PT09PT08YnI+DQpKYW1lcyBTYW5kZm9yZDxicj4NClImYW1w O0QgRW5naW5lZXI8YnI+DQo8YnI+DQpCQkMgUmVzZWFyY2ggYW5kIERldmVsb3BtZW50PGJyPg0K NXRoIEZsb29yPGJyPg0KRG9jayBIb3VzZTxicj4NCk1lZGlhQ2l0eVVLPGJyPg0KU2FsZm9yZDxi cj4NCk01MCAyTEg8YnI+DQo8YnI+DQpUZWw6IDAzMDMwNCAoMDk1NDkpPGJyPg0KV2ViOiA8YSBo cmVmPSJodHRwOi8vd3d3LmJiYy5jby51ay9yZCIgcmVsPSJub29wZW5lciBub3JlZmVycmVyIiB0 YXJnZXQ9Il9ibGFuayI+DQpodHRwOi8vd3d3LmJiYy5jby51ay9yZDwvYT48L3NwYW4+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBjbGFzcz0iTXNvTm9y bWFsIiBhbGlnbj0iY2VudGVyIiBzdHlsZT0idGV4dC1hbGlnbjpjZW50ZXIiPjxzcGFuIHN0eWxl PSJjb2xvcjpibGFjayI+DQo8aHIgc2l6ZT0iMiIgd2lkdGg9IjEwMCUiIGFsaWduPSJjZW50ZXIi Pg0KPC9zcGFuPjwvZGl2Pg0KPGRpdiBpZD0iZGl2UnBGMjgxNjQ5Ij4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZTogMTBwdDsgZm9udC1mYW1pbHk6IFRhaG9tYSwgc2Fucy1zZXJpZjsgY29sb3I6IGJsYWNr OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEwcHQ7IGZvbnQtZmFt aWx5OiBUYWhvbWEsIHNhbnMtc2VyaWY7IGNvbG9yOiBibGFjazsiPiBSb25pIEV2ZW4gKEEpIFs8 YSBocmVmPSJtYWlsdG86cm9uaS5ldmVuQGh1YXdlaS5jb20iPnJvbmkuZXZlbkBodWF3ZWkuY29t PC9hPl08YnI+DQo8Yj5TZW50OjwvYj4gMTIgRmVicnVhcnkgMjAxOSAwNzo1Mjxicj4NCjxiPlRv OjwvYj4gTmlnZWwgTWVnaXR0OyA8YSBocmVmPSJtYWlsdG86cGF5bG9hZEBpZXRmLm9yZyIgcmVs PSJub29wZW5lciBub3JlZmVycmVyIiB0YXJnZXQ9Il9ibGFuayI+DQpwYXlsb2FkQGlldGYub3Jn PC9hPjxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW3BheWxvYWRdIG5ldyBkcmFmdCAtIFJUUCBQ YXlsb2FkIGZvciBUVE1MIFRpbWVkIFRleHQ8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNr Ij48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5z LXNlcmlmOyBjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsiPkhpLDwvc3Bhbj48c3BhbiBzdHlsZT0i Y29sb3I6YmxhY2siPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgY29s b3I6IHJnYigzMSwgNzMsIDEyNSk7Ij5UaGFua3MgZm9yIHRoZSBpbmZvcm1hdGlvbi48L3NwYW4+ PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNh bnMtc2VyaWY7IGNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyI+VGhlIHdheSBJIHNlZSBpdCBpcyB0 aGF0IHRoaXMgZG9jdW1lbnQgb25seSB3YW50cyB0byBzcGVjaWZ5IGhvdyB0byBzZW5kIFRUTSB0 aW1lIHRleHQgdXNpbmcgUlRQIHdoaWNoIGlzIG5vdCBzcGVjaWZpZWQgYnkgVzNDPC9zcGFuPjxz cGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5z LXNlcmlmOyBjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsiPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHls ZT0iY29sb3I6YmxhY2siPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsg Y29sb3I6IHJnYigzMSwgNzMsIDEyNSk7Ij5JIHRoaW5rIHRoYXQgdGhlIHRleHQgZXhwbGFpbnMg aXQgYnV0IG1heWJlIHdlIG5lZWQgYmV0dGVyIGNsYXJpZmljYXRpb24sIGFueSBpbnB1dCBpcyB3 ZWxjb21lLiBJIHRoaW5rIHRoYXQgYXQgbGVhc3QgaXQgc2hvdWxkIHNheSB0aGF0IHRoaXMgZG9j dW1lbnQNCiBvbmx5IGRlZmluZSBob3cgdG8gY2FycnkgVFRNTCB0aW1lIHRleHQgb3ZlciBSVFAg dXNpbmcgdGhlIG1lZGlhIHN1YnR5cGUgZGVmaW5lZCBieSBXM0MgYW5kIHJlZmVyZW5jZSB0aGUg cmVsZXZhbnQgVzNDIGRvY3VtZW50Ljwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAx MXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgY29sb3I6IHJnYigzMSwgNzMs IDEyNSk7Ij4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsgZm9u dC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyI+ SSBhZ3JlZSB0aGF0IHdlIGRvIG5vdCBuZWVkIHRoZSByZWdpc3RyYXRpb24gdGVtcGxhdGUgc2lu Y2UgdGhlIGRvY3VtZW50IHN1Z2dlc3QgdXNpbmcgdGhlIGN1cnJlbnQgcmVnaXN0cmF0aW9uIGlu IHRoZSBJQU5BIG1lZGlhJm5ic3A7IHR5cGUsIHNvIHRoZSBJQU5BDQogY29uc2lkZXJhdGlvbiBz aG91bGQgb25seSBhc2sgZm9yIGFkZGluZyB0aGUgcmVmZXJlbmNlIHRvIHRoaXMgZG9jdW1lbnQg aW4gdGhlIGN1cnJlbnQgcmVnaXN0cmF0aW9uLiBUaGlzIGFzc3VtZXMgdGhhdCB0aGVyZSBhcmUg bm8gY2hhbmdlcyBpbiB0aGUgcmVnaXN0cmF0aW9uIHJlcXVpcmVkLiZuYnNwOyAmbmJzcDtBbm90 aGVyIGRpcmVjdGlvbiBpcyB0byBoYXZlIGEgZGlmZmVyZW50IG1lZGlhIHN1YnR5cGUgbmFtZSBm b3IgdGhlIFJUUCB1c2FnZSBidXQgSW4NCiBzZWUgbm8gcmVhbCByZWFzb24gaWYgdGhlIGRvY3Vt ZW50IG9ubHkgc3BlY2lmeSBob3cgdG8gdXNlIHRoaXMgcGF5bG9hZCBvdmVyIFJUUCBhbmQgY2hh bmdlIG5vdGhpbmcgaW4gdGhlIGN1cnJlbnQgcmVnaXN0cmF0aW9uLjwvc3Bhbj48c3BhbiBzdHls ZT0iY29sb3I6YmxhY2siPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsg Y29sb3I6IHJnYigzMSwgNzMsIDEyNSk7Ij4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9y OmJsYWNrIj48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGNvbG9yOiBy Z2IoMzEsIDczLCAxMjUpOyI+VGhlIG9ubHkgb3RoZXIgY29tbWVudCBJIG5vdGljZWQgaXMg4oCc PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEwLjVwdDsgZm9udC1mYW1pbHk6IENhbGli cmksIHNhbnMtc2VyaWY7IGNvbG9yOiBibGFjazsiPkEgcmVxdWVzdCB0byBtYWtlIHN1cmUNCiB0 aGF0IHRoZSBsYW5ndWFnZSBhYm91dCBwcm9maWxlIHNpZ25hbGxpbmcgZG9lcyBub3QgaW1wbHkg dGhhdCB0aGUgY29kZWNzIHBhcmFtZXRlciBjYW4gZGVub3RlIGFsbCBwcm9maWxlcywgZXNwZWNp YWxseSBpbiB0aGUgY2FzZSB0aGF0IHRoZSBwYXlsb2FkIGRvY3VtZW50IGNvbnRhaW5zIGFuIGVt YmVkZGVkIHByb2ZpbGUuPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDExcHQ7IGZvbnQt ZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsiPuKA nCZuYnNwOw0KIFRoaXMgc2hvdWxkIGJlIGFkZHJlc3NlZCBieSB0aGUgYXV0aG9yczwvc3Bhbj48 c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fu cy1zZXJpZjsgY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7Ij4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5 bGU9ImNvbG9yOmJsYWNrIj48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7 IGNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyI+TGV0IHRoZSBXRyBrbm93IGlmIHRoaXMgc291bmRz IHJlYXNvbmFibGU8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsgZm9udC1m YW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyI+Um9u aSBFdmVuDQo8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1p bHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyI+UGF5bG9h ZCBXRyBjby1jaGFpcjwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBmb250 LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7Ij4m bmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6 IENhbGlicmksIHNhbnMtc2VyaWY7IGNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyI+Jm5ic3A7PC9z cGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJp LCBzYW5zLXNlcmlmOyBjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsiPiZuYnNwOzwvc3Bhbj48c3Bh biBzdHlsZT0iY29sb3I6YmxhY2siPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1z ZXJpZjsgY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7Ij4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9 ImNvbG9yOmJsYWNrIj48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25l OyBib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7IHBhZGRpbmc6My4wcHQgMGluIDBpbiAw aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTBw dDsgZm9udC1mYW1pbHk6IFRhaG9tYSwgc2Fucy1zZXJpZjsgY29sb3I6IGJsYWNrOyI+RnJvbTo8 L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEwcHQ7IGZvbnQtZmFtaWx5OiBUYWhv bWEsIHNhbnMtc2VyaWY7IGNvbG9yOiBibGFjazsiPiBwYXlsb2FkIFs8YSBocmVmPSJtYWlsdG86 cGF5bG9hZC1ib3VuY2VzQGlldGYub3JnIiByZWw9Im5vb3BlbmVyIG5vcmVmZXJyZXIiIHRhcmdl dD0iX2JsYW5rIj5tYWlsdG86cGF5bG9hZC1ib3VuY2VzQGlldGYub3JnPC9hPl0NCjxiPk9uIEJl aGFsZiBPZiA8L2I+TmlnZWwgTWVnaXR0PGJyPg0KPGI+U2VudDo8L2I+IE1vbmRheSwgRmVicnVh cnkgMTEsIDIwMTkgNToxNiBQTTxicj4NCjxiPlRvOjwvYj4gPGEgaHJlZj0ibWFpbHRvOnBheWxv YWRAaWV0Zi5vcmciIHJlbD0ibm9vcGVuZXIgbm9yZWZlcnJlciIgdGFyZ2V0PSJfYmxhbmsiPg0K cGF5bG9hZEBpZXRmLm9yZzwvYT48YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtwYXlsb2FkXSBu ZXcgZHJhZnQgLSBSVFAgUGF5bG9hZCBmb3IgVFRNTCBUaW1lZCBUZXh0PC9zcGFuPjxzcGFuIHN0 eWxlPSJjb2xvcjpibGFjayI+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48L3A+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTAuNXB0 OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgY29sb3I6IGJsYWNrOyI+RGVhciBJ RVRGIFBheWxvYWQgZ3JvdXAsPC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6IDEwLjVwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGNvbG9y OiBibGFjazsiPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOiAxMC41cHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBjb2xvcjog YmxhY2s7Ij5UaGlzIGRyYWZ0IHdhcyBkaXNjdXNzZWQgYnkgdGhlIFczQyBUaW1lZCBUZXh0IFdv cmtpbmcgR3JvdXAgKFRUV0cpIG9uIDIwMTktMDItMDcgWzFdLjwvc3Bhbj48c3BhbiBzdHlsZT0i Y29sb3I6YmxhY2siPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6IDEwLjVwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMt c2VyaWY7IGNvbG9yOiBibGFjazsiPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6Ymxh Y2siPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZTogMTAuNXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgY29s b3I6IGJsYWNrOyI+WzFdIE1pbnV0ZXMgb2YgVzNDIFRUV0cgbWVldGluZyAyMDE5LTAyLTA3OiZu YnNwOzxhIGhyZWY9Imh0dHBzOi8vd3d3LnczLm9yZy8yMDE5LzAyLzA3LXR0LW1pbnV0ZXMuaHRt bCNpdGVtMDMiIHJlbD0ibm9vcGVuZXIgbm9yZWZlcnJlciIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBz Oi8vd3d3LnczLm9yZy8yMDE5LzAyLzA3LXR0LW1pbnV0ZXMuaHRtbCNpdGVtMDM8L2E+PC9zcGFu PjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEwLjVwdDsgZm9udC1m YW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGNvbG9yOiBibGFjazsiPiZuYnNwOzwvc3Bhbj48 c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMC41cHQ7IGZvbnQtZmFt aWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBjb2xvcjogYmxhY2s7Ij5EdXJpbmcgdGhlIG1lZXRp bmcgY29uY2VybiB3YXMgcmFpc2VkIGFib3V0IHRoZSBhcHByb2FjaCB0byB0aGUgSUFOQSByZWdp c3RlcmVkIG1lZGlhIHR5cGUsIHNwZWNpZmljYWxseSB0aGUgbWVhbmluZyBvZiBzZWN0aW9uIDgu IElBTkEgQ29uc2lkZXJhdGlvbnMuPC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6IDEwLjVwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGNv bG9yOiBibGFjazsiPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOiAxMC41cHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBjb2xv cjogYmxhY2s7Ij5UaGVyZSB3YXMgY29uc2Vuc3VzIGFtb25nc3QgdGhlIGdyb3VwIHRoYXQgdGhl IHRleHQgc3BlY2lmeWluZyB0aGF0IHRoaXMgdGV4dDo8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9y OmJsYWNrIj48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTAuNXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fu cy1zZXJpZjsgY29sb3I6IGJsYWNrOyI+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpi bGFjayI+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6IDEwLjVwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMt c2VyaWY7IGNvbG9yOiBibGFjazsiPuKAnFRoZSBtZWRpYSB0eXBlcyByZWdpc3RyeSBTSE9VTEQg YmUgdXBkYXRlZCB0byBtYWtlIHJlZmVyZW5jZSB0byB0aGlzIGRvY3VtZW50IGZvciB0aGUgYXBw bGljYXRpb24vdHRtbCYjNDM7eG1sIG1lZGlhIHR5cGUu4oCdJm5ic3A7PC9zcGFuPjxzcGFuIHN0 eWxlPSJjb2xvcjpibGFjayI+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEwLjVwdDsgZm9udC1mYW1pbHk6IENh bGlicmksIHNhbnMtc2VyaWY7IGNvbG9yOiBibGFjazsiPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHls ZT0iY29sb3I6YmxhY2siPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMC41cHQ7IGZvbnQtZmFtaWx5OiBDYWxp YnJpLCBzYW5zLXNlcmlmOyBjb2xvcjogYmxhY2s7Ij5pcyBpbmNvcnJlY3QgYW5kIG5lZWRzIHRv IGJlIGNoYW5nZWQuIFRoZSBtZWRpYSB0eXBlIHJlZ2lzdHJhdGlvbiBmb3IgVFRNTCBpcyBvd25l ZCBieSBXM0MgYW5kIHNob3VsZCBub3QgYmUgY2hhbmdlZCBieSBJRVRGIOKAkyB3ZSBub3RlIHRo YXQgdGhlIGNoYW5nZSBjb250cm9sDQogaXMgY2xlYXJseSBtYXJrZWQgYXMgYmVpbmcgb3duZWQg YnkgVzNDIHNvIGluIHRoYXQgc2Vuc2UgdGhpcyB0ZXh0IGlzIGluY29uc2lzdGVudC48L3NwYW4+ PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTAuNXB0OyBmb250LWZh bWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgY29sb3I6IGJsYWNrOyI+Jm5ic3A7PC9zcGFuPjxz cGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEwLjVwdDsgZm9udC1mYW1p bHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGNvbG9yOiBibGFjazsiPlRoZSBJQU5BIG1lZGlhIHR5 cGUgcmVnaXN0cmF0aW9uIGl0c2VsZiBkZWZlcnMgdG8gdGhlIFRUV0cgZG9jdW1lbnQg4oCcVFRN TCBNZWRpYSBUeXBlIERlZmluaXRpb24gYW5kIFByb2ZpbGUgUmVnaXN0cnnigJ0gWzJdIHdoaWNo IGlzIGFscmVhZHkgcmVmZXJlbmNlZCBieSB0aGUNCiBSVFAgUGF5bG9hZCBkcmFmdC4gQW4gaW1w cm92ZW1lbnQgd291bGQgdGhlcmVmb3JlIGJlIHRvIHVwZGF0ZSB0aGUgdGV4dCBpbiBzZWN0aW9u IDggdG8gc3VnZ2VzdCB0aGF0IFsyXSBjYW4gYmUgdXBkYXRlZCB0byBpbmNsdWRlIHRoZSBwcm9m aWxlcyBkZWZpbmVkIHdpdGhpbiB0aGUgcGF5bG9hZCBkb2N1bWVudC4gSW5kZWVkIGRvaW5nIHNv IHdvdWxkIHJlc3VsdCBpbiB0aGUgY3JlYXRpb24gb2YgYSBzaG9ydCBjb2RlIGZvciB0aGUgcHJv ZmlsZQ0KIHByb2Nlc3NvciBtZW50aW9uZWQgaW4gc2VjdGlvbiZuYnNwOzQuMi4xLjIuMS4zIFBy b2Nlc3NvciBwcm9maWxlIHNpZ25hbGxpbmcuPC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFj ayI+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6IDEwLjVwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2Vy aWY7IGNvbG9yOiBibGFjazsiPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2si Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOiAxMC41cHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlm OyBjb2xvcjogYmxhY2s7Ij5bMl0gVFRNTCBNZWRpYSBUeXBlIERlZmluaXRpb24gYW5kIFByb2Zp bGUgUmVnaXN0cnkmbmJzcDs8YSBocmVmPSJodHRwczovL3d3dy53My5vcmcvVFIvdHRtbC1wcm9m aWxlLXJlZ2lzdHJ5IiByZWw9Im5vb3BlbmVyIG5vcmVmZXJyZXIiIHRhcmdldD0iX2JsYW5rIj5o dHRwczovL3d3dy53My5vcmcvVFIvdHRtbC1wcm9maWxlLXJlZ2lzdHJ5PC9hPi88L3NwYW4+PHNw YW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTAuNXB0OyBmb250LWZhbWls eTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgY29sb3I6IGJsYWNrOyI+Jm5ic3A7PC9zcGFuPjxzcGFu IHN0eWxlPSJjb2xvcjpibGFjayI+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEwLjVwdDsgZm9udC1mYW1pbHk6 IENhbGlicmksIHNhbnMtc2VyaWY7IGNvbG9yOiBibGFjazsiPiZuYnNwOzwvc3Bhbj48c3BhbiBz dHlsZT0iY29sb3I6YmxhY2siPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMC41cHQ7IGZvbnQtZmFtaWx5OiBD YWxpYnJpLCBzYW5zLXNlcmlmOyBjb2xvcjogYmxhY2s7Ij5UaGUgVFRXRyBhbHNvIGRpc2N1c3Nl ZCB0d28gYWRkaXRpb25hbCBjb25jZXJucyB3aXRob3V0IGNsb3Npbmcgb24gYSBwb3NpdGlvbiBh dCB0aGlzIHRpbWU6PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPG9sIHN0YXJ0PSIxIiB0eXBlPSIxIiBzdHlsZT0ibWFyZ2luLXRvcDowaW4iPg0K PGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJjb2xvcjpibGFjayI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZTogMTAuNXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPkEgcXVl cnkgd2hldGhlciB0aGUgbWVkaWEgdHlwZSByZWdpc3RyYXRpb24gaW5mb3JtYXRpb24gcmVhbGx5 IG5lZWRzIHRvIGJlIGNvcGllZCBpbiBhdCBhbGwgaGVyZSBvciBpZiBpdCBjYW4gYmUgcmVmZXJl bmNlZDs8L3NwYW4+PC9saT48bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImNvbG9yOmJsYWNr Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMC41cHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBz YW5zLXNlcmlmOyI+QSByZXF1ZXN0IHRvIG1ha2Ugc3VyZSB0aGF0IHRoZSBsYW5ndWFnZSBhYm91 dCBwcm9maWxlIHNpZ25hbGxpbmcgZG9lcyBub3QgaW1wbHkgdGhhdCB0aGUgY29kZWNzIHBhcmFt ZXRlciBjYW4gZGVub3RlIGFsbCBwcm9maWxlcywgZXNwZWNpYWxseSBpbiB0aGUNCiBjYXNlIHRo YXQgdGhlIHBheWxvYWQgZG9jdW1lbnQgY29udGFpbnMgYW4gZW1iZWRkZWQgcHJvZmlsZS48L3Nw YW4+PC9saT48L29sPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6IDEwLjVwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGNvbG9y OiBibGFjazsiPlRUV0cgbWF5IHByb3ZpZGUgZnVydGhlciBpbnB1dCBvbiB0aG9zZSB0d28gcG9p bnRzIGJ1dCB3b3VsZCB3ZWxjb21lIGZ1cnRoZXIgaW5wdXQgZXNwZWNpYWxseSBvbiB0aGUgZmly c3QuPC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEwLjVw dDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGNvbG9yOiBibGFjazsiPiZuYnNw Ozwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMC41cHQ7 IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBjb2xvcjogYmxhY2s7Ij5LaW5kIHJl Z2FyZHMsPC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEw LjVwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGNvbG9yOiBibGFjazsiPiZu YnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMC41 cHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBjb2xvcjogYmxhY2s7Ij5OaWdl bCBNZWdpdHQgYXMgQ2hhaXIgb2YgVzNDIFRUV0c8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJs YWNrIj48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZTogMTAuNXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1z ZXJpZjsgY29sb3I6IGJsYWNrOyI+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFj ayI+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9IjE3OWIyNWEyLTMyY2ItNDlkNy1iOWNi LTc4NzE0MjRkOTllOSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTAuNXB0OyBmb250LWZhbWls eTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgY29sb3I6IGJsYWNrOyI+Jm5ic3A7PC9zcGFuPjxzcGFu IHN0eWxlPSJjb2xvcjpibGFjayI+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSIxNzliMjVhMi0zMmNi LTQ5ZDctYjljYi03ODcxNDI0ZDk5ZTkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEwLjVwdDsg Zm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGNvbG9yOiBibGFjazsiPi0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS08YnI+DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNr Ij48YnI+DQo8YSBocmVmPSJodHRwOi8vd3d3LmJiYy5jby51ayIgcmVsPSJub29wZW5lciBub3Jl ZmVycmVyIiB0YXJnZXQ9Il9ibGFuayI+aHR0cDovL3d3dy48c3BhbiBjbGFzcz0iaWwiPmJiYzwv c3Bhbj4uPHNwYW4gY2xhc3M9ImlsIj5jbzwvc3Bhbj4uPHNwYW4gY2xhc3M9ImlsIj51azwvc3Bh bj48L2E+PGJyPg0KVGhpcyBlLW1haWwgKGFuZCBhbnkgYXR0YWNobWVudHMpIGlzIGNvbmZpZGVu dGlhbCBhbmQgbWF5IGNvbnRhaW4gcGVyc29uYWwgdmlld3Mgd2hpY2ggYXJlIG5vdCB0aGUgdmll d3Mgb2YgdGhlDQo8c3BhbiBjbGFzcz0iaWwiPkJCQzwvc3Bhbj4gdW5sZXNzIHNwZWNpZmljYWxs eSBzdGF0ZWQuPGJyPg0KSWYgeW91IGhhdmUgcmVjZWl2ZWQgaXQgaW4gZXJyb3IsIHBsZWFzZSBk ZWxldGUgaXQgZnJvbSB5b3VyIHN5c3RlbS48YnI+DQpEbyBub3QgdXNlLCBjb3B5IG9yIGRpc2Ns b3NlIHRoZSBpbmZvcm1hdGlvbiBpbiBhbnkgd2F5IG5vciBhY3QgaW4gcmVsaWFuY2Ugb24gaXQg YW5kIG5vdGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5Ljxicj4NClBsZWFzZSBub3RlIHRoYXQg dGhlIDxzcGFuIGNsYXNzPSJpbCI+QkJDPC9zcGFuPiBtb25pdG9ycyBlLW1haWxzIHNlbnQgb3Ig cmVjZWl2ZWQuPGJyPg0KRnVydGhlciBjb21tdW5pY2F0aW9uIHdpbGwgc2lnbmlmeSB5b3VyIGNv bnNlbnQgdG8gdGhpcy48L3NwYW4+PC9wPg0KPHAgY2xhc3M9IjE3OWIyNWEyLTMyY2ItNDlkNy1i OWNiLTc4NzE0MjRkOTllOSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTAuNXB0OyBmb250LWZh bWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgY29sb3I6IGJsYWNrOyI+LS0tLS0tLS0tLS0tLS0t LS0tLS0tPC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iOThiZTA3NGItNjky NC00NTg5LTlkZDctZjlkNGVlNjRhYWI4Ij4mbmJzcDs8L3A+DQo8cCBjbGFzcz0iOThiZTA3NGIt NjkyNC00NTg5LTlkZDctZjlkNGVlNjRhYWI4Ij4tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t PGJyPg0KPGJyPg0KPGEgaHJlZj0iaHR0cDovL3d3dy5iYmMuY28udWsiIHJlbD0ibm9vcGVuZXIg bm9yZWZlcnJlciIgdGFyZ2V0PSJfYmxhbmsiPmh0dHA6Ly93d3cuPHNwYW4gY2xhc3M9ImlsIj5i YmM8L3NwYW4+LjxzcGFuIGNsYXNzPSJpbCI+Y288L3NwYW4+LjxzcGFuIGNsYXNzPSJpbCI+dWs8 L3NwYW4+PC9hPjxicj4NClRoaXMgZS1tYWlsIChhbmQgYW55IGF0dGFjaG1lbnRzKSBpcyBjb25m aWRlbnRpYWwgYW5kIG1heSBjb250YWluIHBlcnNvbmFsIHZpZXdzIHdoaWNoIGFyZSBub3QgdGhl IHZpZXdzIG9mIHRoZQ0KPHNwYW4gY2xhc3M9ImlsIj5CQkM8L3NwYW4+IHVubGVzcyBzcGVjaWZp Y2FsbHkgc3RhdGVkLjxicj4NCklmIHlvdSBoYXZlIHJlY2VpdmVkIGl0IGluIGVycm9yLCBwbGVh c2UgZGVsZXRlIGl0IGZyb20geW91ciBzeXN0ZW0uPGJyPg0KRG8gbm90IHVzZSwgY29weSBvciBk aXNjbG9zZSB0aGUgaW5mb3JtYXRpb24gaW4gYW55IHdheSBub3IgYWN0IGluIHJlbGlhbmNlIG9u IGl0IGFuZCBub3RpZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVseS48YnI+DQpQbGVhc2Ugbm90ZSB0 aGF0IHRoZSA8c3BhbiBjbGFzcz0iaWwiPkJCQzwvc3Bhbj4gbW9uaXRvcnMgZS1tYWlscyBzZW50 IG9yIHJlY2VpdmVkLjxicj4NCkZ1cnRoZXIgY29tbXVuaWNhdGlvbiB3aWxsIHNpZ25pZnkgeW91 ciBjb25zZW50IHRvIHRoaXMuPC9wPg0KPHAgY2xhc3M9Ijk4YmUwNzRiLTY5MjQtNDU4OS05ZGQ3 LWY5ZDRlZTY0YWFiOCI+LS0tLS0tLS0tLS0tLS0tLS0tLS0tPC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwPjwvcD4NCjxwIGNsYXNzPSI1ZjIwMmY4MS03MzEw LTRjNjEtYmQxOS03M2VhMzUyODRmM2EiPiZuYnNwOzwvcD4NCjxwIGNsYXNzPSI1ZjIwMmY4MS03 MzEwLTRjNjEtYmQxOS03M2VhMzUyODRmM2EiPi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08 YnI+DQo8Zm9udCBzaXplPSIzIiBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxmb250IHNpemU9IjMi IGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PGZvbnQgc2l6ZT0iMyIgZmFjZT0iVGltZXMgTmV3IFJv bWFuIj48YnI+DQo8Zm9udCBzaXplPSIzIiBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxhIGhyZWY9 Imh0dHA6Ly93d3cuYmJjLmNvLnVrIiB0YXJnZXQ9Il9ibGFuayIgcmVsPSJub29wZW5lciBub3Jl ZmVycmVyIj5odHRwOi8vd3d3LjxzcGFuIGNsYXNzPSJpbCI+YmJjPC9zcGFuPi48c3BhbiBjbGFz cz0iaWwiPmNvPC9zcGFuPi48c3BhbiBjbGFzcz0iaWwiPnVrPC9zcGFuPjwvYT48YnI+DQpUaGlz IGUtbWFpbCAoYW5kIGFueSBhdHRhY2htZW50cykgaXMgY29uZmlkZW50aWFsIGFuZCBtYXkgY29u dGFpbiBwZXJzb25hbCB2aWV3cyB3aGljaCBhcmUgbm90IHRoZSB2aWV3cyBvZiB0aGUNCjxzcGFu IGNsYXNzPSJpbCI+QkJDPC9zcGFuPiB1bmxlc3Mgc3BlY2lmaWNhbGx5IHN0YXRlZC48YnI+DQpJ ZiB5b3UgaGF2ZSByZWNlaXZlZCBpdCBpbiBlcnJvciwgcGxlYXNlIGRlbGV0ZSBpdCBmcm9tIHlv dXIgc3lzdGVtLjxicj4NCkRvIG5vdCB1c2UsIGNvcHkgb3IgZGlzY2xvc2UgdGhlIGluZm9ybWF0 aW9uIGluIGFueSB3YXkgbm9yIGFjdCBpbiByZWxpYW5jZSBvbiBpdCBhbmQgbm90aWZ5IHRoZSBz ZW5kZXIgaW1tZWRpYXRlbHkuPGJyPg0KUGxlYXNlIG5vdGUgdGhhdCB0aGUgPHNwYW4gY2xhc3M9 ImlsIj5CQkM8L3NwYW4+IG1vbml0b3JzIGUtbWFpbHMgc2VudCBvciByZWNlaXZlZC48YnI+DQpG dXJ0aGVyIGNvbW11bmljYXRpb24gd2lsbCBzaWduaWZ5IHlvdXIgY29uc2VudCB0byB0aGlzLjwv Zm9udD48L2ZvbnQ+PC9mb250PjwvZm9udD48L3A+DQo8cCBjbGFzcz0iNWYyMDJmODEtNzMxMC00 YzYxLWJkMTktNzNlYTM1Mjg0ZjNhIj4tLS0tLS0tLS0tLS0tLS0tLS0tLS08L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8 L3NwYW4+DQo8cD48L3A+DQo8cCBjbGFzcz0iMmVhMWNiYzAtOTdhYi00YWYzLWFjMDEtODRiMDk0 OTY4NTlkIj4mbmJzcDs8L3A+DQo8cCBjbGFzcz0iMmVhMWNiYzAtOTdhYi00YWYzLWFjMDEtODRi MDk0OTY4NTlkIj4tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPGJyPg0KPGZvbnQgc2l6ZT0i MyIgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48Zm9udCBzaXplPSIzIiBmYWNlPSJUaW1lcyBOZXcg Um9tYW4iPjxmb250IHNpemU9IjMiIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PGJyPg0KPGZvbnQg c2l6ZT0iMyIgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48YSBocmVmPSJodHRwOi8vd3d3LmJiYy5j by51ayIgdGFyZ2V0PSJfYmxhbmsiPmh0dHA6Ly93d3cuPHNwYW4gY2xhc3M9ImlsIj5iYmM8L3Nw YW4+LjxzcGFuIGNsYXNzPSJpbCI+Y288L3NwYW4+LjxzcGFuIGNsYXNzPSJpbCI+dWs8L3NwYW4+ PC9hPjxicj4NClRoaXMgZS1tYWlsIChhbmQgYW55IGF0dGFjaG1lbnRzKSBpcyBjb25maWRlbnRp YWwgYW5kIG1heSBjb250YWluIHBlcnNvbmFsIHZpZXdzIHdoaWNoIGFyZSBub3QgdGhlIHZpZXdz IG9mIHRoZQ0KPHNwYW4gY2xhc3M9ImlsIj5CQkM8L3NwYW4+IHVubGVzcyBzcGVjaWZpY2FsbHkg c3RhdGVkLjxicj4NCklmIHlvdSBoYXZlIHJlY2VpdmVkIGl0IGluIGVycm9yLCBwbGVhc2UgZGVs ZXRlIGl0IGZyb20geW91ciBzeXN0ZW0uPGJyPg0KRG8gbm90IHVzZSwgY29weSBvciBkaXNjbG9z ZSB0aGUgaW5mb3JtYXRpb24gaW4gYW55IHdheSBub3IgYWN0IGluIHJlbGlhbmNlIG9uIGl0IGFu ZCBub3RpZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVseS48YnI+DQpQbGVhc2Ugbm90ZSB0aGF0IHRo ZSA8c3BhbiBjbGFzcz0iaWwiPkJCQzwvc3Bhbj4gbW9uaXRvcnMgZS1tYWlscyBzZW50IG9yIHJl Y2VpdmVkLjxicj4NCkZ1cnRoZXIgY29tbXVuaWNhdGlvbiB3aWxsIHNpZ25pZnkgeW91ciBjb25z ZW50IHRvIHRoaXMuPC9mb250PjwvZm9udD48L2ZvbnQ+PC9mb250PjwvcD4NCjxwIGNsYXNzPSIy ZWExY2JjMC05N2FiLTRhZjMtYWMwMS04NGIwOTQ5Njg1OWQiPi0tLS0tLS0tLS0tLS0tLS0tLS0t LTwvcD4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_D8A2B50A3E3B9nigelmegittbbccouk_-- From nobody Mon Mar 4 11:08:31 2019 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67E93130DEA; Mon, 4 Mar 2019 11:08:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.7 X-Spam-Level: X-Spam-Status: No, score=0.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, GB_SUMOF=5, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=qti.qualcomm.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RicEiALUsHiP; Mon, 4 Mar 2019 11:08:19 -0800 (PST) Received: from alexa-out-sd-01.qualcomm.com (alexa-out-sd-01.qualcomm.com [199.106.114.38]) (using TLSv1.2 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 98FB01277D2; Mon, 4 Mar 2019 11:08:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1551726498; x=1583262498; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=eyFDtIWfHkKkxTgwE5NCzwfuuMGgxWrSiovJ6UpfnAk=; b=LYiyYjrLyKZuTud2O4y5PMTGaAAwbOnEoIY1Pk5RZUXSk8V6XYqUxXG9 c728N12l9E/7xoFjTjslvIJJTamuGdlKkzF74rMzfPNLp/+WEv1e6cfyw uIMdaBCWP0P1xmKnpkuiO0VoIK+ixl3+dkpTOEO55mBpBWd/vyRpXyTml M=; X-IronPort-AV: E=Sophos;i="5.58,441,1544515200"; d="scan'208";a="31708981" Received: from unknown (HELO ironmsg04-sd.qualcomm.com) ([10.53.140.144]) by alexa-out-sd-01.qualcomm.com with ESMTP; 04 Mar 2019 11:08:16 -0800 Received: from nasanexm01e.na.qualcomm.com ([10.85.0.31]) by ironmsg04-sd.qualcomm.com with ESMTP/TLS/AES256-SHA; 04 Mar 2019 11:08:16 -0800 Received: from NASANEXM01C.na.qualcomm.com (10.85.0.83) by NASANEXM01E.na.qualcomm.com (10.85.0.31) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Mon, 4 Mar 2019 11:08:15 -0800 Received: from NASANEXM01C.na.qualcomm.com ([10.85.0.83]) by NASANEXM01C.na.qualcomm.com ([10.85.0.83]) with mapi id 15.00.1395.000; Mon, 4 Mar 2019 11:08:15 -0800 From: Giridhar Mandyam To: Benjamin Kaduk CC: Magnus Westerlund , The IESG , "roni.even@mail01.huawei.com" , "payload-chairs@ietf.org" , "payload@ietf.org" , "draft-ietf-payload-flexible-fec-scheme@ietf.org" Thread-Topic: [payload] Benjamin Kaduk's Discuss on draft-ietf-payload-flexible-fec-scheme-17: (with DISCUSS and COMMENT) Thread-Index: AQHUx9RmiuNsr5OuwEy90ary5L7nTaXvcY8ggAPq6ICACGIkQA== Date: Mon, 4 Mar 2019 19:08:15 +0000 Message-ID: <55e0b103a8824dd4a770678b974628ce@NASANEXM01C.na.qualcomm.com> References: <155052681367.25946.18116200153523550938.idtracker@ietfa.amsl.com> <0ef384ddaabd4883b77db08a477ab822@NASANEXM01C.na.qualcomm.com> <20190227002556.GE53396@kduck.mit.edu> In-Reply-To: <20190227002556.GE53396@kduck.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [199.106.107.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [payload] Benjamin Kaduk's Discuss on draft-ietf-payload-flexible-fec-scheme-17: (with DISCUSS and COMMENT) X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Mar 2019 19:08:24 -0000 Thanks Benjamin. Apologies for the late reply, but we (the editors) were c= onfirming the best response to your follow-up questions. > Maybe my question was not phrased well. IIUC, the repair packets can onl= y cover real media source streams that are part of the same RTP session. So in order for both audio and video to be available in the same RTP sessio= n as potential input to asingle repair packet stream, the audio and video w= ould need to be together in the same RTP session; presumably that would inv= olve getting demux'd based on payload type or SSRC, which is what I'm readi= ng 3550 as saying to not do. Am I just misunderstanding that the repair in= puts must be part of the same RTP session? In my interpretation, the issue revolves around what "demultiplexing" means= in this context. I do not believe it was meant to contemplate the recover= y of packets from a repair stream, which involves more than just "demultipl= exing" of audio and video payloads. I don't believe Sec. 5.2 of RFC 3550 r= eally applies. > > Payload Type: The (dynamic) payload type for the FEC repair packe= ts is determined through out-of-band means. [...] > > Is "(e.g., SDP)" applicable here? Sorry I missed this in my original response. Yes, it does make sense and I= have added it. >>> Any reason not to include "retransmit" and "fixed block" mnemonics for = the 'R' and 'F' bits?=20 >> Can you explain further? The R/F definitions already include mention of= retransmission and fixed FEC L/D. > I was thinking that the first sentence could say '(R and F bits, for "ret= ransmit" and "fixed block")' to (in effect) "name" the bits right away. Proposed text: 4.2.2. FEC Header of FEC Repair Packets The format of the FEC header has 3 variants, depending on the values in the first 2 bits (R and F bits) as shown in Figure 10. Note that R and F stand for "retransmit" and "fixed block", respectively. > >> Please include a note here that several fields (e.g., P, PT, etc.) in= the FEC header are not meant to be interpreted directly but are instead ac= tual FEC parity data akin to the following "payload". (Absent such an indic= ation, the reader could see that these fields are "used to determine" value= s when they appear to contain values directly, and get confused.) > > >I would suggest adding a forward-reference to Section 6 since that des= cribes how the Repair Payload is calculated. >> I am sorry. I do not understand what is meant by "used to determine" va= lues. Can you explain? >I was trying to consolidate remarks about 4.2.2, 4.2.2.1 and 4.2.2.2 into = a single comment, but it came across badly; sorry for the confusion. The l= ast bullet point of Section 4.2.2 notes that "The P, X, CC, M and PT recove= ry fields are used to determine the corresponding fields of the recovered p= ackets". Similarly, Figures 12 and 13 both have fields named for "PT recove= ry", "length recovery", etc., with corresponding descriptions in the main t= ext like "the length recovery (16 bits) field is used to determine the leng= th of the recovered packets" -- these are the "used to determine" text to w= hich I refer. So my concrete suggestion is to add a reference to Section 6= .3.2 at the end of that final bullet in Section 4.2.2. I'd consider adding= it to the field descriptions in 4.2.2.1 as well, but that might be overkil= l, so use your judgement. Forward reference is added. Thanks. > >> Should implementations set bounds on L and D that are smaller than the= maximum encodable value (255)? > > Yes. This is assumed. >Perhaps it's best to state it explicitly rather than leaving an implicit a= ssumption. > >> If L=3D0, D=3D0, use the optional payload format parameters for L and = D. What is the behavior when those payload format parameters were not prov= ided? > >Optional payload format parameters may be provided in SDP (see Sec. 5.1)= . >Right. But suppose they weren't, and yet the L=3D0,D=3D0 packet shows up = on the wire. This is clearly an error condition; what's the error handling= ? Proposed text immediately following Fig. 14: Given the 8-bit limit on L and D (as depicted in Figure 13), the maximum value of either parameter is 255. The "optional payload format parameters" (Figure 14) to be used when L=3D0 and D=3D0 can be determined through out-of-band signaling (see Section 5). If L=3D0 and D=3D0 and cannot be determined through out-of-band signaling, then the repair packet MUST be ignored by the receiver. In addition when L=3D1 and D=3D0, the repair packet becomes a retransmission of a corresponding source packet. > >> The L=3D1 case seems to imply that some full packet retransmission wil= l be used; is it worth calling that out as a consequence of such a paramete= r choice? >> I am not sure that I understand this statement. L=3D1 does not imply an= ything about the value of D. >I agree with your statement. But, we seem to allow for L to be 1, and in = particular for L=3D1,D=3D0 (also L=3D1,D=3D1). For those combinations of L= and D, the "Row FEC" case will in fact be packet retransmission, as a dege= nerate case. I'm proposing that either this oddity is mentioned explicitly= (e.g., "note that when L=3D1, the Row FEC packets will just be retransmiss= ion"), or disallowed by the numerical constraints. Though now that I know = better how the multi-SSRC case is handled (per Magnus's comments and my rep= ly thereto), I guess you could use L=3D1 as part of a multi-SSRC repair and= it would not be equivalent to retransmission. So the situation is more co= mplicated than I first thought. >Regardless, since the conditions here do allow L=3D1 as a possibility, I s= uggest some additional discussion in the text about how it's a bit strange = and probably not expected to be used. As you mentioned above for bundled protection, individual L/D combinations = can be declared for each SSRC (such as L=3D1,D=3D0) but the overall repair = packet may in fact not be a retransmission of any individual packet. An ex= ample could be an audio/video session where very few audio packets (as few = as one) are bundled with several video packets in the generation of the rep= air packet. In such a case, it might be perfectly valid to set L=3D1, D=3D= 0 for the audio packet. So I am not sure about what is best approach to t= he additional discussion. Did you have a concrete suggestion? >> > What is the interaction between rate, repair-window, and the L and D v= alues? That is, if we set L and D to be large, and rate to be small, can w= e end up claiming a repair window that is too small to accumulate the neces= sary L*D source packets and compute recovery packets? >> Yes, it is possible. We expect that specific uses of FLEX FEC will boun= d the appropriate values for repair window, L and D. It is difficult to es= tablish these bounds in this specification, however, since the applications= that are currently making use of FLEX FEC are varied (e.g. WebRTC, 3GPP MT= SI). We expect these specification to provide concrete guidance on the exp= ected repair windows, L and D, based on the target application. >Please do not rely on unstated expectations for the behavior of consumers = of this mechanism! I strongly suggest to provide some indication, even a v= ague and incomplete one, that there are to be interrelations and implementa= tion restrictions on these parameters. Proposed additional section: 1.1.7. Repair Window Considerations The value for the repair window duration depends on the L and D values and cannot be chosen arbitrarily. More specifically, L and D values determine the lower limit for the repair window duration. The upper limit of the repair window duration does not depend on the L and D values. Note that a discussion of rate is difficult (in my opinion) without making = assumptions about the source SSRC's. For the above section, however, I can= add a sentence such as "The rate of the source streams should also be cons= idered, as the repair window duration should ideally span several packetiza= tion intervals in order to leverage the error correction capabilities of th= e parity code." =20 >> > Section 5.2.1 >>> o The value for the repair-window parameter depends on the L and D = values and cannot be chosen arbitrarily. More specifically, L and D values= determine the lower limit for the repair-window size. The upper limit of t= he repair-window size does not depend on the L and D values. >>>Per my above remark, this consideration seems generally applicable and n= ot limited to SDP Offer/Answer. >> This is also covered in Sec. 1.1, which provides the general guidance. >An inline note that the repair window "is defined as the time that spans a= FEC block", I see now. But this is still in fairly abstract terms; I woul= d have expected to see the note I quoted in my ballot to appear in a top-le= vel Section 5 entry, and not in the subsection specific to SDP O/A. >>> o Any unknown option in the offer MUST be ignored and deleted from = the answer. If FEC is not desired by the receiver, it can be deleted from = the answer. >>> This sounds like it is restating an existing normative requirement (in= which case a reference and descriptive, non-normative, text seems appropri= ate). >> This requirement is specific to SDP O/A. Can you explain further as to w= hy you think there is a different normative requirement? >Ali got what I intended, though I was hoping for a reference to the releva= nt SDP RFC as well as the s/MUST/must/. Proposed modifications: o The value for the repair-window parameter depends on the L and D values. Based on the values of L and D, a lower bound on the repair-window can be inferred (see Section 1.1.7). o Although combinations with the same L and D values but with different repair-window sizes produce the same FEC data, such combinations are still considered different offers. The size of the repair-window is related to the maximum delay between the transmission of a source packet and the associated repair packet. This directly impacts the buffering requirement on the receiver side and the receiver must consider this when choosing an offer. o Any unknown option in the offer must be ignored and deleted from the answer (see Section 6 of [RFC3264]). If FEC is not desired by the receiver, it can be deleted from the answer. Sec. 6.2: > To be clear, this is an editorial matter and you are free to ignore me, b= ut my suggested wording is "The first 16 bits of the RTP header (16 bits), = though the first two (version) bits will be ignored by the recovery procedu= re". Proposed text is added. > s/compute the FEC bit string from/extract the FEC bit string as/ Proposed text is added. >>> I don't see how this matches up with the bit string construction in Se= ction 6.2. >> As per Sec. 6.2, "The rest of the FEC bit string, which contains everyt= hing after ... >In particular I'm confused about the order between length recovery and TS = recovery. In the FEC header (for non-retransmissions), length recovery app= ears before TS recovery. In Section 6.2, as we extract things from the FEC= bit string, we write out the length recovery value into the FEC header, an= d then (the next bits from the FEC bit string are) the TS recovery value. >But here we take the TS field and then the length field from the recovery = bit string, which is in the other order. Am I missing some step that cause= s the order that these fields appear in the bit stream to change? Agreed. The proposed change that seems to fix this in Sec. 6.3.2 is: 11. Set the SN field in the new packet to SEQNUM. 12. Take the next 16 bits of the recovered bit string and set the new variable Y to whatever unsigned integer this represents (assuming network order). Convert Y to host order. Y represents the length of the new packet in bytes minus 12 (for the fixed RTP header), i.e., the sum of the lengths of all the following if present: the CSRC list, header extension, RTP payload and RTP padding. 13. Set the TS field in the new packet to the next 32 bits in the recovered bit string. 14. Set the SSRC of the new packet to the SSRC of the missing source RTP stream. >> "Given that FLEX FEC enables the protection of multiple source streams, = there exists the possibility that multiple source buffers may be created th= at may not be used. An attacker could leverage unused source buffers to as= a means of occupying memory in a FLEX FEC endpoint. ***In addition, an at= tack against the FEC parameters themselves (e.g. repair window, D or L valu= es) can result in a receiver having to allocate source buffer space that ma= y also lead to excessive consumption of resources.*** Moreover the applica= tion source data may not be perfectly matched with FLEX FEC source partitio= ning. If this is the case, there is a possibility for unprotected source d= ata if, for instance, the FLEX FEC implementation discards data that does n= ot fit perfectly into its source processing requirements. "=20 >That's an improvement, thanks. I don't think it covers my penultimate par= agraph about a network attacker being able to force bit flips in the recove= red packet length field, though, and I do think it's worth documenting that= as a risk (when integrity protection is not used). Given that FLEX FEC enables the protection of multiple source streams, there exists the possibility that multiple source buffers may be created that may not be used. An attacker could leverage unused source buffers to as a means of occupying memory in a FLEX FEC endpoint. In addition, an attack against the FEC parameters themselves (e.g. repair window, D or L values) can result in a receiver having to allocate source buffer space that may also lead to excessive consumption of resources. ***Similarly, a network attacker could modify the recovery fields corresponding to packet lengths (assuming there are no message integrity mechanisms) which in turn could force unnecessarily large memory allocations at the receiver.*** Moreover the application source data may not be perfectly matched with FLEX FEC source partitioning. If this is the case, there is a possibility for unprotected source data if, for instance, the FLEX FEC implementation discards data that does not fit perfectly into its source processing requirements. >I would strongly suggest adding some text at the end of or after the first= pargaraph of section 4.2.2.2, to the effect of: > The values of L and D for a given block of recovery data will correspond= to the type of recovery in use for that block of data. In particular, for 2= -D repair, the (L,D) values will not be constant across all packets for a given SSRC being repaired. Similarly, the L and D values can differ acro= ss different blocks of repair data (repairing different SSRCs) in a single packet. Proposed text has been added. Thanks. >Regardless, I am still not 100% clear on the layout of the repair payload = for the multi-SSRC case. E.g., in Figure 13, we see that there are multipl= e SN base/L/D entries before the payload, which is a single consolidated pa= yload that (presumably) covers all the recovery SSRCs. Your description above makes it sound like each SN base/L/D indicates a set= of packets, and the payload is the XOR of all of those sets together (padd= ed if necessary). That is, one could perhaps imagine conceptually doing th= is in two steps: (1) XOR together the packets indicated by the respective S= N base/L/D for each SSRC, and then (2) XOR those results together to combin= e the N SSRC recovery blocks into a single repair payload. Did I get it ri= ght this time? You can do it as you have described. It is not strictly required to do it = that way. The source packets could be arranged in such a way that the XOR = operation can be performed in one step, rather than the two you describe. = Any method is fine as long as the desired parity is created - row-wise, col= umn-wise, or flex mask. -----Original Message----- From: Benjamin Kaduk =20 Sent: Tuesday, February 26, 2019 4:26 PM To: Giridhar Mandyam Cc: Magnus Westerlund ; The IESG ; roni.even@mail01.huawei.com; payload-chairs@ietf.org; payload@ietf.o= rg; draft-ietf-payload-flexible-fec-scheme@ietf.org Subject: Re: [payload] Benjamin Kaduk's Discuss on draft-ietf-payload-flexi= ble-fec-scheme-17: (with DISCUSS and COMMENT) ------------------------------------------------------------------------- CAUTION: This email originated from outside of the organization. ------------------------------------------------------------------------- On Mon, Feb 25, 2019 at 12:03:16AM +0000, Giridhar Mandyam wrote: > Thanks to Magnus for the partial response, and Benjamin for the careful r= eview. Yes, a big thanks to Magnus -- the explanation was quite helpful! I'll reply to his comments inline (i.e., at the very end of this message). > >> It's a little odd to see so much content in Section 1.1 before we get = to requirements notation and defintions/notations. >=20 > I don't know what to make of this comment. Is there a concrete suggestio= n that you may have in mind? To be clear, this matter is entirely editorial discretion and you should do= what you prefer, without giving preference to my input. But I would have = taken all the 1.X subsections and put them into a new top-level section tha= t appears between (the current) sections 3.2 and 4; "Conceptual Overview" w= ould be a fine title for such a hypothetical new section. > > I think I'm a bit confused about current best practices for multiplexi= ng, as RFC 3550 Section 5.2 says "separate audio and video streams SHOULD N= OT be carried in a single RTP session and demultiplexed based on the payloa= d type or SSRC fields", but we seem to be not only recommending using SSRC = for demultiplexing repair packets, but also suggesting that the FEC can cov= er multiple different audio and/or video streams with different SSRCs. I gu= ess RFC 8108 is supposed to clarify when it's okay to use multiple SSRCs i= n the same RTP session, so maybe the answer is just "3550 was overly cautio= us and we don't worry about that anymore". >=20 > I think the confusion lies around audio and video source streams. The re= pair packets corresponding to bundled protection are not really source stre= ams, which is what the 3550 guidance was addressing. I think 3550 did not = contemplate bundled protection. Maybe my question was not phrased well. IIUC, the repair packets can only = cover real media source streams that are part of the same RTP session. So in order for both audio and video to be available in the same RTP sessio= n as potential input to asingle repair packet stream, the audio and video w= ould need to be together in the same RTP session; presumably that would inv= olve getting demux'd based on payload type or SSRC, which is what I'm readi= ng 3550 as saying to not do. Am I just misunderstanding that the repair in= puts must be part of the same RTP session? > > Section 4.2.1 > > > > Version (V) 2 bits: This MUST be set to 2 (binary 10), as this > > specification requires all source RTP packets and all FEC repair > > packets to use RTP version 2. The reason for this restriction is > > the first 2 bits of the FEC header contain other information (R > > and F bits) rather than recovering the RTP version field. > > > > nit: is it better to say that the FEC mechanism does not recover=20 > > this value, rather than talking about how the first 2 bits of the=20 > > FEC header are used for something else? (The FEC header's structure=20 > > need not bear any relation to the 12-byte RTP header, AFAICT.) >=20 > Proposal: remove the sentence starting with "The reason for this restric= tion ...". >=20 > > > > Payload Type: The (dynamic) payload type for the FEC repair > > packets is determined through out-of-band means. [...] > > > > Is "(e.g., SDP)" applicable here? > > > > Sequence Number (SN): The sequence number follows the standard > > definition provided in [RFC3550]. definition. Therefore it=20 > > must > > > > nit: drop separate "definition." > > >=20 > Good catch. Will drop in revised I-D. >=20 > > multiplex multiple repair streams in an RTP session. The repair > > streams' SSRC's CNAME SHOULD be identical to the CNAME of the > > source RTP stream(s) that this repair stream protects. An FEC > > stream that protects multiple source RTP streams with different > > CNAME's uses the CNAME associated with the entity generating the > > FEC stream or the CNAME of the entity on whose behalf it performs > > the protection operation. In cases when the repair stream covers > > packets from multiple source RTP streams with different CNAME > > values, any of these CNAME values MAY be used. > > > > I'm not sure I'm parsing this properly; the penultimate sentence=20 > > says that the CNAME to use is determined by nature of the entity=20 > > producing the repair stream, but the last sentence says that there is a= nondeterministic choice. > > >=20 > Proposed change to last sentence: "in cases when the repair stream cover= s packets from multiple source RTP stream with difference CNAME values and = none of these CNAM values can be associated with the entity generating the = FEC stream, then any of these CNAME values MAY be used." That works for me, as does the follow-up suggestion from Ali. > > Section 4.2.2 > > > > Any reason not to include "retransmit" and "fixed block" mnemonics=20 > > for the 'R' and 'F' bits? > > >=20 > Can you explain further? The R/F definitions already include mention of = retransmission and fixed FEC L/D. I was thinking that the first sentence could say '(R and F bits, for "retra= nsmit" and "fixed block")' to (in effect) "name" the bits right away. > > Please include a note here that several fields (e.g., P, PT, etc.)=20 > > in the FEC header are not meant to be interpreted directly but are=20 > > instead actual FEC parity data akin to the following "payload". > > (Absent such an indication, the reader could see that these fields are = "used to determine" > > values when they appear to contain values directly, and get=20 > > confused.) > > > > I would suggest adding a forward-reference to Section 6 since that=20 > > describes how the Repair Payload is calculated. >=20 > I am sorry. I do not understand what is meant by "used to determine" val= ues. Can you explain? I was trying to consolidate remarks about 4.2.2, 4.2.2.1 and 4.2.2.2 into a= single comment, but it came across badly; sorry for the confusion. The la= st bullet point of Section 4.2.2 notes that "The P, X, CC, M and PT recover= y fields are used to determine the corresponding fields of the recovered pa= ckets". Similarly, Figures 12 and 13 both have fields named for "PT recover= y", "length recovery", etc., with corresponding descriptions in the main te= xt like "the length recovery (16 bits) field is used to determine the lengt= h of the recovered packets" -- these are the "used to determine" text to wh= ich I refer. So my concrete suggestion is to add a reference to Section 6.= 3.2 at the end of that final bullet in Section 4.2.2. I'd consider adding = it to the field descriptions in 4.2.2.1 as well, but that might be overkill= , so use your judgement. > > Section 4.2.2.2 > > > > Should implementations set bounds on L and D that are smaller than=20 > > the maximum encodable value (255)? >=20 > Yes. This is assumed. Perhaps it's best to state it explicitly rather than leaving an implicit as= sumption. >=20 > > If L=3D0, D=3D0, use the optional payload format parameters for L and D= . > > What is the behavior when those payload format parameters were not=20 > > provided? > > >=20 > Optional payload format parameters may be provided in SDP (see Sec. 5.1). Right. But suppose they weren't, and yet the L=3D0,D=3D0 packet shows up o= n the wire. This is clearly an error condition; what's the error handling? > > The L=3D1 case seems to imply that some full packet retransmission=20 > > will be used; is it worth calling that out as a consequence of such a p= arameter choice? >=20 > I am not sure that I understand this statement. L=3D1 does not imply any= thing about the value of D. I agree with your statement. But, we seem to allow for L to be 1, and in p= articular for L=3D1,D=3D0 (also L=3D1,D=3D1). For those combinations of L = and D, the "Row FEC" case will in fact be packet retransmission, as a degen= erate case. I'm proposing that either this oddity is mentioned explicitly = (e.g., "note that when L=3D1, the Row FEC packets will just be retransmissi= on"), or disallowed by the numerical constraints. Though now that I know b= etter how the multi-SSRC case is handled (per Magnus's comments and my repl= y thereto), I guess you could use L=3D1 as part of a multi-SSRC repair and = it would not be equivalent to retransmission. So the situation is more com= plicated than I first thought. Regardless, since the conditions here do allow L=3D1 as a possibility, I su= ggest some additional discussion in the text about how it's a bit strange a= nd probably not expected to be used. >=20 > > Section 4.2.2.3 > > > > nit: The "P|X" bits in Figure 15 seem indented by one too many spaces. >=20 > Thanks. Will revise on next I.-D. >=20 > > Section 5.1 (all subsections) > > > > Having the ToP values for interleaved and non-interleaved 1-D=20 > > protection presented in a different order than virtually all of the=20 > > body text (that presents non-interleaved first) is needlessly hard on t= he reader. >=20 > What would you suggest? Would sub-bullets help? I don't think sub-bullets would make much of a difference. I also don't wa= nt to suggest changing the actual protocol values at this late stage, so th= e choice would seem to be between a fairly drastic "swap sections 1.1.1 and= 1.1.2, and similar changes throughougt the body text, 1.1.3, etc.", and le= aving it as-is. I expect I know which one you'll choose, though :) > > What is the interaction between rate, repair-window, and the L and D=20 > > values? That is, if we set L and D to be large, and rate to be=20 > > small, can we end up claiming a repair window that is too small to=20 > > accumulate the necessary L*D source packets and compute recovery packet= s? >=20 > Yes, it is possible. We expect that specific uses of FLEX FEC will bound= the appropriate values for repair window, L and D. It is difficult to est= ablish these bounds in this specification, however, since the applications = that are currently making use of FLEX FEC are varied (e.g. WebRTC, 3GPP MTS= I). We expect these specification to provide concrete guidance on the expe= cted repair windows, L and D, based on the target application. Please do not rely on unstated expectations for the behavior of consumers o= f this mechanism! I strongly suggest to provide some indication, even a va= gue and incomplete one, that there are to be interrelations and implementat= ion restrictions on these parameters. > > Section 5.2.1 > > > > o The value for the repair-window parameter depends on the L and D > > values and cannot be chosen arbitrarily. More specifically, L an= d > > D values determine the lower limit for the repair-window size. > > The upper limit of the repair-window size does not depend on the = L > > and D values. > > > > Per my above remark, this consideration seems generally applicable=20 > > and not limited to SDP Offer/Answer. >=20 > This is also covered in Sec. 1.1, which provides the general guidance. An inline note that the repair window "is defined as the time that spans a = FEC block", I see now. But this is still in fairly abstract terms; I would= have expected to see the note I quoted in my ballot to appear in a top-lev= el Section 5 entry, and not in the subsection specific to SDP O/A. > > o Any unknown option in the offer MUST be ignored and deleted from > > the answer. If FEC is not desired by the receiver, it can be > > deleted from the answer. > > > > This sounds like it is restating an existing normative requirement=20 > > (in which case a reference and descriptive, non-normative, text=20 > > seems appropriate). >=20 > This requirement is specific to SDP O/A. Can you explain further as to wh= y you think there is a different normative requirement? Ali got what I intended, though I was hoping for a reference to the relevan= t SDP RFC as well as the s/MUST/must/. > > Section 6.2 > > > > o The first 16 bits of the RTP header (16 bits). > > > > Maybe note here that we'll actually ignore the first 2 bits? >=20 > Why? The FEC repair is covering all relevant parts of the first 16 bits = of the RTP header. You can only say that the FEC repair is covering all relevant parts because= we require a specific RTP version and thus mak the first 2 bits not releva= nt! To be clear, this is an editorial matter and you are free to ignore me, but= my suggested wording is "The first 16 bits of the RTP header (16 bits), th= ough the first two (version) bits will be ignored by the recovery procedure= ". > > Section 6.3.2 > > > > 2. For the repair packet in T, compute the FEC bit string from the > > first 80 bits of the FEC header. > > > > I'm scratching my head a bit at this. Is this operation something=20 > > other than "take the first 80 bits of the FEC header"? (If not, the=20 > > length and sequence number base seem to be in different places in=20 > > the source packets and FEC bit string, if I'm reading things right.) >=20 > Yes, this is simply the first 80 bits as per the header formats in Sec.'s= 4.2.2.1 and 4.2.2.2. The wording as it stands seems to be accurate. Did = you have a suggestion in mind? s/compute the FEC bit string from/extract the FEC bit string as/ > > 11. Set the SN field in the new packet to SEQNUM. Skip the next 16 > > bits in the recovered bit string. > > > > To be clear, we're skipping over the xor of the reconstructed length=20 > > field with the seqnum field of the source packets? >=20 > Yes. >=20 > > 13. Take the next 16 bits of the recovered bit string and set the > > new variable Y to whatever unsigned integer this represents > > (assuming network order). Convert Y to host order. Y > > represents the length of the new packet in bytes minus 12 (for > > the fixed RTP header), i.e., the sum of the lengths of all the > > following if present: the CSRC list, header extension, RTP > > payload and RTP padding. > > > > I don't see how this matches up with the bit string construction in=20 > > Section 6.2. >=20 > As per Sec. 6.2, > "The rest of the FEC bit string, which contains everything after > the fixed 12-byte RTP header of the source packet, is written into > the Repair "Payload" following the FEC header, where "Payload" > refers to everything after the fixed 12-byte RTP header, including > extensions, CSRC list, true payloads, and padding." In particular I'm confused about the order between length recovery and TS r= ecovery. In the FEC header (for non-retransmissions), length recovery appe= ars before TS recovery. In Section 6.2, as we extract things from the FEC = bit string, we write out the length recovery value into the FEC header, and= then (the next bits from the FEC bit string are) the TS recovery value. But here we take the TS field and then the length field from the recovery b= it string, which is in the other order. Am I missing some step that causes= the order that these fields appear in the bit stream to change? > > Section 6.3.3 > > > > 1. Append Y bytes to the new packet. > > [...] > > 5. Append the recovered bit string (Y octets) to the new packet > > generated in Section 6.3.2. > > > > I think a different verb than "append" should be used in step 1,=20 > > perhaps "allocate Y additional bytes for the new packet", as the=20 > > text as-written has us appending 2*Y bytes, only Y of which have a valu= e specified. >=20 > Agreed. Proposed new wording for steps 1 and 5: >=20 > "1. Allocate Y additional bytes for the new packet generated in Section = 6.3.2." > "5. Set the last Y octets in the new packet to the recovered bit string.= "=20 That works for me; thanks. > > Section 9 > > > > The main > > security considerations for the RTP packet carrying the RTP payload > > format defined within this memo are confidentiality, integrity and > > source authenticity. Confidentiality is achieved by encrypting the > > RTP payload. Integrity of the RTP packets is achieved through a > > suitable cryptographic integrity protection mechanism. [...] > > > > This phrasing of "is achieved by" implies that the mechanisms for=20 > > doing so are defined in this document, but that's not the case. =20 > > Don't we really mean things like "Confidentiality can be provided by=20 > > encrypting the RTP payload"? >=20 > Proposed new wording as recommended: "Confidentiality can be provided=20 > by encrypting the RTP payload." Thanks! > > Given that FLEX FEC enables the protection of multiple source > > streams, there exists the possibility that multiple source buffers > > may be created that may not be used. An attacker could leverage > > unused source buffers to as a means of occupying memory in a FLEX FE= C > > endpoint. Moreover the application source data may not be perfectly > > matched with FLEX FEC source partitioning. If this is the case, > > there is a possibility for unprotected source data if, for instance, > > the FLEX FEC implementation discards data that does not fit perfectl= y > > into its source processing requirements. > > > > I don't think this text quite covers the risks when interacting with=20 > > an adversarial endpoint -- an attacker could try to advertise FEC=20 > > schemes with large D and L and/or large repair windows, that cause=20 > > the receiver to consume a lot of resources buffering packets that=20 > > may be used as repair inputs. Endpoints need to be aware of the=20 > > risk when deciding whether to accept FEC streams, e.g., via SDP Offer/A= nswer. > > > > Similarly, a network attacker could modify the recovery fields=20 > > corresponding to packet lengths (when integrity protection is not in=20 > > play), to force large allocations on the receiver. It's fairly=20 > > likely that this doesn't even require knowing which source packet(s)=20 > > will be lost, since length is a 16-bit field and the expected input=20 > > values are not likely to have the high bit(s) set. > > > > The need for integrity protection on the SDP Offer/Answer exchange=20 > > is probably sufficiently well-documented elsewhere that we don't=20 > > need to reiterate it here. >=20 > The Section 8 guidance covers scenarios where the use of a given FEC conf= iguration can result in no benefits in performance (or even degradation in = performance). If a receiver detects FEC parameters that are inconsistent w= ith the nature of the source data or the transmission conditions, then the = receiver could reject the offer (as per Sec. 6 of RFC 3264, "An offered str= eam MAY be rejected in the answer, for any reason"). However, additional g= uidance could improve the current text. >=20 > "Given that FLEX FEC enables the protection of multiple source streams, t= here exists the possibility that multiple source buffers may be created tha= t may not be used. An attacker could leverage unused source buffers to as = a means of occupying memory in a FLEX FEC endpoint. ***In addition, an att= ack against the FEC parameters themselves (e.g. repair window, D or L value= s) can result in a receiver having to allocate source buffer space that may= also lead to excessive consumption of resources.*** Moreover the applicat= ion source data may not be perfectly matched with FLEX FEC source partition= ing. If this is the case, there is a possibility for unprotected source da= ta if, for instance, the FLEX FEC implementation discards data that does no= t fit perfectly into its source processing requirements. "=20 That's an improvement, thanks. I don't think it covers my penultimate para= graph about a network attacker being able to force bit flips in the recover= ed packet length field, though, and I do think it's worth documenting that = as a risk (when integrity protection is not used). >=20 > -----Original Message----- > From: payload On Behalf Of Magnus=20 > Westerlund > Sent: Thursday, February 21, 2019 7:09 AM > To: Benjamin Kaduk ; The IESG > Cc: roni.even@mail01.huawei.com; payload-chairs@ietf.org;=20 > payload@ietf.org; draft-ietf-payload-flexible-fec-scheme@ietf.org > Subject: Re: [payload] Benjamin Kaduk's Discuss on=20 > draft-ietf-payload-flexible-fec-scheme-17: (with DISCUSS and COMMENT) >=20 > ---------------------------------------------------------------------- > --- > CAUTION: This email originated from outside of the organization. > ---------------------------------------------------------------------- > --- >=20 > Hi Benjamin, >=20 > I am not one of the authors, but one that have helped beating on this doc= ument in the WG, so I think I can answer your questions. I think the author= s should check what I say and check the last part of the comments. >=20 > On 2019-02-18 22:53, Benjamin Kaduk wrote: > > Benjamin Kaduk has entered the following ballot position for > > draft-ietf-payload-flexible-fec-scheme-17: Discuss > > > > When responding, please keep the subject line intact and reply to=20 > > all email addresses included in the To and CC lines. (Feel free to=20 > > 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-payload-flexible-fec-sch > > em > > e/ > > > > > > > > -------------------------------------------------------------------- > > -- > > DISCUSS: > > -------------------------------------------------------------------- > > -- > > > > I'm confused about some parts of how I'd implement this. > > It's quite possible this is just my error, but I'm including this=20 > > point in the Discuss section in case it's not. This basically=20 > > relates to how multiple recovery packets from a given FEC block get=20 > > encoded and identified on the wire, but also how to populate the=20 > > source block when multiple SSRCs are included. > > > > In short: suppose that I have D=3D3 and L=3D2. I should expect 5 repai= r=20 > > packets for the six source packets in a block; the scheme for=20 > > determining what order to generate them in and what their contents=20 > > are is fairly clear to me. But how do I identify them on the wire? =20 > > I'm assuming that the D and L on the wire are fixed values, since=20 > > there's the possibility to only send zero on the wire and negotiate=20 > > their values out of band. It's a little less clear whether the "SN bas= e" > > fields are expected to be the same for all 5 recovery packets based=20 > > on a given block, but if they do change then I'm not sure how I tell=20 > > whether a given recovery packet is for a row or a column. Is this=20 > > supposed to be using the sequence number from the outer RTP header=20 > > for packet ordering, and the implicit order for row/column FEC packets? > > (It seems that in case of very bad packet loss and dynamic > > L+D, the receiver could then get out of sync as to what the sequence=20 > > L+number > > is that corresponds to the start of a new batch of recovery blocks.) >=20 > So, if one are going to do a 2-D FEC code and have indicated that in the = signaling, each repair packet is still either a row or column FEC. So a Row= packet for your D=3D3 and L=3D2 2-D FEC configurations are going to say: >=20 > Sn base=3D i, L=3D2 D=3D1 >=20 > The rest of the Row packets for this block are going to have: >=20 > Sn base=3Di+2, L=3D2 D=3D1 >=20 > Sn base=3D i+4, L=3D2 D=3D1 >=20 > Then the column packets >=20 > Sn base=3Di, L=3D2 D=3D3 >=20 > Sn base=3Di+1, L=3D2 D=3D3 >=20 > >From a receiver perspective you are not actually not caring about=20 > >what > block structures the sender uses. You anyway only can store received FEC = packet in a receiver buffer for the stipulated time. When a repair packet c= omes in one checks if that repairs any loss, otherwise stores it in the buf= fer. >=20 Okay. So some key takeaways here are that the 'L' and 'D' values will be d= ifferent on the wire for row and column packets even on the same recovery s= tream. I would strongly suggest adding some text at the end of or after th= e first pargaraph of section 4.2.2.2, to the effect of: The values of L and D for a given block of recovery data will correspond = to the type of recovery in use for that block of data. In particular, for 2= -D repair, the (L,D) values will not be constant across all packets for a given SSRC being repaired. Similarly, the L and D values can differ acro= ss different blocks of repair data (repairing different SSRCs) in a single packet. I'd also recommend tweaking the text on page 23 about "[no] column FEC will= follow"; perhaps "If L>0, D=3D0, indicates that Row FEC is in use, with no= column FEC in use for this SSRC", "If L>0, D=3D1, indicates that this pack= et is Row FEC but that column FEC packets are interspersed in ths stream", = and "If L>0, D>0, indicates that this packet is column FEC of every L packe= ts in a group of D packets starting at the SN base. Whether or not Row FEC= packets will be interspersed cannot be determined from just this packet". For the L>0, D=3D1 case, I'd also suggest OLD: Hence, FEC =3D SN, SN+1, SN+2, ... , SN+(L-1), SN+L will be produced for each row. Then FEC =3D SN, SN+L, SN+2L, ..., SN+(D-1)L will be produced for each column. After all row FEC's have been sent, then the column FEC's will be sent. NEW: Hence, FEC =3D SN, SN+1, SN+2, ... , SN+(L-1), SN+L will be produced for each row. Then FEC =3D SN, SN+L, SN+2L, ..., SN+(D-1)L will be produced for each column. Note that the initial SN will be different for all pairs of packets other than the first row/first column packets! After all row FEC's have been sent, then the column FEC's will be sent, though reordering could cause the FECs to appear in a different order at the receiver. But the above are all just suggestions and I do not insist on any specific = change. I do, however, remain concerned about the case where L=3D0,D=3D0 on the wir= e and the optional payload format parameters are used to indicate L and D. In that case, it seems impossible to do 2-D FEC, since there is no way to i= ndicate whether a given L=3D0,D=3D0 packet is row or column repair. I thin= k that pure 1-D column and pure 1-D row are individually unambiguous, thoug= h. Perhaps Section 6.3.1 should disclaim the possibility of 2-D repair for thi= s case? > > I also don't see how, for the case when there are multiple SSRCs, I=20 > > know how many source packets to include from each SSRC in order to=20 > > make up the D x L source block -- since Section 6.2's discussion=20 > > lumps all the "source packets" together into a single set that get=20 > > mutually xor'd, that seems to imply that the encoding is not "do=20 > > recovery for SSRC1, do recovery for SSRC2, ..., concatenate them all". >=20 > Well, for each SSRC one follows the SN base and L and D parameters. This = results in a number of packets that the XOR is performed over. I think I overlooked the text "If there are multiple SSRC's protected by th= e FEC packet, then there will be multiple blocks of data containing an SN b= ase along with L and D fields" on my first read. Or perhaps I also had for= gotten that the SSRCs being recovered are indicated as CSRCs in the recover= y packet's header. Regardless, I am still not 100% clear on the layout of the repair payload f= or the multi-SSRC case. E.g., in Figure 13, we see that there are multiple= SN base/L/D entries before the payload, which is a single consolidated pay= load that (presumably) covers all the recovery SSRCs. Your description above makes it sound like each SN base/L/D indicates a set= of packets, and the payload is the XOR of all of those sets together (padd= ed if necessary). That is, one could perhaps imagine conceptually doing th= is in two steps: (1) XOR together the packets indicated by the respective S= N base/L/D for each SSRC, and then (2) XOR those results together to combin= e the N SSRC recovery blocks into a single repair payload. Did I get it ri= ght this time? > Does this help? Yes, thank you! Now I am at a point where I can actually ask useful questi= ons instead of just flailing around :) -Benjamin From nobody Tue Mar 5 04:26:20 2019 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BB9A129619 for ; Tue, 5 Mar 2019 04:26:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g-OWp6c8F9eA for ; Tue, 5 Mar 2019 04:26:16 -0800 (PST) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 612FD12941A for ; Tue, 5 Mar 2019 04:26:16 -0800 (PST) Received: from LHREML711-CAH.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 4FFF54CE98378FA7E3A5 for ; Tue, 5 Mar 2019 12:26:13 +0000 (GMT) Received: from lhreml709-chm.china.huawei.com (10.201.108.58) by LHREML711-CAH.china.huawei.com (10.201.108.34) with Microsoft SMTP Server (TLS) id 14.3.408.0; Tue, 5 Mar 2019 12:26:13 +0000 Received: from lhreml709-chm.china.huawei.com (10.201.108.58) by lhreml709-chm.china.huawei.com (10.201.108.58) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1591.10; Tue, 5 Mar 2019 12:26:12 +0000 Received: from DGGEMM422-HUB.china.huawei.com (10.1.198.39) by lhreml709-chm.china.huawei.com (10.201.108.58) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P256) id 15.1.1591.10 via Frontend Transport; Tue, 5 Mar 2019 12:26:12 +0000 Received: from DGGEMM526-MBX.china.huawei.com ([169.254.8.222]) by dggemm422-hub.china.huawei.com ([10.1.198.39]) with mapi id 14.03.0415.000; Tue, 5 Mar 2019 20:26:05 +0800 From: "Roni Even (A)" To: "payload@ietf.org" , James Sandford Thread-Topic: new call for adoping RTP Payload for TTML Timed Text as payload WG milestone Thread-Index: AdTMCqH7o6TA4Al/R8yoxaOdd889mAHQ3X5w Date: Tue, 5 Mar 2019 12:26:04 +0000 Message-ID: <6E58094ECC8D8344914996DAD28F1CCD18CB900F@dggemm526-mbx.china.huawei.com> References: <6E58094ECC8D8344914996DAD28F1CCD18CB2856@dggemm526-mbx.china.huawei.com> In-Reply-To: <6E58094ECC8D8344914996DAD28F1CCD18CB2856@dggemm526-mbx.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.200.202.69] Content-Type: multipart/alternative; boundary="_000_6E58094ECC8D8344914996DAD28F1CCD18CB900Fdggemm526mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [payload] new call for adoping RTP Payload for TTML Timed Text as payload WG milestone X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2019 12:26:19 -0000 --_000_6E58094ECC8D8344914996DAD28F1CCD18CB900Fdggemm526mbxchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Based on the feedback from Nigel we can go ahead with the RTP payload for T= TML Timed Text. James, please go ahead and submit draft-sandford-payload-rtp-ttml-03 as dra= ft-ietf-payload-rtp-ttml-00 Roni Even Payload WG co-chair From: payload [mailto:payload-bounces@ietf.org] On Behalf Of Roni Even (A) Sent: Sunday, February 24, 2019 8:36 AM To: payload@ietf.org Subject: new call for adoping RTP Payload for TTML Timed Text as payload WG= milestone Hi, After discussion with W3C TTWG members This is a second call to adopt RTP Payload for TTML Timed Text as a Payloa= d WG milestone and have https://tools.ietf.org/id/draft-sandford-payload-rt= p-ttml-03.txt as the initial document. The maturity level will be standard track and not Informational as currentl= y stated. This is an RTP payload and as such is in the charter of the WG. Please let the chairs know if you are OK with this work. Please respond by March 4th . This will allow submission before IETF104 sub= mission cut-off date which is March 11 Roni Even Payload WG co-chair --_000_6E58094ECC8D8344914996DAD28F1CCD18CB900Fdggemm526mbxchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi, =

Based on the feedback = from Nigel we can go ahead with the RTP payload for TTML Timed Text.

 

James, please go ahead and submit draft-sandford-payload-rtp-ttml-03 as draft-ietf-payload-rtp-ttml-=
00
Roni Even 
Payload WG co-chair

 


 


 


 






From: payload =
[mailto:payload-bounces@ietf.org]
On Behalf Of Roni Even (A)

Sent: Sunday, February 24, 2019 8:36 AM

To: payload@ietf.org

Subject: new call for adoping RTP Payload for TTML Timed Text as pay=
load WG milestone







 


 


 


Hi,


After discussion with W3C TTWG members

 


This is a second call to adopt  RTP Payload for TTML Timed Text as a Payload WG milestone and =
have
https://tools.ietf.org/id/draft-sandford-payload-rtp-ttml-03.txt as t=
he initial document.


 =



The maturity level will =
be standard track and not Informational as currently stated.


 =



This is an RTP payload a=
nd as such is in the charter of the WG.


 =



Please let the chairs kn=
ow if you are OK with this work.


 =



Please respond by March =
4th . This will allow submission before IETF104 submission cut-o=
ff date which is March 11


 =



 =



Roni Even Payload WG co-=
chair


 
--_000_6E58094ECC8D8344914996DAD28F1CCD18CB900Fdggemm526mbxchi_-- From nobody Tue Mar 5 05:34:01 2019 Return-Path: X-Original-To: payload@ietf.org Delivered-To: payload@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 05EB513112D; Tue, 5 Mar 2019 05:34:00 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: payload@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.92.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: payload@ietf.org Message-ID: <155179283997.24517.8296581545846927532@ietfa.amsl.com> Date: Tue, 05 Mar 2019 05:34:00 -0800 Archived-At: Subject: [payload] I-D Action: draft-ietf-payload-rtp-ttml-00.txt X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.29 List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2019 13:34:00 -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 Payloads WG of the IETF. Title : RTP Payload for TTML Timed Text Author : James Sandford Filename : draft-ietf-payload-rtp-ttml-00.txt Pages : 15 Date : 2019-03-05 Abstract: This memo describes a Real-time Transport Protocol (RTP) payload format for TTML, an XML based timed text format for live and file based workflows from W3C. This payload format is specifically targeted at live workflows using TTML. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-payload-rtp-ttml/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-payload-rtp-ttml-00 https://datatracker.ietf.org/doc/html/draft-ietf-payload-rtp-ttml-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Mar 5 06:11:32 2019 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C54AE131268 for ; Tue, 5 Mar 2019 06:11:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com header.b=U1ya/LBx; dkim=pass (1024-bit key) header.d=ericsson.com header.b=eL4dA85A 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 9yAtLk_uRlFU for ; Tue, 5 Mar 2019 06:11:28 -0800 (PST) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (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 A31CF131189 for ; Tue, 5 Mar 2019 06:11:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/relaxed; q=dns/txt; i=@ericsson.com; t=1551795085; x=1554387085; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=aU1lbL+5J+1bqA5B9G8/wjFlqG0umK/zZBVWu8WSe50=; b=U1ya/LBxkbyyFaAobzrpQrGWep7jFAWaereeheqJA4CunVbH3YIrw9qHDeQ42aV9 SCREGL/bMOAiV2h8448hksv8bFsu7b8hKzkqDPtyjo5in87kQRxldG9a9VriAPCW oCxsJUdWA0+2jBsmrY/0kqh+w9YAv6CYzN61bJ46xE8=; X-AuditID: c1b4fb3a-167ff7000000672c-a6-5c7e838dffce Received: from ESESSMB505.ericsson.se (Unknown_Domain [153.88.183.123]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 43.5C.26412.D838E7C5; Tue, 5 Mar 2019 15:11:25 +0100 (CET) Received: from ESESSMR502.ericsson.se (153.88.183.110) by ESESSMB505.ericsson.se (153.88.183.123) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Tue, 5 Mar 2019 15:11:25 +0100 Received: from ESESBMB505.ericsson.se (153.88.183.172) by ESESSMR502.ericsson.se (153.88.183.110) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Tue, 5 Mar 2019 15:11:25 +0100 Received: from EUR03-AM5-obe.outbound.protection.outlook.com (153.88.183.157) by ESESBMB505.ericsson.se (153.88.183.172) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3 via Frontend Transport; Tue, 5 Mar 2019 15:11:24 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=aU1lbL+5J+1bqA5B9G8/wjFlqG0umK/zZBVWu8WSe50=; b=eL4dA85AmYj07UHD9eWI+kxMp/g0k+Rc23r5uXYYcy6/ND8l+RHepdTs32qJP8YLi6menpXIGVuBgikLc8t31kHObepn9nuI3Xep662nN2lvsly7cRJwqQ9eUNm+Xga5o3P7ur8C8mzOAI0TadjZVSkxzUuj7t48UTMBcNVTQpI= Received: from HE1PR0701MB2522.eurprd07.prod.outlook.com (10.168.128.149) by HE1PR0701MB2633.eurprd07.prod.outlook.com (10.168.185.143) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1686.5; Tue, 5 Mar 2019 14:11:23 +0000 Received: from HE1PR0701MB2522.eurprd07.prod.outlook.com ([fe80::4cb:751a:9e20:ca78]) by HE1PR0701MB2522.eurprd07.prod.outlook.com ([fe80::4cb:751a:9e20:ca78%3]) with mapi id 15.20.1686.016; Tue, 5 Mar 2019 14:11:23 +0000 From: Magnus Westerlund To: Giridhar Mandyam , Benjamin Kaduk CC: The IESG , "roni.even@mail01.huawei.com" , "payload-chairs@ietf.org" , "payload@ietf.org" , "draft-ietf-payload-flexible-fec-scheme@ietf.org" Thread-Topic: [payload] Benjamin Kaduk's Discuss on draft-ietf-payload-flexible-fec-scheme-17: (with DISCUSS and COMMENT) Thread-Index: AQHUx9RrE+qo8a/ki06DNNe3BRLJCQ== Date: Tue, 5 Mar 2019 14:11:23 +0000 Message-ID: References: <155052681367.25946.18116200153523550938.idtracker@ietfa.amsl.com> <0ef384ddaabd4883b77db08a477ab822@NASANEXM01C.na.qualcomm.com> <20190227002556.GE53396@kduck.mit.edu> <55e0b103a8824dd4a770678b974628ce@NASANEXM01C.na.qualcomm.com> Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=magnus.westerlund@ericsson.com; x-originating-ip: [192.176.1.91] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 862d859a-0595-4589-f791-08d6a17472bd x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(2017052603328)(7153060)(7193020); SRVR:HE1PR0701MB2633; x-ms-traffictypediagnostic: HE1PR0701MB2633: x-ms-exchange-purlcount: 1 x-microsoft-exchange-diagnostics: =?us-ascii?Q?1; HE1PR0701MB2633; 23:VQnZrmNWU7GfK1SNd4mI739pg50hQUg6Ch4Z23u?= =?us-ascii?Q?LxU5s0VMWCqyxKfJQmh6Y6S0d7r/+DEfBEZuZVHNGuyebftEMnIQJ1JcYmr+?= =?us-ascii?Q?SNwyK1TWSt816vON0RH4gkwic+amNFTIiChK16PoSbF639occZ7PTdsRDYHO?= =?us-ascii?Q?/p8LY3Eojtfcp4LV92WyRjQNEnnrhkSZeD1FV7Z8nLvYDMAvXnMXjlNWH3rI?= =?us-ascii?Q?Mykg/JAqCa+DDkmt3mzNOIexJclWmMJegfhdvmuijNJWFVEt21TbRmv4QI28?= =?us-ascii?Q?QG63KqBjtHYRNyf7vCUc0moOGI01GYnBmUyBL5xYlTXaBtrGrM8oCMrdBOFM?= =?us-ascii?Q?fsZrs3fVZh+4uk9Mqj93Y9I/U/8yXoqWz7woyHyvjf4hkQOER6jvgANEqAGB?= =?us-ascii?Q?Gop1wxRDWxeOpOFOH4r2Cgf0vDKvAT2VKjagLo7bDVCGZRW6FYm8i2NzjMhE?= =?us-ascii?Q?OHHmvzv+M5yAR60z4CniXc2s3K6DhG8MEn+cYRRIvz9BOhYbenXprflTrqGf?= =?us-ascii?Q?3qD+0CJZ65x4904W0ZUKV7ZonWWCiuWWnr7zC9cRpPX0CViNItu8c2c7gNRi?= =?us-ascii?Q?2/sqG5SKPvgfLk0Cc+32Hj1QTRsVDyDPPBtISzVp7kubBJTDZPDDYHkAfzMm?= =?us-ascii?Q?Mk/lDBQfYmEC/KDu2z6sQwVZ5BTiHW27cOzYiXBnIjqnW/yxLJ32wCLlIJ5E?= =?us-ascii?Q?VoefI33P4FmAxOK25DdVRZRaV/TSXiTNcXIupfBI2CzJ5xwqlL8TqyxOTEtX?= =?us-ascii?Q?ATtrDMo76otAOwWfbSlV3jKh7W38OGQ8JexbxCfbME0b4AoVKTj7TzOI31MZ?= =?us-ascii?Q?JQXi3uCu1eaf3X79mdHiU+gcgB0aFEn7a98K+ocJQXlPzPXOIoqMj1WkhQ4r?= =?us-ascii?Q?OFoNpJUVx4Duk6eZR69dmNQ7bUeE+uBDAUtu4NEZXmfI2YzthGZWfMq1NlX2?= =?us-ascii?Q?XjEDAp3R6LaQBkx7rhJDstOXAO8rjUrIrpWexAlZ0BEYbRG/gOGh4KKwkb+X?= =?us-ascii?Q?Vec4ioAOKt2aMioYiPIiC3q3uOt6fLiOAQHf1inMS1Bt/9eLss1qvyi359eH?= =?us-ascii?Q?w2zb+Q4+aURuwoYIMT46mZ18HRlo0Ju9fKCfdF+IQ8Wtl+/+iWE02DLOj/pU?= =?us-ascii?Q?/jFnYHxbn0WUGp26T9cjTYRMgOxokfg8HdQcvPM5QYkvFEKC+TDsyCPoAdoF?= =?us-ascii?Q?kfgTiUT7eIAX7OXh00ms0Xg37V6PGUo55BmJFQNBCdKeKQX17jtjhLZYIsWT?= =?us-ascii?Q?ZZvBeXZSy9aUoKCXanTGuufPIiQEnY8FiZQZ/f4mt5WLl8nWT1WYVGSTpPHn?= =?us-ascii?Q?LcTIX+MwTKdnwQ3twQzSDMpzohJvqB5xI4r/VXehkI+UjeqHklTUtqOIwpBA?= =?us-ascii?Q?Rjhz4zA=3D=3D?= x-microsoft-antispam-prvs: x-forefront-prvs: 0967749BC1 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(136003)(396003)(366004)(346002)(39860400002)(376002)(199004)(189003)(6116002)(5660300002)(81156014)(486006)(110136005)(446003)(316002)(66066001)(52536013)(86362001)(186003)(606006)(14454004)(26005)(256004)(53546011)(478600001)(54906003)(93886005)(76176011)(6506007)(99286004)(71200400001)(71190400001)(53936002)(81166006)(74316002)(7696005)(8676002)(102836004)(14444005)(44832011)(8936002)(6306002)(68736007)(55016002)(105586002)(4326008)(25786009)(6436002)(106356001)(7736002)(476003)(966005)(3846002)(9686003)(229853002)(54896002)(2906002)(97736004)(6246003)(2171002)(33656002)(236005); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR0701MB2633; H:HE1PR0701MB2522.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: ZxIWZCXwbBRXsqfWxw1J5X+Sjso0EPfRu2LBCRef7PTYqUWPLvyLKdXXOYpm/Do86r2BD40F+4QX3mUYa4TXNkLeT0aRqxMLWXh+ZnqEwkjjAb+R32UXGdjShzgMkNDSWMCImHlU4syEku6V848/+BQUTuWhGZChMAepSCwCRJYyYzJecCFcTwl+s0emGdVoEpMaGt/O8n+xFI5kxtkeM/T2W7Uqkn9R6NifEXFRK44KAkBIJHqFVqlzdLEvAbsC5xBBWIFpYDzXfio33HU+JjQkbRMYafg8Y96dKlHc1c1aV4KrJCbB1rjS//0RYVAA33/gv8qnDCBEAfU85OtOvAWHneSE1taSGD/S2ryDdx/EOqzQNI1LL/1sXdzJTl6dOwH2YOt0F7LG3qNqDpJbvqgUs2fAi9P4jRYb/v9XPLM= Content-Type: multipart/alternative; boundary="_000_HE1PR0701MB25221DF39C52C8C66A01F66A95720HE1PR0701MB2522_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 862d859a-0595-4589-f791-08d6a17472bd X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Mar 2019 14:11:23.1243 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB2633 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA02Se0hTURzHOffebVdxdp2KvzTJVhGajzSjW4RkEQ0i0CAzEXLm9ZE6bdfE B5mmmA+CWVQ6CqctRaUyMxUT8jGx1OGrQBN8TdMQNcvSSqNtR8H/Pr/f93PO7/zg0KREL3Ck YxRJnFIhj5MKLamS4MZ0j7vZGaGH8jtc2I1RJVu8XkSyla9KCHZpbQSxTRNrInZwQE+w0zlr 5EmRTKv9TciaXk8IZLd7O0lZ+YMvKIAKsTwRwcXFJHNKL78wy+iyxfTEce+UmkatKBOVuhYg CxoYXxh6skwWIEtawugQTI71i0yBhPmJYFpH48DI6/PFBC6eEjA+NE6ZCopRkaDJ1opw8oiA H92rFC4MCLQTpULTZUKGhZG1LDPbMYHwceO5wMQkU07ASN9pE9syaaDONZDYSYeOvE8CzJ7w rOehmSlmH9S/mzc7YiYMavMnNof1E1C1kGsegBhnGF8do/AAB/g8XUrgVRnQtvSRmO3hq+Gf APtyGM6a2XRcYLSyi8LsDIOlhQjzeVioqUOmYcCMImjontuU3GH55a9NyRHeD3QKsNRqDf33 ZkU4SICWN3nGA7SRd8HSigg7BULo0nwjVchDve2xmBOguvCPQG3e1AY+lExTuO8OmrffhZgP QkXZPLnFva0GYntfg0TVyJ7neD4+ysfHk1PGXOX5BIWngkuqQ8ZP1lb/93gTapv1b0cMjaRW 4v64jFCJQJ7Mp8a3I6BJqZ04/bqxJY6Qp6ZxyoQryhtxHN+OnGhK6iBel9iESpgoeRIXy3GJ nHIrJWgLx0zEX548JQnKHj5W1RUYFqVnL8Xut5+ivdoO7/a6MNUny66zswqq4nrSwm7OXpzx CdixmHhLFxi8cmBKoU6x8FZl7Hkc0tzpe+5F8/3BZH9V4diqW7STPrxSzu6Mqoi2XY88o7lD 6uqv+bUVHVmJDFC7DleenTPkpJQ1hGv3qo5a10opPlru7UYqefl/AWksjGADAAA= Archived-At: Subject: Re: [payload] Benjamin Kaduk's Discuss on draft-ietf-payload-flexible-fec-scheme-17: (with DISCUSS and COMMENT) X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2019 14:11:31 -0000 --_000_HE1PR0701MB25221DF39C52C8C66A01F66A95720HE1PR0701MB2522_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I like to add a bit of clarification to this first part that was unclear in= my opinion. On 2019-03-04 20:08, Giridhar Mandyam wrote: Thanks Benjamin. Apologies for the late reply, but we (the editors) were c= onfirming the best response to your follow-up questions. Maybe my question was not phrased well. IIUC, the repair packets can only = cover real media source streams that are part of the same RTP session. So in order for both audio and video to be available in the same RTP sessio= n as potential input to asingle repair packet stream, the audio and video w= ould need to be together in the same RTP session; presumably that would inv= olve getting demux'd based on payload type or SSRC, which is what I'm readi= ng 3550 as saying to not do. Am I just misunderstanding that the repair in= puts must be part of the same RTP session? They are demultiplexed on SSRC. And although RFC 3550 says not to mix media= types, that has actually been revised. There is an approved for publicatio= n I-D that changes this. This was a huge discussion a bit over 5-years in t= he context of WebRTC. This FEC mechanism is a result of the needs for WebRT= C and its environment. So they all fit together. The I-D is this one: https://datatracker.ietf.org/doc/draft-ietf-avtcore-multi-media-rtp-session= / The repair packets may be sent in the same RTP Session as the source RTP st= reams, the most likely configuration for WebRTC. But the repair RTP streams= may also be sent in a separate RTP session from the source RTP streams. Section 4.2.1 says: Synchronization Source (SSRC): The SSRC value for each repair stream SHALL be randomly assigned as per the guidelines provided in Section 8 of [RFC3550]. This allows the sender to multiplex the source and repair RTP streams in the same RTP session, or multiplex multiple repair streams in an RTP session. Cheers Magnus Westerlund ---------------------------------------------------------------------- Network Architecture & Protocols, Ericsson Research ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Torshamnsgatan 23 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- --_000_HE1PR0701MB25221DF39C52C8C66A01F66A95720HE1PR0701MB2522_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi,

I like to add a bit of clarification to this= first part that was unclear in my opinion.

On 2019-03-04 20:08, Giridhar Mandyam wrote:= 
Thanks Benjamin.  Apologies for the =
late reply, but we (the editors) were confirming the best response to your =
follow-up questions.=0A=
=0A=

Maybe my question was not phrased we=
ll.  IIUC, the repair packets can only cover real media source streams that=
 are part of the same RTP session.=0A=

So in order for both audio and video=
 to be available in the same RTP session as potential input to asingle repa=
ir packet stream, the audio and video would need to be together in the same=
 RTP session; presumably that would involve getting demux'd based on payloa=
d type or SSRC, which is what I'm reading 3550 as saying to not do.  Am I j=
ust misunderstanding that the repair inputs must be part of the same RTP se=
ssion?

They are demultiplexed on SSRC. And although RFC 3550 says not to mix me= dia types, that has actually been revised. There is an approved for publica= tion I-D that changes this. This was a huge discussion a bit over 5-years i= n the context of WebRTC. This FEC mechanism is a result of the needs for WebRTC and its environment. So they= all fit together. The I-D is this one:

https://datatracker.ietf.o= rg/doc/draft-ietf-avtcore-multi-media-rtp-session/

The repair packets may be sent in the same RTP Session as the source RTP= streams, the most likely configuration for WebRTC. But the repair RTP stre= ams may also be sent in a separate RTP session from the source RTP streams.

Section 4.2.1 says:

      Synchronization Source (SSRC): The SSRC value for each repair=0A=
      stream SHALL be randomly assigned as per the guidelines provided=0A=
      in Section 8 of [RFC3550].  This allows the sender to multiplex=0A=
      the source and repair RTP streams in the same RTP session, or=0A=
      multiplex multiple repair streams in an RTP session.=0A=
=0A=
Cheers
=0A=
Magnus Westerlund =0A=
=0A=
----------------------------------------------------------------------=0A=
Network Architecture & Protocols, Ericsson Research=0A=
----------------------------------------------------------------------=0A=
Ericsson AB                 | Phone  +46 10 7148287=0A=
Torshamnsgatan 23           | Mobile +46 73 0949079=0A=
SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.=
com=0A=
----------------------------------------------------------------------



--_000_HE1PR0701MB25221DF39C52C8C66A01F66A95720HE1PR0701MB2522_--


From nobody Tue Mar  5 09:09:04 2019
Return-Path: 
X-Original-To: payload@ietfa.amsl.com
Delivered-To: payload@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BDC113111C; Tue,  5 Mar 2019 09:08:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.699
X-Spam-Level: 
X-Spam-Status: No, score=0.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, GB_SUMOF=5, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=qti.qualcomm.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WwGOFQXUFi2p; Tue,  5 Mar 2019 09:08:53 -0800 (PST)
Received: from alexa-out-sd-01.qualcomm.com (alexa-out-sd-01.qualcomm.com [199.106.114.38]) (using TLSv1.2 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 02B34131268; Tue,  5 Mar 2019 09:08:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1551805726; x=1583341726; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=1aktScg616OdnHwwpvEdS+GNeepmj63ux3by0nrA3sc=; b=zWFDILcEOYA2ExNGcNDbdzBx8BjQyAIkDdub3iQX6yGJawfPI0JdWI+e gE6eSj6gQp7vaL5jZ86q0Jh1+S4TGV8SoDh153WcAQ4paFdFdnULmJ492 ErR3iy1DSYSWHYvyzZSXa6YSpS2ux4rsLnPYW00mVrwd+nso/X8xVbhAZ Y=;
X-IronPort-AV: E=Sophos;i="5.58,444,1544515200"; d="scan'208";a="31791973"
Received: from unknown (HELO ironmsg01-sd.qualcomm.com) ([10.53.140.141]) by alexa-out-sd-01.qualcomm.com with ESMTP; 05 Mar 2019 09:08:45 -0800
Received: from nasanexm01a.na.qualcomm.com ([10.85.0.81]) by ironmsg01-sd.qualcomm.com with ESMTP/TLS/AES256-SHA; 05 Mar 2019 09:08:44 -0800
Received: from NASANEXM01C.na.qualcomm.com (10.85.0.83) by nasanexm01a.na.qualcomm.com (10.85.0.81) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Tue, 5 Mar 2019 09:08:44 -0800
Received: from NASANEXM01C.na.qualcomm.com ([10.85.0.83]) by NASANEXM01C.na.qualcomm.com ([10.85.0.83]) with mapi id 15.00.1395.000; Tue, 5 Mar 2019 09:08:44 -0800
From: Giridhar Mandyam 
To: Benjamin Kaduk 
CC: Magnus Westerlund , The IESG , "roni.even@mail01.huawei.com" ,  "payload-chairs@ietf.org" , "payload@ietf.org" , "draft-ietf-payload-flexible-fec-scheme@ietf.org" 
Thread-Topic: [payload] Benjamin Kaduk's Discuss on draft-ietf-payload-flexible-fec-scheme-17: (with DISCUSS and COMMENT)
Thread-Index: AQHUx9RmiuNsr5OuwEy90ary5L7nTaXvcY8ggAPq6ICACGIkQIABnLDw
Date: Tue, 5 Mar 2019 17:08:43 +0000
Message-ID: 
References: <155052681367.25946.18116200153523550938.idtracker@ietfa.amsl.com>  <0ef384ddaabd4883b77db08a477ab822@NASANEXM01C.na.qualcomm.com> <20190227002556.GE53396@kduck.mit.edu> <55e0b103a8824dd4a770678b974628ce@NASANEXM01C.na.qualcomm.com>
In-Reply-To: <55e0b103a8824dd4a770678b974628ce@NASANEXM01C.na.qualcomm.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.80.80.8]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: 
Subject: Re: [payload] Benjamin Kaduk's Discuss on draft-ietf-payload-flexible-fec-scheme-17: (with DISCUSS and COMMENT)
X-BeenThere: payload@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Audio/Video Transport Payloads working group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 05 Mar 2019 17:08:55 -0000

Looks like my response got cut off.  Let me try again.

Thanks Benjamin.  Apologies for the late reply, but we (the editors) were c=
onfirming the best response to your follow-up questions.

> Maybe my question was not phrased well.  IIUC, the repair packets can onl=
y cover real media source streams that are part of the same RTP session.
So in order for both audio and video to be available in the same RTP sessio=
n as potential input to asingle repair packet stream, the audio and video w=
ould need to be together in the same RTP session; presumably that would inv=
olve getting demux'd based on payload type or SSRC, which is what I'm readi=
ng 3550 as saying to not do.  Am I just misunderstanding that the repair in=
puts must be part of the same RTP session?

In my interpretation, the issue revolves around what "demultiplexing" means=
 in this context.  I do not believe it was meant to contemplate the recover=
y of packets from a repair stream, which involves more than just "demultipl=
exing" of audio and video payloads.  I don't believe Sec. 5.2 of RFC 3550 r=
eally applies.

> >       Payload Type: The (dynamic) payload type for the FEC repair packe=
ts is determined through out-of-band means.  [...]
> >      Is "(e.g., SDP)" applicable here?

Sorry I missed this in my original response.  Yes, it does make sense and I=
 have added it.

>>> Any reason not to include "retransmit" and "fixed block" mnemonics for =
the 'R' and 'F' bits?=20
>> Can you explain further?  The R/F definitions already include mention of=
 retransmission and fixed FEC L/D.
> I was thinking that the first sentence could say '(R and F bits, for "ret=
ransmit" and "fixed block")' to (in effect) "name" the bits right away.

Proposed text:

4.2.2.  FEC Header of FEC Repair Packets

   The format of the FEC header has 3 variants, depending on the values
   in the first 2 bits (R and F bits) as shown in Figure 10.  Note that
   R and F stand for "retransmit" and "fixed block", respectively.

> >> Please include a note here that several fields (e.g., P, PT, etc.) =20
> >> in the FEC header are not meant to be interpreted directly but are=20
> >> instead actual FEC parity data akin to the following "payload".=20
> >> (Absent such an indication, the reader could see that these fields=20
> >> are "used to determine" values when they appear to contain values=20
> >> directly, and get confused.)
> > >I would suggest adding a forward-reference to Section 6 since that des=
cribes how the Repair Payload is calculated.
>> I am sorry.  I do not understand what is meant by "used to determine" va=
lues.  Can you explain?
>I was trying to consolidate remarks about 4.2.2, 4.2.2.1 and 4.2.2.2 into =
a single comment, but it came across badly; sorry for the confusion.  The l=
ast bullet point of Section 4.2.2 notes that "The P, X, CC, M and PT recove=
ry fields are used to determine the corresponding fields of the recovered p=
ackets". Similarly, Figures 12 and 13 both have fields named for "PT recove=
ry", "length recovery", etc., with corresponding descriptions in the main t=
ext like "the length recovery (16 bits) field is used to determine the leng=
th of the recovered packets" -- these are the "used to determine" text to w=
hich I refer.  So my concrete suggestion is to add a reference to Section 6=
.3.2 at the end of that final bullet in Section 4.2.2.  I'd consider adding=
 it to the field descriptions in 4.2.2.1 as well, but that might be overkil=
l, so use your judgement.

Forward reference is added.  Thanks.

> >> Should implementations set bounds on L and D that are smaller than the=
 maximum encodable value (255)?
> > Yes.  This is assumed.
>Perhaps it's best to state it explicitly rather than leaving an implicit a=
ssumption.

> >> If L=3D0, D=3D0, use the optional payload format parameters for L and =
D.  What is the behavior when those payload format parameters were not prov=
ided?
> >Optional payload format parameters may be provided in SDP (see Sec. 5.1)=
.
>Right.  But suppose they weren't, and yet the L=3D0,D=3D0 packet shows up =
on the wire.  This is clearly an error condition; what's the error handling=
?

Proposed text immediately following Fig. 14:

   Given the 8-bit limit on L and D (as depicted in Figure 13), the
   maximum value of either parameter is 255.  The "optional payload
   format parameters" (Figure 14) to be used when L=3D0 and D=3D0 can be
   determined through out-of-band signaling (see Section 5).  If L=3D0 and
   D=3D0 and cannot be determined through out-of-band signaling, then the
   repair packet MUST be ignored by the receiver.  In addition when L=3D1
   and D=3D0, the repair packet becomes a retransmission of a
   corresponding source packet.

> >> The L=3D1 case seems to imply that some full packet retransmission wil=
l be used; is it worth calling that out as a consequence of such a paramete=
r choice?
>> I am not sure that I understand this statement.  L=3D1 does not imply an=
ything about the value of D.
>I agree with your statement.  But, we seem to allow for L to be 1, and in =
particular for L=3D1,D=3D0 (also L=3D1,D=3D1).  For those combinations of L=
 and D, the "Row FEC" case will in fact be packet retransmission, as a dege=
nerate case.  I'm proposing that either this oddity is mentioned explicitly=
 (e.g., "note that when L=3D1, the Row FEC packets will just be retransmiss=
ion"), or disallowed by the numerical constraints.  Though now that I know =
better how the multi-SSRC case is handled (per Magnus's comments and my rep=
ly thereto), I guess you could use L=3D1 as part of a multi-SSRC repair and=
 it would not be equivalent to retransmission.  So the situation is more co=
mplicated than I first thought.
>Regardless, since the conditions here do allow L=3D1 as a possibility, I s=
uggest some additional discussion in the text about how it's a bit strange =
and probably not expected to be used.

As you mentioned above for bundled protection, individual L/D combinations =
can be declared for each SSRC (such as L=3D1,D=3D0) but the overall repair =
packet may in fact not be a retransmission of any individual packet.  An ex=
ample could be an audio/video session where very few audio packets (as few =
as one) are bundled with several video packets in the generation of the rep=
air packet.  In such a case, it might be perfectly valid to set L=3D1, D=3D=
0 for the audio packet.   So I am not sure about what is best approach to t=
he additional discussion.  Did you have a concrete suggestion?

>> > What is the interaction between rate, repair-window, and the L and D v=
alues?  That is, if we set L and D to be large, and rate to be small, can w=
e end up claiming a repair window that is too small to accumulate the neces=
sary L*D source packets and compute recovery packets?
>> Yes, it is possible.  We expect that specific uses of FLEX FEC will boun=
d the appropriate values for repair window, L and D.  It is difficult to es=
tablish these bounds in this specification, however, since the applications=
 that are currently making use of FLEX FEC are varied (e.g. WebRTC, 3GPP MT=
SI).  We expect these specification to provide concrete guidance on the exp=
ected repair windows, L and D, based on the target application.
>Please do not rely on unstated expectations for the behavior of consumers =
of this mechanism!  I strongly suggest to provide some indication, even a v=
ague and incomplete one, that there are to be interrelations and implementa=
tion restrictions on these parameters.

Proposed additional section:


1.1.7.  Repair Window Considerations

   The value for the repair window duration depends on the L and D
   values and cannot be chosen arbitrarily.  More specifically, L and D
   values determine the lower limit for the repair window duration.  The
   upper limit of the repair window duration does not depend on the L
   and D values.

Note that a discussion of rate is difficult (in my opinion) without making =
assumptions about the source SSRC's.  For the above section, however, I can=
 add a sentence such as "The rate of the source streams should also be cons=
idered, as the repair window duration should ideally span several packetiza=
tion intervals in order to leverage the error correction capabilities of th=
e parity code." =20

>> > Section 5.2.1
>>>    o  The value for the repair-window parameter depends on the L and D =
values and cannot be chosen arbitrarily.  More specifically, L and D values=
 determine the lower limit for the repair-window size. The upper limit of t=
he repair-window size does not depend on the L and D values.
>>>Per my above remark, this consideration seems generally applicable and n=
ot limited to SDP Offer/Answer.
>> This is also covered in Sec. 1.1, which provides the general guidance.
>An inline note that the repair window "is defined as the time that spans a=
 FEC block", I see now.  But this is still in fairly abstract terms; I woul=
d have expected to see the note I quoted in my ballot to appear in a top-le=
vel Section 5 entry, and not in the subsection specific to SDP O/A.

>>>    o  Any unknown option in the offer MUST be ignored and deleted from =
the answer.  If FEC is not desired by the receiver, it can be deleted from =
the answer.
>>> This sounds like it is restating an existing normative requirement  (in=
 which case a reference and descriptive, non-normative, text seems appropri=
ate).
>> This requirement is specific to SDP O/A. Can you explain further as to w=
hy you think there is a different normative requirement?
>Ali got what I intended, though I was hoping for a reference to the releva=
nt SDP RFC as well as the s/MUST/must/.

Proposed modifications:

   o  The value for the repair-window parameter depends on the L and D
      values.  Based on the values of L and D, a lower bound on the
      repair-window can be inferred (see Section 1.1.7).

   o  Although combinations with the same L and D values but with
      different repair-window sizes produce the same FEC data, such
      combinations are still considered different offers.  The size of
      the repair-window is related to the maximum delay between the
      transmission of a source packet and the associated repair packet.
      This directly impacts the buffering requirement on the receiver
      side and the receiver must consider this when choosing an offer.

   o  Any unknown option in the offer must be ignored and deleted from
      the answer (see Section 6 of [RFC3264]).  If FEC is not desired by
      the receiver, it can be deleted from the answer.

Sec. 6.2:
> To be clear, this is an editorial matter and you are free to ignore me, b=
ut my suggested wording is "The first 16 bits of the RTP header (16 bits), =
though the first two (version) bits will be ignored by the recovery procedu=
re".

Proposed text is added.

> s/compute the FEC bit string from/extract the FEC bit string as/

Proposed text is added.

>>> I don't see how this matches up with the bit string construction in  Se=
ction 6.2.
>> As per Sec. 6.2,  "The rest of the FEC bit string, which contains everyt=
hing after ...
>In particular I'm confused about the order between length recovery and TS =
recovery.  In the FEC header (for non-retransmissions), length recovery app=
ears before TS recovery.  In Section 6.2, as we extract things from the FEC=
 bit string, we write out the length recovery value into the FEC header, an=
d then (the next bits from the FEC bit string are) the TS recovery value.
>But here we take the TS field and then the length field from the recovery =
bit string, which is in the other order.  Am I missing some step that cause=
s the order that these fields appear in the bit stream to change?

Agreed.  The proposed change that seems to fix this  in Sec. 6.3.2 is:

   11.  Set the SN field in the new packet to SEQNUM.

   12.  Take the next 16 bits of the recovered bit string and set the
        new variable Y to whatever unsigned integer this represents
        (assuming network order).  Convert Y to host order.  Y
        represents the length of the new packet in bytes minus 12 (for
        the fixed RTP header), i.e., the sum of the lengths of all the
        following if present: the CSRC list, header extension, RTP
        payload and RTP padding.

   13.  Set the TS field in the new packet to the next 32 bits in the
        recovered bit string.

   14.  Set the SSRC of the new packet to the SSRC of the missing source
        RTP stream.

>> "Given that FLEX FEC enables the protection of multiple source streams, =
there exists the possibility that multiple source buffers may be created th=
at may not be used.  An attacker could leverage unused source buffers to as=
 a means of occupying memory in a FLEX FEC endpoint.  ***In addition, an at=
tack against the FEC parameters themselves (e.g. repair window, D or L valu=
es) can result in a receiver having to allocate source buffer space that ma=
y also lead to excessive consumption of resources.***  Moreover the applica=
tion source data may not be perfectly matched with FLEX FEC source partitio=
ning.  If this is the case, there is a possibility for unprotected source d=
ata if, for instance, the FLEX FEC implementation discards data that does n=
ot fit perfectly into its source processing requirements. "=20

>That's an improvement, thanks.  I don't think it covers my penultimate par=
agraph about a network attacker being able to force bit flips in the recove=
red packet length field, though, and I do think it's worth documenting that=
 as a risk (when integrity protection is not used).

  Given that FLEX FEC enables the protection of multiple source
   streams, there exists the possibility that multiple source buffers
   may be created that may not be used.  An attacker could leverage
   unused source buffers to as a means of occupying memory in a FLEX FEC
   endpoint.  In addition, an attack against the FEC parameters
   themselves (e.g. repair window, D or L values) can result in a
   receiver having to allocate source buffer space that may also lead to
   excessive consumption of resources.  ***Similarly, a network attacker
   could modify the recovery fields corresponding to packet lengths
   (assuming there are no message integrity mechanisms) which in turn
   could force unnecessarily large memory allocations at the receiver.***
   Moreover the application source data may not be perfectly matched
   with FLEX FEC source partitioning.  If this is the case, there is a
   possibility for unprotected source data if, for instance, the FLEX
   FEC implementation discards data that does not fit perfectly into its
   source processing requirements.

>I would strongly suggest adding some text at the end of or after the first=
 pargaraph of section 4.2.2.2, to the effect of:

>  The values of L and D for a given block of recovery data will=20
> correspond to
  the type of recovery in use for that block of data.  In particular, for 2=
-D
  repair, the (L,D) values will not be constant across all packets for a
  given SSRC being repaired.  Similarly, the L and D values can differ acro=
ss
  different blocks of repair data (repairing different SSRCs) in a single
  packet.

Proposed text has been added.  Thanks.

>Regardless, I am still not 100% clear on the layout of the repair payload =
for the multi-SSRC case.  E.g., in Figure 13, we see that there are multipl=
e SN base/L/D entries before the payload, which is a single consolidated pa=
yload that (presumably) covers all the recovery SSRCs.
Your description above makes it sound like each SN base/L/D indicates a set=
 of packets, and the payload is the XOR of all of those sets together (padd=
ed if necessary).  That is, one could perhaps imagine conceptually doing th=
is in two steps: (1) XOR together the packets indicated by the respective S=
N base/L/D for each SSRC, and then (2) XOR those results together to combin=
e the N SSRC recovery blocks into a single repair payload.  Did I get it ri=
ght this time?

You can do it as you have described.  It is not strictly required to do it =
that way.  The source packets could be arranged in such a way that the XOR =
operation can be performed in one step, rather than the two you describe.  =
Any method is fine as long as the desired parity is created - row-wise, col=
umn-wise, or flex mask.

Note that we have also modified sec. 4.2.1 as follows to better describe th=
e repair RTP header:

CSRC Count (CC) 4 bits, and CSRC List (CSRC_i) 32 bits each:
Source packets can have an optional CSRC list and count, which can
be recovered. FEC repair packets MUST use the CSRC list and count
to specify the SSRC(s) of the source RTP stream(s) protected by
this FEC repair packet.



From nobody Tue Mar  5 09:19:03 2019
Return-Path: 
X-Original-To: payload@ietf.org
Delivered-To: payload@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FA841312DE; Tue,  5 Mar 2019 09:19:02 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: 
Cc: payload@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.92.1
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: payload@ietf.org
Message-ID: <155180634247.24571.9901113243096289600@ietfa.amsl.com>
Date: Tue, 05 Mar 2019 09:19:02 -0800
Archived-At: 
Subject: [payload] I-D Action: draft-ietf-payload-flexible-fec-scheme-18.txt
X-BeenThere: payload@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Audio/Video Transport Payloads working group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 05 Mar 2019 17:19:03 -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 Payloads WG of the IETF.

        Title           : RTP Payload Format for Flexible Forward Error Correction (FEC)
        Authors         : Mo Zanaty
                          Varun Singh
                          Ali Begen
                          Giridhar Mandyam
	Filename        : draft-ietf-payload-flexible-fec-scheme-18.txt
	Pages           : 44
	Date            : 2019-03-05

Abstract:
   This document defines new RTP payload formats for the Forward Error
   Correction (FEC) packets that are generated by the non-interleaved
   and interleaved parity codes from source media encapsulated in RTP.
   These parity codes are systematic codes, where a number of FEC repair
   packets are generated from a set of source packets from one or more
   source RTP streams.  These FEC repair packets are sent in a
   redundancy RTP stream separate from the source RTP stream(s) that
   carries the source packets.  RTP source packets that were lost in
   transmission can be reconstructed using the source and repair packets
   that were received.  The non-interleaved and interleaved parity codes
   which are defined in this specification offer a good protection
   against random and bursty packet losses, respectively, at a cost of
   complexity.  The RTP payload formats that are defined in this
   document address scalability issues experienced with the earlier
   specifications, and offer several improvements.  Due to these
   changes, the new payload formats are not backward compatible with
   earlier specifications, but endpoints that do not implement this
   specification can still work by simply ignoring the FEC repair
   packets.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-payload-flexible-fec-scheme/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-payload-flexible-fec-scheme-18
https://datatracker.ietf.org/doc/html/draft-ietf-payload-flexible-fec-scheme-18

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-payload-flexible-fec-scheme-18


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

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From nobody Tue Mar  5 09:21:08 2019
Return-Path: 
X-Original-To: payload@ietfa.amsl.com
Delivered-To: payload@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A3AF128B36 for ; Tue,  5 Mar 2019 09:21:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.3
X-Spam-Level: 
X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=qti.qualcomm.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0oagEnj51sVN for ; Tue,  5 Mar 2019 09:21:05 -0800 (PST)
Received: from alexa-out-sd-01.qualcomm.com (alexa-out-sd-01.qualcomm.com [199.106.114.38]) (using TLSv1.2 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EEE3812D4F3 for ; Tue,  5 Mar 2019 09:21:04 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1551806464; x=1583342464; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=spJUtHuLOOxFzIhGmciD217UxSGW2JnuzWFgYsFjyaw=; b=yQysXQiIdWA7z6bGy7r5mavbcsu5i6ENZBH88TiBX3Zqh9A5y+ZjSACE RqxGNPNdru1S08SaQCc+XIEZ4iWBni3PEeDn20yPgnU+Yw78EPqIUlhmD p56JZrG2JWfMhG6deFCbV6hQgGRAPw8Qlm9LAmmVI9oXqSIuC14IVnfm5 Q=;
X-IronPort-AV: E=Sophos;i="5.58,444,1544515200"; d="scan'208";a="31795920"
Received: from unknown (HELO ironmsg05-sd.qualcomm.com) ([10.53.140.145]) by alexa-out-sd-01.qualcomm.com with ESMTP; 05 Mar 2019 09:21:04 -0800
Received: from nasanexm01g.na.qualcomm.com ([10.85.0.33]) by ironmsg05-sd.qualcomm.com with ESMTP/TLS/AES256-SHA; 05 Mar 2019 09:21:04 -0800
Received: from NASANEXM01C.na.qualcomm.com (10.85.0.83) by NASANEXM01G.na.qualcomm.com (10.85.0.33) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Tue, 5 Mar 2019 09:21:03 -0800
Received: from NASANEXM01C.na.qualcomm.com ([10.85.0.83]) by NASANEXM01C.na.qualcomm.com ([10.85.0.83]) with mapi id 15.00.1395.000; Tue, 5 Mar 2019 09:21:03 -0800
From: Giridhar Mandyam 
To: "payload@ietf.org" 
Thread-Topic: [payload] I-D Action: draft-ietf-payload-flexible-fec-scheme-18.txt
Thread-Index: AQHU03eOAhGPSJgDx0OlJJufQSSE1aX9SGfA
Date: Tue, 5 Mar 2019 17:21:03 +0000
Message-ID: 
References: <155180634247.24571.9901113243096289600@ietfa.amsl.com>
In-Reply-To: <155180634247.24571.9901113243096289600@ietfa.amsl.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.80.80.8]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: 
Subject: Re: [payload] I-D Action: draft-ietf-payload-flexible-fec-scheme-18.txt
X-BeenThere: payload@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Audio/Video Transport Payloads working group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 05 Mar 2019 17:21:07 -0000

My apologies in advance for not getting final confirmation from Benjamin K.=
 on whether we have addressed the concerns he has raised, but I wanted to g=
et a new version up before the blackout period begins prior to the next IET=
F meeetings.

-Giri

-----Original Message-----
From: payload  On Behalf Of internet-drafts@ietf.=
org
Sent: Tuesday, March 5, 2019 9:19 AM
To: i-d-announce@ietf.org
Cc: payload@ietf.org
Subject: [payload] I-D Action: draft-ietf-payload-flexible-fec-scheme-18.tx=
t

-------------------------------------------------------------------------
CAUTION: This email originated from outside of the organization.
-------------------------------------------------------------------------

A New Internet-Draft is available from the on-line Internet-Drafts director=
ies.
This draft is a work item of the Audio/Video Transport Payloads WG of the I=
ETF.

        Title           : RTP Payload Format for Flexible Forward Error Cor=
rection (FEC)
        Authors         : Mo Zanaty
                          Varun Singh
                          Ali Begen
                          Giridhar Mandyam
	Filename        : draft-ietf-payload-flexible-fec-scheme-18.txt
	Pages           : 44
	Date            : 2019-03-05

Abstract:
   This document defines new RTP payload formats for the Forward Error
   Correction (FEC) packets that are generated by the non-interleaved
   and interleaved parity codes from source media encapsulated in RTP.
   These parity codes are systematic codes, where a number of FEC repair
   packets are generated from a set of source packets from one or more
   source RTP streams.  These FEC repair packets are sent in a
   redundancy RTP stream separate from the source RTP stream(s) that
   carries the source packets.  RTP source packets that were lost in
   transmission can be reconstructed using the source and repair packets
   that were received.  The non-interleaved and interleaved parity codes
   which are defined in this specification offer a good protection
   against random and bursty packet losses, respectively, at a cost of
   complexity.  The RTP payload formats that are defined in this
   document address scalability issues experienced with the earlier
   specifications, and offer several improvements.  Due to these
   changes, the new payload formats are not backward compatible with
   earlier specifications, but endpoints that do not implement this
   specification can still work by simply ignoring the FEC repair
   packets.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-payload-flexible-fec-scheme/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-payload-flexible-fec-scheme-18
https://datatracker.ietf.org/doc/html/draft-ietf-payload-flexible-fec-schem=
e-18

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-payload-flexible-fec-scheme-=
18


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/

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


From nobody Tue Mar  5 09:52:10 2019
Return-Path: 
X-Original-To: payload@ietf.org
Delivered-To: payload@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F58E12D861 for ; Tue,  5 Mar 2019 09:52:08 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
To: 
X-Test-IDTracker: no
X-IETF-IDTracker: 6.92.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <155180832858.24583.16543206438558155356.idtracker@ietfa.amsl.com>
Date: Tue, 05 Mar 2019 09:52:08 -0800
From: IETF Secretariat 
Archived-At: 
Subject: [payload] Milestones changed for payload WG
X-BeenThere: payload@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Audio/Video Transport Payloads working group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 05 Mar 2019 17:52:09 -0000

Changed milestone "Submit  RTP Payload Format for ISO/IEC 21122 (JPEG XS) for
Proposed Standard", set state to active from review, accepting new milestone.

Changed milestone "Submit RTP Payload Format for TTML Timed Text for Proposed
Standard", set state to active from review, accepting new milestone.

URL: https://datatracker.ietf.org/wg/payload/about/


From nobody Tue Mar  5 12:20:30 2019
Return-Path: 
X-Original-To: payload@ietfa.amsl.com
Delivered-To: payload@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4019E129508 for ; Tue,  5 Mar 2019 12:20:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level: 
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MhW18pGAkLkx for ; Tue,  5 Mar 2019 12:20:26 -0800 (PST)
Received: from mail-ua1-x92f.google.com (mail-ua1-x92f.google.com [IPv6:2607:f8b0:4864:20::92f]) (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 7B0CE126C15 for ; Tue,  5 Mar 2019 12:20:26 -0800 (PST)
Received: by mail-ua1-x92f.google.com with SMTP id j7so8143591uak.8 for ; Tue, 05 Mar 2019 12:20:26 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=72wkZ8YFfaOgSWVJjCQuOU3v26T/tIYAvIsfvXh6CD4=; b=QJ9TChsAFqA8Fr524xToDgfDW/ov4o5DKdtUXU2NbH+GMR3uMnI0c+4LdxNiYTvSJT W5R5mXTOVUvEF8ZkdVIInGeaykwlFZJX3kgwzGh2EuZ4d8ZuFBsP2M9kcYij6oVHCeGq vV8YYDYPYnkymOhZn5HvANpvI1OeAM/oplt3k5wiUycLL2NQX4ai/SOLm8f5EDZ5V6pf jbKkgQd+SAAD0Iv+Yo4x7fJulllJFQfPvgWO5yPlwaDPZg3/bpc0NU1grhH7BHhqKBJ6 TN8FNH4vn9I0gyHBamquXYVjV3+NeNmo2LBJAFxig+pk28mbz1E2iXzkLvgGfkGMZNY9 dnTA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=72wkZ8YFfaOgSWVJjCQuOU3v26T/tIYAvIsfvXh6CD4=; b=NOXuo9xj0QrujesOM1PJKtJ6CVpAQnvjkEj6MWms6mkLvL7NjH0nOYhJt7QQhOMIZf sllBLHImhr1NaPqzEjjLtu3uSL3XZ+CTHjzRuUQy3/EmZH5U6WBKKKN22I/1MLHOCFrE Txlgx3gcHDo8CBW6/rbC6GVlrpg1wgIT4ib4qXLe27ZEZUFVgoeT5AObSRIdemwLutF/ voXBRSAKCyp/unOCwzw5tqtWh0nBnGc/fcF4qNMcp83CvpHZB9ugCeRqTe9p/1GxcY0b DIfA03MdyMV1zhvGGlykWx2YAT808jNmP958epId03xyytS897yQ8+eiYGXFJmopqdtF 7x0g==
X-Gm-Message-State: APjAAAXb8XFBAgZsAZOjAmToH8En+9N5vNvJSWvuHqmXqOE5835xLyUe Un3Oi8yga2MfjpglQYe9uxzJWvUc8yxNHcgeDxc=
X-Google-Smtp-Source: APXvYqzrkbhZyGZEA3OK20yHW6DfW2GLoc49nwxoDHBoyz/3ZY345S7VLUKYuwfyQU/SZFYYgzeLnT3FBzjQIuKCFZw=
X-Received: by 2002:ab0:6950:: with SMTP id c16mr2218921uas.0.1551817225068; Tue, 05 Mar 2019 12:20:25 -0800 (PST)
MIME-Version: 1.0
References:     <475EABAD-28F9-461F-A687-1CF580B4EC46@microsoft.com>
In-Reply-To: <475EABAD-28F9-461F-A687-1CF580B4EC46@microsoft.com>
From: Bernard Aboba 
Date: Tue, 5 Mar 2019 12:20:13 -0800
Message-ID: 
To: Bernard Aboba 
Cc: Varun Singh , "payload@ietf.org" ,  Robin Raymond 
Content-Type: multipart/alternative; boundary="00000000000074e59a05835e9ac5"
Archived-At: 
Subject: Re: [payload] SDP O/A -- L, D, ToP and Flexible mode
X-BeenThere: payload@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Audio/Video Transport Payloads working group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 05 Mar 2019 20:20:28 -0000

--00000000000074e59a05835e9ac5
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Varun --

Have your suggestions for clarifying the SDP O/A answer negotiation in the
document made it into the updates to draft-ietf-payload-flexible-fec-scheme=
?

I re-read the latest update, and the problems still seem like they remain.



On Tue, Feb 12, 2019 at 3:09 PM Bernard Aboba  wrote:

> On Feb 12, 2019, at 2:12 PM, Varun Singh  wrote:
> >
> > Do ToP modes 0, 1, and 2 implicitly mean no RTX?
>
> [BA] I believe that is what is implicit now, though it doesn=E2=80=99t ma=
ke much
> sense to me.
>
> > If so, why do we have this following ambiguity  (L, D, ToP are all
> missing) means it is both Flexfec FEC and flexfec RTX?
>
> [BA] Good question. For me, flexible versus fixed and rtx/no rtx are
> orthogonal questions.
>
> > I think the implicit assumption is that all of  flex FEC spec is
> implemented.
> >
> > Offer can send and receive  X and answerer can send and receive Y.
> >
> > I can=E2=80=99t see why we would endorse a partial implementation?
>
> [BA] I agree that all major features and bitmask sizes should be mandator=
y
> to implement. Would also like to see requirements on supported L and D
> values. With this clarified the declarative model would work much better.
> _______________________________________________
> payload mailing list
> payload@ietf.org
> https://www.ietf.org/mailman/listinfo/payload
>

--00000000000074e59a05835e9ac5
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Varun --

Have your suggestions for clar=
ifying the SDP O/A answer negotiation in the document made it into the upda=
tes to draft-ietf-payload-flexible-fec-scheme?

I r=
e-read the latest update, and the problems still seem like they remain.=C2=
=A0



On Tue, Feb 12, 2019 at 3:09 PM Bern=
ard Aboba <Bernard.Aboba=3D40microsoft.com@dmarc.ietf.org> wrote:
On Feb 12, 2019, at 2:12 PM, Varun Singh=
 <varun@callstat=
s.io> wrote:

> 

> Do ToP modes 0, 1, and 2 implicitly mean no RTX?



[BA] I believe that is what is implicit now, though it doesn=E2=80=99t make=
 much sense to me.



> If so, why do we have this following ambiguity=C2=A0 (L, D, ToP are al=
l missing) means it is both Flexfec FEC and flexfec RTX?



[BA] Good question. For me, flexible versus fixed and rtx/no rtx are orthog=
onal questions.



> I think the implicit assumption is that all of=C2=A0 flex FEC spec is =
implemented.=C2=A0 

> 

> Offer can send and receive=C2=A0 X and answerer can send and receive Y=
. 

> 

> I can=E2=80=99t see why we would endorse a partial implementation?



[BA] I agree that all major features and bitmask sizes should be mandatory =
to implement. Would also like to see requirements on supported L and D valu=
es. With this clarified the declarative model would work much better.

_______________________________________________

payload mailing list

payload@ietf.org<=
br>
https://www.ietf.org/mailman/listinfo/payload




--00000000000074e59a05835e9ac5--


From nobody Tue Mar  5 12:23:22 2019
Return-Path: 
X-Original-To: payload@ietfa.amsl.com
Delivered-To: payload@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C6E61277D2 for ; Tue,  5 Mar 2019 12:23:19 -0800 (PST)
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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=callstats.io
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 L_OmplrNHiRe for ; Tue,  5 Mar 2019 12:23:18 -0800 (PST)
Received: from mail-wr1-x435.google.com (mail-wr1-x435.google.com [IPv6:2a00:1450:4864:20::435]) (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 3AF8D126C15 for ; Tue,  5 Mar 2019 12:23:17 -0800 (PST)
Received: by mail-wr1-x435.google.com with SMTP id g12so10915539wrm.5 for ; Tue, 05 Mar 2019 12:23:17 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=callstats.io; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=vw9piAohqPT984izZYqhBbD2Dq/OblsqNTN2+r+dz7Y=; b=dg4xtkBc7kaIjUQigB2zhINoG1mEZaoZjX0gsj8xNWcx1i91DMia2jc3e97xxkWIy3 1fX3qdG2lcQBOSFNY8u9jfo3MxurKKFl/vLZG0hAHN1V8FChicAFNoOzw6oHxj4CRb64 RpbpaM4lemaOMon5C2I7eZh9B820WCqVHV5QI=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=vw9piAohqPT984izZYqhBbD2Dq/OblsqNTN2+r+dz7Y=; b=SDifYCQmllHJcUJVlpI/nk1eAiqZEmiXE7vgh3L86OU8OPtokuLMAacPJCP+9VqhGp pkm/7HtCz7LDy1PqG8xBdjmUK1eoqXszHjcv2PymKHkGVOrgBl0+3yDDlHSJcLZSrbns 7BNLEMWZr3SeQGRWOaVOq4J34iRz8Yxlo2WD9pVft3AblXgr9Sd1jeB0y7FLtnB8X6La DqOPLJhuwVvW+HIj6GL4JLAYMVA05+Z2/Gn6TNDnzgKI4Xnl5gJEzHNPqEFikD1f4kVF xgShjQ72f1ieZZMtWH6Hjd+HPbKXmfZKFQKwxDLwpcthZHlnCKmaQ9ecdOqxjzCRDSi8 Uz/w==
X-Gm-Message-State: APjAAAU/UqZCJdfxvz53t/N8z5qRcleob6LdGWpkXmi2r+NcpLqsOG4g 3reG6BZV3tGRxa5XceyPCCUBFPfMgcg7coRVNo/hhA==
X-Google-Smtp-Source: APXvYqx0tzGdpgxGb5W4RiiWMVMdJJK7odBGN6DQMSUrqXPtDHtwhf4dpDfn60iilVudbXvk/6adMGHdV1rBaUimoOM=
X-Received: by 2002:adf:fecd:: with SMTP id q13mr460934wrs.3.1551817395325; Tue, 05 Mar 2019 12:23:15 -0800 (PST)
MIME-Version: 1.0
References:     <475EABAD-28F9-461F-A687-1CF580B4EC46@microsoft.com> 
In-Reply-To: 
From: Varun Singh 
Date: Tue, 5 Mar 2019 22:23:04 +0200
Message-ID: 
To: Bernard Aboba 
Cc: Bernard Aboba ,  Robin Raymond , "payload@ietf.org" 
Content-Type: multipart/alternative; boundary="0000000000009ae21905835ea4a2"
Archived-At: 
Subject: Re: [payload] SDP O/A -- L, D, ToP and Flexible mode
X-BeenThere: payload@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Audio/Video Transport Payloads working group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 05 Mar 2019 20:23:20 -0000

--0000000000009ae21905835ea4a2
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Bernard,

Thanks for following up.

I didn=E2=80=99t get much feedback apart from you on the proposal, so I=E2=
=80=99d
appreciate if others could weigh in on the suggestions.

Regards,
Varun.

On Tue, 5 Mar 2019 at 22.20, Bernard Aboba  wrote:

> Varun --
>
> Have your suggestions for clarifying the SDP O/A answer negotiation in th=
e
> document made it into the updates to draft-ietf-payload-flexible-fec-sche=
me?
>
> I re-read the latest update, and the problems still seem like they remain=
.
>
>
>
> On Tue, Feb 12, 2019 at 3:09 PM Bernard Aboba  40microsoft.com@dmarc.ietf.org> wrote:
>
>> On Feb 12, 2019, at 2:12 PM, Varun Singh  wrote:
>> >
>> > Do ToP modes 0, 1, and 2 implicitly mean no RTX?
>>
>> [BA] I believe that is what is implicit now, though it doesn=E2=80=99t m=
ake much
>> sense to me.
>>
>> > If so, why do we have this following ambiguity  (L, D, ToP are all
>> missing) means it is both Flexfec FEC and flexfec RTX?
>>
>> [BA] Good question. For me, flexible versus fixed and rtx/no rtx are
>> orthogonal questions.
>>
>> > I think the implicit assumption is that all of  flex FEC spec is
>> implemented.
>> >
>> > Offer can send and receive  X and answerer can send and receive Y.
>> >
>> > I can=E2=80=99t see why we would endorse a partial implementation?
>>
>> [BA] I agree that all major features and bitmask sizes should be
>> mandatory to implement. Would also like to see requirements on supported=
 L
>> and D values. With this clarified the declarative model would work much
>> better.
>>
> _______________________________________________
>> payload mailing list
>> payload@ietf.org
>> https://www.ietf.org/mailman/listinfo/payload
>>
> --
Founder, CEO, callstats.io
http://www.callstats.io

Interested in networking, media quality, and diagnostics.
We are hiring!: www.callstats.io/jobs/

--0000000000009ae21905835ea4a2
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hi Bernard,

Thanks for following up.=C2=A0

I didn=E2=80=99t get much feedback apart from =
you on the proposal, so I=E2=80=99d appreciate if others could weigh in on =
the suggestions.=C2=A0

Regards,
Varun.=C2=A0
On Tue, 5 Mar 2019 at 22.20, Bernard Aboba <bernard.aboba@gmail.com> wr=
ote:
Varun --
=

Have your suggestions for clarifying the SDP O/A answer nego=
tiation in the document made it into the updates to draft-ietf-payload-flex=
ible-fec-scheme?

I re-read the latest update, and =
the problems still seem like they remain.=C2=A0


On Tue, Feb 12, 2019 at 3:09 PM Be=
rnard Aboba <Bernard.Aboba=3D40microsoft.com@dmarc.ietf.org> wrote:
<=
/div>
On Feb 12, 2019, at 2:12 PM, Varun Singh =
<varun@callstats=
.io> wrote:

> 

> Do ToP modes 0, 1, and 2 implicitly mean no RTX?



[BA] I believe that is what is implicit now, though it doesn=E2=80=99t make=
 much sense to me.



> If so, why do we have this following ambiguity=C2=A0 (L, D, ToP are al=
l missing) means it is both Flexfec FEC and flexfec RTX?



[BA] Good question. For me, flexible versus fixed and rtx/no rtx are orthog=
onal questions.



> I think the implicit assumption is that all of=C2=A0 flex FEC spec is =
implemented.=C2=A0 

> 

> Offer can send and receive=C2=A0 X and answerer can send and receive Y=
. 

> 

> I can=E2=80=99t see why we would endorse a partial implementation?



[BA] I agree that all major features and bitmask sizes should be mandatory =
to implement. Would also like to see requirements on supported L and D valu=
es. With this clarified the declarative model would work much better.

_______________________________________________

payload mailing list

payload@ietf.org<=
br>
https://www.ietf.org/mailman/listinfo/payload




-- 
Founder, CEO, callstat=
s.io

Interested in networking=
, media quality, and diagnostics.
We are hiring!: www.callstats.io/jobs/




--0000000000009ae21905835ea4a2--


From nobody Tue Mar  5 12:43:04 2019
Return-Path: 
X-Original-To: payload@ietfa.amsl.com
Delivered-To: payload@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45C91130EC9 for ; Tue,  5 Mar 2019 12:43:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.877
X-Spam-Level: 
X-Spam-Status: No, score=-0.877 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URI_HEX=1.122] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=callstats.io
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 o5Bb0n3H9Z77 for ; Tue,  5 Mar 2019 12:42:59 -0800 (PST)
Received: from mail-wm1-x32a.google.com (mail-wm1-x32a.google.com [IPv6:2a00:1450:4864:20::32a]) (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 C939B128CF3 for ; Tue,  5 Mar 2019 12:42:58 -0800 (PST)
Received: by mail-wm1-x32a.google.com with SMTP id j125so3889554wmj.1 for ; Tue, 05 Mar 2019 12:42:58 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=callstats.io; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=nx7FsxtfBbFC97oMl7nBix0VpcWoAUgncj+goNa4ag4=; b=gJBRz1zUmjtG5LOtNEgT2iEefojZUG37DHLEXFyZA9xRysJLNa97ZLFw3NBLPVoNfX ZAvQxFoP6nK6/O4c7dGVvVNX7FuBxv0JWWUEVGQ/SKVdROX8sLKuMnoqMMNe0mH64+gh c3Eyq0bP5o6fwxZ413PQ+09cwBL2IdPS7nUNw=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=nx7FsxtfBbFC97oMl7nBix0VpcWoAUgncj+goNa4ag4=; b=pvVd8dAEsw9ElXwPlNdKJH+RQvtofN9bZ0INPu/RkzuFdy5SMgXtJuzcXb1GS5FCYg pfRtS4+287XlJ1N81yHC5ShKN7+jCDa5T3aSZC/tdPfFoML266SIE2+YKRx6wmGc/xFE SiT7VClFGAkLP7AB5C3U0r32I5mH7cH6wO2/h3oAB4nIybT7YFlzTIxifO7uIgU4JxQE TK6RR7qqudYe/ozKleJkj7IdYQmYo3njS37eza/cKlYIKUCOhwP81Hy+fUqWsTvpiIIn dILK3rvBX5FO6kLiOSIO2QmNQdupGsJuSZKH+DB4F9Gilv8BpzFUowNlbpEwWctLf9mR lErA==
X-Gm-Message-State: APjAAAWVLbGyZ7H1MW59C3W2/5sH/118I7Sy+SMF8xpV33b0f2hg6/vW cpm81QciSeQOpIoXP0IckuTD8KS242OEFqbCSa0hzg==
X-Google-Smtp-Source: APXvYqzkXE83VPUUv02DES8uhK/bh1iYCNE32FY7qJZTefgYHFqa9BcRSKyJsGTOPakr3Tc9zn1Hy0ZtLAm95ARtOwI=
X-Received: by 2002:a1c:449:: with SMTP id 70mr257319wme.118.1551818576955; Tue, 05 Mar 2019 12:42:56 -0800 (PST)
MIME-Version: 1.0
References:   
In-Reply-To: 
From: Varun Singh 
Date: Tue, 5 Mar 2019 22:42:45 +0200
Message-ID: 
To: Bernard Aboba ,  "draft-ietf-payload-flexible-fec-scheme.authors@ietf.org" ,  "payload@ietf.org" 
Content-Type: multipart/alternative; boundary="00000000000009250a05835eeba8"
Archived-At: 
Subject: [payload] Fwd: SDP O/A -- L, D, ToP and Flexible mode
X-BeenThere: payload@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Audio/Video Transport Payloads working group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 05 Mar 2019 20:43:02 -0000

--00000000000009250a05835eeba8
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi,

Forwarding my clarifications to Bernard=E2=80=99s review.
Full email below.

Feedback appreciated.

Regards,
Varun.

---------- Forwarded message ---------
From: Varun Singh 
Date: Tue, 12 Feb 2019 at 5.40
Subject: Re: SDP O/A -- L, D, ToP and Flexible mode
To: Bernard Aboba 


Hi all,

Thanks Bernard for the quick feedback. See my replies inline.

On Mon, 11 Feb 2019 at 19.13, Bernard Aboba 
wrote:

> Comments below.
>
> On Feb 11, 2019, at 2:45 PM, Varun Singh  wrote:
>
> Hi all,
>
> I  caught up on the mail discussion, initially, I did not run through all
> the cases, but Bernard's follow up email, makes me question if we have to
> be more specific.
>
> Everything in this email is scoped for the SDP.
>
> 0) IIRC the SDP for FlexFec was supposed to be declarative and not really
> a negotiation.
>
>
> [BA] Is it only declaring in one direction - what to send, but not what i=
t
> can receive? Or is there something implicit there?
>

Yes. It=E2=80=99s only in one direction. The implicit assumption is that th=
e
endpoint can receive what it offers.

I can think of an argument being made, where the Offers are what type of
FEC protection/structure is willing to receive rather than send. However,
the negotiation model would be rather complex (and the ability to announce
several capability modes)




>
> - Offerer supports FlexFEC, but the Answerer does not implement it, the
> Answerer would either reject the offer or remove flexFEC from the answer.
>
>
> Otherwise, if both support FlexFEC, the Answerer would just send its own
> FlexFEC (L,D, ToP) configuration.
>
> I do not think negotiation makes a lot of sense:
> For uni-directional media, offerer specifies L, D, ToP. Logically, the
> answerer cannot ask for higher values of L and D, or a different ToP. I
> think if the answerer disagrees in this case, it would just reject the
> offer or remove flexFEC from the answer.
>
>
> [BA] Agree that negotiation isn=E2=80=99t a good model - but the asymmetr=
y between
> Offerer and Answerer can create questions.
>
> What does an Offerer do if it receives an Answer with settings it does no=
t
> support?  Is there a way for the Answerer to infer the set of settings an
> Offerer supports so as to make this unlikely?
>

I don=E2=80=99t think there are really options in this case.

If the offerer wants to use the interleaved mode, I don=E2=80=99t see a leg=
itimate
case for the answerer to try to figure out what other modes exist. In
general I can=E2=80=99t see in what situation would negotiation help?

Are you thinking of a situation where an offerer is not very opinionated at
wants to describe that it=E2=80=99 instead lists a lot of L D ToP capabilit=
ies that
the answerer then picks from?


>
> For bi-directional media, the networks might behave differently, and thus=
,
> the endpoints may want to choose asymmetrical L and Ds. Which would mean
> that the Offerer and Answerer can have different L and D and O/A request
> and response is just telling the other party what their respective L and =
Ds
> will be?
>
>
> [BA] Makes sense.
>
>
> *1) The whole point of specifying L,D, and ToP (modes 0,1, and 2) in SDP
> was to have a rigid FEC transform structure. Agree or disagree?*
>
>
> [BA] Rigid structure makes sense if the goal is to maximize interop by
> specifying well known and required modes. But without required support fo=
r
> a set of configurations it can increase the complexity of negotiation. I =
do
> not like the idea of having to offer multiple potential flexfec
> configurations, for example.
>
>
> 2) ToP and L/D modes
>
> - If an endpoint uses ToP 1 (non-interleaved), it must provide the number
> of columns (L)
> - If an endpoint uses ToP 0 (interleaved), it must provide both L and D. =
L
> to know how much to skip and D to know which packets will be present.
> - If an endpoint uses ToP 2 (2 Dimensional), since all packets in L and D
> are protected, it must provide L and D.
> - If an endpoint wants to use the flexible FEC mode it must not specify L=
,
> D, or ToP.
> (skipping retx for this now)
>
> *Agree on these rules above?*
>
>
> [BA] Yes.
>

I skipped RTX before. So if I understand some of the confusion and now I=E2=
=80=99m
not sure what ToP 3 really means.

Do ToP modes 0, 1, and 2 implicitly mean no RTX?

If so, why do we have this following ambiguity  (L, D, ToP are all missing)
means it is both Flexfec FEC and flexfec RTX?


>
> I am assuming that L and D numbers in the SDP are exactly the ones that
> will be used in the protocol and the endpoints are not using the L and D
> values to mean anything between 0 to the specified value.
>
>
> [BA] Is there an implicit indication of what the Offerer can deal with in
> an Answer (e.g. L and D values less than those in the Offer are supported
> in an Answer)?
>

I think the implicit assumption is that all of  flex FEC spec is
implemented.

Offer can send and receive  X and answerer can send and receive Y.

I can=E2=80=99t see why we would endorse a partial implementation?


>
> 3) FlexFEC Retx and FlexFEC FEC
>
> - If an endpoint wants to use the flexible FEC and FlexFEC Retx it must
> not specify L, D, or ToP.
>
>
> [BA] Makes sense - but what is required of a flexible mode receiver? Must
> it be able to decode anything a sender can send? If not, how does it tell
> the other side that it received something it could not decode?
>
> - If an endpoint wants to use only the FlexFEC Retx it will set ToP to 3
> and skip L and D modes.
>
> *Is there a way to specify FlexFEC and FlexFEC Retx?*
>
>
Should there be explicit way to say in SDP

+ flexfec FEC only
+ flexfec RTX only
+ flexfec FEC and RTX, both?


> If the endpoints are using a declarative modes, I dont think there is an
> issue here. There can be assymetry and if the other party does not like t=
he
> Offer it can reject it or remove flexFEC from the answer.
>
> 4) FLEX FEC Retx and 4588 Retx =3D)
>
> The offer contains
> FLEXFEC RTX and FEC along with 4588 RTX, i.e., no L,D,ToP for FlexFEC and
> 4588 retx
>
> The Answerer can remove the flexFEC line to indicate that it wants to use
> 4588 Retx, but thus it cannot have any form of flexFEC.
>
> Without a re-offer, I dont think the endpoints can do anything better.
>
>
> [BA] Can we interpret negotiation of 4588 RTX to mean =E2=80=9Cno flexfec=
 rtx,
> please=E2=80=9D?
>


Going with the declarative model and restrictions of the SDP o/a semantics
(and I=E2=80=99m really suspicious about the validity of what I=E2=80=99m s=
uggesting below)

Case 1: everyone is happy
Offerer declares rfc4588 RTX and flexfex (with Flex RTX) meaning it has
complete flexibility in sending and receiving.

Answerer responds with rfc4588 RTX and flexfec (without RTX, I don=E2=80=99=
t think
we have a way of doing that), with this the answerer is declaring its
restriction.

Both parties in this case can figure out what needs to be done.

Case 2: no RTX because no compatibility

Offerer declares flexfec (with flex RTX), so no rfc4588 supported. Answerer
can respond with flexfec (without RTX).

In this case, while the offerer can send flex RTX the receiver won=E2=80=99=
t decode
it (and answerer would anyway just discard these packets) So it can just
assume not to send it. The answerer assuming didn=E2=80=99t want to send or=
 receiv
RTX would not send flex RTX.



>
>
>
>
> --
> Founder, CEO, callstats.io
> 
> http://www.callstats.io
> 
>
> Interested in networking, media quality, and diagnostics.
> We are hiring!: www.callstats.io/jobs/
> 
>
> --
Founder, CEO, callstats.io
http://www.callstats.io

Interested in networking, media quality, and diagnostics.
We are hiring!: www.callstats.io/jobs/
--=20
Founder, CEO, callstats.io
http://www.callstats.io

Interested in networking, media quality, and diagnostics.
We are hiring!: www.callstats.io/jobs/

--00000000000009250a05835eeba8
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hi,

Forwarding my clarifications to Bernard=E2=80=99s review.=C2=A0
Full email below.=C2=A0
=

Feedback appreciated.=C2=A0

Regards,
Varun.=C2=
=A0

---------- Forwarded message ---------
F=
rom: Varun Singh <varun@callstats.io>
Date: Tue, 12 Feb 2019 at 5.40
Subject: =
Re: SDP O/A -- L, D, ToP and Flexible mode
To: Bernard Aboba <Bernard.Aboba@mic=
rosoft.com>


Hi all,

Thanks Bernard for th=
e quick feedback. See my replies inline.=C2=A0

O=
n Mon, 11 Feb 2019 at 19.13, Bernard Aboba <Bernard.Aboba@microsoft.com> wr=
ote:









Comments below.




On Feb 11, 2019, at 2:45 PM, Varun Singh <varun@callstats.io> wrote:










Hi all,






I =C2=A0caught up on the mail discussion, initially, I did not run thr=
ough all the cases, but Bernard's follow up email, makes me question if=
 we have to be more=C2=A0specific.







Everything in this email is scoped for the SDP.







0) IIRC the SDP for FlexFec was supposed to be declarative and not rea=
lly a negotiation.=C2=A0












[BA] Is it only declaring in one direction - what to send, but not what it =
can receive? Or is there something implicit there?


Yes. It=E2=80=99s only in one direction. The implicit assumptio=
n is that the endpoint can receive what it offers.=C2=A0

I can think of an argument being made, whe=
re the Offers are what type of FEC protection/structure is willing to recei=
ve rather than send. However, the negotiation model would be rather complex=
 (and the ability to announce several capability modes)



=















- Offerer supports FlexFEC, but the Answerer does not implement it, th=
e Answerer would either reject the offer or remove flexFEC from the answer.=
=C2=A0























Otherwise, if both support FlexFEC, the Answerer would just send its o=
wn FlexFEC (L,D, ToP) configuration.







I do not think negotiation makes a lot of sense:




For uni-directional media, offerer specifies L, D, ToP. Logically, the=
 answerer cannot ask for higher values of L and D, or a different ToP. I th=
ink if the answerer disagrees in this case, it would just reject the offer =
or remove flexFEC from the answer.















[BA] Agree that negotiation isn=E2=80=99t a good model - but the asymm=
etry between Offerer and Answerer can create questions.







What does an Offerer do if it receives an Answer with settings it does=
 not support?=C2=A0 Is there a way for the Answerer to infer the set of set=
tings an Offerer supports so as to make this unlikely?



I don=E2=80=99t think there are really options in this case.=C2=A0

If the offerer wants to u=
se the interleaved mode, I don=E2=80=99t see a legitimate case for the answ=
erer to try to figure out what other modes exist. In general I can=E2=80=99=
t see in what situation would negotiation help?

=

Are you thinking of a situation where an offerer is=
 not very opinionated at wants to describe that it=E2=80=99 instead lists a=
 lot of L D ToP capabilities that the answerer then picks from?
=


















For bi-directional media, the networks might behave differently, and t=
hus, the endpoints may want to choose asymmetrical L and Ds.=C2=A0Which wou=
ld mean that the Offerer and Answerer can have different L and D and O/A re=
quest and response is just telling the
 other party what their respective L and Ds will be?=C2=A0














[BA] Makes sense.
















1) The whole point of specifying L,D, and ToP (modes 0,1, and 2) in=
 SDP was to have a rigid FEC transform structure. Agree or disagree?











[BA] Rigid structure makes sense if the goal is to maximize interop by spec=
ifying well known and required modes. But without required support for a se=
t of configurations it can increase the complexity of negotiation. I do not=
 like the idea of having to offer
 multiple potential flexfec configurations, for example.






















2) ToP and L/D modes











- If an endpoint uses ToP 1 (non-interleaved), it must provide the num=
ber of columns (L)




- If an endpoint uses=C2=A0ToP 0 (interleaved), it must provide both L=
 and D. L to know how much to skip and D to know which packets will be pres=
ent.


- If an endpoint uses ToP 2 (2 Dimensional), since all packets in L an=
d D are protected, it must provide L and D.


- If an endpoint wants to use the flexible FEC mode it must not specif=
y L, D, or ToP.=C2=A0




(skipping retx for this now)









Agree on these rules above?














[BA] Yes.

I skipped RTX before. So if I understand some of the confusion and now=
 I=E2=80=99m not sure what ToP 3 really means.=C2=A0

Do ToP modes 0, 1, and 2 implicitly mean no RT=
X?

If so, why do we have=
 this following ambiguity =C2=A0(L, D, ToP are all missing) means it is bot=
h Flexfec FEC and flexfec RTX?

















I am assuming that L and D numbers in the SDP are exactly the ones tha=
t will be used in the protocol and the endpoints are not using the L and D =
values to mean anything between 0 to the specified value.













[BA] Is there an implicit indication of what the Offerer can deal with=
 in an Answer (e.g. L and D values less than those in the Offer are support=
ed in an Answer)?



=

I think the implicit assumption is that all of =C2=A0flex=
 FEC spec is implemented. =C2=A0

Offer can send and receive =C2=A0X and answerer can send and rece=
ive Y.=C2=A0

I can=E2=80=
=99t see why we would endorse a partial implementation?

<=
div>
















3) FlexFEC Retx and FlexFEC FEC









- If an endpoint wants to use the flexible FEC and FlexFEC Retx it mus=
t not specify L, D, or ToP.=C2=A0

















[BA] Makes sense - but what is required of a flexible mode receiver? M=
ust it be able to decode anything a sender can send? If not, how does it te=
ll the other side that it received something it could not decode?














- If an endpoint wants to use only the FlexFEC Retx it will set ToP to=
 3 and skip L and D modes.











Is there a way to specify FlexFEC and FlexFEC Retx?
=


Should there be explicit way to say in SDP
<=
div dir=3D"auto">
+ flexfec FEC only
+ flexfec RTX only
+ flexfec FEC and RTX=
, both?
<=
br>





If the endpoints are using a declarative modes, I dont think there is =
an issue here. There can be assymetry and if the other party does not like =
the Offer it can reject it or remove flexFEC from the answer.









4) FLEX FEC Retx and 4588 Retx =3D)







The offer contains


FLEXFEC RTX and FEC along with 4588 RTX, i.e., no L,D,ToP for FlexFEC =
and 4588 retx







The Answerer can remove the flexFEC line to indicate that it wants to =
use 4588 Retx, but thus it cannot have any form of flexFEC.=C2=A0







Without a re-offer, I dont think the endpoints can do anything better.=
=C2=A0













[BA] Can we interpret negotiation of 4588 RTX to mean =E2=80=9Cno flex=
fec rtx, please=E2=80=9D?




=

Going with the declarative model and restrictions o=
f the SDP o/a semantics (and I=E2=80=99m really suspicious about the validi=
ty of what I=E2=80=99m suggesting below)

<=
div dir=3D"auto">Case 1: everyone is happy
Offerer d=
eclares rfc4588 RTX and flexfex (with Flex RTX) meaning it has complete fle=
xibility in sending and receiving.=C2=A0

<=
div dir=3D"auto">Answerer responds with rfc4588 RTX and flexfec (without RT=
X, I don=E2=80=99t think we have a way of doing that), with this the answer=
er is declaring its restriction.=C2=A0

Both parties in this case can figure out what needs to be do=
ne.=C2=A0

Case 2: no RTX=
 because no compatibility

Offerer declares flexfec (with flex RTX), so no rfc4588 supported. Answer=
er can respond with flexfec (without RTX).=C2=A0
In this case, while the offerer can send flex RTX =
the receiver won=E2=80=99t decode it (and answerer would anyway just discar=
d these packets) So it can just assume not to send it. The answerer assumin=
g didn=E2=80=99t want to send or receiv RTX would not send flex RTX.=C2=A0<=
/div>
































-- 


Founder, CEO,

callstats.io

http://www.callstats.io



Interested in networking, media quality, and diagnostics. 

We are hiring!: 
www.callstats.io/jobs/

















-- 
Founder, CEO, callstat=
s.io

Interested in networking=
, media quality, and diagnostics.
We are hiring!: www.callstats.io/jobs/


-- 
Founder, CEO, callstats.io

Interested in networking,=
 media quality, and diagnostics.
We are hiring!: www.callstats.io/jobs/


--00000000000009250a05835eeba8--


From nobody Fri Mar  8 14:50:59 2019
Return-Path: 
X-Original-To: payload@ietfa.amsl.com
Delivered-To: payload@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB2DE1277C9; Fri,  8 Mar 2019 14:50:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.999
X-Spam-Level: **
X-Spam-Status: No, score=2.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, GB_SUMOF=5, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mit.edu
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 ISVU_oF_KQm7; Fri,  8 Mar 2019 14:50:54 -0800 (PST)
Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-eopbgr810110.outbound.protection.outlook.com [40.107.81.110]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E43412716C; Fri,  8 Mar 2019 14:50:54 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mit.edu; s=selector1;  h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=cmwElDuhwANNERwVVE7M3kl/ce4MnmrG6c3kKCXoWA8=; b=q4mBPHF7WOiVZthmKjNRjdV10CK4+8HOkxNkmuE0gXaiCzDsd3j1YrHU0eyfnehcDtaJC1fSkCZjZgVVGUprrubbIDwo5S1cKCGizo8cg69TAXYIY6dHGKND3U8+VtMCnxR43glk1P1Bg8ZHZ8S/Eun4ALSAdek8tWvCpLeNwII=
Received: from DM5PR0102CA0017.prod.exchangelabs.com (2603:10b6:4:9c::30) by CY4PR0101MB3077.prod.exchangelabs.com (2603:10b6:910:42::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1686.18; Fri, 8 Mar 2019 22:50:52 +0000
Received: from DM3NAM03FT055.eop-NAM03.prod.protection.outlook.com (2a01:111:f400:7e49::200) by DM5PR0102CA0017.outlook.office365.com (2603:10b6:4:9c::30) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1686.18 via Frontend Transport; Fri, 8 Mar 2019 22:50:52 +0000
Authentication-Results: spf=pass (sender IP is 18.9.28.11) smtp.mailfrom=mit.edu; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=bestguesspass action=none header.from=mit.edu;
Received-SPF: Pass (protection.outlook.com: domain of mit.edu designates 18.9.28.11 as permitted sender) receiver=protection.outlook.com; client-ip=18.9.28.11; helo=outgoing.mit.edu;
Received: from outgoing.mit.edu (18.9.28.11) by DM3NAM03FT055.mail.protection.outlook.com (10.152.83.209) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1686.19 via Frontend Transport; Fri, 8 Mar 2019 22:50:52 +0000
Received: from kduck.mit.edu (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x28MolDF030739 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 8 Mar 2019 17:50:49 -0500
Date: Fri, 8 Mar 2019 16:50:46 -0600
From: Benjamin Kaduk 
To: Giridhar Mandyam 
CC: Magnus Westerlund , The IESG , "roni.even@mail01.huawei.com" ,  "payload-chairs@ietf.org" , "payload@ietf.org" , "draft-ietf-payload-flexible-fec-scheme@ietf.org" 
Message-ID: <20190308225046.GC9824@kduck.mit.edu>
References: <155052681367.25946.18116200153523550938.idtracker@ietfa.amsl.com>  <0ef384ddaabd4883b77db08a477ab822@NASANEXM01C.na.qualcomm.com> <20190227002556.GE53396@kduck.mit.edu> <55e0b103a8824dd4a770678b974628ce@NASANEXM01C.na.qualcomm.com> 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.10.1 (2018-07-13)
X-EOPAttributedMessage: 0
X-Forefront-Antispam-Report: CIP:18.9.28.11; IPV:CAL; SCL:-1; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(376002)(346002)(39860400002)(396003)(136003)(2980300002)(199004)(189003)(51444003)(126002)(8676002)(88552002)(2906002)(229853002)(33656002)(86362001)(23726003)(305945005)(476003)(246002)(53416004)(50466002)(93886005)(6246003)(104016004)(36906005)(6916009)(1076003)(97756001)(106466001)(4326008)(786003)(316002)(5660300002)(30864003)(58126008)(426003)(16586007)(54906003)(26826003)(186003)(7696005)(478600001)(76176011)(14444005)(336012)(106002)(8936002)(47776003)(26005)(46406003)(75432002)(55016002)(6666004)(356004)(11346002)(486006)(446003)(956004); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR0101MB3077; H:outgoing.mit.edu; FPR:; SPF:Pass; LANG:en; PTR:outgoing-auth-1.mit.edu; A:1; MX:1; 
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id: 09b17c5b-1dba-40b0-1a18-08d6a4188471
X-Microsoft-Antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(4608103)(4709054)(2017052603328)(7153060); SRVR:CY4PR0101MB3077; 
X-MS-TrafficTypeDiagnostic: CY4PR0101MB3077:
X-Microsoft-Exchange-Diagnostics: 1; CY4PR0101MB3077; 20:6eB5PU+QQ/E8//s5kJat+d/XE90vaPgfw3/s5j9llld/5MyzPRFgJSJXbyP82xvkB6pkaf6nQunrSv9xkSwKUXPkznJRwdLKTupxIhogPucCOdd1vMo2r2rjzBXy3ipayXbl1MU9r/uS0IHkPRTEeoeqcM+9FnO8GUthcVhTDxeahR60jn1pMmQO/krrpw33o9Ir9pytylR9wXb8ChyoPy8lHnkXKkRwuduJ4wjFvcgfBgDpwvo3/rarcHmm1PqaycEO6SyJuYlfJ3pjRnmxFdbiuRKjVYPF8L67G1wpqzgjLB0s7mf9dSCKE2+arO18YYH5AyewizuFrcR37MOgI69zZ+m7ueMsz1uY045ynOoYzwE8MVM9TiSyD190eLLfWKiWKMNfz0FWGHCQOWnx91UICKLb6w7QWl9tXtxTbYGNZaxNNmrArJUyP4qziDbNAzd5Atffju/3D35ehOGhsPY4XU91/aBJYlEZfsX4SqOCfkQ45Sp8cwzgzjzXwFKaIfJLdY/hdedSJflzXCeGtoKQSmlz6zlMz8FWt03NVdMP+tfK+MSiDabQmV0/ibAX3lDmiEcAb7rKi6G7o4iDOFjCf8U3sckAM3eMr0eQTVs=
X-Microsoft-Antispam-PRVS: 
X-Forefront-PRVS: 0970508454
X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; CY4PR0101MB3077; 23:LYhygZv0Bt0l2k7Y1dK63fQUbucJpb4mUtvwBRZ?= =?us-ascii?Q?7D5i/4bZzzN+v7mMrDWH2RquysRfDXh4P0tHQZHaWgUW01quMjppSTHBWaiY?= =?us-ascii?Q?qoNvw0kdR6Fzegs+WmRzKcy0eDiWzIeST+pWWCApTGSMBBGF1S+4qekb2a7o?= =?us-ascii?Q?6q8AW5gFxZlY7N4e42glrGQV7QY2rHe8mZBnEmP/autHkYtVnPWu6+tsorlJ?= =?us-ascii?Q?BfkshitLS7dW2p9cf5PuSOrr5L93d/4ekxcMp1YPNQzln2xj4fftzazdUsDB?= =?us-ascii?Q?PyiQCi7+2+Xf7rScm0Jh0njVh6ShzT07EyPfG7lMCeOewjlDbwihglcGoL5i?= =?us-ascii?Q?TfGM+jTreeC0/y+pMMLTqxYKKbt3Ep3pqEFcCTKbp2lnNV6RDnYQiPeJwhpk?= =?us-ascii?Q?900PQ0UPKuf2UpLV1FVZO2yS4t0VMC9U/ryj/hhyw1E+OyMLCMh/s1iHKrSF?= =?us-ascii?Q?Oc+y7u0sOAPADq8asHkbzFrsj+EU6g0q1l3GSRwFE/sxswXw7o/Z3UVaGF+r?= =?us-ascii?Q?57FbxPWlC9qOAdx0zCqw+gNs7KnsdqwY7HYCsSjXNIyns/O2fUyli17OvzQ4?= =?us-ascii?Q?XTCxpEI/nzwmrSBN7eGiabcIsY6BhfNFJnGMPLPBTUsNSqo5G9f/yadb+KE2?= =?us-ascii?Q?FJTzf/KqQRNb64YoDpbMy0ANASfCxRoDjbVhVmNySDrltk2rRz3i5EJhaHCq?= =?us-ascii?Q?hRMS8iZGwXe1krX7JLZYx2o7HHYTNHxkGCxU0gV7HN56rM3FN9unU610c3nG?= =?us-ascii?Q?kE4YrjfwHu0YTWGU420warX0roWNoNj6V2e0NSx3zeHS/5VdSK9Y0ergJwxd?= =?us-ascii?Q?RZypjHj4s/mCH5rI1wLPPCVNgVA7uwb9W0ML01roG4p0ytHbdIcnBItHzFj9?= =?us-ascii?Q?Ffp/jTEXzWIyHI7r3TNsRPfA/UUfoZMmSYDLmMPf2JCydhCoOQCoo03mtjYR?= =?us-ascii?Q?sieynbzHIpJBsEJxjaAqZ/Wd+CURgOIVeVlPBr6Ro9+SthuHfb8Z+GQ5GFiG?= =?us-ascii?Q?UVCOkxX7t2ZyylVkuQUv5W/YQcENvKih/24Gvntytc5L97l/Sq+9W3pMhwoo?= =?us-ascii?Q?iKg5lsglTA4bsbEDKeufmB39UTxzRlUBMgo9fE3caj5bYxh7vvV9Sv66Q+KX?= =?us-ascii?Q?8rVUfDlG9FH+ssg+XY9oPVQcSslhqKfQYQVKCCIBOMOpXAQg4bjk83SDEzHa?= =?us-ascii?Q?GySv57H7peogwSEAGI7t81voBhcDtFyhf86aO770pSRyxMHybBAbsMVxocyk?= =?us-ascii?Q?Y1dD4MYCxhZk2N/6d2txfKyr9aTOvffN/GFY461B+52O1tg6z3J65upQioy9?= =?us-ascii?Q?PcQ=3D=3D?=
X-MS-Exchange-SenderADCheck: 1
X-Microsoft-Antispam-Message-Info: ir/Jc4JLxFi2SZ6Q1tYHXPCau/DLFnRC1eQ75pnJklwRkx2gPPrNp7kbunXAEgInLKzPN3HQmKCukvtDURapeCxvfjFqyoVuPHhi215mRQKJosWkKId56xZzP47OAtXTymT26AuZqR5+MAEuZ0h7HbFAsvks9BU+GDHB0hs1F9QKM7raCorv9KAw/mZp8AgWbDlFpKd50htU8gVRrHugtrGivh0ZxUrb2b8+3N8a+iNcww1Ds099j93OrT/O51nzGPiO6DxHFLaN7xkvmBC7e4eFp9lhrCqDa47T/d7pS35lLTkSdtKKzRZEpFhpHAdV5CSOeVcqBTSNlz/Mz4pHQdRIIjvpLJc17r48ffQEXD2eYUYbRWGbvtryR9vx81q7ZfQjAClW3kLk96Lsa46zYpfPZK2KpA5mFkXVpiGqMQw=
X-OriginatorOrg: mit.edu
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 08 Mar 2019 22:50:52.1170 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 09b17c5b-1dba-40b0-1a18-08d6a4188471
X-MS-Exchange-CrossTenant-Id: 64afd9ba-0ecf-4acf-bc36-935f6235ba8b
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=64afd9ba-0ecf-4acf-bc36-935f6235ba8b; Ip=[18.9.28.11];  Helo=[outgoing.mit.edu]
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR0101MB3077
Archived-At: 
Subject: Re: [payload] Benjamin Kaduk's Discuss on draft-ietf-payload-flexible-fec-scheme-17: (with DISCUSS and COMMENT)
X-BeenThere: payload@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Audio/Video Transport Payloads working group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 08 Mar 2019 22:50:58 -0000

On Tue, Mar 05, 2019 at 05:08:43PM +0000, Giridhar Mandyam wrote:
> Looks like my response got cut off.  Let me try again.
> 
> Thanks Benjamin.  Apologies for the late reply, but we (the editors) were confirming the best response to your follow-up questions.

And my apologies as well for the late reply here.

The published -18 addresses my DISCUSS-level concerns, so I've changed my
ballot to No Objection.

I just have a couple more thoughts, inline.

> > Maybe my question was not phrased well.  IIUC, the repair packets can only cover real media source streams that are part of the same RTP session.
> So in order for both audio and video to be available in the same RTP session as potential input to asingle repair packet stream, the audio and video would need to be together in the same RTP session; presumably that would involve getting demux'd based on payload type or SSRC, which is what I'm reading 3550 as saying to not do.  Am I just misunderstanding that the repair inputs must be part of the same RTP session?
> 
> In my interpretation, the issue revolves around what "demultiplexing" means in this context.  I do not believe it was meant to contemplate the recovery of packets from a repair stream, which involves more than just "demultiplexing" of audio and video payloads.  I don't believe Sec. 5.2 of RFC 3550 really applies.

Magnus also followed up here.  I wasn't worried about the direct behavior
specified in this document, but rather that a scenario we were describing
as an example usage was describing something that RFC 3550 says to not do.
Fortunately, that guidance from RFC 3550 has been rescinded, so my initial
guess of "3550 was overly cautious and we don't worry about that anymore"
was correct.

> > >       Payload Type: The (dynamic) payload type for the FEC repair packets is determined through out-of-band means.  [...]
> > >      Is "(e.g., SDP)" applicable here?
> 
> Sorry I missed this in my original response.  Yes, it does make sense and I have added it.
> 
> >>> Any reason not to include "retransmit" and "fixed block" mnemonics for the 'R' and 'F' bits? 
> >> Can you explain further?  The R/F definitions already include mention of retransmission and fixed FEC L/D.
> > I was thinking that the first sentence could say '(R and F bits, for "retransmit" and "fixed block")' to (in effect) "name" the bits right away.
> 
> Proposed text:
> 
> 4.2.2.  FEC Header of FEC Repair Packets
> 
>    The format of the FEC header has 3 variants, depending on the values
>    in the first 2 bits (R and F bits) as shown in Figure 10.  Note that
>    R and F stand for "retransmit" and "fixed block", respectively.
> 
> > >> Please include a note here that several fields (e.g., P, PT, etc.)  
> > >> in the FEC header are not meant to be interpreted directly but are 
> > >> instead actual FEC parity data akin to the following "payload". 
> > >> (Absent such an indication, the reader could see that these fields 
> > >> are "used to determine" values when they appear to contain values 
> > >> directly, and get confused.)
> > > >I would suggest adding a forward-reference to Section 6 since that describes how the Repair Payload is calculated.
> >> I am sorry.  I do not understand what is meant by "used to determine" values.  Can you explain?
> >I was trying to consolidate remarks about 4.2.2, 4.2.2.1 and 4.2.2.2 into a single comment, but it came across badly; sorry for the confusion.  The last bullet point of Section 4.2.2 notes that "The P, X, CC, M and PT recovery fields are used to determine the corresponding fields of the recovered packets". Similarly, Figures 12 and 13 both have fields named for "PT recovery", "length recovery", etc., with corresponding descriptions in the main text like "the length recovery (16 bits) field is used to determine the length of the recovered packets" -- these are the "used to determine" text to which I refer.  So my concrete suggestion is to add a reference to Section 6.3.2 at the end of that final bullet in Section 4.2.2.  I'd consider adding it to the field descriptions in 4.2.2.1 as well, but that might be overkill, so use your judgement.
> 
> Forward reference is added.  Thanks.
> 
> > >> Should implementations set bounds on L and D that are smaller than the maximum encodable value (255)?
> > > Yes.  This is assumed.
> >Perhaps it's best to state it explicitly rather than leaving an implicit assumption.
> 
> > >> If L=0, D=0, use the optional payload format parameters for L and D.  What is the behavior when those payload format parameters were not provided?
> > >Optional payload format parameters may be provided in SDP (see Sec. 5.1).
> >Right.  But suppose they weren't, and yet the L=0,D=0 packet shows up on the wire.  This is clearly an error condition; what's the error handling?
> 
> Proposed text immediately following Fig. 14:
> 
>    Given the 8-bit limit on L and D (as depicted in Figure 13), the
>    maximum value of either parameter is 255.  The "optional payload
>    format parameters" (Figure 14) to be used when L=0 and D=0 can be
>    determined through out-of-band signaling (see Section 5).  If L=0 and
>    D=0 and cannot be determined through out-of-band signaling, then the

nit: maybe "If L=0 and D=0 in a packet and the intended values cannot be
determined [...]"

>    repair packet MUST be ignored by the receiver.  In addition when L=1
>    and D=0, the repair packet becomes a retransmission of a
>    corresponding source packet.
> 
> > >> The L=1 case seems to imply that some full packet retransmission will be used; is it worth calling that out as a consequence of such a parameter choice?
> >> I am not sure that I understand this statement.  L=1 does not imply anything about the value of D.
> >I agree with your statement.  But, we seem to allow for L to be 1, and in particular for L=1,D=0 (also L=1,D=1).  For those combinations of L and D, the "Row FEC" case will in fact be packet retransmission, as a degenerate case.  I'm proposing that either this oddity is mentioned explicitly (e.g., "note that when L=1, the Row FEC packets will just be retransmission"), or disallowed by the numerical constraints.  Though now that I know better how the multi-SSRC case is handled (per Magnus's comments and my reply thereto), I guess you could use L=1 as part of a multi-SSRC repair and it would not be equivalent to retransmission.  So the situation is more complicated than I first thought.
> >Regardless, since the conditions here do allow L=1 as a possibility, I suggest some additional discussion in the text about how it's a bit strange and probably not expected to be used.
> 
> As you mentioned above for bundled protection, individual L/D combinations can be declared for each SSRC (such as L=1,D=0) but the overall repair packet may in fact not be a retransmission of any individual packet.  An example could be an audio/video session where very few audio packets (as few as one) are bundled with several video packets in the generation of the repair packet.  In such a case, it might be perfectly valid to set L=1, D=0 for the audio packet.   So I am not sure about what is best approach to the additional discussion.  Did you have a concrete suggestion?

I think that there are too many possibilities for how source packets can be
combined into the recovery packet for it to make sense to add any text
along these lines -- the case where the repair packet is effectively
retransmission is just a small part of the set of possibilities, and not
one that is especially important or common, so it does not need to get
mentioned specially.  Leaving the text as-is should be fine.

> >> > What is the interaction between rate, repair-window, and the L and D values?  That is, if we set L and D to be large, and rate to be small, can we end up claiming a repair window that is too small to accumulate the necessary L*D source packets and compute recovery packets?
> >> Yes, it is possible.  We expect that specific uses of FLEX FEC will bound the appropriate values for repair window, L and D.  It is difficult to establish these bounds in this specification, however, since the applications that are currently making use of FLEX FEC are varied (e.g. WebRTC, 3GPP MTSI).  We expect these specification to provide concrete guidance on the expected repair windows, L and D, based on the target application.
> >Please do not rely on unstated expectations for the behavior of consumers of this mechanism!  I strongly suggest to provide some indication, even a vague and incomplete one, that there are to be interrelations and implementation restrictions on these parameters.
> 
> Proposed additional section:
> 
> 
> 1.1.7.  Repair Window Considerations
> 
>    The value for the repair window duration depends on the L and D
>    values and cannot be chosen arbitrarily.  More specifically, L and D
>    values determine the lower limit for the repair window duration.  The
>    upper limit of the repair window duration does not depend on the L
>    and D values.
> 
> Note that a discussion of rate is difficult (in my opinion) without making assumptions about the source SSRC's.  For the above section, however, I can add a sentence such as "The rate of the source streams should also be considered, as the repair window duration should ideally span several packetization intervals in order to leverage the error correction capabilities of the parity code."  

I think that would be helpful to add.

> >> > Section 5.2.1
> >>>    o  The value for the repair-window parameter depends on the L and D values and cannot be chosen arbitrarily.  More specifically, L and D values determine the lower limit for the repair-window size. The upper limit of the repair-window size does not depend on the L and D values.
> >>>Per my above remark, this consideration seems generally applicable and not limited to SDP Offer/Answer.
> >> This is also covered in Sec. 1.1, which provides the general guidance.
> >An inline note that the repair window "is defined as the time that spans a FEC block", I see now.  But this is still in fairly abstract terms; I would have expected to see the note I quoted in my ballot to appear in a top-level Section 5 entry, and not in the subsection specific to SDP O/A.
> 
> >>>    o  Any unknown option in the offer MUST be ignored and deleted from the answer.  If FEC is not desired by the receiver, it can be deleted from the answer.
> >>> This sounds like it is restating an existing normative requirement  (in which case a reference and descriptive, non-normative, text seems appropriate).
> >> This requirement is specific to SDP O/A. Can you explain further as to why you think there is a different normative requirement?
> >Ali got what I intended, though I was hoping for a reference to the relevant SDP RFC as well as the s/MUST/must/.
> 
> Proposed modifications:
> 
>    o  The value for the repair-window parameter depends on the L and D
>       values.  Based on the values of L and D, a lower bound on the
>       repair-window can be inferred (see Section 1.1.7).
> 
>    o  Although combinations with the same L and D values but with
>       different repair-window sizes produce the same FEC data, such
>       combinations are still considered different offers.  The size of
>       the repair-window is related to the maximum delay between the
>       transmission of a source packet and the associated repair packet.
>       This directly impacts the buffering requirement on the receiver
>       side and the receiver must consider this when choosing an offer.
> 
>    o  Any unknown option in the offer must be ignored and deleted from
>       the answer (see Section 6 of [RFC3264]).  If FEC is not desired by
>       the receiver, it can be deleted from the answer.
> 
> Sec. 6.2:
> > To be clear, this is an editorial matter and you are free to ignore me, but my suggested wording is "The first 16 bits of the RTP header (16 bits), though the first two (version) bits will be ignored by the recovery procedure".
> 
> Proposed text is added.
> 
> > s/compute the FEC bit string from/extract the FEC bit string as/
> 
> Proposed text is added.
> 
> >>> I don't see how this matches up with the bit string construction in  Section 6.2.
> >> As per Sec. 6.2,  "The rest of the FEC bit string, which contains everything after ...
> >In particular I'm confused about the order between length recovery and TS recovery.  In the FEC header (for non-retransmissions), length recovery appears before TS recovery.  In Section 6.2, as we extract things from the FEC bit string, we write out the length recovery value into the FEC header, and then (the next bits from the FEC bit string are) the TS recovery value.
> >But here we take the TS field and then the length field from the recovery bit string, which is in the other order.  Am I missing some step that causes the order that these fields appear in the bit stream to change?
> 
> Agreed.  The proposed change that seems to fix this  in Sec. 6.3.2 is:
> 
>    11.  Set the SN field in the new packet to SEQNUM.
> 
>    12.  Take the next 16 bits of the recovered bit string and set the
>         new variable Y to whatever unsigned integer this represents
>         (assuming network order).  Convert Y to host order.  Y
>         represents the length of the new packet in bytes minus 12 (for
>         the fixed RTP header), i.e., the sum of the lengths of all the
>         following if present: the CSRC list, header extension, RTP
>         payload and RTP padding.
> 
>    13.  Set the TS field in the new packet to the next 32 bits in the
>         recovered bit string.
> 
>    14.  Set the SSRC of the new packet to the SSRC of the missing source
>         RTP stream.

Thank you for checking this.  I was really worried that I was just missing
a step in the procedure, so it's good to hear that I was correct to be
confused.

> >> "Given that FLEX FEC enables the protection of multiple source streams, there exists the possibility that multiple source buffers may be created that may not be used.  An attacker could leverage unused source buffers to as a means of occupying memory in a FLEX FEC endpoint.  ***In addition, an attack against the FEC parameters themselves (e.g. repair window, D or L values) can result in a receiver having to allocate source buffer space that may also lead to excessive consumption of resources.***  Moreover the application source data may not be perfectly matched with FLEX FEC source partitioning.  If this is the case, there is a possibility for unprotected source data if, for instance, the FLEX FEC implementation discards data that does not fit perfectly into its source processing requirements. " 
> 
> >That's an improvement, thanks.  I don't think it covers my penultimate paragraph about a network attacker being able to force bit flips in the recovered packet length field, though, and I do think it's worth documenting that as a risk (when integrity protection is not used).
> 
>   Given that FLEX FEC enables the protection of multiple source
>    streams, there exists the possibility that multiple source buffers
>    may be created that may not be used.  An attacker could leverage
>    unused source buffers to as a means of occupying memory in a FLEX FEC
>    endpoint.  In addition, an attack against the FEC parameters
>    themselves (e.g. repair window, D or L values) can result in a
>    receiver having to allocate source buffer space that may also lead to
>    excessive consumption of resources.  ***Similarly, a network attacker
>    could modify the recovery fields corresponding to packet lengths
>    (assuming there are no message integrity mechanisms) which in turn
>    could force unnecessarily large memory allocations at the receiver.***
>    Moreover the application source data may not be perfectly matched
>    with FLEX FEC source partitioning.  If this is the case, there is a
>    possibility for unprotected source data if, for instance, the FLEX
>    FEC implementation discards data that does not fit perfectly into its
>    source processing requirements.

Thanks, that's exactly what I was looking for.

> >I would strongly suggest adding some text at the end of or after the first pargaraph of section 4.2.2.2, to the effect of:
> 
> >  The values of L and D for a given block of recovery data will 
> > correspond to
>   the type of recovery in use for that block of data.  In particular, for 2-D
>   repair, the (L,D) values will not be constant across all packets for a
>   given SSRC being repaired.  Similarly, the L and D values can differ across
>   different blocks of repair data (repairing different SSRCs) in a single
>   packet.
> 
> Proposed text has been added.  Thanks.
> 
> >Regardless, I am still not 100% clear on the layout of the repair payload for the multi-SSRC case.  E.g., in Figure 13, we see that there are multiple SN base/L/D entries before the payload, which is a single consolidated payload that (presumably) covers all the recovery SSRCs.
> Your description above makes it sound like each SN base/L/D indicates a set of packets, and the payload is the XOR of all of those sets together (padded if necessary).  That is, one could perhaps imagine conceptually doing this in two steps: (1) XOR together the packets indicated by the respective SN base/L/D for each SSRC, and then (2) XOR those results together to combine the N SSRC recovery blocks into a single repair payload.  Did I get it right this time?
> 
> You can do it as you have described.  It is not strictly required to do it that way.  The source packets could be arranged in such a way that the XOR operation can be performed in one step, rather than the two you describe.  Any method is fine as long as the desired parity is created - row-wise, column-wise, or flex mask.

Understood.  I was breaking the procedure into two steps in my head so that
it was easier to understand (or describe), but of course they do not need
to be separate steps in an actual implementation.

Thank you again for the discussion and updates!

-Benjamin

> Note that we have also modified sec. 4.2.1 as follows to better describe the repair RTP header:
> 
> CSRC Count (CC) 4 bits, and CSRC List (CSRC_i) 32 bits each:
> Source packets can have an optional CSRC list and count, which can
> be recovered. FEC repair packets MUST use the CSRC list and count
> to specify the SSRC(s) of the source RTP stream(s) protected by
> this FEC repair packet.
> 
> 


From nobody Thu Mar 21 01:41:49 2019
Return-Path: 
X-Original-To: payload@ietf.org
Delivered-To: payload@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8735C130E8B; Thu, 21 Mar 2019 01:41:40 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: The IESG 
To: "IETF-Announce" 
X-Test-IDTracker: no
X-IETF-IDTracker: 6.94.1
Auto-Submitted: auto-generated
Precedence: bulk
Cc: ben@nostrum.com, The IESG , payload-chairs@ietf.org, payload@ietf.org, roni.even@mail01.huawei.com, Roni Even , draft-ietf-payload-flexible-fec-scheme@ietf.org, rfc-editor@rfc-editor.org
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Message-ID: <155315770054.9919.5577297727640600792.idtracker@ietfa.amsl.com>
Date: Thu, 21 Mar 2019 01:41:40 -0700
Archived-At: 
Subject: [payload] Protocol Action: 'RTP Payload Format for Flexible Forward Error Correction (FEC)' to Proposed Standard (draft-ietf-payload-flexible-fec-scheme-18.txt)
X-BeenThere: payload@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Audio/Video Transport Payloads working group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 21 Mar 2019 08:41:41 -0000

The IESG has approved the following document:
- 'RTP Payload Format for Flexible Forward Error Correction (FEC)'
  (draft-ietf-payload-flexible-fec-scheme-18.txt) as Proposed Standard

This document is the product of the Audio/Video Transport Payloads Working
Group.

The IESG contact persons are Adam Roach, Alexey Melnikov and Ben Campbell.

A URL of this Internet Draft is:
https://datatracker.ietf.org/doc/draft-ietf-payload-flexible-fec-scheme/




Technical Summary:

This document defines new RTP payload formats for the Forward Error Correction (FEC) packets that are generated by the non-interleaved  and interleaved parity codes from source media encapsulated in RTP.   These parity codes are systematic codes, where a number of FEC repair packets are generated from a set of source packets from one or more source RTP streams.  These FEC repair packets are sent in a redundancy RTP stream separate from the source RTP stream(s) that  carries the source packets.  RTP source packets that were lost in   transmission can be reconstructed using the source and repair packets that were received.  The non-interleaved and interleaved parity codes   which are defined in this specification offer a good protection against random and bursty packet losses, respectively, at a cost of decent complexity. 


Working Group Summary:

The document was discussed in the meetings, and on the mailing list. The open issues were addressed and there are no open issues; there was consensus on the content of the document.

Document Quality:

The payload was developed by members from different vendors and is part of the RTCWEB deliveries. Magnus Westerlund and Steve Botzko did a thorough review of the document.
A request for a media type review was sent to ietf-types and media-types mailing lists.

Personnel:

Roni Even is the Document Shepherd.
The responsible AD is Ben Campbell.


From nobody Thu Mar 21 08:39:47 2019
Return-Path: 
X-Original-To: payload@ietfa.amsl.com
Delivered-To: payload@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81FA41312CF; Thu, 21 Mar 2019 08:39:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level: 
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PlkyfetDOWks; Thu, 21 Mar 2019 08:39:43 -0700 (PDT)
Received: from mail-vs1-xe33.google.com (mail-vs1-xe33.google.com [IPv6:2607:f8b0:4864:20::e33]) (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 727241312F9; Thu, 21 Mar 2019 08:39:40 -0700 (PDT)
Received: by mail-vs1-xe33.google.com with SMTP id z18so3922569vso.7; Thu, 21 Mar 2019 08:39:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=CDkw+/we87BSD2avNI/cbEoaA+IeUgCv6X4eA9z6FlY=; b=jZdhKBftv0We/MxT8mB7eAZTOwpeB5hHaHQp4lkcrNNOIUxYDnILLh4BBFPqdoWcV2 BIyABI6+pFHbop9zqtBpj0fD4MI+wqX61op0SB0AoD3H/3FfG2Hn4rKDCp/0BV75OeVU 0KTNcMyb8Lc6Kl63wnuh4gmy/lYEs6+wSM5HS18uL9ZgL4IevHh0pH71XkOWZgC+VFW2 wFFmqjpt9GlZE+5jmkSIfaHKlZCVeDH/RT2h9UHG8vdsMSYEZHrNREN8xvYQ23R64zOG 8zOmO58U8FalinsA/bbUOfp0XDIhuuSmOHRGTQNFZwjsISRlLK65F2mpt1xWZbvGsxog UVRQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=CDkw+/we87BSD2avNI/cbEoaA+IeUgCv6X4eA9z6FlY=; b=q6plOFNyaqx/FqeVMgwgYMdjLa/K0j5miyOFSrHRFHd6vAF/MGHABe/2jd2AR5vrpl cw8rnJKOt1tjYURDBX3an/oTQKrfLrBxUZKwBLEO9pDtRyvMS4XCnQoCQ2L6Ig4dE8sS cMZUh6HgzcgWZXWl+bgvyLAp292zzvfxIcgZhEka6X0IambYAQIpNUqdepvATc3AITbP uJ5yXcXOyZpgTFNLk9xj3gpfPn5cAND9Ru264OVCoIRxCCq/Bt9StpUfbhFAk88dGXCe FHxppbB9+PGS/Po2TXOoTzVI1X5aGYwS2fbvLtD2u6IqU5C4S1Abc2Sdi6aNK2h8lmLn MISw==
X-Gm-Message-State: APjAAAU2YQTPkiTvnB0X4w1CMvskKV8zsfw8oV4Y0yrDNcSwqzZUSfmD aS4nqsRN1Hn2iB8ELG8q4UC/5onBAVCdSar1vcaGzw==
X-Google-Smtp-Source: APXvYqzQyU6pZCxVX9qPvaVS4mgEVBjRW8aA1D0uHMmqZNs40mliaKzHVqKYu92dTWoVJUE8pOFfG7ULtQUVjlTUzZ4=
X-Received: by 2002:a67:f41a:: with SMTP id p26mr2438938vsn.140.1553182778805;  Thu, 21 Mar 2019 08:39:38 -0700 (PDT)
MIME-Version: 1.0
References: <155315770054.9919.5577297727640600792.idtracker@ietfa.amsl.com>
In-Reply-To: <155315770054.9919.5577297727640600792.idtracker@ietfa.amsl.com>
From: Bernard Aboba 
Date: Thu, 21 Mar 2019 11:39:27 -0400
Message-ID: 
To: payload@ietf.org
Cc: roni.even@mail01.huawei.com, The IESG ,  draft-ietf-payload-flexible-fec-scheme@ietf.org
Content-Type: multipart/alternative; boundary="000000000000cd517005849c8b17"
Archived-At: 
Subject: Re: [payload] Protocol Action: 'RTP Payload Format for Flexible Forward Error Correction (FEC)' to Proposed Standard (draft-ietf-payload-flexible-fec-scheme-18.txt)
X-BeenThere: payload@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Audio/Video Transport Payloads working group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 21 Mar 2019 15:39:45 -0000

--000000000000cd517005849c8b17
Content-Type: text/plain; charset="UTF-8"

This is broken.

During review, serious issues were found with this document, and we were
working through the required changes with one of the authors (Varun).

Just because the editor decided to ignore the problems doesn't mean they
don't need to be fixed.



On Thu, Mar 21, 2019 at 4:42 AM The IESG  wrote:

> The IESG has approved the following document:
> - 'RTP Payload Format for Flexible Forward Error Correction (FEC)'
>   (draft-ietf-payload-flexible-fec-scheme-18.txt) as Proposed Standard
>
> This document is the product of the Audio/Video Transport Payloads Working
> Group.
>
> The IESG contact persons are Adam Roach, Alexey Melnikov and Ben Campbell.
>
> A URL of this Internet Draft is:
> https://datatracker.ietf.org/doc/draft-ietf-payload-flexible-fec-scheme/
>
>
>
>
> Technical Summary:
>
> This document defines new RTP payload formats for the Forward Error
> Correction (FEC) packets that are generated by the non-interleaved  and
> interleaved parity codes from source media encapsulated in RTP.   These
> parity codes are systematic codes, where a number of FEC repair packets are
> generated from a set of source packets from one or more source RTP
> streams.  These FEC repair packets are sent in a redundancy RTP stream
> separate from the source RTP stream(s) that  carries the source packets.
> RTP source packets that were lost in   transmission can be reconstructed
> using the source and repair packets that were received.  The
> non-interleaved and interleaved parity codes   which are defined in this
> specification offer a good protection against random and bursty packet
> losses, respectively, at a cost of decent complexity.
>
>
> Working Group Summary:
>
> The document was discussed in the meetings, and on the mailing list. The
> open issues were addressed and there are no open issues; there was
> consensus on the content of the document.
>
> Document Quality:
>
> The payload was developed by members from different vendors and is part of
> the RTCWEB deliveries. Magnus Westerlund and Steve Botzko did a thorough
> review of the document.
> A request for a media type review was sent to ietf-types and media-types
> mailing lists.
>
> Personnel:
>
> Roni Even is the Document Shepherd.
> The responsible AD is Ben Campbell.
>
> _______________________________________________
> payload mailing list
> payload@ietf.org
> https://www.ietf.org/mailman/listinfo/payload
>

--000000000000cd517005849c8b17
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


This is broken.

During review, serious =
issues were found with this document, and we were working through the requi=
red changes with one of the authors (Varun).=C2=A0

Just because the editor decided to ignore the problems doesn't mean th=
ey don't need to be fixed.=C2=A0



On =
Thu, Mar 21, 2019 at 4:42 AM The IESG <iesg-secretary@ietf.org> wrote:
The IESG has approved the following docume=
nt:

- 'RTP Payload Format for Flexible Forward Error Correction (FEC)'<=
br>
=C2=A0 (draft-ietf-payload-flexible-fec-scheme-18.txt) as Proposed Standard=




This document is the product of the Audio/Video Transport Payloads Working<=
br>
Group.



The IESG contact persons are Adam Roach, Alexey Melnikov and Ben Campbell.<=
br>


A URL of this Internet Draft is:

https://datatracker.ietf.org=
/doc/draft-ietf-payload-flexible-fec-scheme/









Technical Summary:



This document defines new RTP payload formats for the Forward Error Correct=
ion (FEC) packets that are generated by the non-interleaved=C2=A0 and inter=
leaved parity codes from source media encapsulated in RTP.=C2=A0 =C2=A0Thes=
e parity codes are systematic codes, where a number of FEC repair packets a=
re generated from a set of source packets from one or more source RTP strea=
ms.=C2=A0 These FEC repair packets are sent in a redundancy RTP stream sepa=
rate from the source RTP stream(s) that=C2=A0 carries the source packets.=
=C2=A0 RTP source packets that were lost in=C2=A0 =C2=A0transmission can be=
 reconstructed using the source and repair packets that were received.=C2=
=A0 The non-interleaved and interleaved parity codes=C2=A0 =C2=A0which are =
defined in this specification offer a good protection against random and bu=
rsty packet losses, respectively, at a cost of decent complexity. 





Working Group Summary:



The document was discussed in the meetings, and on the mailing list. The op=
en issues were addressed and there are no open issues; there was consensus =
on the content of the document.



Document Quality:



The payload was developed by members from different vendors and is part of =
the RTCWEB deliveries. Magnus Westerlund and Steve Botzko did a thorough re=
view of the document.

A request for a media type review was sent to ietf-types and media-types ma=
iling lists.



Personnel:



Roni Even is the Document Shepherd.

The responsible AD is Ben Campbell.



_______________________________________________

payload mailing list

payload@ietf.org<=
br>
https://www.ietf.org/mailman/listinfo/payload




--000000000000cd517005849c8b17--


From nobody Thu Mar 21 08:43:39 2019
Return-Path: 
X-Original-To: payload@ietfa.amsl.com
Delivered-To: payload@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B443130E94; Thu, 21 Mar 2019 08:43:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.299
X-Spam-Level: 
X-Spam-Status: No, score=-4.299 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=qti.qualcomm.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tVb-jEMa1Xbb; Thu, 21 Mar 2019 08:43:28 -0700 (PDT)
Received: from alexa-out-sd-02.qualcomm.com (alexa-out-sd-02.qualcomm.com [199.106.114.39]) (using TLSv1.2 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C5B8127988; Thu, 21 Mar 2019 08:43:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1553183008; x=1584719008; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=fx6HItuQe2apL6/EQjhMwAzb2MhrDCgChz/+oT07QiU=; b=sJBridIXxlgbFy/TxqnZXApe6NTZ8bnUkFdJ0zB0/EOeOzm5eKv2vZKl 0OPZzmyVhdo5ZGd7uD9M55QNu3QpYhJ3+hoo/eRQKU9GiDSfpV/akasA0 b7Wq6huIhmVNeiRjwuvKyjaOT0/aWGGbB/ZZxZVOX5AIvQzGTXlvaf3t0 Y=;
X-IronPort-AV: E=Sophos; i="5.60,253,1549958400"; d="scan'208,217"; a="38733694"
Received: from unknown (HELO ironmsg05-sd.qualcomm.com) ([10.53.140.145]) by alexa-out-sd-02.qualcomm.com with ESMTP; 21 Mar 2019 08:43:26 -0700
Received: from nasanexm01a.na.qualcomm.com ([10.85.0.81]) by ironmsg05-sd.qualcomm.com with ESMTP/TLS/AES256-SHA; 21 Mar 2019 08:43:26 -0700
Received: from NASANEXM01C.na.qualcomm.com (10.85.0.83) by nasanexm01a.na.qualcomm.com (10.85.0.81) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Thu, 21 Mar 2019 08:43:25 -0700
Received: from NASANEXM01C.na.qualcomm.com ([10.85.0.83]) by NASANEXM01C.na.qualcomm.com ([10.85.0.83]) with mapi id 15.00.1395.000; Thu, 21 Mar 2019 08:43:25 -0700
From: Giridhar Mandyam 
To: Bernard Aboba , "payload@ietf.org" 
CC: "roni.even@mail01.huawei.com" , The IESG , "draft-ietf-payload-flexible-fec-scheme@ietf.org" 
Thread-Topic: [payload] Protocol Action: 'RTP Payload Format for Flexible Forward Error Correction (FEC)' to Proposed Standard (draft-ietf-payload-flexible-fec-scheme-18.txt)
Thread-Index: AQHU38Hpy/Y+aT9PEkKCMAIq5eMfDaYWrl2A//+K7IA=
Date: Thu, 21 Mar 2019 15:43:24 +0000
Message-ID: <4654947926ae4a368fad694118cd9da3@NASANEXM01C.na.qualcomm.com>
References: <155315770054.9919.5577297727640600792.idtracker@ietfa.amsl.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.80.80.8]
Content-Type: multipart/alternative; boundary="_000_4654947926ae4a368fad694118cd9da3NASANEXM01Cnaqualcommco_"
MIME-Version: 1.0
Archived-At: 
Subject: Re: [payload] Protocol Action: 'RTP Payload Format for Flexible Forward Error Correction (FEC)' to Proposed Standard (draft-ietf-payload-flexible-fec-scheme-18.txt)
X-BeenThere: payload@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Audio/Video Transport Payloads working group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 21 Mar 2019 15:43:31 -0000

--_000_4654947926ae4a368fad694118cd9da3NASANEXM01Cnaqualcommco_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

PiBKdXN0IGJlY2F1c2UgdGhlIGVkaXRvciBkZWNpZGVkIHRvIGlnbm9yZSB0aGUgcHJvYmxlbXMg
ZG9lc24ndCBtZWFuIHRoZXkgZG9uJ3QgbmVlZCB0byBiZSBmaXhlZC4NCg0KSSBkaWQgbm90IGln
bm9yZSBhbnkg4oCccHJvYmxlbXPigJ0uICBJIGp1c3QgZGlkIG5vdCBzZWUgYW4gYWN0aW9uYWJs
ZSAgcHJvcG9zYWwgZm9yIHNwZWNpZmljIHRleHQgdGhhdCBjb3VsZCBiZSBhZGRlZCB0byB0aGUg
SS4tRC4gIElmIHlvdSBoYXZlIHN1Z2dlc3Rpb25zLCBwbGVhc2UgcHJvdmlkZSB0aGVtLg0KDQpJ
ZiB0aGUgZGlzY3Vzc2lvbiBpcyBnb2luZyB0byBiZSB0aGlzIGNvbnRlbnRpb3VzLCBJIGFtIGFm
cmFpZCB3ZSB3aWxsIGhhdmUgdHJvdWJsZSByZWFjaGluZyBhIGRlc2lyZWQgb3V0Y29tZSDigJMg
YSBjb21wbGV0ZSBhbmQgdXNhYmxlIHNwZWNpZmljYXRpb24uDQoNCi1HaXJpDQoNCkZyb206IEJl
cm5hcmQgQWJvYmEgPGJlcm5hcmQuYWJvYmFAZ21haWwuY29tPg0KU2VudDogVGh1cnNkYXksIE1h
cmNoIDIxLCAyMDE5IDg6MzkgQU0NClRvOiBwYXlsb2FkQGlldGYub3JnDQpDYzogcm9uaS5ldmVu
QG1haWwwMS5odWF3ZWkuY29tOyBUaGUgSUVTRyA8aWVzZ0BpZXRmLm9yZz47IGRyYWZ0LWlldGYt
cGF5bG9hZC1mbGV4aWJsZS1mZWMtc2NoZW1lQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW3BheWxv
YWRdIFByb3RvY29sIEFjdGlvbjogJ1JUUCBQYXlsb2FkIEZvcm1hdCBmb3IgRmxleGlibGUgRm9y
d2FyZCBFcnJvciBDb3JyZWN0aW9uIChGRUMpJyB0byBQcm9wb3NlZCBTdGFuZGFyZCAoZHJhZnQt
aWV0Zi1wYXlsb2FkLWZsZXhpYmxlLWZlYy1zY2hlbWUtMTgudHh0KQ0KDQoNCkNBVVRJT046IFRo
aXMgZW1haWwgb3JpZ2luYXRlZCBmcm9tIG91dHNpZGUgb2YgdGhlIG9yZ2FuaXphdGlvbi4NClRo
aXMgaXMgYnJva2VuLg0KDQpEdXJpbmcgcmV2aWV3LCBzZXJpb3VzIGlzc3VlcyB3ZXJlIGZvdW5k
IHdpdGggdGhpcyBkb2N1bWVudCwgYW5kIHdlIHdlcmUgd29ya2luZyB0aHJvdWdoIHRoZSByZXF1
aXJlZCBjaGFuZ2VzIHdpdGggb25lIG9mIHRoZSBhdXRob3JzIChWYXJ1bikuDQoNCkp1c3QgYmVj
YXVzZSB0aGUgZWRpdG9yIGRlY2lkZWQgdG8gaWdub3JlIHRoZSBwcm9ibGVtcyBkb2Vzbid0IG1l
YW4gdGhleSBkb24ndCBuZWVkIHRvIGJlIGZpeGVkLg0KDQoNCg0KT24gVGh1LCBNYXIgMjEsIDIw
MTkgYXQgNDo0MiBBTSBUaGUgSUVTRyA8aWVzZy1zZWNyZXRhcnlAaWV0Zi5vcmc8bWFpbHRvOmll
c2ctc2VjcmV0YXJ5QGlldGYub3JnPj4gd3JvdGU6DQpUaGUgSUVTRyBoYXMgYXBwcm92ZWQgdGhl
IGZvbGxvd2luZyBkb2N1bWVudDoNCi0gJ1JUUCBQYXlsb2FkIEZvcm1hdCBmb3IgRmxleGlibGUg
Rm9yd2FyZCBFcnJvciBDb3JyZWN0aW9uIChGRUMpJw0KICAoZHJhZnQtaWV0Zi1wYXlsb2FkLWZs
ZXhpYmxlLWZlYy1zY2hlbWUtMTgudHh0KSBhcyBQcm9wb3NlZCBTdGFuZGFyZA0KDQpUaGlzIGRv
Y3VtZW50IGlzIHRoZSBwcm9kdWN0IG9mIHRoZSBBdWRpby9WaWRlbyBUcmFuc3BvcnQgUGF5bG9h
ZHMgV29ya2luZw0KR3JvdXAuDQoNClRoZSBJRVNHIGNvbnRhY3QgcGVyc29ucyBhcmUgQWRhbSBS
b2FjaCwgQWxleGV5IE1lbG5pa292IGFuZCBCZW4gQ2FtcGJlbGwuDQoNCkEgVVJMIG9mIHRoaXMg
SW50ZXJuZXQgRHJhZnQgaXM6DQpodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFm
dC1pZXRmLXBheWxvYWQtZmxleGlibGUtZmVjLXNjaGVtZS8NCg0KDQoNCg0KVGVjaG5pY2FsIFN1
bW1hcnk6DQoNClRoaXMgZG9jdW1lbnQgZGVmaW5lcyBuZXcgUlRQIHBheWxvYWQgZm9ybWF0cyBm
b3IgdGhlIEZvcndhcmQgRXJyb3IgQ29ycmVjdGlvbiAoRkVDKSBwYWNrZXRzIHRoYXQgYXJlIGdl
bmVyYXRlZCBieSB0aGUgbm9uLWludGVybGVhdmVkICBhbmQgaW50ZXJsZWF2ZWQgcGFyaXR5IGNv
ZGVzIGZyb20gc291cmNlIG1lZGlhIGVuY2Fwc3VsYXRlZCBpbiBSVFAuICAgVGhlc2UgcGFyaXR5
IGNvZGVzIGFyZSBzeXN0ZW1hdGljIGNvZGVzLCB3aGVyZSBhIG51bWJlciBvZiBGRUMgcmVwYWly
IHBhY2tldHMgYXJlIGdlbmVyYXRlZCBmcm9tIGEgc2V0IG9mIHNvdXJjZSBwYWNrZXRzIGZyb20g
b25lIG9yIG1vcmUgc291cmNlIFJUUCBzdHJlYW1zLiAgVGhlc2UgRkVDIHJlcGFpciBwYWNrZXRz
IGFyZSBzZW50IGluIGEgcmVkdW5kYW5jeSBSVFAgc3RyZWFtIHNlcGFyYXRlIGZyb20gdGhlIHNv
dXJjZSBSVFAgc3RyZWFtKHMpIHRoYXQgIGNhcnJpZXMgdGhlIHNvdXJjZSBwYWNrZXRzLiAgUlRQ
IHNvdXJjZSBwYWNrZXRzIHRoYXQgd2VyZSBsb3N0IGluICAgdHJhbnNtaXNzaW9uIGNhbiBiZSBy
ZWNvbnN0cnVjdGVkIHVzaW5nIHRoZSBzb3VyY2UgYW5kIHJlcGFpciBwYWNrZXRzIHRoYXQgd2Vy
ZSByZWNlaXZlZC4gIFRoZSBub24taW50ZXJsZWF2ZWQgYW5kIGludGVybGVhdmVkIHBhcml0eSBj
b2RlcyAgIHdoaWNoIGFyZSBkZWZpbmVkIGluIHRoaXMgc3BlY2lmaWNhdGlvbiBvZmZlciBhIGdv
b2QgcHJvdGVjdGlvbiBhZ2FpbnN0IHJhbmRvbSBhbmQgYnVyc3R5IHBhY2tldCBsb3NzZXMsIHJl
c3BlY3RpdmVseSwgYXQgYSBjb3N0IG9mIGRlY2VudCBjb21wbGV4aXR5Lg0KDQoNCldvcmtpbmcg
R3JvdXAgU3VtbWFyeToNCg0KVGhlIGRvY3VtZW50IHdhcyBkaXNjdXNzZWQgaW4gdGhlIG1lZXRp
bmdzLCBhbmQgb24gdGhlIG1haWxpbmcgbGlzdC4gVGhlIG9wZW4gaXNzdWVzIHdlcmUgYWRkcmVz
c2VkIGFuZCB0aGVyZSBhcmUgbm8gb3BlbiBpc3N1ZXM7IHRoZXJlIHdhcyBjb25zZW5zdXMgb24g
dGhlIGNvbnRlbnQgb2YgdGhlIGRvY3VtZW50Lg0KDQpEb2N1bWVudCBRdWFsaXR5Og0KDQpUaGUg
cGF5bG9hZCB3YXMgZGV2ZWxvcGVkIGJ5IG1lbWJlcnMgZnJvbSBkaWZmZXJlbnQgdmVuZG9ycyBh
bmQgaXMgcGFydCBvZiB0aGUgUlRDV0VCIGRlbGl2ZXJpZXMuIE1hZ251cyBXZXN0ZXJsdW5kIGFu
ZCBTdGV2ZSBCb3R6a28gZGlkIGEgdGhvcm91Z2ggcmV2aWV3IG9mIHRoZSBkb2N1bWVudC4NCkEg
cmVxdWVzdCBmb3IgYSBtZWRpYSB0eXBlIHJldmlldyB3YXMgc2VudCB0byBpZXRmLXR5cGVzIGFu
ZCBtZWRpYS10eXBlcyBtYWlsaW5nIGxpc3RzLg0KDQpQZXJzb25uZWw6DQoNClJvbmkgRXZlbiBp
cyB0aGUgRG9jdW1lbnQgU2hlcGhlcmQuDQpUaGUgcmVzcG9uc2libGUgQUQgaXMgQmVuIENhbXBi
ZWxsLg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K
cGF5bG9hZCBtYWlsaW5nIGxpc3QNCnBheWxvYWRAaWV0Zi5vcmc8bWFpbHRvOnBheWxvYWRAaWV0
Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3BheWxvYWQNCg==

--_000_4654947926ae4a368fad694118cd9da3NASANEXM01Cnaqualcommco_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m
YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy
IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws
IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ
Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph
OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv
cjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1z
b0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJw
bGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25v
cm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28t
bWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90
dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZv
bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTIwDQoJe21z
by1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5z
LXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxl
LXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0K
QHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAx
LjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24x
O30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRz
IHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtp
ZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1h
cCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRp
Zl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVy
cGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4m
Z3Q7IEp1c3QgYmVjYXVzZSB0aGUgZWRpdG9yIGRlY2lkZWQgdG8gaWdub3JlIHRoZSBwcm9ibGVt
cyBkb2Vzbid0IG1lYW4gdGhleSBkb24ndCBuZWVkIHRvIGJlIGZpeGVkLiZuYnNwOzxvOnA+PC9v
OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj5JIGRpZCBub3QgaWdub3JlIGFueSDigJxwcm9ibGVtc+KAnS4mbmJz
cDsgSSBqdXN0IGRpZCBub3Qgc2VlIGFuIGFjdGlvbmFibGUgJm5ic3A7cHJvcG9zYWwgZm9yIHNw
ZWNpZmljIHRleHQgdGhhdCBjb3VsZCBiZSBhZGRlZCB0byB0aGUgSS4tRC4mbmJzcDsgSWYgeW91
IGhhdmUgc3VnZ2VzdGlvbnMsIHBsZWFzZSBwcm92aWRlIHRoZW0uPG86cD48L286cD48L3A+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPklmIHRoZSBkaXNjdXNzaW9uIGlzIGdvaW5nIHRvIGJlIHRoaXMgY29udGVudGlvdXMs
IEkgYW0gYWZyYWlkIHdlIHdpbGwgaGF2ZSB0cm91YmxlIHJlYWNoaW5nIGEgZGVzaXJlZCBvdXRj
b21lIOKAkyBhIGNvbXBsZXRlIGFuZCB1c2FibGUgc3BlY2lmaWNhdGlvbi48bzpwPjwvbzpwPjwv
cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+LUdpcmk8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv
OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+RnJvbTo8L2I+IEJl
cm5hcmQgQWJvYmEgJmx0O2Jlcm5hcmQuYWJvYmFAZ21haWwuY29tJmd0OyA8YnI+DQo8Yj5TZW50
OjwvYj4gVGh1cnNkYXksIE1hcmNoIDIxLCAyMDE5IDg6MzkgQU08YnI+DQo8Yj5Ubzo8L2I+IHBh
eWxvYWRAaWV0Zi5vcmc8YnI+DQo8Yj5DYzo8L2I+IHJvbmkuZXZlbkBtYWlsMDEuaHVhd2VpLmNv
bTsgVGhlIElFU0cgJmx0O2llc2dAaWV0Zi5vcmcmZ3Q7OyBkcmFmdC1pZXRmLXBheWxvYWQtZmxl
eGlibGUtZmVjLXNjaGVtZUBpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW3BheWxv
YWRdIFByb3RvY29sIEFjdGlvbjogJ1JUUCBQYXlsb2FkIEZvcm1hdCBmb3IgRmxleGlibGUgRm9y
d2FyZCBFcnJvciBDb3JyZWN0aW9uIChGRUMpJyB0byBQcm9wb3NlZCBTdGFuZGFyZCAoZHJhZnQt
aWV0Zi1wYXlsb2FkLWZsZXhpYmxlLWZlYy1zY2hlbWUtMTgudHh0KTxvOnA+PC9vOnA+PC9wPg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cD48c3Ryb25nPjxz
cGFuIHN0eWxlPSJmb250LXNpemU6OC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDss
c2Fucy1zZXJpZjtiYWNrZ3JvdW5kOiNGRkVCOUMiPkNBVVRJT048L3NwYW4+PC9zdHJvbmc+PHNw
YW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90Oyxz
YW5zLXNlcmlmO2JhY2tncm91bmQ6I0ZGRUI5QyI+OiBUaGlzIGVtYWlsIG9yaWdpbmF0ZWQgZnJv
bSBvdXRzaWRlIG9mIHRoZSBvcmdhbml6YXRpb24uPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoaXMgaXMgYnJva2VuLjxvOnA+PC9vOnA+PC9wPg0K
PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+
DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+RHVyaW5nIHJldmlldywgc2VyaW91cyBpc3N1
ZXMgd2VyZSBmb3VuZCB3aXRoIHRoaXMgZG9jdW1lbnQsIGFuZCB3ZSB3ZXJlIHdvcmtpbmcgdGhy
b3VnaCB0aGUgcmVxdWlyZWQgY2hhbmdlcyB3aXRoIG9uZSBvZiB0aGUgYXV0aG9ycyAoVmFydW4p
LiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj5KdXN0IGJlY2F1c2UgdGhlIGVkaXRvciBkZWNpZGVkIHRvIGlnbm9yZSB0aGUgcHJvYmxl
bXMgZG9lc24ndCBtZWFuIHRoZXkgZG9uJ3QgbmVlZCB0byBiZSBmaXhlZC4mbmJzcDs8bzpwPjwv
bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7
PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz
cDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m
bmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFRo
dSwgTWFyIDIxLCAyMDE5IGF0IDQ6NDIgQU0gVGhlIElFU0cgJmx0OzxhIGhyZWY9Im1haWx0bzpp
ZXNnLXNlY3JldGFyeUBpZXRmLm9yZyI+aWVzZy1zZWNyZXRhcnlAaWV0Zi5vcmc8L2E+Jmd0OyB3
cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpu
b25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2
LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPlRoZSBJRVNHIGhhcyBhcHByb3ZlZCB0aGUgZm9sbG93aW5nIGRvY3VtZW50Ojxicj4N
Ci0gJ1JUUCBQYXlsb2FkIEZvcm1hdCBmb3IgRmxleGlibGUgRm9yd2FyZCBFcnJvciBDb3JyZWN0
aW9uIChGRUMpJzxicj4NCiZuYnNwOyAoZHJhZnQtaWV0Zi1wYXlsb2FkLWZsZXhpYmxlLWZlYy1z
Y2hlbWUtMTgudHh0KSBhcyBQcm9wb3NlZCBTdGFuZGFyZDxicj4NCjxicj4NClRoaXMgZG9jdW1l
bnQgaXMgdGhlIHByb2R1Y3Qgb2YgdGhlIEF1ZGlvL1ZpZGVvIFRyYW5zcG9ydCBQYXlsb2FkcyBX
b3JraW5nPGJyPg0KR3JvdXAuPGJyPg0KPGJyPg0KVGhlIElFU0cgY29udGFjdCBwZXJzb25zIGFy
ZSBBZGFtIFJvYWNoLCBBbGV4ZXkgTWVsbmlrb3YgYW5kIEJlbiBDYW1wYmVsbC48YnI+DQo8YnI+
DQpBIFVSTCBvZiB0aGlzIEludGVybmV0IERyYWZ0IGlzOjxicj4NCjxhIGhyZWY9Imh0dHBzOi8v
ZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtcGF5bG9hZC1mbGV4aWJsZS1mZWMt
c2NoZW1lLyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9j
L2RyYWZ0LWlldGYtcGF5bG9hZC1mbGV4aWJsZS1mZWMtc2NoZW1lLzwvYT48YnI+DQo8YnI+DQo8
YnI+DQo8YnI+DQo8YnI+DQpUZWNobmljYWwgU3VtbWFyeTo8YnI+DQo8YnI+DQpUaGlzIGRvY3Vt
ZW50IGRlZmluZXMgbmV3IFJUUCBwYXlsb2FkIGZvcm1hdHMgZm9yIHRoZSBGb3J3YXJkIEVycm9y
IENvcnJlY3Rpb24gKEZFQykgcGFja2V0cyB0aGF0IGFyZSBnZW5lcmF0ZWQgYnkgdGhlIG5vbi1p
bnRlcmxlYXZlZCZuYnNwOyBhbmQgaW50ZXJsZWF2ZWQgcGFyaXR5IGNvZGVzIGZyb20gc291cmNl
IG1lZGlhIGVuY2Fwc3VsYXRlZCBpbiBSVFAuJm5ic3A7ICZuYnNwO1RoZXNlIHBhcml0eSBjb2Rl
cyBhcmUgc3lzdGVtYXRpYyBjb2Rlcywgd2hlcmUgYSBudW1iZXINCiBvZiBGRUMgcmVwYWlyIHBh
Y2tldHMgYXJlIGdlbmVyYXRlZCBmcm9tIGEgc2V0IG9mIHNvdXJjZSBwYWNrZXRzIGZyb20gb25l
IG9yIG1vcmUgc291cmNlIFJUUCBzdHJlYW1zLiZuYnNwOyBUaGVzZSBGRUMgcmVwYWlyIHBhY2tl
dHMgYXJlIHNlbnQgaW4gYSByZWR1bmRhbmN5IFJUUCBzdHJlYW0gc2VwYXJhdGUgZnJvbSB0aGUg
c291cmNlIFJUUCBzdHJlYW0ocykgdGhhdCZuYnNwOyBjYXJyaWVzIHRoZSBzb3VyY2UgcGFja2V0
cy4mbmJzcDsgUlRQIHNvdXJjZSBwYWNrZXRzDQogdGhhdCB3ZXJlIGxvc3QgaW4mbmJzcDsgJm5i
c3A7dHJhbnNtaXNzaW9uIGNhbiBiZSByZWNvbnN0cnVjdGVkIHVzaW5nIHRoZSBzb3VyY2UgYW5k
IHJlcGFpciBwYWNrZXRzIHRoYXQgd2VyZSByZWNlaXZlZC4mbmJzcDsgVGhlIG5vbi1pbnRlcmxl
YXZlZCBhbmQgaW50ZXJsZWF2ZWQgcGFyaXR5IGNvZGVzJm5ic3A7ICZuYnNwO3doaWNoIGFyZSBk
ZWZpbmVkIGluIHRoaXMgc3BlY2lmaWNhdGlvbiBvZmZlciBhIGdvb2QgcHJvdGVjdGlvbiBhZ2Fp
bnN0IHJhbmRvbSBhbmQgYnVyc3R5IHBhY2tldA0KIGxvc3NlcywgcmVzcGVjdGl2ZWx5LCBhdCBh
IGNvc3Qgb2YgZGVjZW50IGNvbXBsZXhpdHkuIDxicj4NCjxicj4NCjxicj4NCldvcmtpbmcgR3Jv
dXAgU3VtbWFyeTo8YnI+DQo8YnI+DQpUaGUgZG9jdW1lbnQgd2FzIGRpc2N1c3NlZCBpbiB0aGUg
bWVldGluZ3MsIGFuZCBvbiB0aGUgbWFpbGluZyBsaXN0LiBUaGUgb3BlbiBpc3N1ZXMgd2VyZSBh
ZGRyZXNzZWQgYW5kIHRoZXJlIGFyZSBubyBvcGVuIGlzc3VlczsgdGhlcmUgd2FzIGNvbnNlbnN1
cyBvbiB0aGUgY29udGVudCBvZiB0aGUgZG9jdW1lbnQuPGJyPg0KPGJyPg0KRG9jdW1lbnQgUXVh
bGl0eTo8YnI+DQo8YnI+DQpUaGUgcGF5bG9hZCB3YXMgZGV2ZWxvcGVkIGJ5IG1lbWJlcnMgZnJv
bSBkaWZmZXJlbnQgdmVuZG9ycyBhbmQgaXMgcGFydCBvZiB0aGUgUlRDV0VCIGRlbGl2ZXJpZXMu
IE1hZ251cyBXZXN0ZXJsdW5kIGFuZCBTdGV2ZSBCb3R6a28gZGlkIGEgdGhvcm91Z2ggcmV2aWV3
IG9mIHRoZSBkb2N1bWVudC48YnI+DQpBIHJlcXVlc3QgZm9yIGEgbWVkaWEgdHlwZSByZXZpZXcg
d2FzIHNlbnQgdG8gaWV0Zi10eXBlcyBhbmQgbWVkaWEtdHlwZXMgbWFpbGluZyBsaXN0cy48YnI+
DQo8YnI+DQpQZXJzb25uZWw6PGJyPg0KPGJyPg0KUm9uaSBFdmVuIGlzIHRoZSBEb2N1bWVudCBT
aGVwaGVyZC48YnI+DQpUaGUgcmVzcG9uc2libGUgQUQgaXMgQmVuIENhbXBiZWxsLjxicj4NCjxi
cj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0K
cGF5bG9hZCBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86cGF5bG9hZEBpZXRmLm9y
ZyIgdGFyZ2V0PSJfYmxhbmsiPnBheWxvYWRAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0
cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9wYXlsb2FkIiB0YXJnZXQ9Il9ibGFu
ayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9wYXlsb2FkPC9hPjxvOnA+
PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRt
bD4NCg==

--_000_4654947926ae4a368fad694118cd9da3NASANEXM01Cnaqualcommco_--


From nobody Thu Mar 21 08:45:48 2019
Return-Path: 
X-Original-To: payload@ietfa.amsl.com
Delivered-To: payload@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A8601312FF for ; Thu, 21 Mar 2019 08:45:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=callstats.io
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 u7tNKUPazTNW for ; Thu, 21 Mar 2019 08:45:41 -0700 (PDT)
Received: from mail-wr1-x42d.google.com (mail-wr1-x42d.google.com [IPv6:2a00:1450:4864:20::42d]) (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 54660131301 for ; Thu, 21 Mar 2019 08:45:41 -0700 (PDT)
Received: by mail-wr1-x42d.google.com with SMTP id w2so7106941wrt.11 for ; Thu, 21 Mar 2019 08:45:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=callstats.io; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :content-transfer-encoding; bh=2PBj2ZYHRQoEnQg2IfNy8XGxh7FWM3lgDarenAWaxLk=; b=APvLtH2O0HwU5IWNfWYxNdp/vrAp09/RSJxYH+iVqK5X9sxVLfdDAaIl47/FXMKSlL FXD7rizEXUJ1MeXEbIz++TknYqZkFIevTomlPFAPgAG0P/kr/doaSHIeNZaCdw5IydiD 5YH13/tY5TkYI8kWxveMcQtmQlxynkhBXjxy8=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:content-transfer-encoding; bh=2PBj2ZYHRQoEnQg2IfNy8XGxh7FWM3lgDarenAWaxLk=; b=XSV6wWKbne25if9pB2XpN5UTOIrakJl/bMu+ZHbJY+GRuV9eZR5Z71BRyxk9WSf09q 7uHJSFMx6J/VXSG7HkJ8IXZCAzY+wzoMU/cS0tzmYCcEb1qrpqSGMJ+pBAQnSMrsbK51 OEzUGKZt5zPn0OKFMLYgN0Cm9QYRSdINqKTXZBHdajgPEIUYhbBKlma+4G2rAXKjPW/z xAoiHeDtNTude+26RXw2Ff/4sLYO8vsP64qQjfQjQgE76hbpJjipg8kyEAsguSxZVcnE FDw/tpkTFzOyB0aXBoXsfSmXPB4Ss76mbkNKg5rhB2gp68G8wsg5Murhs6SQAS/ZKWW2 W1Xg==
X-Gm-Message-State: APjAAAX5iyPHSQJ3AnjuvWjdmWnz7vkTzl9fKvxc742172Ou+DlPZgTU kvNKjPLWSRjfo+7NltSCuwRYdkDHNoxkHEQ45I0Ztw==
X-Google-Smtp-Source: APXvYqxPNP7SJAhMtTHkeiTfX0J+fgSQIWYwJ+WiZwYhgADFA7aM7UQqmITvjnDJLVT8SeSzGkLViZvLeEh9SK+MmdU=
X-Received: by 2002:a5d:660c:: with SMTP id n12mr2985799wru.160.1553183139214;  Thu, 21 Mar 2019 08:45:39 -0700 (PDT)
MIME-Version: 1.0
References:    
In-Reply-To: 
From: Varun Singh 
Date: Thu, 21 Mar 2019 17:45:25 +0200
Message-ID: 
To: Bernard Aboba ,  "draft-ietf-payload-flexible-fec-scheme.authors@ietf.org" ,  "payload@ietf.org" 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: Re: [payload] SDP O/A -- L, D, ToP and Flexible mode
X-BeenThere: payload@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Audio/Video Transport Payloads working group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 21 Mar 2019 15:45:46 -0000

Hi folks,

The draft was reviewed and approved by the IESG, however, we have not
incorporated the feedback/comments raised by Bernard. Feedback on this
is appreciated, because it  changes the O/A mechanism of FlexFEC.

Regards,
Varun

On Tue, Mar 5, 2019 at 10:42 PM Varun Singh  wrote:
>
> Hi,
>
> Forwarding my clarifications to Bernard=E2=80=99s review.
> Full email below.
>
> Feedback appreciated.
>
> Regards,
> Varun.
>
> ---------- Forwarded message ---------
> From: Varun Singh 
> Date: Tue, 12 Feb 2019 at 5.40
> Subject: Re: SDP O/A -- L, D, ToP and Flexible mode
> To: Bernard Aboba 
>
>
> Hi all,
>
> Thanks Bernard for the quick feedback. See my replies inline.
>
> On Mon, 11 Feb 2019 at 19.13, Bernard Aboba =
 wrote:
>>
>> Comments below.
>>
>> On Feb 11, 2019, at 2:45 PM, Varun Singh  wrote:
>>
>> Hi all,
>>
>> I  caught up on the mail discussion, initially, I did not run through al=
l the cases, but Bernard's follow up email, makes me question if we have to=
 be more specific.
>>
>> Everything in this email is scoped for the SDP.
>>
>> 0) IIRC the SDP for FlexFec was supposed to be declarative and not reall=
y a negotiation.
>>
>>
>> [BA] Is it only declaring in one direction - what to send, but not what =
it can receive? Or is there something implicit there?
>
>
> Yes. It=E2=80=99s only in one direction. The implicit assumption is that =
the endpoint can receive what it offers.
>
> I can think of an argument being made, where the Offers are what type of =
FEC protection/structure is willing to receive rather than send. However, t=
he negotiation model would be rather complex (and the ability to announce s=
everal capability modes)
>
>
>
>>
>>
>> - Offerer supports FlexFEC, but the Answerer does not implement it, the =
Answerer would either reject the offer or remove flexFEC from the answer.
>>
>>
>> Otherwise, if both support FlexFEC, the Answerer would just send its own=
 FlexFEC (L,D, ToP) configuration.
>>
>> I do not think negotiation makes a lot of sense:
>> For uni-directional media, offerer specifies L, D, ToP. Logically, the a=
nswerer cannot ask for higher values of L and D, or a different ToP. I thin=
k if the answerer disagrees in this case, it would just reject the offer or=
 remove flexFEC from the answer.
>>
>>
>> [BA] Agree that negotiation isn=E2=80=99t a good model - but the asymmet=
ry between Offerer and Answerer can create questions.
>>
>> What does an Offerer do if it receives an Answer with settings it does n=
ot support?  Is there a way for the Answerer to infer the set of settings a=
n Offerer supports so as to make this unlikely?
>
>
> I don=E2=80=99t think there are really options in this case.
>
> If the offerer wants to use the interleaved mode, I don=E2=80=99t see a l=
egitimate case for the answerer to try to figure out what other modes exist=
. In general I can=E2=80=99t see in what situation would negotiation help?
>
> Are you thinking of a situation where an offerer is not very opinionated =
at wants to describe that it=E2=80=99 instead lists a lot of L D ToP capabi=
lities that the answerer then picks from?
>
>>
>>
>> For bi-directional media, the networks might behave differently, and thu=
s, the endpoints may want to choose asymmetrical L and Ds. Which would mean=
 that the Offerer and Answerer can have different L and D and O/A request a=
nd response is just telling the other party what their respective L and Ds =
will be?
>>
>>
>> [BA] Makes sense.
>>
>>
>> 1) The whole point of specifying L,D, and ToP (modes 0,1, and 2) in SDP =
was to have a rigid FEC transform structure. Agree or disagree?
>>
>>
>> [BA] Rigid structure makes sense if the goal is to maximize interop by s=
pecifying well known and required modes. But without required support for a=
 set of configurations it can increase the complexity of negotiation. I do =
not like the idea of having to offer multiple potential flexfec configurati=
ons, for example.
>>
>>
>> 2) ToP and L/D modes
>>
>> - If an endpoint uses ToP 1 (non-interleaved), it must provide the numbe=
r of columns (L)
>> - If an endpoint uses ToP 0 (interleaved), it must provide both L and D.=
 L to know how much to skip and D to know which packets will be present.
>> - If an endpoint uses ToP 2 (2 Dimensional), since all packets in L and =
D are protected, it must provide L and D.
>> - If an endpoint wants to use the flexible FEC mode it must not specify =
L, D, or ToP.
>> (skipping retx for this now)
>>
>> Agree on these rules above?
>>
>>
>> [BA] Yes.
>
>
> I skipped RTX before. So if I understand some of the confusion and now I=
=E2=80=99m not sure what ToP 3 really means.
>
> Do ToP modes 0, 1, and 2 implicitly mean no RTX?
>
> If so, why do we have this following ambiguity  (L, D, ToP are all missin=
g) means it is both Flexfec FEC and flexfec RTX?
>
>>
>>
>> I am assuming that L and D numbers in the SDP are exactly the ones that =
will be used in the protocol and the endpoints are not using the L and D va=
lues to mean anything between 0 to the specified value.
>>
>>
>> [BA] Is there an implicit indication of what the Offerer can deal with i=
n an Answer (e.g. L and D values less than those in the Offer are supported=
 in an Answer)?
>
>
> I think the implicit assumption is that all of  flex FEC spec is implemen=
ted.
>
> Offer can send and receive  X and answerer can send and receive Y.
>
> I can=E2=80=99t see why we would endorse a partial implementation?
>
>>
>>
>> 3) FlexFEC Retx and FlexFEC FEC
>>
>> - If an endpoint wants to use the flexible FEC and FlexFEC Retx it must =
not specify L, D, or ToP.
>>
>>
>> [BA] Makes sense - but what is required of a flexible mode receiver? Mus=
t it be able to decode anything a sender can send? If not, how does it tell=
 the other side that it received something it could not decode?
>>
>> - If an endpoint wants to use only the FlexFEC Retx it will set ToP to 3=
 and skip L and D modes.
>>
>> Is there a way to specify FlexFEC and FlexFEC Retx?
>
>
> Should there be explicit way to say in SDP
>
> + flexfec FEC only
> + flexfec RTX only
> + flexfec FEC and RTX, both?
>
>>
>> If the endpoints are using a declarative modes, I dont think there is an=
 issue here. There can be assymetry and if the other party does not like th=
e Offer it can reject it or remove flexFEC from the answer.
>>
>> 4) FLEX FEC Retx and 4588 Retx =3D)
>>
>> The offer contains
>> FLEXFEC RTX and FEC along with 4588 RTX, i.e., no L,D,ToP for FlexFEC an=
d 4588 retx
>>
>> The Answerer can remove the flexFEC line to indicate that it wants to us=
e 4588 Retx, but thus it cannot have any form of flexFEC.
>>
>> Without a re-offer, I dont think the endpoints can do anything better.
>>
>>
>> [BA] Can we interpret negotiation of 4588 RTX to mean =E2=80=9Cno flexfe=
c rtx, please=E2=80=9D?
>
>
>
> Going with the declarative model and restrictions of the SDP o/a semantic=
s (and I=E2=80=99m really suspicious about the validity of what I=E2=80=99m=
 suggesting below)
>
> Case 1: everyone is happy
> Offerer declares rfc4588 RTX and flexfex (with Flex RTX) meaning it has c=
omplete flexibility in sending and receiving.
>
> Answerer responds with rfc4588 RTX and flexfec (without RTX, I don=E2=80=
=99t think we have a way of doing that), with this the answerer is declarin=
g its restriction.
>
> Both parties in this case can figure out what needs to be done.
>
> Case 2: no RTX because no compatibility
>
> Offerer declares flexfec (with flex RTX), so no rfc4588 supported. Answer=
er can respond with flexfec (without RTX).
>
> In this case, while the offerer can send flex RTX the receiver won=E2=80=
=99t decode it (and answerer would anyway just discard these packets) So it=
 can just assume not to send it. The answerer assuming didn=E2=80=99t want =
to send or receiv RTX would not send flex RTX.
>
>
>>
>>
>>
>>
>>
>> --
>> Founder, CEO, callstats.io
>> http://www.callstats.io
>>
>> Interested in networking, media quality, and diagnostics.
>> We are hiring!: www.callstats.io/jobs/
>
> --
> Founder, CEO, callstats.io
> http://www.callstats.io
>
> Interested in networking, media quality, and diagnostics.
> We are hiring!: www.callstats.io/jobs/
> --
> Founder, CEO, callstats.io
> http://www.callstats.io
>
> Interested in networking, media quality, and diagnostics.
> We are hiring!: www.callstats.io/jobs/



--
Founder, CEO, callstats.io
http://www.callstats.io

Interested in networking, media quality, and diagnostics.
We are hiring!: www.callstats.io/jobs/


From nobody Thu Mar 21 11:33:22 2019
Return-Path: 
X-Original-To: payload@ietfa.amsl.com
Delivered-To: payload@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B01CF1315BA; Thu, 21 Mar 2019 11:33:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.678
X-Spam-Level: 
X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=nostrum.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 24udRFoHL8jK; Thu, 21 Mar 2019 11:33:03 -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 CC7CD1315A9; Thu, 21 Mar 2019 11:33:03 -0700 (PDT)
Received: from bens-macbook.lan (cpe-66-25-20-105.tx.res.rr.com [66.25.20.105]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id x2LIWxAP012424 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 21 Mar 2019 13:33:00 -0500 (CDT) (envelope-from ben@nostrum.com)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1553193182; bh=qBY3HeP7nCf9u4xGSe9Y7p3uO+PwO+ZLtrH6FzKdijo=; h=From:Subject:Date:In-Reply-To:Cc:To:References; b=rdHijarW5BW0af7FPdB6T2ei52ZTlukyeSr8Ua8vqnHYpKnKew0KywdB7I/szT9nH j94JUeLF5+c5UqSurQCdm9hg0SNaD632hT7/eXRBLHcoPjD6y0vgHIbdRQcxNWWexv sOcBpARMEmJvNJ+Rb60YWynDil2kqGr8TYiGQjVg=
X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-20-105.tx.res.rr.com [66.25.20.105] claimed to be bens-macbook.lan
From: Ben Campbell 
Message-Id: <2BBDBF81-05D9-4C75-BA2B-BE20527B0C61@nostrum.com>
Content-Type: multipart/signed; boundary="Apple-Mail=_91766CFD-BB01-4F28-818A-92249924A1B2"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\))
Date: Thu, 21 Mar 2019 13:32:53 -0500
In-Reply-To: 
Cc: payload@ietf.org, roni.even@mail01.huawei.com, The IESG , draft-ietf-payload-flexible-fec-scheme@ietf.org
To: Bernard Aboba 
References: <155315770054.9919.5577297727640600792.idtracker@ietfa.amsl.com> 
X-Mailer: Apple Mail (2.3445.102.3)
Archived-At: 
Subject: Re: [payload] Protocol Action: 'RTP Payload Format for Flexible Forward Error Correction (FEC)' to Proposed Standard (draft-ietf-payload-flexible-fec-scheme-18.txt)
X-BeenThere: payload@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Audio/Video Transport Payloads working group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 21 Mar 2019 18:33:12 -0000

--Apple-Mail=_91766CFD-BB01-4F28-818A-92249924A1B2
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_0FE5DE08-922D-4E1A-A92C-761B146E21EA"


--Apple-Mail=_0FE5DE08-922D-4E1A-A92C-761B146E21EA
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Hi Bernard,

It=E2=80=99s already been pulled back to the =E2=80=9CPoint raised=E2=80=9D=
 sub-state. It was an error on my part to approve it prematurely.

However, last I checked I think Varun was waiting for feedback from you. =
(Apologies If that happened since I checked last.)

Thanks!

Ben.

> On Mar 21, 2019, at 10:39 AM, Bernard Aboba  =
wrote:
>=20
> This is broken.
>=20
> During review, serious issues were found with this document, and we =
were working through the required changes with one of the authors =
(Varun).
>=20
> Just because the editor decided to ignore the problems doesn't mean =
they don't need to be fixed.
>=20
>=20
>=20
> On Thu, Mar 21, 2019 at 4:42 AM The IESG > wrote:
> The IESG has approved the following document:
> - 'RTP Payload Format for Flexible Forward Error Correction (FEC)'
>   (draft-ietf-payload-flexible-fec-scheme-18.txt) as Proposed Standard
>=20
> This document is the product of the Audio/Video Transport Payloads =
Working
> Group.
>=20
> The IESG contact persons are Adam Roach, Alexey Melnikov and Ben =
Campbell.
>=20
> A URL of this Internet Draft is:
> =
https://datatracker.ietf.org/doc/draft-ietf-payload-flexible-fec-scheme/ =
=

>=20
>=20
>=20
>=20
> Technical Summary:
>=20
> This document defines new RTP payload formats for the Forward Error =
Correction (FEC) packets that are generated by the non-interleaved  and =
interleaved parity codes from source media encapsulated in RTP.   These =
parity codes are systematic codes, where a number of FEC repair packets =
are generated from a set of source packets from one or more source RTP =
streams.  These FEC repair packets are sent in a redundancy RTP stream =
separate from the source RTP stream(s) that  carries the source packets. =
 RTP source packets that were lost in   transmission can be =
reconstructed using the source and repair packets that were received.  =
The non-interleaved and interleaved parity codes   which are defined in =
this specification offer a good protection against random and bursty =
packet losses, respectively, at a cost of decent complexity.
>=20
>=20
> Working Group Summary:
>=20
> The document was discussed in the meetings, and on the mailing list. =
The open issues were addressed and there are no open issues; there was =
consensus on the content of the document.
>=20
> Document Quality:
>=20
> The payload was developed by members from different vendors and is =
part of the RTCWEB deliveries. Magnus Westerlund and Steve Botzko did a =
thorough review of the document.
> A request for a media type review was sent to ietf-types and =
media-types mailing lists.
>=20
> Personnel:
>=20
> Roni Even is the Document Shepherd.
> The responsible AD is Ben Campbell.
>=20
> _______________________________________________
> payload mailing list
> payload@ietf.org 
> https://www.ietf.org/mailman/listinfo/payload =



--Apple-Mail=_0FE5DE08-922D-4E1A-A92C-761B146E21EA
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

Hi =
Bernard,

It=E2=80=99s =
already been pulled back to the =E2=80=9CPoint raised=E2=80=9D =
sub-state. It was an error on my part to approve it =
prematurely.

However, last I checked I think Varun was waiting for =
feedback from you. (Apologies If that happened since I checked =
last.)

Thanks!

Ben.

On Mar 21, 2019, at 10:39 AM, =
Bernard Aboba <bernard.aboba@gmail.com> wrote:

This is broken.

During review, serious issues were found with this document, =
and we were working through the required changes with one of the authors =
(Varun). 

Just because the editor decided to ignore the problems =
doesn't mean they don't need to be fixed. 



On Thu, Mar 21, 2019 at 4:42 AM The IESG <iesg-secretary@ietf.org> wrote:
The IESG has approved the following =
document:

- 'RTP Payload Format for Flexible Forward Error Correction (FEC)'

  (draft-ietf-payload-flexible-fec-scheme-18.txt) as Proposed =
Standard



This document is the product of the Audio/Video Transport Payloads =
Working

Group.



The IESG contact persons are Adam Roach, Alexey Melnikov and Ben =
Campbell.



A URL of this Internet Draft is:

https://datatracker.ietf.org/doc/draft-ietf-payload-flexible-fe=
c-scheme/









Technical Summary:



This document defines new RTP payload formats for the Forward Error =
Correction (FEC) packets that are generated by the non-interleaved  =
and interleaved parity codes from source media encapsulated in =
RTP.   These parity codes are systematic codes, where a number =
of FEC repair packets are generated from a set of source packets from =
one or more source RTP streams.  These FEC repair packets are sent =
in a redundancy RTP stream separate from the source RTP stream(s) =
that  carries the source packets.  RTP source packets that =
were lost in   transmission can be reconstructed using the =
source and repair packets that were received.  The non-interleaved =
and interleaved parity codes   which are defined in this =
specification offer a good protection against random and bursty packet =
losses, respectively, at a cost of decent complexity. 





Working Group Summary:



The document was discussed in the meetings, and on the mailing list. The =
open issues were addressed and there are no open issues; there was =
consensus on the content of the document.



Document Quality:



The payload was developed by members from different vendors and is part =
of the RTCWEB deliveries. Magnus Westerlund and Steve Botzko did a =
thorough review of the document.

A request for a media type review was sent to ietf-types and media-types =
mailing lists.



Personnel:



Roni Even is the Document Shepherd.

The responsible AD is Ben Campbell.



_______________________________________________

payload mailing list

payload@ietf.org

https://www.ietf.org/mailman/listinfo/payload





=

--Apple-Mail=_0FE5DE08-922D-4E1A-A92C-761B146E21EA--

--Apple-Mail=_91766CFD-BB01-4F28-818A-92249924A1B2
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - https://gpgtools.org

iQIzBAEBCgAdFiEExW9rpd7ez4DexOFOgFZKbJXz1A0FAlyT2NUACgkQgFZKbJXz
1A2u6hAAompqbAn2KmG+DStVGQrsCkpPB9KNFUAN87vw5p/XTFQausI/jjL1HnEl
huTR0oKjYVxQjTI92+7d8GedN7oz0YHyjI6mcMQgFMQAe5cXClFAgeeWx1heYi6F
7j+hG1H0WG0pyOry8YcF69uROwCLzeq6X6WBFSoEfpjq1dBB+R3uc3TFLOv2S1Rr
k2L5vkogkw1VmwttpoTGprkaBgL4/5OdH1k+1nbAVPe+5hwXFEV63Arzx8R6iCer
YaBhXyqoyil+WdKrJuokeXGLLI9+rKLvuuL34NcV+VUy4/fSagUS4c+6e6bWjou9
xzKZHwLBvdWptBkwEUYtrAd1qgUJMXCCEawsyIUbGcJ8z5QrgXWx+6VMBMQnjcDn
TbGPR5QV6b9euWsMTBwuYCVrfLvi2hmIMieCbNkfB8Vdz/QOJJgxhdngu9Z3ctab
uiqDYeDxK8nT5NKJnlz/tLkr7wJ1m9rnnQJLYA8hZonEwDiGf0ynuVmmbM3E6ajf
Eg7yo/4mOFchbXBARCur3qPoyUngBN2p0RyWY69ECQuaPLr4nZKV+42WipHo1Z+o
c3GDsU+NzQmL8PucyKzZ8RhZarizTcXtkA8qW9OHRe+BuvQd4zAo+e1eoxN9g1gH
Tknm8QtJxyo4txYWQX/fYTNzkZ4pyC1jHDRsqNvzQO8qHk+Qyyo=
=uBMC
-----END PGP SIGNATURE-----

--Apple-Mail=_91766CFD-BB01-4F28-818A-92249924A1B2--


From nobody Thu Mar 21 17:40:09 2019
Return-Path: 
X-Original-To: payload@ietfa.amsl.com
Delivered-To: payload@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74F48131282; Thu, 21 Mar 2019 17:40:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level: 
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pjGe-A2u54CG; Thu, 21 Mar 2019 17:40:04 -0700 (PDT)
Received: from mail-vs1-xe42.google.com (mail-vs1-xe42.google.com [IPv6:2607:f8b0:4864:20::e42]) (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 5E4DB130EB3; Thu, 21 Mar 2019 17:40:04 -0700 (PDT)
Received: by mail-vs1-xe42.google.com with SMTP id j184so397171vsd.11; Thu, 21 Mar 2019 17:40:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ZR9uGYWxmv1HCSCTR1uq2+6TMRsng3NVhLGgb8swT6s=; b=sXu8j/eDoQx8HK44NX4qbS/4qcBckBbmQoT5UbNw08m0dJhhD6XbzZuXSp8v6LYTjW Fzp2afbI+DAUTs/aXDYE3lPmGCiRtrZgcdhcahFfjkdz1N0gDEeOHZr7e3W313sJUB08 v41Nxr1n1+Pp6ybeHiZZemUBleWmKEURe++HYSLd5NOes3cN5BnqpVMLYl3Dx6CZdI65 awvoOxqEWJqJ2E6uwBCnqcXBZLYVhdLD1LpLYwY6HhqS0+0GoF+hKD1ecl5ZwyVDz+PC QTihB6RvRH9V/tnqAyW+C7GikFjmMXVswIxZXq8gR9GJmL+o5WTfHXtwYwbEirXBieHg K4mg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ZR9uGYWxmv1HCSCTR1uq2+6TMRsng3NVhLGgb8swT6s=; b=nytrXxRCNX8pghdx8e99AzLTLnpaYHhUxgj4Qx1xCWCpO9e0/gYVita5KBu5YBoQNI bitjENCFWTVuWUUOyJxUmejqws4FouzXwhNRx6ZkchcqZg/HT6BBaQwsheAtzWenyA90 zd10IBwHIJMF4X9VCPYnJkCZHsolcYzfZMEtzuuCQl7dOXTtFoWo2vFfSD+1Q+wpvLsi Yj9ROWDOGRmDXp5k0Ud3mGddABEMehzpavqmAqL0qLJ1IH7PkjihPl/OyqxraP9+QhCJ SqiwTFj9VbovscleCokK7Tfvp3DBwuKbGGYHn8cjNsnwyqM5lGjEX2Rhh8n3VZ6S1IiW S8tw==
X-Gm-Message-State: APjAAAUjt1fPblKDjqhcumChINUQQZ8silBWLcbnjs/QuUDDe2RuD5YU WieGDAbdRvj7eLUQdr1bLoiSr7efCZr9jakPzcu5+g==
X-Google-Smtp-Source: APXvYqy7VviNOl5gvIGDInZjpPbrWAPC4py/RY+nLSRUludnJBv7e50H9tAeK+AisHLcvDEGaWlYRMTrNgd2TEs3k5I=
X-Received: by 2002:a67:f695:: with SMTP id n21mr4254967vso.226.1553215202956;  Thu, 21 Mar 2019 17:40:02 -0700 (PDT)
MIME-Version: 1.0
References: <155315770054.9919.5577297727640600792.idtracker@ietfa.amsl.com>  <2BBDBF81-05D9-4C75-BA2B-BE20527B0C61@nostrum.com>
In-Reply-To: <2BBDBF81-05D9-4C75-BA2B-BE20527B0C61@nostrum.com>
From: Bernard Aboba 
Date: Thu, 21 Mar 2019 20:39:51 -0400
Message-ID: 
To: Ben Campbell 
Cc: payload@ietf.org, roni.even@mail01.huawei.com, The IESG ,  draft-ietf-payload-flexible-fec-scheme@ietf.org
Content-Type: multipart/alternative; boundary="0000000000006e9b2c0584a418fb"
Archived-At: 
Subject: Re: [payload] Protocol Action: 'RTP Payload Format for Flexible Forward Error Correction (FEC)' to Proposed Standard (draft-ietf-payload-flexible-fec-scheme-18.txt)
X-BeenThere: payload@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Audio/Video Transport Payloads working group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 22 Mar 2019 00:40:08 -0000

--0000000000006e9b2c0584a418fb
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

I believe that Varun was looking for feedback from the WG not from me
(since I generally agreed with his proposal for rewriting the SDP section
of the document).



On Thu, Mar 21, 2019 at 2:33 PM Ben Campbell  wrote:

> Hi Bernard,
>
> It=E2=80=99s already been pulled back to the =E2=80=9CPoint raised=E2=80=
=9D sub-state. It was an
> error on my part to approve it prematurely.
>
> However, last I checked I think Varun was waiting for feedback from you.
> (Apologies If that happened since I checked last.)
>
> Thanks!
>
> Ben.
>
> On Mar 21, 2019, at 10:39 AM, Bernard Aboba 
> wrote:
>
> This is broken.
>
> During review, serious issues were found with this document, and we were
> working through the required changes with one of the authors (Varun).
>
> Just because the editor decided to ignore the problems doesn't mean they
> don't need to be fixed.
>
>
>
> On Thu, Mar 21, 2019 at 4:42 AM The IESG  wrote:
>
>> The IESG has approved the following document:
>> - 'RTP Payload Format for Flexible Forward Error Correction (FEC)'
>>   (draft-ietf-payload-flexible-fec-scheme-18.txt) as Proposed Standard
>>
>> This document is the product of the Audio/Video Transport Payloads Worki=
ng
>> Group.
>>
>> The IESG contact persons are Adam Roach, Alexey Melnikov and Ben Campbel=
l.
>>
>> A URL of this Internet Draft is:
>> https://datatracker.ietf.org/doc/draft-ietf-payload-flexible-fec-scheme/
>>
>>
>>
>>
>> Technical Summary:
>>
>> This document defines new RTP payload formats for the Forward Error
>> Correction (FEC) packets that are generated by the non-interleaved  and
>> interleaved parity codes from source media encapsulated in RTP.   These
>> parity codes are systematic codes, where a number of FEC repair packets =
are
>> generated from a set of source packets from one or more source RTP
>> streams.  These FEC repair packets are sent in a redundancy RTP stream
>> separate from the source RTP stream(s) that  carries the source packets.
>> RTP source packets that were lost in   transmission can be reconstructed
>> using the source and repair packets that were received.  The
>> non-interleaved and interleaved parity codes   which are defined in this
>> specification offer a good protection against random and bursty packet
>> losses, respectively, at a cost of decent complexity.
>>
>>
>> Working Group Summary:
>>
>> The document was discussed in the meetings, and on the mailing list. The
>> open issues were addressed and there are no open issues; there was
>> consensus on the content of the document.
>>
>> Document Quality:
>>
>> The payload was developed by members from different vendors and is part
>> of the RTCWEB deliveries. Magnus Westerlund and Steve Botzko did a thoro=
ugh
>> review of the document.
>> A request for a media type review was sent to ietf-types and media-types
>> mailing lists.
>>
>> Personnel:
>>
>> Roni Even is the Document Shepherd.
>> The responsible AD is Ben Campbell.
>>
>> _______________________________________________
>> payload mailing list
>> payload@ietf.org
>> https://www.ietf.org/mailman/listinfo/payload
>>
>
>

--0000000000006e9b2c0584a418fb
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


I believe that Varun was looking for feedback from the WG =
not from me (since I generally agreed with his proposal for rewriting the S=
DP section of the document).=C2=A0



<=
div class=3D"gmail_quote">
On Thu, Mar=
 21, 2019 at 2:33 PM Ben Campbell <be=
n@nostrum.com> wrote:
Hi Bernard,

=

It=E2=80=99s already been pulled back to the =E2=80=9CPoint rais=
ed=E2=80=9D sub-state. It was an error on my part to approve it prematurely=
.

However, last I checked I think Varun was waitin=
g for feedback from you. (Apologies If that happened since I checked last.)=


Thanks!

Ben.
On Mar 21, 2019, at 10:39 AM, Bernard Aboba=
 <bernard.a=
boba@gmail.com> wrote:

This is broken.

During review, serious issues were found with this document, and w=
e were working through the required changes with one of the authors (Varun)=
.=C2=A0

Just because the editor decided to ignore =
the problems doesn't mean they don't need to be fixed.=C2=A0
<=
div>


On Thu, Mar 21, 2019 at 4:42 AM The IESG <=
iesg-secretary=
@ietf.org> wrote:
The IESG has approved the following document:

- 'RTP Payload Format for Flexible Forward Error Correction (FEC)'<=
br>
=C2=A0 (draft-ietf-payload-flexible-fec-scheme-18.txt) as Proposed Standard=




This document is the product of the Audio/Video Transport Payloads Working<=
br>
Group.



The IESG contact persons are Adam Roach, Alexey Melnikov and Ben Campbell.<=
br>


A URL of this Internet Draft is:

https://datatracker.ietf.org=
/doc/draft-ietf-payload-flexible-fec-scheme/









Technical Summary:



This document defines new RTP payload formats for the Forward Error Correct=
ion (FEC) packets that are generated by the non-interleaved=C2=A0 and inter=
leaved parity codes from source media encapsulated in RTP.=C2=A0 =C2=A0Thes=
e parity codes are systematic codes, where a number of FEC repair packets a=
re generated from a set of source packets from one or more source RTP strea=
ms.=C2=A0 These FEC repair packets are sent in a redundancy RTP stream sepa=
rate from the source RTP stream(s) that=C2=A0 carries the source packets.=
=C2=A0 RTP source packets that were lost in=C2=A0 =C2=A0transmission can be=
 reconstructed using the source and repair packets that were received.=C2=
=A0 The non-interleaved and interleaved parity codes=C2=A0 =C2=A0which are =
defined in this specification offer a good protection against random and bu=
rsty packet losses, respectively, at a cost of decent complexity. 





Working Group Summary:



The document was discussed in the meetings, and on the mailing list. The op=
en issues were addressed and there are no open issues; there was consensus =
on the content of the document.



Document Quality:



The payload was developed by members from different vendors and is part of =
the RTCWEB deliveries. Magnus Westerlund and Steve Botzko did a thorough re=
view of the document.

A request for a media type review was sent to ietf-types and media-types ma=
iling lists.



Personnel:



Roni Even is the Document Shepherd.

The responsible AD is Ben Campbell.



_______________________________________________

payload mailing list

payload@ietf.org<=
br>
https://www.ietf.org/mailman/listinfo/payload







--0000000000006e9b2c0584a418fb--


From nobody Thu Mar 28 11:17:59 2019
Return-Path: 
X-Original-To: payload@ietf.org
Delivered-To: payload@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 640C812027A; Thu, 28 Mar 2019 11:17:57 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: 
Cc: payload@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.94.1
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: payload@ietf.org
Message-ID: <155379707735.1596.13842676046173094047@ietfa.amsl.com>
Date: Thu, 28 Mar 2019 11:17:57 -0700
Archived-At: 
Subject: [payload] I-D Action: draft-ietf-payload-flexible-fec-scheme-19.txt
X-BeenThere: payload@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Audio/Video Transport Payloads working group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 28 Mar 2019 18:17: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 Payloads WG of the IETF.

        Title           : RTP Payload Format for Flexible Forward Error Correction (FEC)
        Authors         : Mo Zanaty
                          Varun Singh
                          Ali Begen
                          Giridhar Mandyam
	Filename        : draft-ietf-payload-flexible-fec-scheme-19.txt
	Pages           : 41
	Date            : 2019-03-28

Abstract:
   This document defines new RTP payload formats for the Forward Error
   Correction (FEC) packets that are generated by the non-interleaved
   and interleaved parity codes from source media encapsulated in RTP.
   These parity codes are systematic codes (Flexible FEC, or "FLEX
   FEC"), where a number of FEC repair packets are generated from a set
   of source packets from one or more source RTP streams.  These FEC
   repair packets are sent in a redundancy RTP stream separate from the
   source RTP stream(s) that carries the source packets.  RTP source
   packets that were lost in transmission can be reconstructed using the
   source and repair packets that were received.  The non-interleaved
   and interleaved parity codes which are defined in this specification
   offer a good protection against random and bursty packet losses,
   respectively, at a cost of complexity.  The RTP payload formats that
   are defined in this document address scalability issues experienced
   with the earlier specifications, and offer several improvements.  Due
   to these changes, the new payload formats are not backward compatible
   with earlier specifications, but endpoints that do not implement this
   specification can still work by simply ignoring the FEC repair
   packets.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-payload-flexible-fec-scheme/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-payload-flexible-fec-scheme-19
https://datatracker.ietf.org/doc/html/draft-ietf-payload-flexible-fec-scheme-19

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-payload-flexible-fec-scheme-19


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 Mar 28 11:18:24 2019
Return-Path: 
X-Original-To: payload@ietfa.amsl.com
Delivered-To: payload@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 209C712033B for ; Thu, 28 Mar 2019 11:18:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.301
X-Spam-Level: 
X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=qti.qualcomm.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 26p8WdlWWLK7 for ; Thu, 28 Mar 2019 11:18:09 -0700 (PDT)
Received: from alexa-out-sd-02.qualcomm.com (alexa-out-sd-02.qualcomm.com [199.106.114.39]) (using TLSv1.2 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 421BC120345 for ; Thu, 28 Mar 2019 11:18:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1553797089; x=1585333089; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=Tp2ZYn5f+nNRwTM87tk1ymTeP6X7z28Pp0myG76QVjw=; b=rH6Ow5ktPc0A0jC+VBsadj+ulz71brHE6E9knIpHT+Jr4eI09bT1A64Q 1meSBIZndhNzuaH3WSkWHp0obt1EQgiomw9Wgb4pU/lRIg+P0GXO8e07B A2F6mNxAtZSyvQ04yfbIgvlCAdamNOKPUTvLhg+AqzIfnjUBdIAV3pF4j Y=;
X-IronPort-AV: E=Sophos;i="5.60,281,1549958400"; d="scan'208";a="40386959"
Received: from unknown (HELO ironmsg03-sd.qualcomm.com) ([10.53.140.143]) by alexa-out-sd-02.qualcomm.com with ESMTP; 28 Mar 2019 11:18:08 -0700
Received: from nasanexm01c.na.qualcomm.com ([10.85.0.83]) by ironmsg03-sd.qualcomm.com with ESMTP/TLS/AES256-SHA; 28 Mar 2019 11:18:08 -0700
Received: from NASANEXM01C.na.qualcomm.com (10.85.0.83) by NASANEXM01C.na.qualcomm.com (10.85.0.83) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Thu, 28 Mar 2019 11:18:07 -0700
Received: from NASANEXM01C.na.qualcomm.com ([10.85.0.83]) by NASANEXM01C.na.qualcomm.com ([10.85.0.83]) with mapi id 15.00.1395.000; Thu, 28 Mar 2019 11:18:07 -0700
From: Giridhar Mandyam 
To: "payload@ietf.org" 
Thread-Topic: Updates on FLEX FEC (ver -19)
Thread-Index: AdTlkiuoQvnOaQJpTdKMsfXe7HImOA==
Date: Thu, 28 Mar 2019 18:18:06 +0000
Message-ID: <5e948e46153445c892dc661085d21073@NASANEXM01C.na.qualcomm.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.80.80.8]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: 
Subject: [payload] Updates on FLEX FEC (ver -19)
X-BeenThere: payload@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Audio/Video Transport Payloads working group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 28 Mar 2019 18:18:23 -0000

RGVhciBQYXlsb2FkIFdHLA0KDQpBZnRlciBvZmZsaW5lIGRpc2N1c3Npb24gd2l0aCB0aGUgZWRp
dG9ycyBhbmQgcmV2aWV3ZXJzIChzcGVjaWFsIHRoYW5rcyB0byBCZXJuYXJkIEFib2JhKSwgd2Ug
aGF2ZSBkZWNpZGVkIHRoYXQgdGhlIHNwZWMgbmVlZGVkIHRvIGJlIHNsaWdodGx5IG1vZGlmaWVk
LiAgVmVyc2lvbiAtMTkgY29udGFpbnMgdGhlIGZvbGxvd2luZyBjaGFuZ2VzOg0KDQphKSBSZWNv
bW1lbmRhdGlvbiBhZ2FpbnN0IG5lZ290aWF0aW9uIG9mIFJUUCBSVFggd2hlbiBGTEVYIEZFQyBp
cyB1c2VkLiAgQSBuZXcgc2VjdGlvbiAxLjEuNyBvbiB0aGUgdXNlIG9mIEZMRVggRkVDIHJldHJh
bnNtaXNzaW9ucyBoYXMgYmVlbiBhZGRlZCB0byBpbmRpY2F0ZSBhcyBzdWNoLg0KDQpiKSBFbGlt
aW5hdGlvbiBvZiBhbGwgb3B0aW9uYWwgU0RQIHBhcmFtZXRlcnMgKGUuZy4gVG9QLCBMIGFuZCBE
IGZpZWxkcykuICBUaGlzIG1lYW5zIHRoYXQgdGhlIHNlbmRlciBjYW4gc2VuZCBhbnkgRkVDIGNv
bmZpZ3VyYXRpb24gKGFzIGluZGljYXRlZCBieSB0aGUgRkVDIGhlYWRlcikgYXMgbG9uZyBhcyBp
dCBzdGF5cyBjb25zaXN0ZW50IHdpdGggdGhlIG1hbmRhdG9yeSBTRFAgcGFyYW1ldGVycyAocmF0
ZSBhbmQgcmVwYWlyIHdpbmRvdykuICBTZWMuIDEuMS42LCAxLjEuNywgNC4yLjIsIGFuZCA1IGFy
ZSB0aGUgcHJpbWFyeSBpbXBhY3RlZCBzZWN0aW9ucy4gIFdlIGJlbGlldmUgdGhpcyB3aWxsIGdy
ZWF0bHkgc2ltcGxpZnkgU0RQIE8vQSBhbmQgd2hpbGUgcmV0YWluaW5nIHRoZSAiZmxleGliaWxp
dHkiIG9mIEZMRVggRkVDIHRvIGFkYXB0IEZFQyByZXBhaXIgZGF0YSBvbiBhIHBhY2tldC1ieS1w
YWNrZXQgYmFzaXMuIA0KCS0gTm90ZSB0aGF0IEwgYW5kIEQgY2Fubm90IGJlIGxhcmdlciB0aGFu
IDI1NSwgcmVzcGVjdGl2ZWx5LiAgQXMgd2UgZ2FpbiBpbXBsZW1lbnRhdGlvbiBleHBlcmllbmNl
LCBpZiB3ZSBkZWNpZGUgdGhhdCAyNTUgaXMgbm90IHN1ZmZpY2llbnQgdGhlbiBpdCBjb3VsZCBi
ZSBwb3NzaWJsZSB0byBleHRlbmQgdGhlIGNvcnJlc3BvbmRpbmcgaGVhZGVyIGZpZWxkcyBpbiB0
aGUgZnV0dXJlLiBDdXJyZW50bHkgdGhlcmUgYXJlIGhlYWRlciB2YWx1ZXMgdGhhdCBhcmUgcmVz
ZXJ2ZWQgKFI9Rj0xIGFuZCAgTD1EPTApIHRoYXQgY291bGQgYmUgdXNlZCB0byBpbmRpY2F0ZSB0
aGUgdXNlIG9mIGFuIGV4dGVuZGVkIEwgYW5kIEQgZmllbGQsIGFzIGFuIGV4YW1wbGUgb2Ygb25l
IHdheSB0byBpbXBsZW1lbnQgZXh0ZW5kZWQgZmllbGRzIGZvciBMIGFuZCBELg0KDQpjKSBTbGln
aHQgYWRqdXN0bWVudCBvZiBTZWMuIDYuMy4xLjIgdG8gY29ycmVjdCBmb3Igc2VxdWVuY2UgbnVt
YmVyaW5nIGVycm9ycyBpbiB0aGUgYWJzdHJhY3QgcHJvY2VkdXJlIGZvciBncm91cGluZyBvZiBz
b3VyY2UgcGFja2V0cyB1c2luZyB0aGVpciBSVFAgc2VxdWVuY2UgbnVtYmVycy4NCg0KZCkgQWNj
b3VudGluZyBmb3IgdGhlIHJlbWFpbmluZyBuaXQncyBpbiBCZW5qYW1pbiBLYWR1aydzIGxhc3Qg
cmV2aWV3Lg0KDQplKSBFeHBsaWNpdGx5IGRlZmluaW5nICJGTEVYIEZFQyIgaW4gdGhlIGFic3Ry
YWN0Lg0KDQpQbGVhc2UgcHJvdmlkZSBhbnkgZmVlZGJhY2sgd2l0aGluIDcgZGF5cyBvZiB0aGUg
c2VuZGluZyBvZiB0aGlzIG5vdGlmaWNhdGlvbi4NCg0KVGhhbmsgeW91LA0KDQotVGhlIEVkaXRv
cnMgb2YgRkxFWCBGRUMNCg0KDQo=