From nobody Mon Jun 8 08:58:41 2015 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07E811A9231 for ; Mon, 8 Jun 2015 08:58:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.603 X-Spam-Level: X-Spam-Status: No, score=0.603 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_WEB=0.77, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 45QaOEuwBDyj for ; Mon, 8 Jun 2015 08:58:32 -0700 (PDT) Received: from mx0a-00198e01.pphosted.com (mx0a-00198e01.pphosted.com [67.231.149.202]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 73AEC1B2FBF for ; Mon, 8 Jun 2015 08:58:09 -0700 (PDT) Received: from pps.filterd (m0073109.ppops.net [127.0.0.1]) by mx0a-00198e01.pphosted.com (8.14.7/8.14.7) with SMTP id t58FtEDl032679 for ; Mon, 8 Jun 2015 11:58:09 -0400 Received: from mail.vidyo.com ([162.209.16.214]) by mx0a-00198e01.pphosted.com with ESMTP id 1uq920mun1-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Mon, 08 Jun 2015 11:58:08 -0400 Received: from 492132-EXCH1.vidyo.com ([fe80::50:56ff:fe85:4f77]) by 492133-EXCH2.vidyo.com ([fe80::50:56ff:fe85:6b62%13]) with mapi id 14.03.0195.001; Mon, 8 Jun 2015 10:58:08 -0500 From: Jonathan Lennox To: "avtext@ietf.org" Thread-Topic: Publication requested for draft-ietf-avtext-rtp-stream-pause Thread-Index: AQHQogPpAUg+OuzFS0yt3w4UXQDsKA== Date: Mon, 8 Jun 2015 15:58:07 +0000 Message-ID: <209715FF-A4B7-4229-B3AD-CE58EC542B51@vidyo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [160.79.219.114] Content-Type: multipart/mixed; boundary="_002_209715FFA4B74229B3ADCE58EC542B51vidyocom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.14.151, 1.0.33, 0.0.0000 definitions=2015-06-08_09:2015-06-08,2015-06-08,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1506080257 Archived-At: Subject: [avtext] Publication requested for draft-ietf-avtext-rtp-stream-pause X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jun 2015 15:58:39 -0000 --_002_209715FFA4B74229B3ADCE58EC542B51vidyocom_ Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 SeKAmXZlIHNlbnQgdGhlIElFU0cgdGhlIHB1YmxpY2F0aW9uIHJlcXVlc3QgZm9yIGRyYWZ0LWll dGYtYXZ0ZXh0LXJ0cC1zdHJlYW0tcGF1c2UuICBUaGUgUHViUmVxIHdyaXRldXAgaXMgYXR0YWNo ZWQuIA0KDQo= --_002_209715FFA4B74229B3ADCE58EC542B51vidyocom_ Content-Type: text/plain; name="Stream-Pause-Writeup.txt" Content-Description: Stream-Pause-Writeup.txt Content-Disposition: attachment; filename="Stream-Pause-Writeup.txt"; size=8990; creation-date="Mon, 08 Jun 2015 15:58:07 GMT"; modification-date="Mon, 08 Jun 2015 15:58:07 GMT" Content-ID: <894447A16D59174584AFD7F73CB2E733@vidyo.com> Content-Transfer-Encoding: base64 QXMgcmVxdWlyZWQgYnkgUkZDIDQ4NTgsIHRoaXMgaXMgdGhlIGN1cnJlbnQgdGVtcGxhdGUgZm9y IHRoZSBEb2N1bWVudCANClNoZXBoZXJkIFdyaXRlLVVwLg0KDQpDaGFuZ2VzIGFyZSBleHBlY3Rl ZCBvdmVyIHRpbWUuIFRoaXMgdmVyc2lvbiBpcyBkYXRlZCAyNCBGZWJydWFyeSAyMDEyLg0KDQoo MSkgV2hhdCB0eXBlIG9mIFJGQyBpcyBiZWluZyByZXF1ZXN0ZWQgKEJDUCwgUHJvcG9zZWQgU3Rh bmRhcmQsDQpJbnRlcm5ldCBTdGFuZGFyZCwgSW5mb3JtYXRpb25hbCwgRXhwZXJpbWVudGFsLCBv ciBIaXN0b3JpYyk/ICBXaHkNCmlzIHRoaXMgdGhlIHByb3BlciB0eXBlIG9mIFJGQz8gIElzIHRo aXMgdHlwZSBvZiBSRkMgaW5kaWNhdGVkIGluIHRoZQ0KdGl0bGUgcGFnZSBoZWFkZXI/DQoNCkEg UHJvcG9zZWQgU3RhbmRhcmQgUkZDIGlzIGJlaW5nIHJlcXVlc3RlZC4gIFRoaXMgZG9jdW1lbnQg ZGVmaW5lcw0Kbm9ybWF0aXZlIGJlaGF2aW9yIGZvciBSVFAgZmVlZGJhY2sgbWVzc2FnZXMsIGFu ZCB1cGRhdGVzIFJGQyA1MTA0LA0Kd2hpY2ggaXMgYSBQcm9wb3NlZCBTdGFuZGFyZC4gIFRoZSB0 aXRsZSBwYWdlIGluZGljYXRlcyAiU3RhbmRhcmRzIFRyYWNrIi4NCg0KDQooMikgVGhlIElFU0cg YXBwcm92YWwgYW5ub3VuY2VtZW50IGluY2x1ZGVzIGEgRG9jdW1lbnQgQW5ub3VuY2VtZW50DQpX cml0ZS1VcC4gUGxlYXNlIHByb3ZpZGUgc3VjaCBhIERvY3VtZW50IEFubm91bmNlbWVudCBXcml0 ZS1VcC4gUmVjZW50DQpleGFtcGxlcyBjYW4gYmUgZm91bmQgaW4gdGhlICJBY3Rpb24iIGFubm91 bmNlbWVudHMgZm9yIGFwcHJvdmVkDQpkb2N1bWVudHMuIFRoZSBhcHByb3ZhbCBhbm5vdW5jZW1l bnQgY29udGFpbnMgdGhlIGZvbGxvd2luZyBzZWN0aW9uczoNCg0KVGVjaG5pY2FsIFN1bW1hcnkN Cg0KICBSZWxldmFudCBjb250ZW50IGNhbiBmcmVxdWVudGx5IGJlIGZvdW5kIGluIHRoZSBhYnN0 cmFjdCANCiAgYW5kL29yIGludHJvZHVjdGlvbiBvZiB0aGUgZG9jdW1lbnQuIElmIG5vdCwgdGhp cyBtYXkgYmUgDQogIGFuIGluZGljYXRpb24gdGhhdCB0aGVyZSBhcmUgZGVmaWNpZW5jaWVzIGlu IHRoZSBhYnN0cmFjdCANCiAgb3IgaW50cm9kdWN0aW9uLg0KDQpUaGlzIGRvY3VtZW50IHByb3Zp ZGVzIGEgbWVjaGFuaXNtIHRvIHVzZSBleGlzdGluZyBSVENQIEZlZWRiYWNrIENvZGVjDQpDb250 cm9sIE1lc3NhZ2VzIChSRkMgNTEwNCksIGFzIHdlbGwgYXMgYSBncm91cCBvZiBuZXcgbWVzc2Fn ZXMsIHRvDQpwYXVzZSBhbmQgcmVzdW1lIFJUUCBtZWRpYSBzdHJlYW1zLg0KDQpUaGUgZG9jdW1l bnQgZGVmaW5lcyB0d28gc2VwYXJhdGUgbWVjaGFuaXNtIGZvciBwYXVzaW5nIGFuZA0KcmVzdW1p bmcgUlRQIHN0cmVhbXMuICBPbmUgbWVjaGFuaXNtIGNvZGlmaWVzIGV4aXN0aW5nIHByYWN0aWNl IG9mIGhvdw0KdG8gdXNlIFJGQyA1MTA0IG1lc3NhZ2VzIHRvIHBhdXNlIGFuZCByZXN1bWUgc3Ry ZWFtcywgYnV0IGlzIG9ubHkNCmFwcGxpY2FibGUgdG8gYSBzdWJzZXQgb2YgcG9zc2libGUgUlRQ IHRvcG9sb2dpZXMuICBUaGUgb3RoZXIgaXMgYSBuZXcNCm1lY2hhbmlzbSBhbmQgaXMgZ2VuZXJh bGx5IGFwcGxpY2FibGUuICBHdWlkYW5jZSBpcyBwcm92aWRlZCBhcyB0bw0Kd2hlbiBvbmUgb3Ig dGhlIG90aGVyIG1lY2hhbmlzbSBzaG91bGQgYmUgdXNlZC4NCg0KDQpXb3JraW5nIEdyb3VwIFN1 bW1hcnkNCg0KICBXYXMgdGhlcmUgYW55dGhpbmcgaW4gV0cgcHJvY2VzcyB0aGF0IGlzIHdvcnRo IG5vdGluZz8gRm9yIA0KICBleGFtcGxlLCB3YXMgdGhlcmUgY29udHJvdmVyc3kgYWJvdXQgcGFy dGljdWxhciBwb2ludHMgb3IgDQogIHdlcmUgdGhlcmUgZGVjaXNpb25zIHdoZXJlIHRoZSBjb25z ZW5zdXMgd2FzIHBhcnRpY3VsYXJseSANCiAgcm91Z2g/DQoNClRoZSB0d28gcHJvdG9jb2wgbWVj aGFuaXNtcyB3ZXJlIHRoZSByZXN1bHQgb2YgdHdvIHNlcGFyYXRlIHByb3Bvc2Fscw0KYXMgdG8g aG93IHRvIHNvbHZlIHRoZSByZXF1aXJlbWVudDsgb25jZSB0aGUgcHJvcG9zYWxzIHdlcmUgbWVy Z2VkDQppbnRvIGEgc2luZ2xlIGRvY3VtZW50LCB0aGVyZSB3ZXJlIG5vIG9iamVjdGlvbnMgdG8g V0cgY29uc2Vuc3VzLg0KDQpEb2N1bWVudCBRdWFsaXR5DQoNCiAgQXJlIHRoZXJlIGV4aXN0aW5n IGltcGxlbWVudGF0aW9ucyBvZiB0aGUgcHJvdG9jb2w/IEhhdmUgYSANCiAgc2lnbmlmaWNhbnQg bnVtYmVyIG9mIHZlbmRvcnMgaW5kaWNhdGVkIHRoZWlyIHBsYW4gdG8gDQogIGltcGxlbWVudCB0 aGUgc3BlY2lmaWNhdGlvbj8gQXJlIHRoZXJlIGFueSByZXZpZXdlcnMgdGhhdCANCiAgbWVyaXQg c3BlY2lhbCBtZW50aW9uIGFzIGhhdmluZyBkb25lIGEgdGhvcm91Z2ggcmV2aWV3LCANCiAgZS5n Liwgb25lIHRoYXQgcmVzdWx0ZWQgaW4gaW1wb3J0YW50IGNoYW5nZXMgb3IgYSANCiAgY29uY2x1 c2lvbiB0aGF0IHRoZSBkb2N1bWVudCBoYWQgbm8gc3Vic3RhbnRpdmUgaXNzdWVzPyBJZiANCiAg dGhlcmUgd2FzIGEgTUlCIERvY3RvciwgTWVkaWEgVHlwZSBvciBvdGhlciBleHBlcnQgcmV2aWV3 LCANCiAgd2hhdCB3YXMgaXRzIGNvdXJzZSAoYnJpZWZseSk/IEluIHRoZSBjYXNlIG9mIGEgTWVk aWEgVHlwZSANCiAgcmV2aWV3LCBvbiB3aGF0IGRhdGUgd2FzIHRoZSByZXF1ZXN0IHBvc3RlZD8N Cg0KVGhlcmUgYXJlIGV4aXN0aW5nIGRlcGxveWVkIGltcGxlbWVudGF0aW9ucyBvZiB0aGUgUkZD IDUxMDQtYmFzZWQNCm1lY2hhbmlzbXMgdG8gcGF1c2UgYW5kIHJlc3VtZSBSVFAgc3RyZWFtcy4N Cg0KQW4gU0RQIGRpcmVjdG9yYXRlIHJldmlldyBoYXMgYmVlbiByZXF1ZXN0ZWQgZm9yIHRoZSBk b2N1bWVudCdzIHVzYWdlDQpvZiBTRFAuDQoNClBlcnNvbm5lbA0KDQogIFdobyBpcyB0aGUgRG9j dW1lbnQgU2hlcGhlcmQ/IFdobyBpcyB0aGUgUmVzcG9uc2libGUgQXJlYQ0KICBEaXJlY3Rvcj8N Cg0KVGhlIERvY3VtZW50IFNoZXBoZXJkIGlzIEpvbmF0aGFuIExlbm5veDsgdGhlIFJlc3BvbnNp YmxlIEFyZWENCkRpcmVjdG9yIGlzIEJlbiBDYW1wYmVsbC4NCg0KKDMpIEJyaWVmbHkgZGVzY3Jp YmUgdGhlIHJldmlldyBvZiB0aGlzIGRvY3VtZW50IHRoYXQgd2FzIHBlcmZvcm1lZCBieQ0KdGhl IERvY3VtZW50IFNoZXBoZXJkLiAgSWYgdGhpcyB2ZXJzaW9uIG9mIHRoZSBkb2N1bWVudCBpcyBu b3QgcmVhZHkNCmZvciBwdWJsaWNhdGlvbiwgcGxlYXNlIGV4cGxhaW4gd2h5IHRoZSBkb2N1bWVu dCBpcyBiZWluZyBmb3J3YXJkZWQgdG8NCnRoZSBJRVNHLg0KDQpUaGUgZG9jdW1lbnQgc2hlcGhl cmQgcmVhZCB0aGUgc3VibWl0dGVkIHZlcnNpb24gb2YgdGhlIGRvY3VtZW50DQpmdWxseSwgYXMg d2VsbCBhcyByZXZpZXdpbmcgc2V2ZXJhbCBlYXJsaWVyIHZlcnNpb25zIG9mIHRoZSBkb2N1bWVu dC4NCg0KKDQpIERvZXMgdGhlIGRvY3VtZW50IFNoZXBoZXJkIGhhdmUgYW55IGNvbmNlcm5zIGFi b3V0IHRoZSBkZXB0aCBvcg0KYnJlYWR0aCBvZiB0aGUgcmV2aWV3cyB0aGF0IGhhdmUgYmVlbiBw ZXJmb3JtZWQ/DQoNClRoaXMgZG9jdW1lbnQgZ290IGdvb2QgcmV2aWV3IGJ5IG11bHRpcGxlIG1l bWJlcnMgb2YgdGhlIEFWVGV4dA0Kd29ya2luZyBncm91cCBhbmQgYWxsIGNvbW1lbnRzIHdlcmUg YWRkcmVzc2VkLg0KDQooNSkgRG8gcG9ydGlvbnMgb2YgdGhlIGRvY3VtZW50IG5lZWQgcmV2aWV3 IGZyb20gYSBwYXJ0aWN1bGFyIG9yIGZyb20NCmJyb2FkZXIgcGVyc3BlY3RpdmUsIGUuZy4sIHNl Y3VyaXR5LCBvcGVyYXRpb25hbCBjb21wbGV4aXR5LCBBQUEsIEROUywNCkRIQ1AsIFhNTCwgb3Ig aW50ZXJuYXRpb25hbGl6YXRpb24/IElmIHNvLCBkZXNjcmliZSB0aGUgcmV2aWV3IHRoYXQNCnRv b2sgcGxhY2UuDQoNClRoaXMgZG9jdW1lbnQgZ290IGdvb2QgcmV2aWV3IGJ5IG11bHRpcGxlIHBl b3BsZSBmcm9tIEFWVGV4dCBhbmQgYWxsDQpjb21tZW50cyB3ZXJlIGFkZHJlc3NlZC4NCg0KDQoo NikgRGVzY3JpYmUgYW55IHNwZWNpZmljIGNvbmNlcm5zIG9yIGlzc3VlcyB0aGF0IHRoZSBEb2N1 bWVudCBTaGVwaGVyZA0KaGFzIHdpdGggdGhpcyBkb2N1bWVudCB0aGF0IHRoZSBSZXNwb25zaWJs ZSBBcmVhIERpcmVjdG9yIGFuZC9vciB0aGUNCklFU0cgc2hvdWxkIGJlIGF3YXJlIG9mPyBGb3Ig ZXhhbXBsZSwgcGVyaGFwcyBoZSBvciBzaGUgaXMgdW5jb21mb3J0YWJsZQ0Kd2l0aCBjZXJ0YWlu IHBhcnRzIG9mIHRoZSBkb2N1bWVudCwgb3IgaGFzIGNvbmNlcm5zIHdoZXRoZXIgdGhlcmUgcmVh bGx5DQppcyBhIG5lZWQgZm9yIGl0LiBJbiBhbnkgZXZlbnQsIGlmIHRoZSBXRyBoYXMgZGlzY3Vz c2VkIHRob3NlIGlzc3VlcyBhbmQNCmhhcyBpbmRpY2F0ZWQgdGhhdCBpdCBzdGlsbCB3aXNoZXMg dG8gYWR2YW5jZSB0aGUgZG9jdW1lbnQsIGRldGFpbCB0aG9zZQ0KY29uY2VybnMgaGVyZS4NCg0K Tm8gY29uY2VybnMuDQoNCg0KKDcpIEhhcyBlYWNoIGF1dGhvciBjb25maXJtZWQgdGhhdCBhbnkg YW5kIGFsbCBhcHByb3ByaWF0ZSBJUFINCmRpc2Nsb3N1cmVzIHJlcXVpcmVkIGZvciBmdWxsIGNv bmZvcm1hbmNlIHdpdGggdGhlIHByb3Zpc2lvbnMgb2YgQkNQIDc4DQphbmQgQkNQIDc5IGhhdmUg YWxyZWFkeSBiZWVuIGZpbGVkLiBJZiBub3QsIGV4cGxhaW4gd2h5Lg0KDQpBbGwgYXV0aG9ycyBo YXZlIGNvbmZpcm1lZCB0aGF0IHRoZXkga25vdyBvZiBubyBJUFIgZGlzY2xvc3VyZXMNCnJlcXVp cmVkIGJleW9uZCB0aG9zZSBhbHJlYWR5IGRpc2Nsb3NlZA0KDQoNCig4KSBIYXMgYW4gSVBSIGRp c2Nsb3N1cmUgYmVlbiBmaWxlZCB0aGF0IHJlZmVyZW5jZXMgdGhpcyBkb2N1bWVudD8NCklmIHNv LCBzdW1tYXJpemUgYW55IFdHIGRpc2N1c3Npb24gYW5kIGNvbmNsdXNpb24gcmVnYXJkaW5nIHRo ZSBJUFINCmRpc2Nsb3N1cmVzLg0KDQpUd28gSVBSIGRlY2xhcmF0aW9ucyBoYXZlIGJlZW4gbWFk ZSB0aGF0IHJlZmVyZW5jZSB0aGlzIGRvY3VtZW50LiAgVGhlDQpXb3JraW5nIEdyb3VwIGNvbnNp ZGVyZWQgdGhlIGRlY2xhcmF0aW9ucyBhbmQgZGVjaWRlZCB0aGV5IHdlcmUNCmFjY2VwdGFibGUu DQoNCg0KKDkpIEhvdyBzb2xpZCBpcyB0aGUgV0cgY29uc2Vuc3VzIGJlaGluZCB0aGlzIGRvY3Vt ZW50PyBEb2VzIGl0IA0KcmVwcmVzZW50IHRoZSBzdHJvbmcgY29uY3VycmVuY2Ugb2YgYSBmZXcg aW5kaXZpZHVhbHMsIHdpdGggb3RoZXJzDQpiZWluZyBzaWxlbnQsIG9yIGRvZXMgdGhlIFdHIGFz IGEgd2hvbGUgdW5kZXJzdGFuZCBhbmQgYWdyZWUgd2l0aCBpdD8gICANCg0KV2hpbGUgb25seSBh IHJlbGF0aXZlbHkgc21hbGwgbnVtYmVyIG9mIHBlb3BsZSBoYXZlIGNvbW1lbnRlZCBvbiB0aGUN CmRyYWZ0LCB0aGlzIGlzIG5vdCBhdHlwaWNhbCBmb3IgdGhlIEFWVEVYVCB3b3JraW5nIGdyb3Vw LCBhbmQgbW9zdCBvZg0KdGhlIGdyb3VwJ3MgbW9zdCBhY3RpdmUgKGFuZCBleHBlcnQpIHBhcnRp Y2lwYW50cyBoYXZlIGluZGljYXRlZA0KYWdyZWVtZW50IHdpdGggdGhlIGRvY3VtZW50Lg0KDQoN CigxMCkgSGFzIGFueW9uZSB0aHJlYXRlbmVkIGFuIGFwcGVhbCBvciBvdGhlcndpc2UgaW5kaWNh dGVkIGV4dHJlbWUgDQpkaXNjb250ZW50PyBJZiBzbywgcGxlYXNlIHN1bW1hcmlzZSB0aGUgYXJl YXMgb2YgY29uZmxpY3QgaW4gc2VwYXJhdGUNCmVtYWlsIG1lc3NhZ2VzIHRvIHRoZSBSZXNwb25z aWJsZSBBcmVhIERpcmVjdG9yLiAoSXQgc2hvdWxkIGJlIGluIGENCnNlcGFyYXRlIGVtYWlsIGJl Y2F1c2UgdGhpcyBxdWVzdGlvbm5haXJlIGlzIHB1YmxpY2x5IGF2YWlsYWJsZS4pIA0KDQpOby4N Cg0KDQooMTEpIElkZW50aWZ5IGFueSBJRCBuaXRzIHRoZSBEb2N1bWVudCBTaGVwaGVyZCBoYXMg Zm91bmQgaW4gdGhpcw0KZG9jdW1lbnQuIChTZWUgaHR0cDovL3d3dy5pZXRmLm9yZy90b29scy9p ZG5pdHMvIGFuZCB0aGUgSW50ZXJuZXQtRHJhZnRzDQpDaGVja2xpc3QpLiBCb2lsZXJwbGF0ZSBj aGVja3MgYXJlIG5vdCBlbm91Z2g7IHRoaXMgY2hlY2sgbmVlZHMgdG8gYmUNCnRob3JvdWdoLg0K DQpodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaWRuaXRzP3VybD1odHRwOi8vdG9vbHMuaWV0Zi5vcmcv aWQvZHJhZnQtaWV0Zi1hdnRleHQtcnRwLXN0cmVhbS1wYXVzZS0wNy50eHQNCg0KVGhvdWdoIHRo ZSBkb2N1bWVudCB1cGRhdGVzIFJGQyA1MTA0ICh3aGljaCBpcyBwcmUtQkNQNzgpLCBpdCBkb2Vz IG5vdA0KaW5jb3Jwb3JhdGUgYW55IHRleHQgZnJvbSBpdC4gIEFsbCB0aGUgdGV4dCBpbiB0aGlz IGRvY3VtZW50IHdhcw0Kc3VibWl0dGVkIHVuZGVyIHRoZSB0ZXJtcyBvZiBCQ1A3OC4NCg0KVXBk YXRlZCB2ZXJzaW9ucyBvZiBzb21lIG9mIHRoZSByZWZlcmVuY2VzIGhhdmUgYmVlbiBwdWJsaXNo ZWQ7IHRoZXNlDQpjYW4gYmUgdXBkYXRlZCBhcyBub3JtYWwgZm9yIGEgcG9zdCBJRVRGLUxDIHZl cnNpb24gb2YgdGhlIGRvY3VtZW50Lg0KDQoNCigxMikgRGVzY3JpYmUgaG93IHRoZSBkb2N1bWVu dCBtZWV0cyBhbnkgcmVxdWlyZWQgZm9ybWFsIHJldmlldw0KY3JpdGVyaWEsIHN1Y2ggYXMgdGhl IE1JQiBEb2N0b3IsIG1lZGlhIHR5cGUsIGFuZCBVUkkgdHlwZSByZXZpZXdzLg0KDQpOb3QgYXBw bGljYWJsZS4NCg0KDQooMTMpIEhhdmUgYWxsIHJlZmVyZW5jZXMgd2l0aGluIHRoaXMgZG9jdW1l bnQgYmVlbiBpZGVudGlmaWVkIGFzDQplaXRoZXIgbm9ybWF0aXZlIG9yIGluZm9ybWF0aXZlPw0K DQpZZXMuDQoNCg0KKDE0KSBBcmUgdGhlcmUgbm9ybWF0aXZlIHJlZmVyZW5jZXMgdG8gZG9jdW1l bnRzIHRoYXQgYXJlIG5vdCByZWFkeSBmb3INCmFkdmFuY2VtZW50IG9yIGFyZSBvdGhlcndpc2Ug aW4gYW4gdW5jbGVhciBzdGF0ZT8gSWYgc3VjaCBub3JtYXRpdmUNCnJlZmVyZW5jZXMgZXhpc3Qs IHdoYXQgaXMgdGhlIHBsYW4gZm9yIHRoZWlyIGNvbXBsZXRpb24/DQoNCk5vLg0KDQoNCigxNSkg QXJlIHRoZXJlIGRvd253YXJkIG5vcm1hdGl2ZSByZWZlcmVuY2VzIHJlZmVyZW5jZXMgKHNlZSBS RkMgMzk2Nyk/DQpJZiBzbywgbGlzdCB0aGVzZSBkb3dud2FyZCByZWZlcmVuY2VzIHRvIHN1cHBv cnQgdGhlIEFyZWEgRGlyZWN0b3IgaW4gDQp0aGUgTGFzdCBDYWxsIHByb2NlZHVyZS4gDQoNCk5v Lg0KDQoNCigxNikgV2lsbCBwdWJsaWNhdGlvbiBvZiB0aGlzIGRvY3VtZW50IGNoYW5nZSB0aGUg c3RhdHVzIG9mIGFueQ0KZXhpc3RpbmcgUkZDcz8gQXJlIHRob3NlIFJGQ3MgbGlzdGVkIG9uIHRo ZSB0aXRsZSBwYWdlIGhlYWRlciwgbGlzdGVkDQppbiB0aGUgYWJzdHJhY3QsIGFuZCBkaXNjdXNz ZWQgaW4gdGhlIGludHJvZHVjdGlvbj8gSWYgdGhlIFJGQ3MgYXJlIG5vdA0KbGlzdGVkIGluIHRo ZSBBYnN0cmFjdCBhbmQgSW50cm9kdWN0aW9uLCBleHBsYWluIHdoeSwgYW5kIHBvaW50IHRvIHRo ZQ0KcGFydCBvZiB0aGUgZG9jdW1lbnQgd2hlcmUgdGhlIHJlbGF0aW9uc2hpcCBvZiB0aGlzIGRv Y3VtZW50IHRvIHRoZQ0Kb3RoZXIgUkZDcyBpcyBkaXNjdXNzZWQuIElmIHRoaXMgaW5mb3JtYXRp b24gaXMgbm90IGluIHRoZSBkb2N1bWVudCwNCmV4cGxhaW4gd2h5IHRoZSBXRyBjb25zaWRlcnMg aXQgdW5uZWNlc3NhcnkuDQoNClRoaXMgZG9jdW1lbnQgdXBkYXRlcyBSRkMgNTEwNC4gIFRoaXMg aXMgc3RhdGVkIGluIGl0cyBoZWFkZXIgYW5kDQphYnN0cmFjdC4NCg0KDQooMTcpIERlc2NyaWJl IHRoZSBEb2N1bWVudCBTaGVwaGVyZCdzIHJldmlldyBvZiB0aGUgSUFOQSBjb25zaWRlcmF0aW9u cw0Kc2VjdGlvbiwgZXNwZWNpYWxseSB3aXRoIHJlZ2FyZCB0byBpdHMgY29uc2lzdGVuY3kgd2l0 aCB0aGUgYm9keSBvZiB0aGUNCmRvY3VtZW50LiBDb25maXJtIHRoYXQgYWxsIHByb3RvY29sIGV4 dGVuc2lvbnMgdGhhdCB0aGUgZG9jdW1lbnQgbWFrZXMNCmFyZSBhc3NvY2lhdGVkIHdpdGggdGhl IGFwcHJvcHJpYXRlIHJlc2VydmF0aW9ucyBpbiBJQU5BIHJlZ2lzdHJpZXMuDQpDb25maXJtIHRo YXQgYW55IHJlZmVyZW5jZWQgSUFOQSByZWdpc3RyaWVzIGhhdmUgYmVlbiBjbGVhcmx5DQppZGVu dGlmaWVkLiBDb25maXJtIHRoYXQgbmV3bHkgY3JlYXRlZCBJQU5BIHJlZ2lzdHJpZXMgaW5jbHVk ZSBhDQpkZXRhaWxlZCBzcGVjaWZpY2F0aW9uIG9mIHRoZSBpbml0aWFsIGNvbnRlbnRzIGZvciB0 aGUgcmVnaXN0cnksIHRoYXQNCmFsbG9jYXRpb25zIHByb2NlZHVyZXMgZm9yIGZ1dHVyZSByZWdp c3RyYXRpb25zIGFyZSBkZWZpbmVkLCBhbmQgYQ0KcmVhc29uYWJsZSBuYW1lIGZvciB0aGUgbmV3 IHJlZ2lzdHJ5IGhhcyBiZWVuIHN1Z2dlc3RlZCAoc2VlIFJGQyA1MjI2KS4NCg0KVGhlIGRvY3Vt ZW50IG1ha2VzIHR3byBJQU5BIHJlZ2lzdHJhdGlvbnMgKFNlY3Rpb24gMTEpLCB3aGljaCBhcmUN CmRlc2NyaWJlZCBjb3JyZWN0bHkuICBObyBuZXcgcmVnaXN0cmllcyBhcmUgZGVmaW5lZC4NCg0K DQooMTgpIExpc3QgYW55IG5ldyBJQU5BIHJlZ2lzdHJpZXMgdGhhdCByZXF1aXJlIEV4cGVydCBS ZXZpZXcgZm9yIGZ1dHVyZQ0KYWxsb2NhdGlvbnMuIFByb3ZpZGUgYW55IHB1YmxpYyBndWlkYW5j ZSB0aGF0IHRoZSBJRVNHIHdvdWxkIGZpbmQNCnVzZWZ1bCBpbiBzZWxlY3RpbmcgdGhlIElBTkEg RXhwZXJ0cyBmb3IgdGhlc2UgbmV3IHJlZ2lzdHJpZXMuDQoNClRoaXMgZG9jdW1lbnQgZG9lcyBu b3QgZGVmaW5lIGFueSBuZXcgcmVnaXN0cmllcy4NCg0KDQooMTkpIERlc2NyaWJlIHJldmlld3Mg YW5kIGF1dG9tYXRlZCBjaGVja3MgcGVyZm9ybWVkIGJ5IHRoZSBEb2N1bWVudA0KU2hlcGhlcmQg dG8gdmFsaWRhdGUgc2VjdGlvbnMgb2YgdGhlIGRvY3VtZW50IHdyaXR0ZW4gaW4gYSBmb3JtYWwN Cmxhbmd1YWdlLCBzdWNoIGFzIFhNTCBjb2RlLCBCTkYgcnVsZXMsIE1JQiBkZWZpbml0aW9ucywg ZXRjLg0KDQpUaGUgQUJORiBmb3IgdGhlIFNEUCBleHRlbnNpb25zIHdpbGwgYmUgcmV2aWV3ZWQg YXMgcGFydCBvZiB0aGUgU0RQDQpEaXJlY3RvcmF0ZSByZXZpZXcuDQo= --_002_209715FFA4B74229B3ADCE58EC542B51vidyocom_-- From nobody Wed Jun 10 11:01:54 2015 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 866C21ACD86; Wed, 10 Jun 2015 10:16:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.312 X-Spam-Level: X-Spam-Status: No, score=-2.312 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 04ddpFU89st2; Wed, 10 Jun 2015 10:16:03 -0700 (PDT) Received: from alum-mailsec-scanner-3.mit.edu (alum-mailsec-scanner-3.mit.edu [18.7.68.14]) by ietfa.amsl.com (Postfix) with ESMTP id D65A21A90F0; Wed, 10 Jun 2015 10:15:58 -0700 (PDT) X-AuditID: 1207440e-f79fc6d000000caf-19-557870cd73d7 Received: from outgoing-alum.mit.edu (OUTGOING-ALUM.MIT.EDU [18.7.68.33]) by alum-mailsec-scanner-3.mit.edu (Symantec Messaging Gateway) with SMTP id 49.01.03247.DC078755; Wed, 10 Jun 2015 13:15:57 -0400 (EDT) Received: from Paul-Kyzivats-MacBook-Pro.local (c-50-138-229-151.hsd1.ma.comcast.net [50.138.229.151]) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.13.8/8.12.4) with ESMTP id t5AHFuth004953 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 10 Jun 2015 13:15:57 -0400 Message-ID: <557870CB.9090800@alum.mit.edu> Date: Wed, 10 Jun 2015 13:15:55 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: draft-ietf-avtext-rtp-stream-pause.all@ietf.org, avtext@ietf.org Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrAIsWRmVeSWpSXmKPExsUixO6iqHu2oCLU4NoFOYuP926wWpz7MJXV 4umjHSwOzB5LlvxkCmCM4rZJSiwpC85Mz9O3S+DO+P3mJnvBU+6KS68vMzcw7uPsYuTkkBAw kZjYuJwRwhaTuHBvPVsXIxeHkMBlRonfD7ZAOc+ZJLoWt7CDVPEKaEucXN4P1sEioCqxtfMP M4jNJqAlMefQfxYQW1QgReLZkt1MEPWCEidnPgGKc3CICLhIbFtvBxJmFjCT+LqshxXEFhaw kbj77zYjTHze5ofMELa8xPa3c5gnMPLNQjJpFpKyWUjKFjAyr2KUS8wpzdXNTczMKU5N1i1O TszLSy3SNdbLzSzRS00p3cQICT2+HYzt62UOMQpwMCrx8M7ILQ8VYk0sK67MPcQoycGkJMo7 P6kiVIgvKT+lMiOxOCO+qDQntfgQowQHs5II7xY9oBxvSmJlVWpRPkxKmoNFSZxXbYm6n5BA emJJanZqakFqEUxWhoNDSYL3cz5Qo2BRanpqRVpmTglCmomDE2Q4l5RIcWpeSmpRYmlJRjwo 8uKLgbEHkuIB2nsYpJ23uCAxFygK0XqKUVFKnPcYSEIAJJFRmgc3FpZQXjGKA30pzNsOUsUD TEZw3a+ABjMBDV7IXA4yuCQRISXVwLjyCevBxsMPJh1kTXxnLlzGVfJuasfdVwtS0v8/lp14 3HzDGctFO48Y9KV/amoyVFNc5ao+1eeQo6Hvu/gnpbbPQ1Me5+50UK57UmVTzJUm/vHJyWMM UUWHrBqPzRXn9Tx18+euZWK2i3r7FJJjv+Yo/fu3eH/B5ab/mavSuAsnTudafWTn3RQlluKM REMt5qLiRAAQBNVrAwMAAA== Archived-At: X-Mailman-Approved-At: Wed, 10 Jun 2015 11:01:53 -0700 Cc: SDP Directorate Subject: [avtext] SDP review of draft-ietf-avtext-rtp-stream-pause-07 X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jun 2015 17:16:04 -0000 I am the assigned SDP directorate reviewer for this draft. For background on the SDP directorate, please see the FAQ at http://www.ietf.org/iesg/directorate/sdp.html Please wait for direction from your document shepherd or AD before posting a new version of the draft. Summary: The SDP aspects of this draft are well written and clear. In my opinion it *can* be published in this form. However, I do have concern about one aspect - that the manner of configuring the supported options of this feature is obscure and confusing. (This is of course a matter of taste.) Details: I have concerns about the way the configuration of options is specified using a numeric value. I can see how that might be reasonable if the numbers represented a pure hierarchy. But that seems not to be the case. The rules for valid answers are quite complex. (It isn't something that can be easily remembered.) This is because each number represents a particular combination of semi-independent properties, each of which has separate rules for answers vs. offers. It seems to me that it would be better to configure these distinct properties independently. Perhaps just declare each of {PAUSE,RESUME,PAUSED,REFUSED} that can be sent and received. (And for convenience, perhaps some extra keywords for common combinations. (E.g. "all".) Then the rules for valid answers for a given offer would be easy to state and understand. Thanks, Paul Kyzivat, for the SDP Directorate From nobody Mon Jun 15 20:19:08 2015 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D28031AD352; Mon, 15 Jun 2015 20:19:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LBnzKBvoPVZq; Mon, 15 Jun 2015 20:19: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 CD3E31B38E3; Mon, 15 Jun 2015 20:19:02 -0700 (PDT) Received: from [10.0.1.23] (cpe-70-119-203-4.tx.res.rr.com [70.119.203.4]) (authenticated bits=0) by nostrum.com (8.15.1/8.14.9) with ESMTPSA id t5G3Ioh3006384 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 15 Jun 2015 22:19:01 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-70-119-203-4.tx.res.rr.com [70.119.203.4] claimed to be [10.0.1.23] From: "Ben Campbell" To: draft-ietf-avtext-rtp-stream-pause.all@ietf.org, avtext@ietf.org Date: Mon, 15 Jun 2015 22:18:50 -0500 Message-ID: <257ACC1A-936C-4C32-81E2-E2A88512B20A@nostrum.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Mailer: MailMate (1.9.1r5084) Archived-At: Subject: [avtext] AD Evaluation of draft-ietf-avtext-rtp-stream-pause-07 X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jun 2015 03:19:06 -0000 Hi, Here's my AD Evaluation of draft-ietf-avtext-rtp-stream-pause-07. I've broken it down between things I'd like to see discussed prior to IETF last call, things I think can be worked in parallel to the last call, and things that are just editorial. Thanks! Ben. *** Things to discuss before IETF Last Call: -- Partial Support Configuration I concur with Paul's SDP review that the current method of configuring partial support is confusing and error prone. I will go further and say I am concerned that the whole idea of partial support can really impact interoperability. It seems like there are many combinations where participants can simply fail to work (where failing to work means they cannot use this extension at all.) Have you had people say they are willing to implement some but not all features of this spec? Do the features cause harm if a participant tries to send them to a peer that doesn't understand them? (This is a bit of RTCP CCM esoterica that I do not know off-hand: Are recipients expected to ignore things they don't understand?) I can see a switch or mixer declaring that it will never send PAUSE or RESUME. But it seems like encouraging (or even allowing) partial support for “endpoint” participants will hurt interoperability. For example, you have reason why a mixer or switch might choose to send pause—but that will never work if the endpoints don’t support receiving it. So, when section 9 says " 'config' allows for partial implementation of this specification according to the different roles in the use cases section", do you mean to constrain the use of "config" to only those roles where it is needed? Would it make sense to say that mixers/switches that support pause must support at least certain configs, where endpoints must support other minimums? -- "Available PauseID" I find the specification of "Available PauseID" to be very confusing. Section 8.1 (third paragraph) seems to say that the PauseID in the PAUSE request should be taken from the most recently received PAUSED indication. But the next paragraph says the value from PAUSED should be incremented by one. I think the confusion comes from two things. First, the name "Available PauseID" is a confusing choice. To me, "available" means I can use it. But if I understand correctly, I can't use that one for a "new" PAUSE request. Perhaps a better term would be "Current PauseID". That would make more sense if I refer to the "current" value to act on a current pause (or most recent) condition, and then have the concept of a "next" PauseID which would be the current one plus 1. I also think it would help to have one section that describes (non-normatively) all the semantics of PauseID early in section 5 (before the concept is first referenced.) -- 2.2: Are the definitions in the RTP Taxonomy document necessary to understand/implement this draft? If so, this should be a normative reference, which we would need to call out in the last call. (I'm not saying they are required to understand this one--I'm not sure one way or another.) -- 5.3, 3rd paragraph: Does this mean the stream receiver may see a PAUSED indication prior to the stream actually being paused? (That is, see a paused indication, but continue to receive the stream?) I don't think that's the intent, but seeing this after the paragraphs on the PAUSED indication makes me wonder. *** Things that can be treated as part of IETF Last Call: -- I'm not going to push on this, since I assume this was a well-discussed compromise in the WG. But it seems to me that having two independent mechanisms to accomplish the same thing, with one only working in limited conditions (TMMBR/TMMBN) adds more complexity that value, and is likely to reduce interoperability. -- 4.1: "The pause operation is arguably not very time critical" This seems to contradict the previous sentence. I assume the point is that both are time sensitive, but pause is less so than resume? -- 4.3: Is it possible for the sender to change the SSRC between the pause and resume requests, so that the resume request refers to a stale SSRC value? Does it hurt anything if it happens? -- 6.3.1, 2nd bullet:"the sender MUST keep record of which receiver that caused the RTP stream to pause. If that receiver sends an RTCP BYE message observed by the sender, the sender SHALL resume the RTP stream." If no other participant objected to the pause in the first place, why do we assume that exit of the original pause requestor means the other participants want the stream to resume? Why put the burden on the sender to track this? -- 8: "If the messages defined in this specification are supported in addition to TMMBR/TMMBN, pause/ resume signaling MUST use messages from this specification." What if one (PTP) participant supports these formats, and the other only supports TMMBR/TMMBN? As worded that seems to mean that pause/resume cannot be used. (i.e. one MUST NOT use TMMBR/TMMBN because it supports the FCI messages, and the other only understands TMMBR/TMMBN? "If the topology is not point-to-point and the messages defined in this specification are not supported, pause/resume functionality with TMMBR/TMMBN MUST NOT be used." This MUST NOT seems to be non-constraining. -- 8.1, 3rd paragraph: "as indicated by PAUSED" ... or REFUSED? -- 8.1, 4th from end: Can you offer guidance on selecting an appropriate time? -- 2nd paragraph from end: This is a little confusing. Is the counter-indication really that local considerations make it _impossible_ to pause, or is simply _undesirable_ sufficient? Is pausing effectively optional? Also, shouldn’t this mention the hold off? -- 8.2, 2nd paragraph Is this true for the locally paused state? If so, how is the PauseID value calculated for local pausing. -- 3rd paragraph: "PAUSED SHALL contain..." I assume this goes into the Type Specific field. If so, it would be worth explicitly mentioning that. Also, I assume that implies a fixed-length Type Specific in a PAUSED indication? --8.4, 3rd paragraph:"receives a RESUME with a PauseID less than the valid one, in which case the RESUME SHALL be ignored." This seems to conflict with the last sentence in 8.3. It says the resume is ignored if it contains a _valid_ PauseID or a value less than the valid one. --8.4, 6th paragraph: Can you offer guidance on selecting an appropriate time? -- 15.2: Seems like the references for RFCs 3264 and 4560 should be normative. This draft specified normative behavior for use with SDP and the offer/answer model. *** Editorial Things: -- section 1, paragraph 4, last sentence: Long, convoluted sentence. Consider breaking into multiple, simpler sentences. also, s/anyway/still -- paragraph 5: s/ "As the RTP streams..." / "As the set of RTP streams..." s/ "... using Extended RTP Profile..." / "... using the Extended RTP Profile..." -- 2nd to last paragraph: "... it is proposed to define..." I suggest "This document defines..." -- 3.1, three paragraphs starting with "RTCWEB WG's use case..." These don't seem specific to this use case. Consider moving it out of the use case, or perhaps to the RTP Mixer to Media Sender use case (since that one mentions allowing the media sender to signal the receiver that it is pausing a stream.) -- 3.2, First paragraph: "That is accomplished through the Mixer originating its’ own streams, identified by SSRC..." s/its'/its Also, I seem you mean "identified by _distinct_ SSRC values"? -- 3rd paragraph: "request to pause a particular stream" request that a particular stream be paused, or request the sender to pause a particular stream. -- 4th paragraph: "there may be situations that makes it desirable to the Mixer to pause some of its sent RTP streams" do you mean "desirable _for_ the mixer…"? (Or do you mean to say the mixer desires that the streams be paused? -- Figure 3: Do B and D ever get mentioned? If not, it would be simpler without them. -- 3.4 It’s kind of confusing to find that this section combines both the unicast and multicast cases, when the previous two sections separated them. I think it would be easier to understand if the information in this section were split between 3.2 and 3.3. -- 4.1: While I recognize that RAI has historically used real-time in this sense, it’s not the usual meaning of real-time in the field of computer science. Consider replacing “real-time” with “time-sensitive” or “time-sensitivity” depending on context. -- 4.2: s/who/that (both times) s/likes/needs (or wants) -- 4.4, first paragraph, 2nd sentence: Long, convoluted sentence. Please consider breaking it down into simpler sentences. (This is further confused by the presence of lots of commas, some of which separate list members, and some separate clauses.) -- 4.5, last sentence: I’m confused by this sentence. Do you mean to say, "In this error condition a negative acknowledgement may be needed…" -- 4.8, first paragraph: Any reason to cite 4566 but not 3261? (Both have been cited earlier in the draft.) -- 5, 2nd paragraph: "It is proposed..." Unless that proposal has not been accepted, consider saying "This solution re-uses..." -- 5.4, 1st paragraph: "can request to resume... " request the sender to resume, or request the resumption of... -- paragraph 6: "it cannot be resumed due to local considerations" This can be read to say that local considerations may prevent resumption, but I think you mean that resumption is prevented by protocol, even if the sender would like to resume due to local considerations. -- 7th paragraph: "Should such temporal dependency between before and after the media was paused be used by the RTP stream sender, it requires the RTP stream receiver to have saved the sample from before the pause for successful continued decoding when resuming." Do you mean temporal dependency between samples sent before and after the media was paused? "temporal dependency to before the pause" dependency on samples from before the pause? -- 6.4, 4th paragraph from end: s/"responsible to leave"/"responsible for leaving" Figure 5: is all of the above (Both the common packet and the FCI formats and the intervening text) one figure, or should they be figure 5 and 6? -- 8.2, first paragraph: Are there other ways to get into those states? Wouldn’t it be simpler to say the indication MUST be sent whenever entering the paused or locally paused states? -- 9, first paragraph after Figure 7: "but MAY use existing ccm tmmbr signaling [RFC5104] if the limitations in functionality as described in this specification coming from such usage are considered acceptable." I don't understand what "coming from such usage" means in context. -- 9, 2nd paragraph after figure 7: s/independent/independently s/likes/needs (or wants) From nobody Mon Jun 15 23:01:49 2015 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 024971B324B; Mon, 15 Jun 2015 23:01:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nJ6n2mttsHJu; Mon, 15 Jun 2015 23:01:44 -0700 (PDT) Received: from mail-wg0-x233.google.com (mail-wg0-x233.google.com [IPv6:2a00:1450:400c:c00::233]) (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 647CC1B3249; Mon, 15 Jun 2015 23:01:44 -0700 (PDT) Received: by wgzl5 with SMTP id l5so4277817wgz.3; Mon, 15 Jun 2015 23:01:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:content-transfer-encoding:thread-index :content-language; bh=57fDkeezUH5e0mUfkDkfyShV11xeqsje8pPbdgMsQMQ=; b=HijQb3LnnFN4uWm08fan9lpfCRuo3V2eFjSMCPh3ydIE81A1lyHY5ri0LOntEqmiIt 65mfJPFSbUaiUUYZZ8PciCqY9XpqrWED0W95gY9v1vQKozMIwJad+EJBfm0ezpAiiTVg Zew8kxoTNI8rAoA6Z0hDzQPv05Sr2mRVl0haT7dJ+0AaO8tGpkIBn0jbmFgLY/OEgk4c joFMqdWtkzBkAZfUcZia4TsYKM3m5UyKTiK5unax9NmbaGfR+D/NLKlYFEURXxXXIL3o MtUOJ+3y05LldBOZPSrQOyY9SFyaJslI9w0P4b1D+ywxeddlEVUGO3wfdH//NCI0IoAE PHcQ== X-Received: by 10.180.98.103 with SMTP id eh7mr2969986wib.75.1434434503190; Mon, 15 Jun 2015 23:01:43 -0700 (PDT) Received: from RoniE (bzq-79-182-120-178.red.bezeqint.net. [79.182.120.178]) by mx.google.com with ESMTPSA id m2sm19085298wiy.7.2015.06.15.23.01.40 (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 15 Jun 2015 23:01:42 -0700 (PDT) From: "Roni Even" To: "'Ben Campbell'" , , References: <257ACC1A-936C-4C32-81E2-E2A88512B20A@nostrum.com> In-Reply-To: <257ACC1A-936C-4C32-81E2-E2A88512B20A@nostrum.com> Date: Tue, 16 Jun 2015 09:01:37 +0300 Message-ID: <035701d0a7f9$ea1ed990$be5c8cb0$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKjuhw4eY8Rk6zCz+Wdh9uQRtZpyZwIfBWA Content-Language: en-us Archived-At: Subject: Re: [avtext] AD Evaluation of draft-ietf-avtext-rtp-stream-pause-07 X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jun 2015 06:01:48 -0000 Hi Ben, With regards to=20 > -- I'm not going to push on this, since I assume this was a = well-discussed > compromise in the WG. But it seems to me that having two independent > mechanisms to accomplish the same thing, with one only working in = limited > conditions (TMMBR/TMMBN) adds more complexity that value, and is = likely to > reduce interoperability. This has to do with the definition of TMMBR /TMMBN in RFC5104. The use = case there support a group media session like multicast but since a lot = of usage is by point to point video conferencing (even multipoint in = these applications is doing media as point to point connection) allowed = those usages to use TMMBR/TMMBN also for pause and resume since there = are only two parties in each media session and it is used this way. As = explained in the document TMMBR/TMMBN will not be efficient in multicast = since the sender must look at what all participants wants and that is = why we need this new messages. Still current system that use TMMBR/TMMBN = for pausing are not contradicting RFC5104 and this is why we documented = both methods Roni > -----Original Message----- > From: avtext [mailto:avtext-bounces@ietf.org] On Behalf Of Ben = Campbell > Sent: 16 June, 2015 6:19 AM > To: draft-ietf-avtext-rtp-stream-pause.all@ietf.org; avtext@ietf.org > Subject: [avtext] AD Evaluation of = draft-ietf-avtext-rtp-stream-pause-07 >=20 > Hi, >=20 > Here's my AD Evaluation of draft-ietf-avtext-rtp-stream-pause-07. I've = broken it > down between things I'd like to see discussed prior to IETF last call, = things I > think can be worked in parallel to the last call, and things that are = just editorial. >=20 > Thanks! >=20 > Ben. >=20 > *** Things to discuss before IETF Last Call: >=20 > -- Partial Support Configuration >=20 > I concur with Paul's SDP review that the current method of configuring = partial > support is confusing and error prone. I will go further and say I am = concerned > that the whole idea of partial support can really impact = interoperability. It > seems like there are many combinations where participants can simply = fail to > work (where failing to work means they cannot use this extension at = all.) Have > you had people say they are willing to implement some but not all = features of > this spec? Do the features cause harm if a participant tries to send = them to a > peer that doesn't understand them? (This is a bit of RTCP CCM = esoterica that I > do not know off-hand: Are recipients expected to ignore things they = don't > understand?) >=20 > I can see a switch or mixer declaring that it will never send PAUSE or = RESUME. > But it seems like encouraging (or even allowing) partial support for = =E2=80=9Cendpoint=E2=80=9D > participants will hurt interoperability. For example, you have reason = why a > mixer or switch might choose to send pause=E2=80=94but that will never = work if the > endpoints don=E2=80=99t support receiving it. >=20 > So, when section 9 says " 'config' allows for partial implementation = of this > specification according to the different roles in the use cases = section", do you > mean to constrain the use of "config" to only those roles where it is = needed? > Would it make sense to say that mixers/switches that support pause = must > support at least certain configs, where endpoints must support other > minimums? >=20 > -- "Available PauseID" >=20 > I find the specification of "Available PauseID" to be very confusing. > Section 8.1 (third paragraph) seems to say that the PauseID in the = PAUSE > request should be taken from the most recently received PAUSED = indication. > But the next paragraph says the value from PAUSED should be = incremented by > one. >=20 > I think the confusion comes from two things. First, the name = "Available > PauseID" is a confusing choice. To me, "available" means I can use it. > But if I understand correctly, I can't use that one for a "new" PAUSE = request. > Perhaps a better term would be "Current PauseID". That would make more > sense if I refer to the "current" value to act on a current pause (or = most recent) > condition, and then have the concept of a "next" > PauseID which would be the current one plus 1. >=20 > I also think it would help to have one section that describes > (non-normatively) all the semantics of PauseID early in section 5 = (before the > concept is first referenced.) >=20 > -- 2.2: Are the definitions in the RTP Taxonomy document necessary to > understand/implement this draft? If so, this should be a normative = reference, > which we would need to call out in the last call. (I'm not saying they = are > required to understand this one--I'm not sure one way or > another.) >=20 > -- 5.3, 3rd paragraph: >=20 > Does this mean the stream receiver may see a PAUSED indication prior = to the > stream actually being paused? (That is, see a paused indication, but = continue to > receive the stream?) I don't think that's the intent, but seeing this = after the > paragraphs on the PAUSED indication makes me wonder. >=20 > *** Things that can be treated as part of IETF Last Call: >=20 > -- I'm not going to push on this, since I assume this was a = well-discussed > compromise in the WG. But it seems to me that having two independent > mechanisms to accomplish the same thing, with one only working in = limited > conditions (TMMBR/TMMBN) adds more complexity that value, and is = likely to > reduce interoperability. >=20 > -- 4.1: "The pause operation is arguably not very time critical" >=20 > This seems to contradict the previous sentence. I assume the point is = that both > are time sensitive, but pause is less so than resume? >=20 > -- 4.3: >=20 > Is it possible for the sender to change the SSRC between the pause and = resume > requests, so that the resume request refers to a stale SSRC value? = Does it hurt > anything if it happens? >=20 > -- 6.3.1, 2nd bullet:"the sender MUST keep > record of which receiver that caused the RTP stream to pause. = If > that receiver sends an RTCP BYE message observed by the sender, > the sender SHALL resume the RTP stream." >=20 > If no other participant objected to the pause in the first place, why = do we > assume that exit of the original pause requestor means the other = participants > want the stream to resume? Why put the burden on the sender to track = this? >=20 > -- 8: "If the messages defined in > this specification are supported in addition to TMMBR/TMMBN, = pause/ > resume signaling MUST use messages from this specification." >=20 > What if one (PTP) participant supports these formats, and the other = only > supports TMMBR/TMMBN? As worded that seems to mean that pause/resume > cannot be used. (i.e. one MUST NOT use TMMBR/TMMBN because it supports > the FCI messages, and the other only understands TMMBR/TMMBN? >=20 > "If the topology is not point-to-point and the messages defined in = this > specification are not supported, pause/resume functionality with > TMMBR/TMMBN MUST NOT be used." >=20 > This MUST NOT seems to be non-constraining. >=20 > -- 8.1, 3rd paragraph: "as indicated by PAUSED" >=20 > ... or REFUSED? >=20 > -- 8.1, 4th from end: >=20 > Can you offer guidance on selecting an appropriate time? >=20 > -- 2nd paragraph from end: >=20 > This is a little confusing. Is the counter-indication really that = local > considerations make it _impossible_ to pause, or is simply = _undesirable_ > sufficient? Is pausing effectively optional? >=20 > Also, shouldn=E2=80=99t this mention the hold off? >=20 > -- 8.2, 2nd paragraph >=20 > Is this true for the locally paused state? If so, how is the PauseID = value > calculated for local pausing. >=20 > -- 3rd paragraph: "PAUSED SHALL contain..." >=20 > I assume this goes into the Type Specific field. If so, it would be = worth explicitly > mentioning that. Also, I assume that implies a fixed-length Type = Specific in a > PAUSED indication? >=20 > --8.4, 3rd paragraph:"receives a RESUME with a PauseID less than the = valid > one, in which case the RESUME SHALL be ignored." >=20 > This seems to conflict with the last sentence in 8.3. It says the = resume is > ignored if it contains a _valid_ PauseID or a value less than the = valid one. >=20 > --8.4, 6th paragraph: >=20 > Can you offer guidance on selecting an appropriate time? >=20 >=20 > -- 15.2: >=20 > Seems like the references for RFCs 3264 and 4560 should be normative. > This draft specified normative behavior for use with SDP and the = offer/answer > model. >=20 > *** Editorial Things: >=20 > -- section 1, paragraph 4, last sentence: >=20 > Long, convoluted sentence. Consider breaking into multiple, simpler = sentences. >=20 > also, s/anyway/still >=20 > -- paragraph 5: >=20 > s/ "As the RTP streams..." / "As the set of RTP streams..." > s/ "... using Extended RTP Profile..." / "... using the Extended RTP = Profile..." >=20 > -- 2nd to last paragraph: "... it is proposed to define..." >=20 > I suggest "This document defines..." >=20 > -- 3.1, three paragraphs starting with "RTCWEB WG's use case..." >=20 > These don't seem specific to this use case. Consider moving it out of = the use > case, or perhaps to the RTP Mixer to Media Sender use case (since that = one > mentions allowing the media sender to signal the receiver that it is = pausing a > stream.) >=20 >=20 > -- 3.2, First paragraph: >=20 > "That is accomplished > through the Mixer originating its=E2=80=99 own streams, identified = by SSRC..." >=20 > s/its'/its >=20 > Also, I seem you mean "identified by _distinct_ SSRC values"? >=20 > -- 3rd paragraph: "request to pause a particular stream" >=20 > request that a particular stream be paused, or request the sender to = pause a > particular stream. >=20 > -- 4th paragraph: "there may be situations that makes it desirable to = the Mixer > to pause some of its sent RTP streams" >=20 > do you mean "desirable _for_ the mixer=E2=80=A6"? (Or do you mean to = say the mixer > desires that the streams be paused? >=20 > -- Figure 3: >=20 > Do B and D ever get mentioned? If not, it would be simpler without = them. >=20 > -- 3.4 >=20 > It=E2=80=99s kind of confusing to find that this section combines both = the unicast and > multicast cases, when the previous two sections separated them. I = think it > would be easier to understand if the information in this section were = split > between 3.2 and 3.3. >=20 > -- 4.1: >=20 > While I recognize that RAI has historically used real-time in this = sense, it=E2=80=99s not > the usual meaning of real-time in the field of computer science. = Consider > replacing =E2=80=9Creal-time=E2=80=9D with = =E2=80=9Ctime-sensitive=E2=80=9D or =E2=80=9Ctime-sensitivity=E2=80=9D = depending on > context. >=20 > -- 4.2: >=20 > s/who/that (both times) > s/likes/needs (or wants) >=20 > -- 4.4, first paragraph, 2nd sentence: >=20 > Long, convoluted sentence. Please consider breaking it down into = simpler > sentences. (This is further confused by the presence of lots of = commas, some of > which separate list members, and some separate clauses.) >=20 > -- 4.5, last sentence: >=20 > I=E2=80=99m confused by this sentence. Do you mean to say, "In this = error condition a > negative acknowledgement may be needed=E2=80=A6" >=20 > -- 4.8, first paragraph: >=20 > Any reason to cite 4566 but not 3261? (Both have been cited earlier in = the > draft.) >=20 > -- 5, 2nd paragraph: "It is proposed..." >=20 > Unless that proposal has not been accepted, consider saying "This = solution re- > uses..." >=20 > -- 5.4, 1st paragraph: "can request to resume... " >=20 > request the sender to resume, or request the resumption of... >=20 > -- paragraph 6: "it cannot be resumed due to local considerations" >=20 > This can be read to say that local considerations may prevent = resumption, but I > think you mean that resumption is prevented by protocol, even if the = sender > would like to resume due to local considerations. >=20 > -- 7th paragraph: "Should such temporal dependency between before and = after > the media was paused be used by the RTP stream sender, it requires > the RTP stream receiver to have saved the sample from before the > pause for successful continued decoding when resuming." >=20 > Do you mean temporal dependency between samples sent before and after = the > media was paused? >=20 > "temporal dependency to before the pause" >=20 > dependency on samples from before the pause? >=20 > -- 6.4, 4th paragraph from end: >=20 > s/"responsible to leave"/"responsible for leaving" >=20 > Figure 5: >=20 > is all of the above (Both the common packet and the FCI formats and = the > intervening text) one figure, or should they be figure 5 and 6? >=20 > -- 8.2, first paragraph: >=20 > Are there other ways to get into those states? Wouldn=E2=80=99t it be = simpler to say the > indication MUST be sent whenever entering the paused or locally paused > states? >=20 > -- 9, first paragraph after Figure 7: "but MAY use existing ccm tmmbr = signaling > [RFC5104] if the limitations in functionality as described in this = specification > coming from such usage are considered acceptable." >=20 > I don't understand what "coming from such usage" means in context. >=20 > -- 9, 2nd paragraph after figure 7: >=20 > s/independent/independently > s/likes/needs (or wants) >=20 >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > avtext mailing list > avtext@ietf.org > https://www.ietf.org/mailman/listinfo/avtext From nobody Tue Jun 16 00:28:34 2015 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B88581B32F6; Tue, 16 Jun 2015 00:28:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.801 X-Spam-Level: X-Spam-Status: No, score=-2.801 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gQZ819uyNYkt; Tue, 16 Jun 2015 00:28:31 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 286AA1B32E2; Tue, 16 Jun 2015 00:28:29 -0700 (PDT) X-AuditID: c1b4fb25-f79b66d000001131-4a-557fd01ce893 Received: from ESESSHC021.ericsson.se (Unknown_Domain [153.88.253.125]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 0B.B7.04401.C10DF755; Tue, 16 Jun 2015 09:28:28 +0200 (CEST) Received: from ESESSMB105.ericsson.se ([169.254.5.230]) by ESESSHC021.ericsson.se ([153.88.183.81]) with mapi id 14.03.0210.002; Tue, 16 Jun 2015 09:28:27 +0200 From: Bo Burman To: Paul Kyzivat , "draft-ietf-avtext-rtp-stream-pause.all@ietf.org" , "avtext@ietf.org" Thread-Topic: SDP review of draft-ietf-avtext-rtp-stream-pause-07 Thread-Index: AQHQo6EjO/DzgweOa0a+ak17/jVwop2uvT9g Date: Tue, 16 Jun 2015 07:28:26 +0000 Message-ID: References: <557870CB.9090800@alum.mit.edu> In-Reply-To: <557870CB.9090800@alum.mit.edu> Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.146] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrKLMWRmVeSWpSXmKPExsUyM+Jvra7MhfpQgynHpC0+3rvBanHuw1RW ixUbDrBaPH20g8WBxePv+w9MHkuW/GQKYIrisklJzcksSy3St0vgyrjU+5KtYIdCxZ0PE9gb GM/IdzFyckgImEh8v/iMBcIWk7hwbz0biC0kcJRR4uQC3S5GLiB7CaNE68GfrCAJNgENifk7 7jKCJEQEdjBK7NhzihEkwSxgJvF1WQ9YkbCAg8TDWZvBJokIOEo8XrkeyjaSaHqxFsxmEVCV mPHvIFg9r4CvRPfqw1CbtSVONu4HmsnBwSmgI9F4LRQkzCggK3H/+z0WiFXiEreezGeCOFpA Ysme88wQtqjEy8f/WCFsJYkfGy6xgIxhFtCUWL9LH6JVUWJK90N2iK2CEidnPmGZwCg2C8nU WQgds5B0zELSsYCRZRWjaHFqcVJuupGxXmpRZnJxcX6eXl5qySZGYDwd3PJbdQfj5TeOhxgF OBiVeHgTftaGCrEmlhVX5h5ilOZgURLnnbE5L1RIID2xJDU7NbUgtSi+qDQntfgQIxMHp1QD o0TFi2/fTS1ymE59E2h9+ni76nKVlJ3TOnmLgpv323/a7blFfZ/nJfkPj4/vfXb8VX6TWV77 qusZS+fmvr/rcmkzz+V9/J+FfVv7tKU2cbPLJMSsnuAZHuDq+Ka2r1byy43TmS2rtveLxPe9 bjnx5cLdcJuHO6foTb1/9b6k18qFmqdmaXkEJyuxFGckGmoxFxUnAgD8qV5siAIAAA== Archived-At: Cc: SDP Directorate Subject: Re: [avtext] SDP review of draft-ietf-avtext-rtp-stream-pause-07 X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jun 2015 07:28:32 -0000 SXQgaXMgYXMgeW91IHNheSBhIG1hdHRlciBvZiB0YXN0ZSBob3cgdGhlIGNvbmZpZ3VyYXRpb24g aXMgZXhwcmVzc2VkLiBJIGNhbiBhZ3JlZSB0aGF0IHRoZSBjaG9zZW4gImNvbmZpZyIgYXBwcm9h Y2ggaXMgbGVzcyBzdWl0YWJsZSBmb3IgYSBodW1hbiBTRFAgcmVhZGVyLCBidXQgaXMgcHJvYmFi bHkgYmV0dGVyIHN1aXRlZCBmb3IgYW4gYXV0b21hdGVkIFNEUCBwYXJzZXIgYW5kIG9mZmVyL2Fu c3dlciBsb2dpYy4NCg0KVGhlIHJlYXNvbnMgdGhlIGF1dGhvcnMgY2hvc2UgdGhlIG51bWJlci1i YXNlZCAiY29uZmlnIiBwYXJhbWV0ZXIgaXMgYmVjYXVzZSB3ZSBmb3VuZCBTRFAgT2ZmZXIvQW5z d2VyIHJ1bGVzIGZvciB0aGUgZm91ciBpbmRpdmlkdWFsIG1lc3NhZ2VzIGluIHRoZSB0d28gZGlm ZmVyZW50IGRpcmVjdGlvbnMgKHNlbmQgc3VwcG9ydCBhbmQgcmVjZWl2ZSBzdXBwb3J0KSB0byBi ZSBoYXJkIHRvIGV4cHJlc3MgaW4gcHJvc2UsIGFuZCBpdCB3YXMgZGlmZmljdWx0IHRvIGNsZWFy bHkgZGVzY3JpYmUgdGhlIHJlc3RyaWN0aW9ucyB0aGF0IG11c3QgYmUgcHV0IHRvIHRoZSBvZmZl cmVyIGFuZCBhbnN3ZXJlciB0byBwcm92aWRlIGEgd29ya2luZyBhbmQgbWVhbmluZ2Z1bCBmdW5j dGlvbmFsaXR5Lg0KDQpUaGVyZSB3YXMgdGh1cyBhIGRlZmluaXRlIG5lZWQgdG8gc2ltcGxpZnku IFRoZSBudW1iZXJlZCAiY29uZmlnIiBlc3BlY2lhbGx5IG1hZGUgdGhlIGRlc2NyaXB0aW9uIHNp Z25pZmljYW50bHkgc2hvcnRlciwgbW9yZSBzdHJ1Y3R1cmVkIGFuZCBjbGVhciBpbiB3aGF0IG1l c3NhZ2VzIGFuZCBkaXJlY3Rpb25zIG11c3QgYmUgc3VwcG9ydGVkIGluIGFuIGFuc3dlciwgZ2l2 ZW4gYSBjZXJ0YWluIHN1cHBvcnQgb2YgbWVzc2FnZXMgYW5kIGRpcmVjdGlvbnMgaW4gdGhlIG9m ZmVyLg0KDQpXZSBjb3VsZCBvZiBjb3Vyc2UgZ28gYmFjayBhbmQgdHJ5IHRvIGRlc2NyaWJlIHRo ZSBwZXItbWVzc2FnZS1wZXItZGlyZWN0aW9uIGFwcHJvYWNoIGFnYWluLCBidXQgdW5sZXNzIHRo ZXJlJ3MgY29uc2Vuc3VzIHRoYXQgdGhlICJjb25maWciIGFwcHJvYWNoIGlzIGhhcmQgdG8gdW5k ZXJzdGFuZCwgaGFyZCB0byB1c2Ugb3IgZXZlbiBicm9rZW4sIEknbSBwZXJzb25hbGx5IGhlc2l0 YW50IHRvIGRvIHRoYXQgZ2l2ZW4gdGhhdCB3ZSBhbHJlYWR5IHRyaWVkIGFuZCBmYWlsZWQuDQoN CkNoZWVycywNCkJvDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogUGF1 bCBLeXppdmF0IFttYWlsdG86cGt5eml2YXRAYWx1bS5taXQuZWR1XQ0KPiBTZW50OiBkZW4gMTAg anVuaSAyMDE1IDE5OjE2DQo+IFRvOiBkcmFmdC1pZXRmLWF2dGV4dC1ydHAtc3RyZWFtLXBhdXNl LmFsbEBpZXRmLm9yZzsgYXZ0ZXh0QGlldGYub3JnDQo+IENjOiBTRFAgRGlyZWN0b3JhdGUNCj4g U3ViamVjdDogU0RQIHJldmlldyBvZiBkcmFmdC1pZXRmLWF2dGV4dC1ydHAtc3RyZWFtLXBhdXNl LTA3DQo+IA0KPiBJIGFtIHRoZSBhc3NpZ25lZCBTRFAgZGlyZWN0b3JhdGUgcmV2aWV3ZXIgZm9y IHRoaXMgZHJhZnQuDQo+IEZvciBiYWNrZ3JvdW5kIG9uIHRoZSBTRFAgZGlyZWN0b3JhdGUsIHBs ZWFzZSBzZWUgdGhlIEZBUSBhdCBodHRwOi8vd3d3LmlldGYub3JnL2llc2cvZGlyZWN0b3JhdGUv c2RwLmh0bWwNCj4gDQo+IFBsZWFzZSB3YWl0IGZvciBkaXJlY3Rpb24gZnJvbSB5b3VyIGRvY3Vt ZW50IHNoZXBoZXJkIG9yIEFEIGJlZm9yZSBwb3N0aW5nIGEgbmV3IHZlcnNpb24gb2YgdGhlIGRy YWZ0Lg0KPiANCj4gU3VtbWFyeToNCj4gDQo+IFRoZSBTRFAgYXNwZWN0cyBvZiB0aGlzIGRyYWZ0 IGFyZSB3ZWxsIHdyaXR0ZW4gYW5kIGNsZWFyLiBJbiBteSBvcGluaW9uIGl0ICpjYW4qIGJlIHB1 Ymxpc2hlZCBpbiB0aGlzIGZvcm0uDQo+IA0KPiBIb3dldmVyLCBJIGRvIGhhdmUgY29uY2VybiBh Ym91dCBvbmUgYXNwZWN0IC0gdGhhdCB0aGUgbWFubmVyIG9mIGNvbmZpZ3VyaW5nIHRoZSBzdXBw b3J0ZWQgb3B0aW9ucyBvZiB0aGlzIGZlYXR1cmUgaXMNCj4gb2JzY3VyZSBhbmQgY29uZnVzaW5n LiAoVGhpcyBpcyBvZiBjb3Vyc2UgYSBtYXR0ZXIgb2YgdGFzdGUuKQ0KPiANCj4gRGV0YWlsczoN Cj4gDQo+IEkgaGF2ZSBjb25jZXJucyBhYm91dCB0aGUgd2F5IHRoZSBjb25maWd1cmF0aW9uIG9m IG9wdGlvbnMgaXMgc3BlY2lmaWVkIHVzaW5nIGEgbnVtZXJpYyB2YWx1ZS4gSSBjYW4gc2VlIGhv dyB0aGF0IG1pZ2h0DQo+IGJlIHJlYXNvbmFibGUgaWYgdGhlIG51bWJlcnMgcmVwcmVzZW50ZWQg YSBwdXJlIGhpZXJhcmNoeS4gQnV0IHRoYXQgc2VlbXMgbm90IHRvIGJlIHRoZSBjYXNlLg0KPiBU aGUgcnVsZXMgZm9yIHZhbGlkIGFuc3dlcnMgYXJlIHF1aXRlIGNvbXBsZXguIChJdCBpc24ndCBz b21ldGhpbmcgdGhhdCBjYW4gYmUgZWFzaWx5IHJlbWVtYmVyZWQuKSBUaGlzIGlzIGJlY2F1c2Ug ZWFjaA0KPiBudW1iZXIgcmVwcmVzZW50cyBhIHBhcnRpY3VsYXIgY29tYmluYXRpb24gb2Ygc2Vt aS1pbmRlcGVuZGVudCBwcm9wZXJ0aWVzLCBlYWNoIG9mIHdoaWNoIGhhcyBzZXBhcmF0ZSBydWxl cyBmb3INCj4gYW5zd2VycyB2cy4gb2ZmZXJzLg0KPiANCj4gSXQgc2VlbXMgdG8gbWUgdGhhdCBp dCB3b3VsZCBiZSBiZXR0ZXIgdG8gY29uZmlndXJlIHRoZXNlIGRpc3RpbmN0IHByb3BlcnRpZXMg aW5kZXBlbmRlbnRseS4gUGVyaGFwcyBqdXN0IGRlY2xhcmUgZWFjaCBvZg0KPiB7UEFVU0UsUkVT VU1FLFBBVVNFRCxSRUZVU0VEfSB0aGF0IGNhbiBiZSBzZW50IGFuZCByZWNlaXZlZC4gKEFuZCBm b3IgY29udmVuaWVuY2UsIHBlcmhhcHMgc29tZSBleHRyYSBrZXl3b3Jkcw0KPiBmb3IgY29tbW9u IGNvbWJpbmF0aW9ucy4gKEUuZy4NCj4gImFsbCIuKSBUaGVuIHRoZSBydWxlcyBmb3IgdmFsaWQg YW5zd2VycyBmb3IgYSBnaXZlbiBvZmZlciB3b3VsZCBiZSBlYXN5IHRvIHN0YXRlIGFuZCB1bmRl cnN0YW5kLg0KPiANCj4gCVRoYW5rcywNCj4gCVBhdWwgS3l6aXZhdCwgZm9yIHRoZSBTRFAgRGly ZWN0b3JhdGUNCg== From nobody Tue Jun 16 08:26:39 2015 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CCCD1B3ADC for ; Tue, 16 Jun 2015 08:26:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VW9u7wj43Lf5 for ; Tue, 16 Jun 2015 08:26:06 -0700 (PDT) Received: from resqmta-ch2-05v.sys.comcast.net (resqmta-ch2-05v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:37]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E22751B3ADA for ; Tue, 16 Jun 2015 08:26:05 -0700 (PDT) Received: from resomta-ch2-12v.sys.comcast.net ([69.252.207.108]) by resqmta-ch2-05v.sys.comcast.net with comcast id h3Qf1q0082LrikM013S5eP; Tue, 16 Jun 2015 15:26:05 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-ch2-12v.sys.comcast.net with comcast id h3S41q00L3Ge9ey013S4cc; Tue, 16 Jun 2015 15:26:05 +0000 Message-ID: <5580400B.5050902@alum.mit.edu> Date: Tue, 16 Jun 2015 11:26:03 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Bo Burman , "draft-ietf-avtext-rtp-stream-pause.all@ietf.org" , "avtext@ietf.org" References: <557870CB.9090800@alum.mit.edu> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1434468365; bh=U2R48OMETyp1OVHL3KdLkz3fAqW1V1zuLdJVDwAoPK4=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=N9MmiTQHySkMCGPoQbX9tJ0Cg1+U6YcWP28OILViTaVqMpJc0x/d7BHjQAdiCMkZU xPz9Ot1l3UQFcwt4qhSCVVVMzFD8qeTHiZl0OCgXtaz8S6NlQse8xMCK13jztXVznH Ney14LP7n85mWxjpN0waDHxl5JsoUsizTLH+wAyvzTmktB0LmLlGHLSoZQ6KR3pdXR dAJxeZXraxkBIbK21ILoUdqFam0UAjB6YeRkTch8Iy840F4ukGg+R1hCrxkf+lVl5S uH+43Wh5OdPok33tacTIqEqLwAB7SBlrRyhgxeVExewrdUQ6mNy1KhDMXTvuZo6cwg E+4TEl59r9s7w== Archived-At: X-Mailman-Approved-At: Tue, 16 Jun 2015 08:26:38 -0700 Cc: SDP Directorate Subject: Re: [avtext] SDP review of draft-ietf-avtext-rtp-stream-pause-07 X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jun 2015 15:26:07 -0000 On 6/16/15 3:28 AM, Bo Burman wrote: > It is as you say a matter of taste how the configuration is expressed. I can agree that the chosen "config" approach is less suitable for a human SDP reader, but is probably better suited for an automated SDP parser and offer/answer logic. > > The reasons the authors chose the number-based "config" parameter is because we found SDP Offer/Answer rules for the four individual messages in the two different directions (send support and receive support) to be hard to express in prose, and it was difficult to clearly describe the restrictions that must be put to the offerer and answerer to provide a working and meaningful functionality. > > There was thus a definite need to simplify. The numbered "config" especially made the description significantly shorter, more structured and clear in what messages and directions must be supported in an answer, given a certain support of messages and directions in the offer. > > We could of course go back and try to describe the per-message-per-direction approach again, but unless there's consensus that the "config" approach is hard to understand, hard to use or even broken, I'm personally hesitant to do that given that we already tried and failed. At the end of the day it is the wg, the ADs, and the IESG that should decide this. I expressed an opinion, but it is only that. Thanks, Paul > Cheers, > Bo > >> -----Original Message----- >> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] >> Sent: den 10 juni 2015 19:16 >> To: draft-ietf-avtext-rtp-stream-pause.all@ietf.org; avtext@ietf.org >> Cc: SDP Directorate >> Subject: SDP review of draft-ietf-avtext-rtp-stream-pause-07 >> >> I am the assigned SDP directorate reviewer for this draft. >> For background on the SDP directorate, please see the FAQ at http://www.ietf.org/iesg/directorate/sdp.html >> >> Please wait for direction from your document shepherd or AD before posting a new version of the draft. >> >> Summary: >> >> The SDP aspects of this draft are well written and clear. In my opinion it *can* be published in this form. >> >> However, I do have concern about one aspect - that the manner of configuring the supported options of this feature is >> obscure and confusing. (This is of course a matter of taste.) >> >> Details: >> >> I have concerns about the way the configuration of options is specified using a numeric value. I can see how that might >> be reasonable if the numbers represented a pure hierarchy. But that seems not to be the case. >> The rules for valid answers are quite complex. (It isn't something that can be easily remembered.) This is because each >> number represents a particular combination of semi-independent properties, each of which has separate rules for >> answers vs. offers. >> >> It seems to me that it would be better to configure these distinct properties independently. Perhaps just declare each of >> {PAUSE,RESUME,PAUSED,REFUSED} that can be sent and received. (And for convenience, perhaps some extra keywords >> for common combinations. (E.g. >> "all".) Then the rules for valid answers for a given offer would be easy to state and understand. >> >> Thanks, >> Paul Kyzivat, for the SDP Directorate From nobody Tue Jun 16 08:33:24 2015 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 915BF1B3ADB; Tue, 16 Jun 2015 08:33:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QZ-ksnKUfffK; Tue, 16 Jun 2015 08:33:11 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0756D1B2DDD; Tue, 16 Jun 2015 08:32:58 -0700 (PDT) Received: from [172.20.10.2] (mobile-166-177-122-254.mycingular.net [166.177.122.254] (may be forged)) (authenticated bits=0) by nostrum.com (8.15.1/8.14.9) with ESMTPSA id t5GFWpJS087306 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 16 Jun 2015 10:32:53 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host mobile-166-177-122-254.mycingular.net [166.177.122.254] (may be forged) claimed to be [172.20.10.2] From: "Ben Campbell" To: "Bo Burman" Date: Tue, 16 Jun 2015 10:32:46 -0500 Message-ID: <2E4A4B48-9FDE-40B4-B5D8-BC33514CA30E@nostrum.com> In-Reply-To: <5580400B.5050902@alum.mit.edu> References: <557870CB.9090800@alum.mit.edu> <5580400B.5050902@alum.mit.edu> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.1r5084) Archived-At: Cc: SDP Directorate , "avtext@ietf.org" , "draft-ietf-avtext-rtp-stream-pause.all@ietf.org" , Paul Kyzivat Subject: Re: [avtext] SDP review of draft-ietf-avtext-rtp-stream-pause-07 X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jun 2015 15:33:17 -0000 On 16 Jun 2015, at 10:26, Paul Kyzivat wrote: > On 6/16/15 3:28 AM, Bo Burman wrote: >> It is as you say a matter of taste how the configuration is >> expressed. I can agree that the chosen "config" approach is less >> suitable for a human SDP reader, but is probably better suited for an >> automated SDP parser and offer/answer logic. >> >> The reasons the authors chose the number-based "config" parameter is >> because we found SDP Offer/Answer rules for the four individual >> messages in the two different directions (send support and receive >> support) to be hard to express in prose, and it was difficult to >> clearly describe the restrictions that must be put to the offerer and >> answerer to provide a working and meaningful functionality. >> >> There was thus a definite need to simplify. The numbered "config" >> especially made the description significantly shorter, more >> structured and clear in what messages and directions must be >> supported in an answer, given a certain support of messages and >> directions in the offer. >> >> We could of course go back and try to describe the >> per-message-per-direction approach again, but unless there's >> consensus that the "config" approach is hard to understand, hard to >> use or even broken, I'm personally hesitant to do that given that we >> already tried and failed. > > At the end of the day it is the wg, the ADs, and the IESG that should > decide this. I expressed an opinion, but it is only that. As I mentioned in my AD review, I am also concerned about the complexity of this--but I'm not sure expressing the config per-message helps. Both approaches seem to encourage non-interoperable implementations. I'm sure this has already been discussed, but I'd like to see opinions on how much configurability is really required. For example, do the use cases mentioned as supporting the config parameter really need all these options? > > Thanks, > Paul > > >> Cheers, >> Bo >> >>> -----Original Message----- >>> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] >>> Sent: den 10 juni 2015 19:16 >>> To: draft-ietf-avtext-rtp-stream-pause.all@ietf.org; avtext@ietf.org >>> Cc: SDP Directorate >>> Subject: SDP review of draft-ietf-avtext-rtp-stream-pause-07 >>> >>> I am the assigned SDP directorate reviewer for this draft. >>> For background on the SDP directorate, please see the FAQ at >>> http://www.ietf.org/iesg/directorate/sdp.html >>> >>> Please wait for direction from your document shepherd or AD before >>> posting a new version of the draft. >>> >>> Summary: >>> >>> The SDP aspects of this draft are well written and clear. In my >>> opinion it *can* be published in this form. >>> >>> However, I do have concern about one aspect - that the manner of >>> configuring the supported options of this feature is >>> obscure and confusing. (This is of course a matter of taste.) >>> >>> Details: >>> >>> I have concerns about the way the configuration of options is >>> specified using a numeric value. I can see how that might >>> be reasonable if the numbers represented a pure hierarchy. But that >>> seems not to be the case. >>> The rules for valid answers are quite complex. (It isn't something >>> that can be easily remembered.) This is because each >>> number represents a particular combination of semi-independent >>> properties, each of which has separate rules for >>> answers vs. offers. >>> >>> It seems to me that it would be better to configure these distinct >>> properties independently. Perhaps just declare each of >>> {PAUSE,RESUME,PAUSED,REFUSED} that can be sent and received. (And >>> for convenience, perhaps some extra keywords >>> for common combinations. (E.g. >>> "all".) Then the rules for valid answers for a given offer would be >>> easy to state and understand. >>> >>> Thanks, >>> Paul Kyzivat, for the SDP Directorate From nobody Tue Jun 16 17:21:58 2015 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 420481B2FB6 for ; Tue, 16 Jun 2015 17:21:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ozce-8rHiqaA for ; Tue, 16 Jun 2015 17:21:54 -0700 (PDT) Received: from cserver5.myshophosting.com (cserver5.myshophosting.com [175.107.161.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB2161A8A48 for ; Tue, 16 Jun 2015 17:21:53 -0700 (PDT) Received: from ppp118-209-82-127.lns20.mel4.internode.on.net ([118.209.82.127]:50108 helo=[192.168.1.22]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.85) (envelope-from ) id 1Z5170-001Q7S-BG for avtext@ietf.org; Wed, 17 Jun 2015 10:21:50 +1000 Message-ID: <5580BD99.2090606@nteczone.com> Date: Wed, 17 Jun 2015 10:21:45 +1000 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: avtext@ietf.org References: <557870CB.9090800@alum.mit.edu> <5580400B.5050902@alum.mit.edu> <2E4A4B48-9FDE-40B4-B5D8-BC33514CA30E@nostrum.com> In-Reply-To: <2E4A4B48-9FDE-40B4-B5D8-BC33514CA30E@nostrum.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cserver5.myshophosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - nteczone.com X-Get-Message-Sender-Via: cserver5.myshophosting.com: authenticated_id: christian.groves@nteczone.com X-Source: X-Source-Args: X-Source-Dir: Archived-At: Subject: Re: [avtext] SDP review of draft-ietf-avtext-rtp-stream-pause-07 X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jun 2015 00:21:56 -0000 Hello, I agree with Bo's response. Originally this was specified by a per message response but the text around it was very complex. Its not just a case of saying that an endpoint supports a message. There are certain message combinations that don't make sense. So you would end up having to list all the combinations that don't make sense. The draft then has to enforce the valid scenarios via procedural text because writing the ABNF would be a pain. The approach taken by the draft in figure 6 is simple and concise. The endpoint simply sends the config number of the valid set of messages it supports. A receiving endpoint doesn't have to parse the SDP to see if the set of advertised messages is actually valid. The number of configurations is due to states local pause, local resume, remote pause and remote resume and optionality in what the local and remote endpoints support. E.g. an endpoint may only support local pause by sending a PAUSED indication (config 8), an endpoint may support local and remote pausing and supports all messages (config 1) or something in between, like it may only request remote pause (by sending pause/resume and receiving PAUSED/REFUSED indications) but not support local pause (config 4). With respect to interop, Fig.8 of the draft makes it clear what configurations may be permitted in an SDP answer. Part of this is to ensure commonality between local and remote endpoints. I wouldn't like to try to draft a table like this for the "per message" approach. Regards, Christian On 17/06/2015 1:32 AM, Ben Campbell wrote: > > > On 16 Jun 2015, at 10:26, Paul Kyzivat wrote: > >> On 6/16/15 3:28 AM, Bo Burman wrote: >>> It is as you say a matter of taste how the configuration is >>> expressed. I can agree that the chosen "config" approach is less >>> suitable for a human SDP reader, but is probably better suited for >>> an automated SDP parser and offer/answer logic. >>> >>> The reasons the authors chose the number-based "config" parameter is >>> because we found SDP Offer/Answer rules for the four individual >>> messages in the two different directions (send support and receive >>> support) to be hard to express in prose, and it was difficult to >>> clearly describe the restrictions that must be put to the offerer >>> and answerer to provide a working and meaningful functionality. >>> >>> There was thus a definite need to simplify. The numbered "config" >>> especially made the description significantly shorter, more >>> structured and clear in what messages and directions must be >>> supported in an answer, given a certain support of messages and >>> directions in the offer. >>> >>> We could of course go back and try to describe the >>> per-message-per-direction approach again, but unless there's >>> consensus that the "config" approach is hard to understand, hard to >>> use or even broken, I'm personally hesitant to do that given that we >>> already tried and failed. >> >> At the end of the day it is the wg, the ADs, and the IESG that should >> decide this. I expressed an opinion, but it is only that. > > As I mentioned in my AD review, I am also concerned about the > complexity of this--but I'm not sure expressing the config per-message > helps. Both approaches seem to encourage non-interoperable > implementations. > > I'm sure this has already been discussed, but I'd like to see opinions > on how much configurability is really required. For example, do the > use cases mentioned as supporting the config parameter really need all > these options? > >> >> Thanks, >> Paul >> >> >>> Cheers, >>> Bo >>> >>>> -----Original Message----- >>>> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] >>>> Sent: den 10 juni 2015 19:16 >>>> To: draft-ietf-avtext-rtp-stream-pause.all@ietf.org; avtext@ietf.org >>>> Cc: SDP Directorate >>>> Subject: SDP review of draft-ietf-avtext-rtp-stream-pause-07 >>>> >>>> I am the assigned SDP directorate reviewer for this draft. >>>> For background on the SDP directorate, please see the FAQ at >>>> http://www.ietf.org/iesg/directorate/sdp.html >>>> >>>> Please wait for direction from your document shepherd or AD before >>>> posting a new version of the draft. >>>> >>>> Summary: >>>> >>>> The SDP aspects of this draft are well written and clear. In my >>>> opinion it *can* be published in this form. >>>> >>>> However, I do have concern about one aspect - that the manner of >>>> configuring the supported options of this feature is >>>> obscure and confusing. (This is of course a matter of taste.) >>>> >>>> Details: >>>> >>>> I have concerns about the way the configuration of options is >>>> specified using a numeric value. I can see how that might >>>> be reasonable if the numbers represented a pure hierarchy. But that >>>> seems not to be the case. >>>> The rules for valid answers are quite complex. (It isn't something >>>> that can be easily remembered.) This is because each >>>> number represents a particular combination of semi-independent >>>> properties, each of which has separate rules for >>>> answers vs. offers. >>>> >>>> It seems to me that it would be better to configure these distinct >>>> properties independently. Perhaps just declare each of >>>> {PAUSE,RESUME,PAUSED,REFUSED} that can be sent and received. (And >>>> for convenience, perhaps some extra keywords >>>> for common combinations. (E.g. >>>> "all".) Then the rules for valid answers for a given offer would be >>>> easy to state and understand. >>>> >>>> Thanks, >>>> Paul Kyzivat, for the SDP Directorate > > _______________________________________________ > avtext mailing list > avtext@ietf.org > https://www.ietf.org/mailman/listinfo/avtext > From nobody Thu Jun 18 13:56:49 2015 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08F881A0065; Thu, 18 Jun 2015 13:56:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Aa6bWFd-zgvC; Thu, 18 Jun 2015 13:56:44 -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 CDC721B352A; Thu, 18 Jun 2015 13:56:44 -0700 (PDT) Received: from [10.0.1.23] (cpe-70-119-203-4.tx.res.rr.com [70.119.203.4]) (authenticated bits=0) by nostrum.com (8.15.1/8.14.9) with ESMTPSA id t5IKuWOw095747 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Thu, 18 Jun 2015 15:56:43 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-70-119-203-4.tx.res.rr.com [70.119.203.4] claimed to be [10.0.1.23] From: "Ben Campbell" To: draft-ietf-avtext-rtp-stream-pause.all@ietf.org, avtext@ietf.org Date: Thu, 18 Jun 2015 15:56:32 -0500 Message-ID: <14F5435A-E14C-48E3-BAC2-5BF2CB7D6F33@nostrum.com> In-Reply-To: <257ACC1A-936C-4C32-81E2-E2A88512B20A@nostrum.com> References: <257ACC1A-936C-4C32-81E2-E2A88512B20A@nostrum.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Mailer: MailMate (1.9.1r5084) Archived-At: Subject: Re: [avtext] AD Evaluation of draft-ietf-avtext-rtp-stream-pause-07 X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jun 2015 20:56:48 -0000 Hi, I have a few comments on further reflection: I notice that there are IPR declarations against the original version (prior to wg acceptance.) The license terms allow the possibility of royalties. I also see that the shepherd writeup mentions that avtext discussed these and are okay with them. However, this draft references some RTCWEB requirements as partial motivation. Have the IPR disclosures been discussed with RTCWEB, to confirm that they would be willing to use a mechanism with those disclosures? On my comments about the "config" parameter: The root of my concern is not the mechanism for negotiating partial support, but the number of config "profiles". It seems like this could encourage implementations that cannot use the mechanism interoperably. For example, the draft shows use cases where a conference bridge might need to ask an endpoint to pause. If people build endpoints that only support 2 or 3, then this would not be possible. So my real question is, does the mechanism really need all 8 modes? Are there known situations where an implementer would choose not to implement this mechanism if one of the modes didn't exist? Some of them seem to have fairly subtle differences (e.g. whether the device may locally pause or not.) Ben. On 15 Jun 2015, at 22:18, Ben Campbell wrote: > Hi, > > Here's my AD Evaluation of draft-ietf-avtext-rtp-stream-pause-07. I've > broken it down between things I'd like to see discussed prior to IETF > last call, things I think can be worked in parallel to the last call, > and things that are just editorial. > > Thanks! > > Ben. > > *** Things to discuss before IETF Last Call: > > -- Partial Support Configuration > > I concur with Paul's SDP review that the current method of configuring > partial support is confusing and error prone. I will go further and > say I am concerned that the whole idea of partial support can really > impact interoperability. It seems like there are many combinations > where participants can simply fail to work (where failing to work > means they cannot use this extension at all.) Have you had people say > they are willing to implement some but not all features of this spec? > Do the features cause harm if a participant tries to send them to a > peer that doesn't understand them? (This is a bit of RTCP CCM > esoterica that I do not know off-hand: Are recipients expected to > ignore things they don't understand?) > > I can see a switch or mixer declaring that it will never send PAUSE or > RESUME. But it seems like encouraging (or even allowing) partial > support for “endpoint” participants will hurt interoperability. > For example, you have reason why a mixer or switch might choose to > send pause—but that will never work if the endpoints don’t support > receiving it. > > So, when section 9 says " 'config' allows for partial implementation > of this specification according to the different roles in the use > cases section", do you mean to constrain the use of "config" to only > those roles where it is needed? Would it make sense to say that > mixers/switches that support pause must support at least certain > configs, where endpoints must support other minimums? > > -- "Available PauseID" > > I find the specification of "Available PauseID" to be very confusing. > Section 8.1 (third paragraph) seems to say that the PauseID in the > PAUSE request should be taken from the most recently received PAUSED > indication. But the next paragraph says the value from PAUSED should > be incremented by one. > > I think the confusion comes from two things. First, the name > "Available PauseID" is a confusing choice. To me, "available" means I > can use it. But if I understand correctly, I can't use that one for a > "new" PAUSE request. Perhaps a better term would be "Current PauseID". > That would make more sense if I refer to the "current" value to act on > a current pause (or most recent) condition, and then have the concept > of a "next" PauseID which would be the current one plus 1. > > I also think it would help to have one section that describes > (non-normatively) all the semantics of PauseID early in section 5 > (before the concept is first referenced.) > > -- 2.2: Are the definitions in the RTP Taxonomy document necessary to > understand/implement this draft? If so, this should be a normative > reference, which we would need to call out in the last call. (I'm not > saying they are required to understand this one--I'm not sure one way > or another.) > > -- 5.3, 3rd paragraph: > > Does this mean the stream receiver may see a PAUSED indication prior > to the stream actually being paused? (That is, see a paused > indication, but continue to receive the stream?) I don't think that's > the intent, but seeing this after the paragraphs on the PAUSED > indication makes me wonder. > > *** Things that can be treated as part of IETF Last Call: > > -- I'm not going to push on this, since I assume this was a > well-discussed compromise in the WG. But it seems to me that having > two independent mechanisms to accomplish the same thing, with one only > working in limited conditions (TMMBR/TMMBN) adds more complexity that > value, and is likely to reduce interoperability. > > -- 4.1: "The pause operation is arguably not very time critical" > > This seems to contradict the previous sentence. I assume the point is > that both are time sensitive, but pause is less so than resume? > > -- 4.3: > > Is it possible for the sender to change the SSRC between the pause and > resume requests, so that the resume request refers to a stale SSRC > value? Does it hurt anything if it happens? > > -- 6.3.1, 2nd bullet:"the sender MUST keep > record of which receiver that caused the RTP stream to pause. If > that receiver sends an RTCP BYE message observed by the sender, > the sender SHALL resume the RTP stream." > > If no other participant objected to the pause in the first place, why > do we assume that exit of the original pause requestor means the other > participants want the stream to resume? Why put the burden on the > sender to track this? > > -- 8: "If the messages defined in > this specification are supported in addition to TMMBR/TMMBN, pause/ > resume signaling MUST use messages from this specification." > > What if one (PTP) participant supports these formats, and the other > only supports TMMBR/TMMBN? As worded that seems to mean that > pause/resume cannot be used. (i.e. one MUST NOT use TMMBR/TMMBN > because it supports the FCI messages, and the other only understands > TMMBR/TMMBN? > > "If the topology is not point-to-point and the messages defined in > this > specification are not supported, pause/resume functionality with > TMMBR/TMMBN MUST NOT be used." > > This MUST NOT seems to be non-constraining. > > -- 8.1, 3rd paragraph: "as indicated by PAUSED" > > ... or REFUSED? > > -- 8.1, 4th from end: > > Can you offer guidance on selecting an appropriate time? > > -- 2nd paragraph from end: > > This is a little confusing. Is the counter-indication really that > local considerations make it _impossible_ to pause, or is simply > _undesirable_ sufficient? Is pausing effectively optional? > > Also, shouldn’t this mention the hold off? > > -- 8.2, 2nd paragraph > > Is this true for the locally paused state? If so, how is the PauseID > value calculated for local pausing. > > -- 3rd paragraph: "PAUSED SHALL contain..." > > I assume this goes into the Type Specific field. If so, it would be > worth explicitly mentioning that. Also, I assume that implies a > fixed-length Type Specific in a PAUSED indication? > > --8.4, 3rd paragraph:"receives a RESUME with a PauseID less than the > valid one, in which case the RESUME SHALL be ignored." > > This seems to conflict with the last sentence in 8.3. It says the > resume is ignored if it contains a _valid_ PauseID or a value less > than the valid one. > > --8.4, 6th paragraph: > > Can you offer guidance on selecting an appropriate time? > > > -- 15.2: > > Seems like the references for RFCs 3264 and 4560 should be normative. > This draft specified normative behavior for use with SDP and the > offer/answer model. > > *** Editorial Things: > > -- section 1, paragraph 4, last sentence: > > Long, convoluted sentence. Consider breaking into multiple, simpler > sentences. > > also, s/anyway/still > > -- paragraph 5: > > s/ "As the RTP streams..." / "As the set of RTP streams..." > s/ "... using Extended RTP Profile..." / "... using the Extended RTP > Profile..." > > -- 2nd to last paragraph: "... it is proposed to define..." > > I suggest "This document defines..." > > -- 3.1, three paragraphs starting with "RTCWEB WG's use case..." > > These don't seem specific to this use case. Consider moving it out of > the use case, or perhaps to the RTP Mixer to Media Sender use case > (since that one mentions allowing the media sender to signal the > receiver that it is pausing a stream.) > > > -- 3.2, First paragraph: > > "That is accomplished > through the Mixer originating its’ own streams, identified by > SSRC..." > > s/its'/its > > Also, I seem you mean "identified by _distinct_ SSRC values"? > > -- 3rd paragraph: "request to pause a particular stream" > > request that a particular stream be paused, or request the sender to > pause a particular stream. > > -- 4th paragraph: "there may be situations that makes it desirable to > the Mixer to pause some of its sent RTP streams" > > do you mean "desirable _for_ the mixer…"? (Or do you mean to say the > mixer desires that the streams be paused? > > -- Figure 3: > > Do B and D ever get mentioned? If not, it would be simpler without > them. > > -- 3.4 > > It’s kind of confusing to find that this section combines both the > unicast and multicast cases, when the previous two sections separated > them. I think it would be easier to understand if the information in > this section were split between 3.2 and 3.3. > > -- 4.1: > > While I recognize that RAI has historically used real-time in this > sense, it’s not the usual meaning of real-time in the field of > computer science. Consider replacing “real-time” with > “time-sensitive” or “time-sensitivity” depending on context. > > -- 4.2: > > s/who/that (both times) > s/likes/needs (or wants) > > -- 4.4, first paragraph, 2nd sentence: > > Long, convoluted sentence. Please consider breaking it down into > simpler sentences. (This is further confused by the presence of lots > of commas, some of which separate list members, and some separate > clauses.) > > -- 4.5, last sentence: > > I’m confused by this sentence. Do you mean to say, "In this error > condition a negative acknowledgement may be needed…" > > -- 4.8, first paragraph: > > Any reason to cite 4566 but not 3261? (Both have been cited earlier in > the draft.) > > -- 5, 2nd paragraph: "It is proposed..." > > Unless that proposal has not been accepted, consider saying "This > solution re-uses..." > > -- 5.4, 1st paragraph: "can request to resume... " > > request the sender to resume, or request the resumption of... > > -- paragraph 6: "it cannot be resumed due to local considerations" > > This can be read to say that local considerations may prevent > resumption, but I think you mean that resumption is prevented by > protocol, even if the sender would like to resume due to local > considerations. > > -- 7th paragraph: "Should such temporal dependency between before and > after > the media was paused be used by the RTP stream sender, it requires > the RTP stream receiver to have saved the sample from before the > pause for successful continued decoding when resuming." > > Do you mean temporal dependency between samples sent before and after > the media was paused? > > "temporal dependency to before the pause" > > dependency on samples from before the pause? > > -- 6.4, 4th paragraph from end: > > s/"responsible to leave"/"responsible for leaving" > > Figure 5: > > is all of the above (Both the common packet and the FCI formats and > the intervening text) one figure, or should they be figure 5 and 6? > > -- 8.2, first paragraph: > > Are there other ways to get into those states? Wouldn’t it be > simpler to say the indication MUST be sent whenever entering the > paused or locally paused states? > > -- 9, first paragraph after Figure 7: "but MAY use existing ccm tmmbr > signaling [RFC5104] if the limitations in functionality as described > in this specification coming from such usage are considered > acceptable." > > I don't understand what "coming from such usage" means in context. > > -- 9, 2nd paragraph after figure 7: > > s/independent/independently > s/likes/needs (or wants) > > > > > > > _______________________________________________ > avtext mailing list > avtext@ietf.org > https://www.ietf.org/mailman/listinfo/avtext From nobody Mon Jun 22 09:42:11 2015 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8853A1B3038; Mon, 22 Jun 2015 09:42:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.501 X-Spam-Level: X-Spam-Status: No, score=-1.501 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aHH6FMmP-CAC; Mon, 22 Jun 2015 09:42:07 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B28811B3035; Mon, 22 Jun 2015 09:42:05 -0700 (PDT) X-AuditID: c1b4fb25-f79b66d000001131-9d-55883adbda56 Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.253.125]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 8D.5D.04401.BDA38855; Mon, 22 Jun 2015 18:42:04 +0200 (CEST) Received: from ESESSMB105.ericsson.se ([169.254.5.230]) by ESESSHC007.ericsson.se ([153.88.183.39]) with mapi id 14.03.0210.002; Mon, 22 Jun 2015 18:42:03 +0200 From: Bo Burman To: Ben Campbell , "draft-ietf-avtext-rtp-stream-pause.all@ietf.org" , "avtext@ietf.org" Thread-Topic: [avtext] AD Evaluation of draft-ietf-avtext-rtp-stream-pause-07 Thread-Index: AQHQp+M1de23osNNK0+7Tf45n1U2852yoTUAgAXnfsA= Date: Mon, 22 Jun 2015 16:42:02 +0000 Message-ID: References: <257ACC1A-936C-4C32-81E2-E2A88512B20A@nostrum.com> <14F5435A-E14C-48E3-BAC2-5BF2CB7D6F33@nostrum.com> In-Reply-To: <14F5435A-E14C-48E3-BAC2-5BF2CB7D6F33@nostrum.com> Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.147] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrKLMWRmVeSWpSXmKPExsUyM+Jvre4dq45Qg8erGS0+3rvBajG/8zS7 xbkPU1kdmD2WLPnJ5DFr5xOWAKYoLpuU1JzMstQifbsErozJbc9ZClYcZayY+9a1gXHBAcYu Rk4OCQETiZlfjkDZYhIX7q1n62Lk4hASOMoo8XHbKihnCaPE0rdrWEGq2AQ0JObvuMsIkhAR 2MQoMePKd3aQhLCAj8SCKxeAOjiAEr4S7+bpgIRFBKwkXr2+BVbCIqAqsebXNrBtvEAl9/Ye YwOxhQSKJVYuuQdWwylgL3Hn3jEwm1FAVuL+93ssIDazgLjErSfzmSAuFZBYsuc8M4QtKvHy 8T9WkLUSAkoS07amgZjMApoS63fpQ3QqSkzpfsgOsVVQ4uTMJywTGEVnIRk6C6FjFpKOWUg6 FjCyrGIULU4tTspNNzLWSy3KTC4uzs/Ty0st2cQIjJeDW36r7mC8/MbxEKMAB6MSD69CTnuo EGtiWXFl7iFGaQ4WJXHeGZvzQoUE0hNLUrNTUwtSi+KLSnNSiw8xMnFwSjUwViwJ8jg5NTbq EOeBbZr7e6ZqLzuTylhXpnmOqeMH14PnOjO5En23Lp/pXXylw9KncubX5IvPlDLnvyvMsZMw fVj6W2SFat8xdkP9G1uY1YMjRWb/2b13/7dLbT94a+8LsRVIha8OOn5z4fof6nmvz7c8CY8V 2XvjcezMvUyCc1bGrVGWVKwvUGIpzkg01GIuKk4EAN7gKDN4AgAA Archived-At: Subject: Re: [avtext] AD Evaluation of draft-ietf-avtext-rtp-stream-pause-07 X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jun 2015 16:42:10 -0000 QmVuLCBhbGwsDQoNClBsZWFzZSBzZWUgaW5saW5lLg0KDQpDaGVlcnMsDQpCbw0KDQo+IC0tLS0t T3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IEJlbiBDYW1wYmVsbCBbbWFpbHRvOmJlbkBu b3N0cnVtLmNvbV0NCj4gU2VudDogZGVuIDE4IGp1bmkgMjAxNSAyMjo1Nw0KPiBUbzogZHJhZnQt aWV0Zi1hdnRleHQtcnRwLXN0cmVhbS1wYXVzZS5hbGxAaWV0Zi5vcmc7IGF2dGV4dEBpZXRmLm9y Zw0KPiBTdWJqZWN0OiBSZTogW2F2dGV4dF0gQUQgRXZhbHVhdGlvbiBvZiBkcmFmdC1pZXRmLWF2 dGV4dC1ydHAtc3RyZWFtLXBhdXNlLTA3DQo+IA0KPiBIaSwNCj4gDQo+IEkgaGF2ZSBhIGZldyBj b21tZW50cyBvbiBmdXJ0aGVyIHJlZmxlY3Rpb246DQo+IA0KPiBJIG5vdGljZSB0aGF0IHRoZXJl IGFyZSBJUFIgZGVjbGFyYXRpb25zIGFnYWluc3QgdGhlIG9yaWdpbmFsIHZlcnNpb24gKHByaW9y IHRvIHdnIGFjY2VwdGFuY2UuKSBUaGUgbGljZW5zZSB0ZXJtcyBhbGxvdyB0aGUNCj4gcG9zc2li aWxpdHkgb2Ygcm95YWx0aWVzLiBJIGFsc28gc2VlIHRoYXQgdGhlIHNoZXBoZXJkIHdyaXRldXAg bWVudGlvbnMgdGhhdCBhdnRleHQgZGlzY3Vzc2VkIHRoZXNlIGFuZCBhcmUgb2theSB3aXRoDQo+ IHRoZW0uIEhvd2V2ZXIsIHRoaXMgZHJhZnQgcmVmZXJlbmNlcyBzb21lIFJUQ1dFQiByZXF1aXJl bWVudHMgYXMgcGFydGlhbCBtb3RpdmF0aW9uLiBIYXZlIHRoZSBJUFIgZGlzY2xvc3VyZXMgYmVl bg0KPiBkaXNjdXNzZWQgd2l0aCBSVENXRUIsIHRvIGNvbmZpcm0gdGhhdCB0aGV5IHdvdWxkIGJl IHdpbGxpbmcgdG8gdXNlIGEgbWVjaGFuaXNtIHdpdGggdGhvc2UgZGlzY2xvc3VyZXM/DQpbQm9C XSBVc2Ugb2YgdGhpcyBkcmFmdCBpbiBSVENXRUIgY29udGV4dCBoYXMgYmVlbiBkaXNjdXNzZWQs IGUuZy4gaW4gdGhpcyB0aHJlYWQgaHR0cHM6Ly9tYWlsYXJjaGl2ZS5pZXRmLm9yZy9hcmNoL21z Zy9ydGN3ZWIvZDk1QWZSNVl0aEU3TzRoZTR5YVRDT2o4aDFvLCBjbGFyaWZ5aW5nIHRoYXQgdXNl IGluIFJUQ1dFQiB3b3VsZCBtYWlubHkgdGFyZ2V0IHRoZSBSRkMgNTEwNC1iYXNlZCBUTU1CUi9U TU1CTiAwIG1vZGUsIGFuZCBvbmUgb2YgdGhlIGNvbmNsdXNpb25zIG9mIHRoZSBkaXNjdXNzaW9u IHdhcyB0byBrZWVwIHRoZSBmdW5jdGlvbmFsaXR5IG91dCBvZiB2MS4wLiBUaGUgZHJhZnQgaXMg Y3VycmVudGx5IG5vdCByZWZlcmVuY2VkIGZyb20gYW55IFJUQ1dFQiB2MS4wIHNwZWNpZmljYXRp b24uIE9uZSBvZiB0aGUgYWx0ZXJuYXRpdmVzIG1lbnRpb25lZCBpbiB0aGUgdGhyZWFkIGFib3Zl IHdhcyB0byB1c2UgYW4gYXBwbGljYXRpb24tc3BlY2lmaWMgbWVzc2FnZSBpbiBhIERhdGFDaGFu bmVsLCBidXQgSSBjYW5ub3QgZmluZCB0aGF0IHRoZXJlIHdhcyBldmVyIGFueSBjb25zZW5zdXMg b24gd2hhdCB0byBkbyBpbiB2MS4wLCBvciBpZiBpdCBzaG91bGQgYmUgc3BlY2lmaWVkIGF0IGFs bC4NCg0KPiANCj4gT24gbXkgY29tbWVudHMgYWJvdXQgdGhlICJjb25maWciIHBhcmFtZXRlcjoN Cj4gDQo+IFRoZSByb290IG9mIG15IGNvbmNlcm4gaXMgbm90IHRoZSBtZWNoYW5pc20gZm9yIG5l Z290aWF0aW5nIHBhcnRpYWwgc3VwcG9ydCwgYnV0IHRoZSBudW1iZXIgb2YgY29uZmlnICJwcm9m aWxlcyIuIEl0DQo+IHNlZW1zIGxpa2UgdGhpcyBjb3VsZCBlbmNvdXJhZ2UgaW1wbGVtZW50YXRp b25zIHRoYXQgY2Fubm90IHVzZSB0aGUgbWVjaGFuaXNtIGludGVyb3BlcmFibHkuDQo+IEZvciBl eGFtcGxlLCB0aGUgZHJhZnQgc2hvd3MgdXNlIGNhc2VzIHdoZXJlIGEgY29uZmVyZW5jZSBicmlk Z2UgbWlnaHQgbmVlZCB0byBhc2sgYW4gZW5kcG9pbnQgdG8gcGF1c2UuIElmIHBlb3BsZQ0KPiBi dWlsZCBlbmRwb2ludHMgdGhhdCBvbmx5IHN1cHBvcnQgMiBvciAzLCB0aGVuIHRoaXMgd291bGQg bm90IGJlIHBvc3NpYmxlLg0KW0JvQl0gTGV0IG1lIHRyeSB0byBhbnN3ZXIgYnkgaGlnaGxpZ2h0 aW5nIGFuZCBzdW1tYXJpemluZyB0aGUgdW5kZXJseWluZyByZWFzb25zIGZvciB0aG9zZSBkaWZm ZXJlbnQgY29uZmlnICJwcm9maWxlcyIuDQoNCkNvbmZpZz0xIGlzIHRoZSAiZnVsbCIgaW1wbGVt ZW50YXRpb24uDQoNCkNvbmZpZz0yIGFuZCA0IGFyZSBpbnRlbmRlZCBmb3IgdGhlIFJUUCBzdHJl YW0gcmVjZWl2ZXIgdGhhdCB3YW50cyB0byBwYXVzZS9yZXN1bWUgdGhlIHJlbW90ZSBzZW5kZXIn cyBzdHJlYW0sIGJ1dCBzZWVzIG5vIHVzZSBvZiBsZXR0aW5nIGFueW9uZSBwYXVzZS9yZXN1bWUg aXRzIG93biBzZW50IFJUUCBzdHJlYW1zIChpZiBhbnkpLiBUaGlzIG1heSB0eXBpY2FsbHkgYmUg aW1wbGVtZW50ZWQgYnkgYSBjb25mZXJlbmNlIGJyaWRnZS4gQ29uZmlnPTQgZGlmZmVycyBmcm9t IDIgb25seSBpbiB0aGF0IGNvbmZpZz00IGhhcyBubyBQQVVTRUQgc3VwcG9ydC4gVG8gaW1wbGVt ZW50IGNvbmZpZz0yIG9yIDQgaW4gYW4gZW5kcG9pbnQgc3VwcG9zZWQgdG8gYmUgY29ubmVjdGVk IHRvIGEgY29uZmVyZW5jZSBicmlkZ2Ugd291bGQgb2J2aW91c2x5IG5vdCB3b3JrIGFuZCB3b3Vs ZCBpbiBteSBtaW5kIGJlIGEgbWlzdGFrZSBvciBtaXN1bmRlcnN0YW5kaW5nIG9mIHRoZSBkcmFm dCB0ZXh0IHJhdGhlciB0aGFuIGEgZGVsaWJlcmF0ZSBkZXNpZ24uIERvIHlvdSB0aGluayB0aGF0 IGEgY2xhcmlmaWNhdGlvbiBpcyBuZWVkZWQgaW4gdGhpcyByZXNwZWN0Pw0KDQpDb25maWc9MyBh bmQgNSBhcmUgaW50ZW5kZWQgZm9yIHRoZSBSVFAgc3RyZWFtIHNlbmRlciB0aGF0IHdhbnRzIHRv IGxlYXZlIHBhdXNlL3Jlc3VtZSBjb250cm9sIHRvIGEgcmVtb3RlIFJUUCBzdHJlYW0gcmVjZWl2 ZXIsIGJ1dCBoYXMgbm8gZGVzaXJlIHRvIGNvbnRyb2wgYW55b25lIGVsc2UncyBSVFAgc3RyZWFt cy4gVGhpcyBtYXkgdHlwaWNhbGx5IGJlIGltcGxlbWVudGVkIGJ5IGFuIGVuZHBvaW50IHBhcnRp Y2lwYXRpbmcgaW4gYSBncm91cCBjYWxsIHRocm91Z2ggYSBjb25mZXJlbmNlIGJyaWRnZS4gNSBk aWZmZXJzIGZyb20gMyBvbmx5IGluIHRoYXQgaXQgaGFzIG5vIFBBVVNFRCBzdXBwb3J0LiBTaW1p bGFyIHRvIGFib3ZlLCBpbXBsZW1lbnRpbmcgY29uZmlnPTMgb3IgNSBpbiBhIGNvbmZlcmVuY2Ug YnJpZGdlIGNvdWxkIGJlIGEgbWlzdW5kZXJzdGFuZGluZyBvciBtaXN0YWtlLiBEbyB5b3UgY2xh cmlmaWNhdGlvbiBpcyBuZWVkZWQ/DQoNCkNvbmZpZz02LTggYWxsIGRlYWwgb25seSB3aXRoIFBB VVNFRCAoc2VuZHJlY3YvcmVjdm9ubHkvc2VuZG9ubHkgY2FwYWJpbGl0eSwgcmVzcGVjdGl2ZWx5 KS4gSWYgSSByZW1lbWJlciBjb3JyZWN0bHksIGl0IHdhcyBicm91Z2h0IHVwIGR1cmluZyBhbiBJ RVRGIG1lZXRpbmcgKGZvcmdvdCB3aGljaCBhbmQgYnkgd2hvbSkgdGhhdCBpdCBjb3VsZCBiZSBh IHVzZWZ1bCBmdW5jdGlvbmFsaXR5IGluIGl0c2VsZiB0byBpbmRpY2F0ZSBsb2NhbCBwYXVzZS4g SSB0aGVuIGFzc3VtZWQgdGhhdCB0aGUgaXQgd2FzIG5vdCBkZXNpcmFibGUgdG8gcmVxdWlyZSB0 aGUgcmVzdCBvZiBwYXVzZS9yZXN1bWUgZnVuY3Rpb25hbGl0eSB0byBiZSBhYmxlIHRvIHVzZSB0 aGF0LCB3aGljaCBpcyB3aHkgY29uZmlnPTYtOCBhcmUgdGhlcmUgaW4gdGhlIGRyYWZ0LiBJbXBs ZW1lbnRhdGlvbnMgb2YgY29uZmlnPTYtOCBhcmUgb2J2aW91c2x5IG5vdCBhYmxlIHRvIGdldCBh bnkgcGF1c2UvcmVzdW1lIGZ1bmN0aW9uYWxpdHksIGJ1dCBhc3N1bWVkbHkgYWxzbyBkb24ndCB3 aXNoIHRvLCBhbmQgYXJlIGluIGFueSBjYXNlICJpbnRlcm9wZXJhYmxlIiB3aXRoIG90aGVyIGNv bmZpZyBzdXBwb3J0aW5nIFBBVVNFRC4NCg0KUmVnYXJkaW5nIGNvbmZpZz00IGFuZCA1LCBub3Qg c3VwcG9ydGluZyBQQVVTRUQgaXMgbm90IGRldHJpbWVudGFsIHRvIHBhdXNlL3Jlc3VtZSBmdW5j dGlvbmFsaXR5IGFuZCBpcyBpbiB0aGF0IHNlbnNlICJiYWNrd2FyZHMgY29tcGF0aWJsZSIsIGJ1 dCBoYXZpbmcgZXhwbGljaXQgaW5kaWNhdGlvbiBvZiBQQVVTRUQgc3VwcG9ydCBhbGxvd3MgdG8g YXZvaWQgc29tZSBoZXVyaXN0aWNzIGFuZCBkZWxheXMgaW4gcGF1c2UvcmVzdW1lIGltcGxlbWVu dGF0aW9uIGNvbnRyb2wgbG9naWMsIGluIGFkZGl0aW9uIHRvIHNhdmluZyB0aGUgYmFuZHdpZHRo IGZvciBzZW5kaW5nIHVubmVjZXNzYXJ5IFBBVVNFRC4NCg0KQXMgYSBzaWRlIGNvbW1lbnQsIHVz ZSBvZiBwYXVzZS9yZXN1bWUgaW4gYSBjb25mZXJlbmNlIGJyaWRnZSBjYXNjYWRpbmcgc2NlbmFy aW8gd291bGQgbGlrZWx5IHJlcXVpcmUgY29uZmlnPTEgYmV0d2VlbiB0aGUgY29uZmVyZW5jZSBi cmlkZ2VzIHRvIHByb3ZpZGUgc3VmZmljaWVudCBmdW5jdGlvbmFsaXR5Lg0KDQo+IA0KPiBTbyBt eSByZWFsIHF1ZXN0aW9uIGlzLCBkb2VzIHRoZSBtZWNoYW5pc20gcmVhbGx5IG5lZWQgYWxsIDgg bW9kZXM/IEFyZSB0aGVyZSBrbm93biBzaXR1YXRpb25zIHdoZXJlIGFuIGltcGxlbWVudGVyDQo+ IHdvdWxkIGNob29zZSBub3QgdG8gaW1wbGVtZW50IHRoaXMgbWVjaGFuaXNtIGlmIG9uZSBvZiB0 aGUgbW9kZXMgZGlkbid0IGV4aXN0PyBTb21lIG9mIHRoZW0gc2VlbSB0byBoYXZlIGZhaXJseQ0K PiBzdWJ0bGUgZGlmZmVyZW5jZXMgKGUuZy4gd2hldGhlciB0aGUgZGV2aWNlIG1heSBsb2NhbGx5 IHBhdXNlIG9yIG5vdC4pDQpbQm9CXSBJJ2QgcmF0aGVyIHNheSB0aGF0IGlmIHRoZXJlIHdlcmUg bm8gY29uZmlndXJhdGlvbnMgYXQgYWxsLCB0aGVyZSdzIGEgcmlzayB0aGF0IGltcGxlbWVudGF0 aW9ucyBtYXkgYW55d2F5IGNob29zZSB0byBpbXBsZW1lbnQgYSBzdWJzZXQgb2YgdGhlIGZ1bGwg ZnVuY3Rpb25hbGl0eSBiZWNhdXNlIGl0IHNlZXMgbm8gdXNlIGZvciB0aGUgcmVzdCAoY29ycmVj dGx5IG9yIG5vdCksIGxpa2UgYSBjb25mZXJlbmNlIGJyaWRnZSB0aGF0IHNlZXMgbm8gcG9pbnQg aW4gcGF1c2luZyBpdHMgc2VudCBSVFAgc3RyZWFtcy4gSXMgaXQgbm90IGJldHRlciBmcm9tIGFu IGludGVyb3BlcmFiaWxpdHkgcGVyc3BlY3RpdmUgdG8gc3BlY2lmeSBob3cgdGhpcyBzdWJzZXQg cmVzdHJpY3Rpb24gbXVzdCBiZSBtYWRlIHRvIGFjaGlldmUgYSBjZXJ0YWluIGRlc2lyYWJsZSBm dW5jdGlvbmFsaXR5LCBpbnN0ZWFkIG9mIGxlYXZpbmcgaXQgdG8gaW5kaXZpZHVhbCBpbXBsZW1l bnRhdGlvbnMgdG8gZGVjaWRlIHdoYXQgcGFydHMgb2YgdGhlIHNwZWNpZmljYXRpb24gY2FuIGFu ZCB3aGF0IGNhbm5vdCBiZSBvbWl0dGVkIChhZG1pdHRlZGx5IGluIHZpb2xhdGlvbiBvZiB0aGUg c3BlY2lmaWNhdGlvbiksIHRvIHN0aWxsIGhhdmUgYSByZWFzb25hYmx5IHdvcmtpbmcgYW5kIGlu dGVyb3BlcmFibGUgaW1wbGVtZW50YXRpb24/DQoNCkFyZSB0aGVyZSB0b28gbWFueSBjb25maWd1 cmF0aW9ucz8gSSBkb24ndCBzZWUgaG93IHRoaXMgY2FuIGJlIGRldGVybWluZWQgd2l0aCBhbnkg Y2VydGFpbnR5IHVudGlsIHRoZXJlIGlzIGEgc2lnbmlmaWNhbnQgbnVtYmVyIG9mIGltcGxlbWVu dGF0aW9ucyBpbiBzZXZlcmFsIGRpZmZlcmVudCBjb250ZXh0cy4gVGhlIG51bWJlciBvZiBjb25m aWcncyBfY2FuXyBjZXJ0YWlubHkgYmUgcmVkdWNlZCBpZiB5b3UgY2hhbmdlIHRoZSBwcmVjb25k aXRpb25zLiBJZiB5b3UgZm9yIGV4YW1wbGUgd2VyZSB0byByZXF1aXJlIHRoYXQgYWxsIGltcGxl bWVudGF0aW9ucyBtdXN0IHN1cHBvcnQgUEFVU0VELCBfYW5kXyB0aGF0IG5vIGltcGxlbWVudGF0 aW9ucyBhcmUgYWxsb3dlZCB0byBfb25seV8gc3VwcG9ydCBQQVVTRUQsIHRoZSBudW1iZXIgb2Yg Y29uZmlndXJhdGlvbnMgdGhhdCBhcmUgc3VwcG9ydGVkIGJ5IGFueSByZWFzb25hYmxlIHJlbWFp bmluZyB1c2UgY2FzZSB3b3VsZCBpbW1lZGlhdGVseSBkcm9wIHRvIHRocmVlIChjb25maWd1cmF0 aW9ucyAxLTMpLg0KDQo+IA0KPiBCZW4uDQo+IA0KPiBPbiAxNSBKdW4gMjAxNSwgYXQgMjI6MTgs IEJlbiBDYW1wYmVsbCB3cm90ZToNCj4gDQo+ID4gSGksDQo+ID4NCj4gPiBIZXJlJ3MgbXkgQUQg RXZhbHVhdGlvbiBvZiBkcmFmdC1pZXRmLWF2dGV4dC1ydHAtc3RyZWFtLXBhdXNlLTA3LiBJJ3Zl DQo+ID4gYnJva2VuIGl0IGRvd24gYmV0d2VlbiB0aGluZ3MgSSdkIGxpa2UgdG8gc2VlIGRpc2N1 c3NlZCBwcmlvciB0byBJRVRGDQo+ID4gbGFzdCBjYWxsLCB0aGluZ3MgSSB0aGluayBjYW4gYmUg d29ya2VkIGluIHBhcmFsbGVsIHRvIHRoZSBsYXN0IGNhbGwsDQo+ID4gYW5kIHRoaW5ncyB0aGF0 IGFyZSBqdXN0IGVkaXRvcmlhbC4NCj4gPg0KPiA+IFRoYW5rcyENCj4gPg0KPiA+IEJlbi4NCj4g Pg0KPiA+ICoqKiBUaGluZ3MgdG8gZGlzY3VzcyBiZWZvcmUgSUVURiBMYXN0IENhbGw6DQo+ID4N Cj4gPiAtLSBQYXJ0aWFsIFN1cHBvcnQgQ29uZmlndXJhdGlvbg0KPiA+DQo+ID4gSSBjb25jdXIg d2l0aCBQYXVsJ3MgU0RQIHJldmlldyB0aGF0IHRoZSBjdXJyZW50IG1ldGhvZCBvZiBjb25maWd1 cmluZw0KPiA+IHBhcnRpYWwgc3VwcG9ydCBpcyBjb25mdXNpbmcgYW5kIGVycm9yIHByb25lLiBJ IHdpbGwgZ28gZnVydGhlciBhbmQNCj4gPiBzYXkgSSBhbSBjb25jZXJuZWQgdGhhdCB0aGUgd2hv bGUgaWRlYSBvZiBwYXJ0aWFsIHN1cHBvcnQgY2FuIHJlYWxseQ0KPiA+IGltcGFjdCBpbnRlcm9w ZXJhYmlsaXR5LiBJdCBzZWVtcyBsaWtlIHRoZXJlIGFyZSBtYW55IGNvbWJpbmF0aW9ucw0KPiA+ IHdoZXJlIHBhcnRpY2lwYW50cyBjYW4gc2ltcGx5IGZhaWwgdG8gd29yayAod2hlcmUgZmFpbGlu ZyB0byB3b3JrDQo+ID4gbWVhbnMgdGhleSBjYW5ub3QgdXNlIHRoaXMgZXh0ZW5zaW9uIGF0IGFs bC4pIEhhdmUgeW91IGhhZCBwZW9wbGUgc2F5DQo+ID4gdGhleSBhcmUgd2lsbGluZyB0byBpbXBs ZW1lbnQgc29tZSBidXQgbm90IGFsbCBmZWF0dXJlcyBvZiB0aGlzIHNwZWM/DQo+ID4gRG8gdGhl IGZlYXR1cmVzIGNhdXNlIGhhcm0gaWYgYSBwYXJ0aWNpcGFudCB0cmllcyB0byBzZW5kIHRoZW0g dG8gYQ0KPiA+IHBlZXIgdGhhdCBkb2Vzbid0IHVuZGVyc3RhbmQgdGhlbT8gKFRoaXMgaXMgYSBi aXQgb2YgUlRDUCBDQ00NCj4gPiBlc290ZXJpY2EgdGhhdCBJIGRvIG5vdCBrbm93IG9mZi1oYW5k OiBBcmUgcmVjaXBpZW50cyBleHBlY3RlZCB0bw0KPiA+IGlnbm9yZSB0aGluZ3MgdGhleSBkb24n dCB1bmRlcnN0YW5kPykNCj4gPg0KPiA+IEkgY2FuIHNlZSBhIHN3aXRjaCBvciBtaXhlciBkZWNs YXJpbmcgdGhhdCBpdCB3aWxsIG5ldmVyIHNlbmQgUEFVU0Ugb3INCj4gPiBSRVNVTUUuIEJ1dCBp dCBzZWVtcyBsaWtlIGVuY291cmFnaW5nIChvciBldmVuIGFsbG93aW5nKSBwYXJ0aWFsDQo+ID4g c3VwcG9ydCBmb3Ig4oCcZW5kcG9pbnTigJ0gcGFydGljaXBhbnRzIHdpbGwgaHVydCBpbnRlcm9w ZXJhYmlsaXR5Lg0KPiA+IEZvciBleGFtcGxlLCB5b3UgaGF2ZSByZWFzb24gd2h5IGEgbWl4ZXIg b3Igc3dpdGNoIG1pZ2h0IGNob29zZSB0bw0KPiA+IHNlbmQgcGF1c2XigJRidXQgdGhhdCB3aWxs IG5ldmVyIHdvcmsgaWYgdGhlIGVuZHBvaW50cyBkb27igJl0IHN1cHBvcnQNCj4gPiByZWNlaXZp bmcgaXQuDQo+ID4NCj4gPiBTbywgd2hlbiBzZWN0aW9uIDkgc2F5cyAiICdjb25maWcnIGFsbG93 cyBmb3IgcGFydGlhbCBpbXBsZW1lbnRhdGlvbg0KPiA+IG9mIHRoaXMgc3BlY2lmaWNhdGlvbiBh Y2NvcmRpbmcgdG8gdGhlIGRpZmZlcmVudCByb2xlcyBpbiB0aGUgdXNlDQo+ID4gY2FzZXMgc2Vj dGlvbiIsIGRvIHlvdSBtZWFuIHRvIGNvbnN0cmFpbiB0aGUgdXNlIG9mICJjb25maWciIHRvIG9u bHkNCj4gPiB0aG9zZSByb2xlcyB3aGVyZSBpdCBpcyBuZWVkZWQ/IFdvdWxkIGl0IG1ha2Ugc2Vu c2UgdG8gc2F5IHRoYXQNCj4gPiBtaXhlcnMvc3dpdGNoZXMgdGhhdCBzdXBwb3J0IHBhdXNlIG11 c3Qgc3VwcG9ydCBhdCBsZWFzdCBjZXJ0YWluDQo+ID4gY29uZmlncywgd2hlcmUgZW5kcG9pbnRz IG11c3Qgc3VwcG9ydCBvdGhlciBtaW5pbXVtcz8NCj4gPg0KPiA+IC0tICJBdmFpbGFibGUgUGF1 c2VJRCINCj4gPg0KPiA+IEkgZmluZCB0aGUgc3BlY2lmaWNhdGlvbiBvZiAiQXZhaWxhYmxlIFBh dXNlSUQiIHRvIGJlIHZlcnkgY29uZnVzaW5nLg0KPiA+IFNlY3Rpb24gOC4xICh0aGlyZCBwYXJh Z3JhcGgpIHNlZW1zIHRvIHNheSB0aGF0IHRoZSBQYXVzZUlEIGluIHRoZQ0KPiA+IFBBVVNFIHJl cXVlc3Qgc2hvdWxkIGJlIHRha2VuIGZyb20gdGhlIG1vc3QgcmVjZW50bHkgcmVjZWl2ZWQgUEFV U0VEDQo+ID4gaW5kaWNhdGlvbi4gQnV0IHRoZSBuZXh0IHBhcmFncmFwaCBzYXlzIHRoZSB2YWx1 ZSBmcm9tIFBBVVNFRCBzaG91bGQNCj4gPiBiZSBpbmNyZW1lbnRlZCBieSBvbmUuDQo+ID4NCj4g PiBJIHRoaW5rIHRoZSBjb25mdXNpb24gY29tZXMgZnJvbSB0d28gdGhpbmdzLiBGaXJzdCwgdGhl IG5hbWUNCj4gPiAiQXZhaWxhYmxlIFBhdXNlSUQiIGlzIGEgY29uZnVzaW5nIGNob2ljZS4gVG8g bWUsICJhdmFpbGFibGUiIG1lYW5zIEkNCj4gPiBjYW4gdXNlIGl0LiBCdXQgaWYgSSB1bmRlcnN0 YW5kIGNvcnJlY3RseSwgSSBjYW4ndCB1c2UgdGhhdCBvbmUgZm9yIGENCj4gPiAibmV3IiBQQVVT RSByZXF1ZXN0LiBQZXJoYXBzIGEgYmV0dGVyIHRlcm0gd291bGQgYmUgIkN1cnJlbnQgUGF1c2VJ RCIuDQo+ID4gVGhhdCB3b3VsZCBtYWtlIG1vcmUgc2Vuc2UgaWYgSSByZWZlciB0byB0aGUgImN1 cnJlbnQiIHZhbHVlIHRvIGFjdCBvbg0KPiA+IGEgY3VycmVudCBwYXVzZSAob3IgbW9zdCByZWNl bnQpIGNvbmRpdGlvbiwgYW5kIHRoZW4gaGF2ZSB0aGUgY29uY2VwdA0KPiA+IG9mIGEgIm5leHQi IFBhdXNlSUQgd2hpY2ggd291bGQgYmUgdGhlIGN1cnJlbnQgb25lIHBsdXMgMS4NCj4gPg0KPiA+ IEkgYWxzbyB0aGluayBpdCB3b3VsZCBoZWxwIHRvIGhhdmUgb25lIHNlY3Rpb24gdGhhdCBkZXNj cmliZXMNCj4gPiAobm9uLW5vcm1hdGl2ZWx5KSBhbGwgdGhlIHNlbWFudGljcyBvZiBQYXVzZUlE IGVhcmx5IGluIHNlY3Rpb24gNQ0KPiA+IChiZWZvcmUgdGhlIGNvbmNlcHQgaXMgZmlyc3QgcmVm ZXJlbmNlZC4pDQo+ID4NCj4gPiAtLSAyLjI6IEFyZSB0aGUgZGVmaW5pdGlvbnMgaW4gdGhlIFJU UCBUYXhvbm9teSBkb2N1bWVudCBuZWNlc3NhcnkgdG8NCj4gPiB1bmRlcnN0YW5kL2ltcGxlbWVu dCB0aGlzIGRyYWZ0PyBJZiBzbywgdGhpcyBzaG91bGQgYmUgYSBub3JtYXRpdmUNCj4gPiByZWZl cmVuY2UsIHdoaWNoIHdlIHdvdWxkIG5lZWQgdG8gY2FsbCBvdXQgaW4gdGhlIGxhc3QgY2FsbC4g KEknbSBub3QNCj4gPiBzYXlpbmcgdGhleSBhcmUgcmVxdWlyZWQgdG8gdW5kZXJzdGFuZCB0aGlz IG9uZS0tSSdtIG5vdCBzdXJlIG9uZSB3YXkNCj4gPiBvciBhbm90aGVyLikNCj4gPg0KPiA+IC0t IDUuMywgM3JkIHBhcmFncmFwaDoNCj4gPg0KPiA+IERvZXMgdGhpcyBtZWFuIHRoZSBzdHJlYW0g cmVjZWl2ZXIgbWF5IHNlZSBhIFBBVVNFRCBpbmRpY2F0aW9uIHByaW9yDQo+ID4gdG8gdGhlIHN0 cmVhbSBhY3R1YWxseSBiZWluZyBwYXVzZWQ/IChUaGF0IGlzLCBzZWUgYSBwYXVzZWQNCj4gPiBp bmRpY2F0aW9uLCBidXQgY29udGludWUgdG8gcmVjZWl2ZSB0aGUgc3RyZWFtPykgSSBkb24ndCB0 aGluayB0aGF0J3MNCj4gPiB0aGUgaW50ZW50LCBidXQgc2VlaW5nIHRoaXMgYWZ0ZXIgdGhlIHBh cmFncmFwaHMgb24gdGhlIFBBVVNFRA0KPiA+IGluZGljYXRpb24gbWFrZXMgbWUgd29uZGVyLg0K PiA+DQo+ID4gKioqIFRoaW5ncyB0aGF0IGNhbiBiZSB0cmVhdGVkIGFzIHBhcnQgb2YgSUVURiBM YXN0IENhbGw6DQo+ID4NCj4gPiAtLSBJJ20gbm90IGdvaW5nIHRvIHB1c2ggb24gdGhpcywgc2lu Y2UgSSBhc3N1bWUgdGhpcyB3YXMgYQ0KPiA+IHdlbGwtZGlzY3Vzc2VkIGNvbXByb21pc2UgaW4g dGhlIFdHLiBCdXQgaXQgc2VlbXMgdG8gbWUgdGhhdCBoYXZpbmcNCj4gPiB0d28gaW5kZXBlbmRl bnQgbWVjaGFuaXNtcyB0byBhY2NvbXBsaXNoIHRoZSBzYW1lIHRoaW5nLCB3aXRoIG9uZSBvbmx5 DQo+ID4gd29ya2luZyBpbiBsaW1pdGVkIGNvbmRpdGlvbnMgKFRNTUJSL1RNTUJOKSBhZGRzIG1v cmUgY29tcGxleGl0eSB0aGF0DQo+ID4gdmFsdWUsIGFuZCBpcyBsaWtlbHkgdG8gcmVkdWNlIGlu dGVyb3BlcmFiaWxpdHkuDQo+ID4NCj4gPiAtLSA0LjE6ICJUaGUgcGF1c2Ugb3BlcmF0aW9uIGlz IGFyZ3VhYmx5IG5vdCB2ZXJ5IHRpbWUgY3JpdGljYWwiDQo+ID4NCj4gPiBUaGlzIHNlZW1zIHRv IGNvbnRyYWRpY3QgdGhlIHByZXZpb3VzIHNlbnRlbmNlLiBJIGFzc3VtZSB0aGUgcG9pbnQgaXMN Cj4gPiB0aGF0IGJvdGggYXJlIHRpbWUgc2Vuc2l0aXZlLCBidXQgcGF1c2UgaXMgbGVzcyBzbyB0 aGFuIHJlc3VtZT8NCj4gPg0KPiA+IC0tIDQuMzoNCj4gPg0KPiA+IElzIGl0IHBvc3NpYmxlIGZv ciB0aGUgc2VuZGVyIHRvIGNoYW5nZSB0aGUgU1NSQyBiZXR3ZWVuIHRoZSBwYXVzZSBhbmQNCj4g PiByZXN1bWUgcmVxdWVzdHMsIHNvIHRoYXQgdGhlIHJlc3VtZSByZXF1ZXN0IHJlZmVycyB0byBh IHN0YWxlIFNTUkMNCj4gPiB2YWx1ZT8gRG9lcyBpdCBodXJ0IGFueXRoaW5nIGlmIGl0IGhhcHBl bnM/DQo+ID4NCj4gPiAtLSA2LjMuMSwgMm5kIGJ1bGxldDoidGhlIHNlbmRlciBNVVNUIGtlZXAN Cj4gPiAgICByZWNvcmQgb2Ygd2hpY2ggcmVjZWl2ZXIgdGhhdCBjYXVzZWQgdGhlIFJUUCBzdHJl YW0gdG8gcGF1c2UuICBJZg0KPiA+ICAgIHRoYXQgcmVjZWl2ZXIgc2VuZHMgYW4gUlRDUCBCWUUg bWVzc2FnZSBvYnNlcnZlZCBieSB0aGUgc2VuZGVyLA0KPiA+ICAgIHRoZSBzZW5kZXIgU0hBTEwg cmVzdW1lIHRoZSBSVFAgc3RyZWFtLiINCj4gPg0KPiA+IElmIG5vIG90aGVyIHBhcnRpY2lwYW50 IG9iamVjdGVkIHRvIHRoZSBwYXVzZSBpbiB0aGUgZmlyc3QgcGxhY2UsIHdoeQ0KPiA+IGRvIHdl IGFzc3VtZSB0aGF0IGV4aXQgb2YgdGhlIG9yaWdpbmFsIHBhdXNlIHJlcXVlc3RvciBtZWFucyB0 aGUgb3RoZXINCj4gPiBwYXJ0aWNpcGFudHMgd2FudCB0aGUgc3RyZWFtIHRvIHJlc3VtZT8gV2h5 IHB1dCB0aGUgYnVyZGVuIG9uIHRoZQ0KPiA+IHNlbmRlciB0byB0cmFjayB0aGlzPw0KPiA+DQo+ ID4gLS0gODogIklmIHRoZSBtZXNzYWdlcyBkZWZpbmVkIGluDQo+ID4gdGhpcyBzcGVjaWZpY2F0 aW9uIGFyZSBzdXBwb3J0ZWQgaW4gYWRkaXRpb24gdG8gVE1NQlIvVE1NQk4sIHBhdXNlLw0KPiA+ IHJlc3VtZSBzaWduYWxpbmcgTVVTVCB1c2UgbWVzc2FnZXMgZnJvbSB0aGlzIHNwZWNpZmljYXRp b24uIg0KPiA+DQo+ID4gV2hhdCBpZiBvbmUgKFBUUCkgcGFydGljaXBhbnQgc3VwcG9ydHMgdGhl c2UgZm9ybWF0cywgYW5kIHRoZSBvdGhlcg0KPiA+IG9ubHkgc3VwcG9ydHMgVE1NQlIvVE1NQk4/ IEFzIHdvcmRlZCB0aGF0IHNlZW1zIHRvIG1lYW4gdGhhdA0KPiA+IHBhdXNlL3Jlc3VtZSBjYW5u b3QgYmUgdXNlZC4gKGkuZS4gb25lIE1VU1QgTk9UIHVzZSBUTU1CUi9UTU1CTg0KPiA+IGJlY2F1 c2UgaXQgc3VwcG9ydHMgdGhlIEZDSSBtZXNzYWdlcywgYW5kIHRoZSBvdGhlciBvbmx5IHVuZGVy c3RhbmRzDQo+ID4gVE1NQlIvVE1NQk4/DQo+ID4NCj4gPiAiSWYgdGhlIHRvcG9sb2d5IGlzIG5v dCBwb2ludC10by1wb2ludCBhbmQgdGhlIG1lc3NhZ2VzIGRlZmluZWQgaW4NCj4gPiB0aGlzIHNw ZWNpZmljYXRpb24gYXJlIG5vdCBzdXBwb3J0ZWQsIHBhdXNlL3Jlc3VtZSBmdW5jdGlvbmFsaXR5 IHdpdGgNCj4gPiBUTU1CUi9UTU1CTiBNVVNUIE5PVCBiZSB1c2VkLiINCj4gPg0KPiA+IFRoaXMg TVVTVCBOT1Qgc2VlbXMgdG8gYmUgbm9uLWNvbnN0cmFpbmluZy4NCj4gPg0KPiA+IC0tIDguMSwg M3JkIHBhcmFncmFwaDogImFzIGluZGljYXRlZCBieSBQQVVTRUQiDQo+ID4NCj4gPiAuLi4gb3Ig UkVGVVNFRD8NCj4gPg0KPiA+IC0tIDguMSwgNHRoIGZyb20gZW5kOg0KPiA+DQo+ID4gQ2FuIHlv dSBvZmZlciBndWlkYW5jZSBvbiBzZWxlY3RpbmcgYW4gYXBwcm9wcmlhdGUgdGltZT8NCj4gPg0K PiA+IC0tIDJuZCBwYXJhZ3JhcGggZnJvbSBlbmQ6DQo+ID4NCj4gPiBUaGlzIGlzIGEgbGl0dGxl IGNvbmZ1c2luZy4gSXMgdGhlIGNvdW50ZXItaW5kaWNhdGlvbiByZWFsbHkgdGhhdA0KPiA+IGxv Y2FsIGNvbnNpZGVyYXRpb25zIG1ha2UgaXQgX2ltcG9zc2libGVfIHRvIHBhdXNlLCBvciBpcyBz aW1wbHkNCj4gPiBfdW5kZXNpcmFibGVfIHN1ZmZpY2llbnQ/IElzIHBhdXNpbmcgZWZmZWN0aXZl bHkgb3B0aW9uYWw/DQo+ID4NCj4gPiBBbHNvLCBzaG91bGRu4oCZdCB0aGlzIG1lbnRpb24gdGhl IGhvbGQgb2ZmPw0KPiA+DQo+ID4gLS0gOC4yLCAybmQgcGFyYWdyYXBoDQo+ID4NCj4gPiBJcyB0 aGlzIHRydWUgZm9yIHRoZSBsb2NhbGx5IHBhdXNlZCBzdGF0ZT8gSWYgc28sIGhvdyBpcyB0aGUg UGF1c2VJRA0KPiA+IHZhbHVlIGNhbGN1bGF0ZWQgZm9yIGxvY2FsIHBhdXNpbmcuDQo+ID4NCj4g PiAtLSAzcmQgcGFyYWdyYXBoOiAiUEFVU0VEIFNIQUxMIGNvbnRhaW4uLi4iDQo+ID4NCj4gPiBJ IGFzc3VtZSB0aGlzIGdvZXMgaW50byB0aGUgVHlwZSBTcGVjaWZpYyBmaWVsZC4gSWYgc28sIGl0 IHdvdWxkIGJlDQo+ID4gd29ydGggZXhwbGljaXRseSBtZW50aW9uaW5nIHRoYXQuIEFsc28sIEkg YXNzdW1lIHRoYXQgaW1wbGllcyBhDQo+ID4gZml4ZWQtbGVuZ3RoIFR5cGUgU3BlY2lmaWMgaW4g YSBQQVVTRUQgaW5kaWNhdGlvbj8NCj4gPg0KPiA+IC0tOC40LCAzcmQgcGFyYWdyYXBoOiJyZWNl aXZlcyBhIFJFU1VNRSB3aXRoIGEgUGF1c2VJRCBsZXNzIHRoYW4gdGhlDQo+ID4gdmFsaWQgb25l LCBpbiB3aGljaCBjYXNlIHRoZSBSRVNVTUUgU0hBTEwgYmUgaWdub3JlZC4iDQo+ID4NCj4gPiBU aGlzIHNlZW1zIHRvIGNvbmZsaWN0IHdpdGggdGhlIGxhc3Qgc2VudGVuY2UgaW4gOC4zLiBJdCBz YXlzIHRoZQ0KPiA+IHJlc3VtZSBpcyBpZ25vcmVkIGlmIGl0IGNvbnRhaW5zIGEgX3ZhbGlkXyBQ YXVzZUlEIG9yIGEgdmFsdWUgbGVzcw0KPiA+IHRoYW4gdGhlIHZhbGlkIG9uZS4NCj4gPg0KPiA+ IC0tOC40LCA2dGggcGFyYWdyYXBoOg0KPiA+DQo+ID4gQ2FuIHlvdSBvZmZlciBndWlkYW5jZSBv biBzZWxlY3RpbmcgYW4gYXBwcm9wcmlhdGUgdGltZT8NCj4gPg0KPiA+DQo+ID4gLS0gMTUuMjoN Cj4gPg0KPiA+IFNlZW1zIGxpa2UgdGhlIHJlZmVyZW5jZXMgZm9yIFJGQ3MgMzI2NCBhbmQgNDU2 MCBzaG91bGQgYmUgbm9ybWF0aXZlLg0KPiA+IFRoaXMgZHJhZnQgc3BlY2lmaWVkIG5vcm1hdGl2 ZSBiZWhhdmlvciBmb3IgdXNlIHdpdGggU0RQIGFuZCB0aGUNCj4gPiBvZmZlci9hbnN3ZXIgbW9k ZWwuDQo+ID4NCj4gPiAqKiogRWRpdG9yaWFsIFRoaW5nczoNCj4gPg0KPiA+IC0tIHNlY3Rpb24g MSwgcGFyYWdyYXBoIDQsIGxhc3Qgc2VudGVuY2U6DQo+ID4NCj4gPiBMb25nLCBjb252b2x1dGVk IHNlbnRlbmNlLiBDb25zaWRlciBicmVha2luZyBpbnRvIG11bHRpcGxlLCBzaW1wbGVyDQo+ID4g c2VudGVuY2VzLg0KPiA+DQo+ID4gYWxzbywgcy9hbnl3YXkvc3RpbGwNCj4gPg0KPiA+IC0tIHBh cmFncmFwaCA1Og0KPiA+DQo+ID4gcy8gIkFzIHRoZSBSVFAgc3RyZWFtcy4uLiIgLyAiQXMgdGhl IHNldCBvZiBSVFAgc3RyZWFtcy4uLiINCj4gPiBzLyAiLi4uIHVzaW5nIEV4dGVuZGVkIFJUUCBQ cm9maWxlLi4uIiAvICIuLi4gdXNpbmcgdGhlIEV4dGVuZGVkIFJUUA0KPiA+IFByb2ZpbGUuLi4i DQo+ID4NCj4gPiAtLSAybmQgdG8gbGFzdCBwYXJhZ3JhcGg6ICIuLi4gaXQgaXMgcHJvcG9zZWQg dG8gZGVmaW5lLi4uIg0KPiA+DQo+ID4gSSBzdWdnZXN0ICJUaGlzIGRvY3VtZW50IGRlZmluZXMu Li4iDQo+ID4NCj4gPiAtLSAzLjEsIHRocmVlIHBhcmFncmFwaHMgc3RhcnRpbmcgd2l0aCAiUlRD V0VCIFdHJ3MgdXNlIGNhc2UuLi4iDQo+ID4NCj4gPiBUaGVzZSBkb24ndCBzZWVtIHNwZWNpZmlj IHRvIHRoaXMgdXNlIGNhc2UuIENvbnNpZGVyIG1vdmluZyBpdCBvdXQgb2YNCj4gPiB0aGUgdXNl IGNhc2UsIG9yIHBlcmhhcHMgdG8gdGhlIFJUUCBNaXhlciB0byBNZWRpYSBTZW5kZXIgdXNlIGNh c2UNCj4gPiAoc2luY2UgdGhhdCBvbmUgbWVudGlvbnMgYWxsb3dpbmcgdGhlIG1lZGlhIHNlbmRl ciB0byBzaWduYWwgdGhlDQo+ID4gcmVjZWl2ZXIgdGhhdCBpdCBpcyBwYXVzaW5nIGEgc3RyZWFt LikNCj4gPg0KPiA+DQo+ID4gLS0gMy4yLCBGaXJzdCBwYXJhZ3JhcGg6DQo+ID4NCj4gPiAiVGhh dCBpcyBhY2NvbXBsaXNoZWQNCj4gPiB0aHJvdWdoIHRoZSBNaXhlciBvcmlnaW5hdGluZyBpdHPi gJkgb3duIHN0cmVhbXMsIGlkZW50aWZpZWQgYnkgU1NSQy4uLiINCj4gPg0KPiA+IHMvaXRzJy9p dHMNCj4gPg0KPiA+IEFsc28sIEkgc2VlbSB5b3UgbWVhbiAiaWRlbnRpZmllZCBieSBfZGlzdGlu Y3RfIFNTUkMgdmFsdWVzIj8NCj4gPg0KPiA+IC0tIDNyZCBwYXJhZ3JhcGg6ICJyZXF1ZXN0IHRv IHBhdXNlIGEgcGFydGljdWxhciBzdHJlYW0iDQo+ID4NCj4gPiByZXF1ZXN0IHRoYXQgYSBwYXJ0 aWN1bGFyIHN0cmVhbSBiZSBwYXVzZWQsIG9yIHJlcXVlc3QgdGhlIHNlbmRlciB0bw0KPiA+IHBh dXNlIGEgcGFydGljdWxhciBzdHJlYW0uDQo+ID4NCj4gPiAtLSA0dGggcGFyYWdyYXBoOiAidGhl cmUgbWF5IGJlIHNpdHVhdGlvbnMgdGhhdCBtYWtlcyBpdCBkZXNpcmFibGUgdG8NCj4gPiB0aGUg TWl4ZXIgdG8gcGF1c2Ugc29tZSBvZiBpdHMgc2VudCBSVFAgc3RyZWFtcyINCj4gPg0KPiA+IGRv IHlvdSBtZWFuICJkZXNpcmFibGUgX2Zvcl8gdGhlIG1peGVy4oCmIj8gKE9yIGRvIHlvdSBtZWFu IHRvIHNheSB0aGUNCj4gPiBtaXhlciBkZXNpcmVzIHRoYXQgdGhlIHN0cmVhbXMgYmUgcGF1c2Vk Pw0KPiA+DQo+ID4gLS0gRmlndXJlIDM6DQo+ID4NCj4gPiBEbyBCIGFuZCBEIGV2ZXIgZ2V0IG1l bnRpb25lZD8gSWYgbm90LCBpdCB3b3VsZCBiZSBzaW1wbGVyIHdpdGhvdXQNCj4gPiB0aGVtLg0K PiA+DQo+ID4gLS0gMy40DQo+ID4NCj4gPiBJdOKAmXMga2luZCBvZiBjb25mdXNpbmcgdG8gZmlu ZCB0aGF0IHRoaXMgc2VjdGlvbiBjb21iaW5lcyBib3RoIHRoZQ0KPiA+IHVuaWNhc3QgYW5kIG11 bHRpY2FzdCBjYXNlcywgd2hlbiB0aGUgcHJldmlvdXMgdHdvIHNlY3Rpb25zIHNlcGFyYXRlZA0K PiA+IHRoZW0uIEkgdGhpbmsgaXQgd291bGQgYmUgZWFzaWVyIHRvIHVuZGVyc3RhbmQgaWYgdGhl IGluZm9ybWF0aW9uIGluDQo+ID4gdGhpcyBzZWN0aW9uIHdlcmUgc3BsaXQgYmV0d2VlbiAzLjIg YW5kIDMuMy4NCj4gPg0KPiA+IC0tIDQuMToNCj4gPg0KPiA+IFdoaWxlIEkgcmVjb2duaXplIHRo YXQgUkFJIGhhcyBoaXN0b3JpY2FsbHkgdXNlZCByZWFsLXRpbWUgaW4gdGhpcw0KPiA+IHNlbnNl LCBpdOKAmXMgbm90IHRoZSB1c3VhbCBtZWFuaW5nIG9mIHJlYWwtdGltZSBpbiB0aGUgZmllbGQg b2YNCj4gPiBjb21wdXRlciBzY2llbmNlLiBDb25zaWRlciByZXBsYWNpbmcg4oCccmVhbC10aW1l 4oCdIHdpdGgg4oCcdGltZS1zZW5zaXRpdmXigJ0NCj4gPiBvciDigJx0aW1lLXNlbnNpdGl2aXR5 4oCdIGRlcGVuZGluZyBvbiBjb250ZXh0Lg0KPiA+DQo+ID4gLS0gNC4yOg0KPiA+DQo+ID4gcy93 aG8vdGhhdCAgKGJvdGggdGltZXMpDQo+ID4gcy9saWtlcy9uZWVkcyAob3Igd2FudHMpDQo+ID4N Cj4gPiAtLSA0LjQsIGZpcnN0IHBhcmFncmFwaCwgMm5kIHNlbnRlbmNlOg0KPiA+DQo+ID4gTG9u ZywgY29udm9sdXRlZCBzZW50ZW5jZS4gUGxlYXNlIGNvbnNpZGVyIGJyZWFraW5nIGl0IGRvd24g aW50bw0KPiA+IHNpbXBsZXIgc2VudGVuY2VzLiAoVGhpcyBpcyBmdXJ0aGVyIGNvbmZ1c2VkIGJ5 IHRoZSBwcmVzZW5jZSBvZiBsb3RzDQo+ID4gb2YgY29tbWFzLCBzb21lIG9mIHdoaWNoIHNlcGFy YXRlIGxpc3QgbWVtYmVycywgYW5kIHNvbWUgc2VwYXJhdGUNCj4gPiBjbGF1c2VzLikNCj4gPg0K PiA+IC0tIDQuNSwgbGFzdCBzZW50ZW5jZToNCj4gPg0KPiA+IEnigJltIGNvbmZ1c2VkIGJ5IHRo aXMgc2VudGVuY2UuIERvIHlvdSBtZWFuIHRvIHNheSwgIkluIHRoaXMgZXJyb3INCj4gPiBjb25k aXRpb24gYSBuZWdhdGl2ZSBhY2tub3dsZWRnZW1lbnQgbWF5IGJlIG5lZWRlZOKApiINCj4gPg0K PiA+IC0tIDQuOCwgZmlyc3QgcGFyYWdyYXBoOg0KPiA+DQo+ID4gQW55IHJlYXNvbiB0byBjaXRl IDQ1NjYgYnV0IG5vdCAzMjYxPyAoQm90aCBoYXZlIGJlZW4gY2l0ZWQgZWFybGllciBpbg0KPiA+ IHRoZSBkcmFmdC4pDQo+ID4NCj4gPiAtLSA1LCAybmQgcGFyYWdyYXBoOiAiSXQgaXMgcHJvcG9z ZWQuLi4iDQo+ID4NCj4gPiBVbmxlc3MgdGhhdCBwcm9wb3NhbCBoYXMgbm90IGJlZW4gYWNjZXB0 ZWQsIGNvbnNpZGVyIHNheWluZyAiVGhpcw0KPiA+IHNvbHV0aW9uIHJlLXVzZXMuLi4iDQo+ID4N Cj4gPiAtLSA1LjQsIDFzdCBwYXJhZ3JhcGg6ICJjYW4gcmVxdWVzdCB0byByZXN1bWUuLi4gIg0K PiA+DQo+ID4gcmVxdWVzdCB0aGUgc2VuZGVyIHRvIHJlc3VtZSwgb3IgcmVxdWVzdCB0aGUgcmVz dW1wdGlvbiBvZi4uLg0KPiA+DQo+ID4gLS0gcGFyYWdyYXBoIDY6ICJpdCBjYW5ub3QgYmUgcmVz dW1lZCBkdWUgdG8gbG9jYWwgY29uc2lkZXJhdGlvbnMiDQo+ID4NCj4gPiBUaGlzIGNhbiBiZSBy ZWFkIHRvIHNheSB0aGF0IGxvY2FsIGNvbnNpZGVyYXRpb25zIG1heSBwcmV2ZW50DQo+ID4gcmVz dW1wdGlvbiwgYnV0IEkgdGhpbmsgeW91IG1lYW4gdGhhdCByZXN1bXB0aW9uIGlzIHByZXZlbnRl ZCBieQ0KPiA+IHByb3RvY29sLCBldmVuIGlmIHRoZSBzZW5kZXIgd291bGQgbGlrZSB0byByZXN1 bWUgZHVlIHRvIGxvY2FsDQo+ID4gY29uc2lkZXJhdGlvbnMuDQo+ID4NCj4gPiAtLSA3dGggcGFy YWdyYXBoOiAiU2hvdWxkIHN1Y2ggdGVtcG9yYWwgZGVwZW5kZW5jeSBiZXR3ZWVuIGJlZm9yZSBh bmQNCj4gPiBhZnRlciB0aGUgbWVkaWEgd2FzIHBhdXNlZCBiZSB1c2VkIGJ5IHRoZSBSVFAgc3Ry ZWFtIHNlbmRlciwgaXQNCj4gPiByZXF1aXJlcyB0aGUgUlRQIHN0cmVhbSByZWNlaXZlciB0byBo YXZlIHNhdmVkIHRoZSBzYW1wbGUgZnJvbSBiZWZvcmUNCj4gPiB0aGUgcGF1c2UgZm9yIHN1Y2Nl c3NmdWwgY29udGludWVkIGRlY29kaW5nIHdoZW4gcmVzdW1pbmcuIg0KPiA+DQo+ID4gRG8geW91 IG1lYW4gdGVtcG9yYWwgZGVwZW5kZW5jeSBiZXR3ZWVuIHNhbXBsZXMgc2VudCBiZWZvcmUgYW5k IGFmdGVyDQo+ID4gdGhlIG1lZGlhIHdhcyBwYXVzZWQ/DQo+ID4NCj4gPiAidGVtcG9yYWwgZGVw ZW5kZW5jeSB0byBiZWZvcmUgdGhlIHBhdXNlIg0KPiA+DQo+ID4gZGVwZW5kZW5jeSBvbiBzYW1w bGVzIGZyb20gYmVmb3JlIHRoZSBwYXVzZT8NCj4gPg0KPiA+IC0tIDYuNCwgNHRoIHBhcmFncmFw aCBmcm9tIGVuZDoNCj4gPg0KPiA+IHMvInJlc3BvbnNpYmxlIHRvIGxlYXZlIi8icmVzcG9uc2li bGUgZm9yIGxlYXZpbmciDQo+ID4NCj4gPiBGaWd1cmUgNToNCj4gPg0KPiA+IGlzIGFsbCBvZiB0 aGUgYWJvdmUgKEJvdGggdGhlIGNvbW1vbiBwYWNrZXQgYW5kIHRoZSBGQ0kgZm9ybWF0cyBhbmQN Cj4gPiB0aGUgaW50ZXJ2ZW5pbmcgdGV4dCkgb25lIGZpZ3VyZSwgb3Igc2hvdWxkIHRoZXkgYmUg ZmlndXJlIDUgYW5kIDY/DQo+ID4NCj4gPiAtLSA4LjIsIGZpcnN0IHBhcmFncmFwaDoNCj4gPg0K PiA+IEFyZSB0aGVyZSBvdGhlciB3YXlzIHRvIGdldCBpbnRvIHRob3NlIHN0YXRlcz8gV291bGRu 4oCZdCBpdCBiZSBzaW1wbGVyDQo+ID4gdG8gc2F5IHRoZSBpbmRpY2F0aW9uIE1VU1QgYmUgc2Vu dCB3aGVuZXZlciBlbnRlcmluZyB0aGUgcGF1c2VkIG9yDQo+ID4gbG9jYWxseSBwYXVzZWQgc3Rh dGVzPw0KPiA+DQo+ID4gLS0gOSwgZmlyc3QgcGFyYWdyYXBoIGFmdGVyIEZpZ3VyZSA3OiAiYnV0 IE1BWSB1c2UgZXhpc3RpbmcgY2NtIHRtbWJyDQo+ID4gc2lnbmFsaW5nIFtSRkM1MTA0XSBpZiB0 aGUgbGltaXRhdGlvbnMgaW4gZnVuY3Rpb25hbGl0eSBhcyBkZXNjcmliZWQNCj4gPiBpbiB0aGlz IHNwZWNpZmljYXRpb24gY29taW5nIGZyb20gc3VjaCB1c2FnZSBhcmUgY29uc2lkZXJlZA0KPiA+ IGFjY2VwdGFibGUuIg0KPiA+DQo+ID4gSSBkb24ndCB1bmRlcnN0YW5kIHdoYXQgImNvbWluZyBm cm9tIHN1Y2ggdXNhZ2UiIG1lYW5zIGluIGNvbnRleHQuDQo+ID4NCj4gPiAtLSA5LCAybmQgcGFy YWdyYXBoIGFmdGVyIGZpZ3VyZSA3Og0KPiA+DQo+ID4gcy9pbmRlcGVuZGVudC9pbmRlcGVuZGVu dGx5DQo+ID4gcy9saWtlcy9uZWVkcyAob3Igd2FudHMpDQo+ID4NCj4gPg0KPiA+DQo+ID4NCj4g Pg0KPiA+DQo+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCj4gPiBhdnRleHQgbWFpbGluZyBsaXN0DQo+ID4gYXZ0ZXh0QGlldGYub3JnDQo+ID4gaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9hdnRleHQNCg== From nobody Mon Jun 22 13:44:58 2015 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4B841ACE3C; Mon, 22 Jun 2015 13:44:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TMv9NXyJpjlq; Mon, 22 Jun 2015 13:44:54 -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 8DC3C1ACDAA; Mon, 22 Jun 2015 13:44:54 -0700 (PDT) Received: from [10.0.1.23] (cpe-70-119-203-4.tx.res.rr.com [70.119.203.4]) (authenticated bits=0) by nostrum.com (8.15.1/8.14.9) with ESMTPSA id t5MKieOK096571 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 22 Jun 2015 15:44:50 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-70-119-203-4.tx.res.rr.com [70.119.203.4] claimed to be [10.0.1.23] From: "Ben Campbell" To: "Bo Burman" Date: Mon, 22 Jun 2015 15:44:40 -0500 Message-ID: <3A48DE66-626B-4CED-9F1A-E7E90557768F@nostrum.com> In-Reply-To: References: <257ACC1A-936C-4C32-81E2-E2A88512B20A@nostrum.com> <14F5435A-E14C-48E3-BAC2-5BF2CB7D6F33@nostrum.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.1r5084) Archived-At: Cc: "avtext@ietf.org" , "draft-ietf-avtext-rtp-stream-pause.all@ietf.org" Subject: Re: [avtext] AD Evaluation of draft-ietf-avtext-rtp-stream-pause-07 X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jun 2015 20:44:56 -0000 On 22 Jun 2015, at 11:42, Bo Burman wrote: > Ben, all, > > Please see inline. > > Cheers, > Bo > >> -----Original Message----- >> From: Ben Campbell [mailto:ben@nostrum.com] >> Sent: den 18 juni 2015 22:57 >> To: draft-ietf-avtext-rtp-stream-pause.all@ietf.org; avtext@ietf.org >> Subject: Re: [avtext] AD Evaluation of >> draft-ietf-avtext-rtp-stream-pause-07 >> >> Hi, >> >> I have a few comments on further reflection: >> >> I notice that there are IPR declarations against the original version >> (prior to wg acceptance.) The license terms allow the >> possibility of royalties. I also see that the shepherd writeup >> mentions that avtext discussed these and are okay with >> them. However, this draft references some RTCWEB requirements as >> partial motivation. Have the IPR disclosures been >> discussed with RTCWEB, to confirm that they would be willing to use a >> mechanism with those disclosures? > [BoB] Use of this draft in RTCWEB context has been discussed, e.g. in > this thread > https://mailarchive.ietf.org/arch/msg/rtcweb/d95AfR5YthE7O4he4yaTCOj8h1o, > clarifying that use in RTCWEB would mainly target the RFC 5104-based > TMMBR/TMMBN 0 mode, and one of the conclusions of the discussion was > to keep the functionality out of v1.0. The draft is currently not > referenced from any RTCWEB v1.0 specification. One of the alternatives > mentioned in the thread above was to use an application-specific > message in a DataChannel, but I cannot find that there was ever any > consensus on what to do in v1.0, or if it should be specified at all. If this draft is not referenced by RTCWEB, is the mention of RTCWEB use cases still relevant? (Unless I am reading it wrong, the quoted use cases really only support the "paused" semantic.) > >> >> On my comments about the "config" parameter: >> >> The root of my concern is not the mechanism for negotiating partial >> support, but the number of config "profiles". It >> seems like this could encourage implementations that cannot use the >> mechanism interoperably. >> For example, the draft shows use cases where a conference bridge >> might need to ask an endpoint to pause. If people >> build endpoints that only support 2 or 3, then this would not be >> possible. > [BoB] Let me try to answer by highlighting and summarizing the > underlying reasons for those different config "profiles". > > Config=1 is the "full" implementation. > > Config=2 and 4 are intended for the RTP stream receiver that wants to > pause/resume the remote sender's stream, but sees no use of letting > anyone pause/resume its own sent RTP streams (if any). This may > typically be implemented by a conference bridge. Config=4 differs from > 2 only in that config=4 has no PAUSED support. To implement config=2 > or 4 in an endpoint supposed to be connected to a conference bridge > would obviously not work and would in my mind be a mistake or > misunderstanding of the draft text rather than a deliberate design. Do > you think that a clarification is needed in this respect? > > Config=3 and 5 are intended for the RTP stream sender that wants to > leave pause/resume control to a remote RTP stream receiver, but has no > desire to control anyone else's RTP streams. This may typically be > implemented by an endpoint participating in a group call through a > conference bridge. 5 differs from 3 only in that it has no PAUSED > support. Similar to above, implementing config=3 or 5 in a conference > bridge could be a misunderstanding or mistake. Do you clarification is > needed? (In reference to the last sentence of each paragraph): In general, I think this is an issue of balancing interoperability against the ability of implemntors that don't (think they) need to support all use cases to implement profiles. That's been a general issue for the IETF more than once, and I'm not sure we've ever gotten it right. A few paragraphs about the interoperability considerations among the various modes would be helpful. > > Config=6-8 all deal only with PAUSED (sendrecv/recvonly/sendonly > capability, respectively). If I remember correctly, it was brought up > during an IETF meeting (forgot which and by whom) that it could be a > useful functionality in itself to indicate local pause. I then assumed > that the it was not desirable to require the rest of pause/resume > functionality to be able to use that, which is why config=6-8 are > there in the draft. Implementations of config=6-8 are obviously not > able to get any pause/resume functionality, but assumedly also don't > wish to, and are in any case "interoperable" with other config > supporting PAUSED. I'm skeptical about adding modes because they "might be useful", vs demonstrably needed. To some degree, the "might be useful" argument supports Paul's suggestion of indicating support on a per-method basis. But it's a bit late in the process to push on that (the "might be useful) part, so I will not do so further. > > Regarding config=4 and 5, not supporting PAUSED is not detrimental to > pause/resume functionality and is in that sense "backwards > compatible", but having explicit indication of PAUSED support allows > to avoid some heuristics and delays in pause/resume implementation > control logic, in addition to saving the bandwidth for sending > unnecessary PAUSED. > > As a side comment, use of pause/resume in a conference bridge > cascading scenario would likely require config=1 between the > conference bridges to provide sufficient functionality. That would be worth a mention in the aforementioned interop considerations. > >> >> So my real question is, does the mechanism really need all 8 modes? >> Are there known situations where an implementer >> would choose not to implement this mechanism if one of the modes >> didn't exist? Some of them seem to have fairly >> subtle differences (e.g. whether the device may locally pause or >> not.) > [BoB] I'd rather say that if there were no configurations at all, > there's a risk that implementations may anyway choose to implement a > subset of the full functionality because it sees no use for the rest > (correctly or not), like a conference bridge that sees no point in > pausing its sent RTP streams. Is it not better from an > interoperability perspective to specify how this subset restriction > must be made to achieve a certain desirable functionality, instead of > leaving it to individual implementations to decide what parts of the > specification can and what cannot be omitted (admittedly in violation > of the specification), to still have a reasonably working and > interoperable implementation? Have potential implementors indicated they would do that? > > Are there too many configurations? I don't see how this can be > determined with any certainty until there is a significant number of > implementations in several different contexts. The number of config's > _can_ certainly be reduced if you change the preconditions. If you for > example were to require that all implementations must support PAUSED, > _and_ that no implementations are allowed to _only_ support PAUSED, > the number of configurations that are supported by any reasonable > remaining use case would immediately drop to three (configurations > 1-3). I guess I was thinking more in terms of whether all the modes are actually needed by use cases that people have thought about. But this also falls into the case of being too late in the process to push on it. [...] Thanks! Ben. From nobody Mon Jun 22 16:42:44 2015 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A8A01B2A2F; Mon, 22 Jun 2015 16:42:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FrI83RZIGAK1; Mon, 22 Jun 2015 16:42:40 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpgre-esg-01.alcatel-lucent.com [135.245.210.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C6F61B2B19; Mon, 22 Jun 2015 16:42:40 -0700 (PDT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (unknown [135.239.2.122]) by Websense Email Security Gateway with ESMTPS id B91E879B0F7BE; Mon, 22 Jun 2015 23:42:34 +0000 (GMT) Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id t5MNgbPn029808 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 23 Jun 2015 01:42:38 +0200 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.203]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.03.0195.001; Tue, 23 Jun 2015 01:42:37 +0200 From: "DRAGE, Keith (Keith)" To: Ben Campbell , Bo Burman Thread-Topic: [avtext] AD Evaluation of draft-ietf-avtext-rtp-stream-pause-07 Thread-Index: AQHQp+M5Kaz9t8QKX0KKwl0dRiYB5J2yoTQAgAYCOQCAAEPKAIAAUpYQ Date: Mon, 22 Jun 2015 23:42:36 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8B6973118C@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <257ACC1A-936C-4C32-81E2-E2A88512B20A@nostrum.com> <14F5435A-E14C-48E3-BAC2-5BF2CB7D6F33@nostrum.com> <3A48DE66-626B-4CED-9F1A-E7E90557768F@nostrum.com> In-Reply-To: <3A48DE66-626B-4CED-9F1A-E7E90557768F@nostrum.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.40] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "avtext@ietf.org" , "draft-ietf-avtext-rtp-stream-pause.all@ietf.org" Subject: Re: [avtext] AD Evaluation of draft-ietf-avtext-rtp-stream-pause-07 X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jun 2015 23:42:43 -0000 I'd note there are drafts all over IETF that could potentially be used in R= TCWEB implementations, even though they are not directly referenced. We cou= ld start with all PAYLOAD deliverables, all XRBLOCK deliverables, all CLUE = deliverables .... Your initial comment is effectively asking for RTCWEB to be included in the= WGLC of all those documents. Regards Keith =20 > -----Original Message----- > From: Ben Campbell [mailto:ben@nostrum.com]=20 > Sent: 22 June 2015 21:45 > To: Bo Burman > Cc: draft-ietf-avtext-rtp-stream-pause.all@ietf.org; avtext@ietf.org > Subject: Re: [avtext] AD Evaluation of=20 > draft-ietf-avtext-rtp-stream-pause-07 >=20 > On 22 Jun 2015, at 11:42, Bo Burman wrote: >=20 > > Ben, all, > > > > Please see inline. > > > > Cheers, > > Bo > > > >> -----Original Message----- > >> From: Ben Campbell [mailto:ben@nostrum.com] > >> Sent: den 18 juni 2015 22:57 > >> To: draft-ietf-avtext-rtp-stream-pause.all@ietf.org;=20 > avtext@ietf.org > >> Subject: Re: [avtext] AD Evaluation of > >> draft-ietf-avtext-rtp-stream-pause-07 > >> > >> Hi, > >> > >> I have a few comments on further reflection: > >> > >> I notice that there are IPR declarations against the=20 > original version=20 > >> (prior to wg acceptance.) The license terms allow the=20 > possibility of=20 > >> royalties. I also see that the shepherd writeup mentions=20 > that avtext=20 > >> discussed these and are okay with them. However, this draft=20 > >> references some RTCWEB requirements as partial motivation.=20 > Have the=20 > >> IPR disclosures been discussed with RTCWEB, to confirm that they=20 > >> would be willing to use a mechanism with those disclosures? > > [BoB] Use of this draft in RTCWEB context has been=20 > discussed, e.g. in=20 > > this thread=20 > >=20 > https://mailarchive.ietf.org/arch/msg/rtcweb/d95AfR5YthE7O4he4yaTCOj8h > > 1o, clarifying that use in RTCWEB would mainly target the RFC=20 > > 5104-based TMMBR/TMMBN 0 mode, and one of the conclusions of the=20 > > discussion was to keep the functionality out of v1.0. The draft is=20 > > currently not referenced from any RTCWEB v1.0 specification. One of=20 > > the alternatives mentioned in the thread above was to use an=20 > > application-specific message in a DataChannel, but I cannot=20 > find that=20 > > there was ever any consensus on what to do in v1.0, or if=20 > it should be=20 > > specified at all. >=20 > If this draft is not referenced by RTCWEB, is the mention of=20 > RTCWEB use cases still relevant? (Unless I am reading it=20 > wrong, the quoted use cases really only support the "paused"=20 > semantic.) >=20 > > > >> > >> On my comments about the "config" parameter: > >> > >> The root of my concern is not the mechanism for=20 > negotiating partial=20 > >> support, but the number of config "profiles". It > >> seems like this could encourage implementations that=20 > cannot use the=20 > >> mechanism interoperably. > >> For example, the draft shows use cases where a conference bridge=20 > >> might need to ask an endpoint to pause. If people > >> build endpoints that only support 2 or 3, then this would not be=20 > >> possible. > > [BoB] Let me try to answer by highlighting and summarizing the=20 > > underlying reasons for those different config "profiles". > > > > Config=3D1 is the "full" implementation. > > > > Config=3D2 and 4 are intended for the RTP stream receiver=20 > that wants to=20 > > pause/resume the remote sender's stream, but sees no use of letting=20 > > anyone pause/resume its own sent RTP streams (if any). This may=20 > > typically be implemented by a conference bridge. Config=3D4=20 > differs from=20 > > 2 only in that config=3D4 has no PAUSED support. To implement=20 > config=3D2=20 > > or 4 in an endpoint supposed to be connected to a conference bridge=20 > > would obviously not work and would in my mind be a mistake or=20 > > misunderstanding of the draft text rather than a deliberate=20 > design. Do=20 > > you think that a clarification is needed in this respect? > > > > Config=3D3 and 5 are intended for the RTP stream sender that wants to=20 > > leave pause/resume control to a remote RTP stream receiver,=20 > but has no=20 > > desire to control anyone else's RTP streams. This may typically be=20 > > implemented by an endpoint participating in a group call through a=20 > > conference bridge. 5 differs from 3 only in that it has no PAUSED=20 > > support. Similar to above, implementing config=3D3 or 5 in a=20 > conference=20 > > bridge could be a misunderstanding or mistake. Do you=20 > clarification is=20 > > needed? >=20 > (In reference to the last sentence of each paragraph): In general, I=20 > think this is an issue of balancing interoperability against=20 > the ability=20 > of implemntors that don't (think they) need to support all=20 > use cases to=20 > implement profiles. That's been a general issue for the IETF=20 > more than=20 > once, and I'm not sure we've ever gotten it right. A few paragraphs=20 > about the interoperability considerations among the various=20 > modes would=20 > be helpful. > > > > Config=3D6-8 all deal only with PAUSED (sendrecv/recvonly/sendonly=20 > > capability, respectively). If I remember correctly, it was=20 > brought up=20 > > during an IETF meeting (forgot which and by whom) that it=20 > could be a=20 > > useful functionality in itself to indicate local pause. I=20 > then assumed=20 > > that the it was not desirable to require the rest of pause/resume=20 > > functionality to be able to use that, which is why config=3D6-8 are=20 > > there in the draft. Implementations of config=3D6-8 are obviously not=20 > > able to get any pause/resume functionality, but assumedly=20 > also don't=20 > > wish to, and are in any case "interoperable" with other config=20 > > supporting PAUSED. >=20 > I'm skeptical about adding modes because they "might be useful", vs=20 > demonstrably needed. To some degree, the "might be useful" argument=20 > supports Paul's suggestion of indicating support on a=20 > per-method basis.=20 > But it's a bit late in the process to push on that (the "might be=20 > useful) part, so I will not do so further. >=20 > > > > Regarding config=3D4 and 5, not supporting PAUSED is not=20 > detrimental to=20 > > pause/resume functionality and is in that sense "backwards=20 > > compatible", but having explicit indication of PAUSED=20 > support allows=20 > > to avoid some heuristics and delays in pause/resume implementation=20 > > control logic, in addition to saving the bandwidth for sending=20 > > unnecessary PAUSED. > > > > As a side comment, use of pause/resume in a conference bridge=20 > > cascading scenario would likely require config=3D1 between the=20 > > conference bridges to provide sufficient functionality. >=20 > That would be worth a mention in the aforementioned interop=20 > considerations. >=20 > > > >> > >> So my real question is, does the mechanism really need all=20 > 8 modes?=20 > >> Are there known situations where an implementer > >> would choose not to implement this mechanism if one of the modes=20 > >> didn't exist? Some of them seem to have fairly > >> subtle differences (e.g. whether the device may locally pause or=20 > >> not.) > > [BoB] I'd rather say that if there were no configurations at all,=20 > > there's a risk that implementations may anyway choose to=20 > implement a=20 > > subset of the full functionality because it sees no use for=20 > the rest=20 > > (correctly or not), like a conference bridge that sees no point in=20 > > pausing its sent RTP streams. Is it not better from an=20 > > interoperability perspective to specify how this subset restriction=20 > > must be made to achieve a certain desirable functionality,=20 > instead of=20 > > leaving it to individual implementations to decide what=20 > parts of the=20 > > specification can and what cannot be omitted (admittedly in=20 > violation=20 > > of the specification), to still have a reasonably working and=20 > > interoperable implementation? >=20 > Have potential implementors indicated they would do that? >=20 > > > > Are there too many configurations? I don't see how this can be=20 > > determined with any certainty until there is a significant=20 > number of=20 > > implementations in several different contexts. The number=20 > of config's=20 > > _can_ certainly be reduced if you change the preconditions.=20 > If you for=20 > > example were to require that all implementations must=20 > support PAUSED,=20 > > _and_ that no implementations are allowed to _only_ support PAUSED,=20 > > the number of configurations that are supported by any reasonable=20 > > remaining use case would immediately drop to three (configurations=20 > > 1-3). >=20 > I guess I was thinking more in terms of whether all the modes are=20 > actually needed by use cases that people have thought about. But this=20 > also falls into the case of being too late in the process to=20 > push on it. >=20 > [...] >=20 > Thanks! >=20 > Ben. > = From nobody Mon Jun 22 16:48:22 2015 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE7141B2A6E; Mon, 22 Jun 2015 16:48:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y6NQ24Vw5-Ud; Mon, 22 Jun 2015 16:48:17 -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 994FC1B2AC4; Mon, 22 Jun 2015 16:48:17 -0700 (PDT) Received: from [10.0.1.23] (cpe-70-119-203-4.tx.res.rr.com [70.119.203.4]) (authenticated bits=0) by nostrum.com (8.15.1/8.14.9) with ESMTPSA id t5MNm0Oc012631 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 22 Jun 2015 18:48:11 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-70-119-203-4.tx.res.rr.com [70.119.203.4] claimed to be [10.0.1.23] From: "Ben Campbell" To: "DRAGE, Keith (Keith)" Date: Mon, 22 Jun 2015 18:48:00 -0500 Message-ID: <6C30C3F4-058B-4CCD-ADC3-829132657050@nostrum.com> In-Reply-To: <949EF20990823C4C85C18D59AA11AD8B6973118C@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <257ACC1A-936C-4C32-81E2-E2A88512B20A@nostrum.com> <14F5435A-E14C-48E3-BAC2-5BF2CB7D6F33@nostrum.com> <3A48DE66-626B-4CED-9F1A-E7E90557768F@nostrum.com> <949EF20990823C4C85C18D59AA11AD8B6973118C@FR712WXCHMBA11.zeu.alcatel-lucent.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.1r5084) Archived-At: Cc: "avtext@ietf.org" , "draft-ietf-avtext-rtp-stream-pause.all@ietf.org" Subject: Re: [avtext] AD Evaluation of draft-ietf-avtext-rtp-stream-pause-07 X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jun 2015 23:48:21 -0000 On 22 Jun 2015, at 18:42, DRAGE, Keith (Keith) wrote: > I'd note there are drafts all over IETF that could potentially be used > in RTCWEB implementations, even though they are not directly > referenced. We could start with all PAYLOAD deliverables, all XRBLOCK > deliverables, all CLUE deliverables .... > > Your initial comment is effectively asking for RTCWEB to be included > in the WGLC of all those documents. That wasn't my intent. This document _explicitly_ lists RTCWEB use cases, and this document (actually its predecessor) has potentially non-royalty-free IPR disclosures. My question was, if RTCWEB had a dependency on the mechanism(s) in this draft, were they okay with the IPR. The answer seems to be that RTCWEB does not (at this time) have a dependency on this draft. So it's all good :-) I followed up to question whether it still made sense to mention the RTCWEB use cases, but I'm okay either way there. Ben. > > Regards > > Keith > > >> -----Original Message----- >> From: Ben Campbell [mailto:ben@nostrum.com] >> Sent: 22 June 2015 21:45 >> To: Bo Burman >> Cc: draft-ietf-avtext-rtp-stream-pause.all@ietf.org; avtext@ietf.org >> Subject: Re: [avtext] AD Evaluation of >> draft-ietf-avtext-rtp-stream-pause-07 >> >> On 22 Jun 2015, at 11:42, Bo Burman wrote: >> >>> Ben, all, >>> >>> Please see inline. >>> >>> Cheers, >>> Bo >>> >>>> -----Original Message----- >>>> From: Ben Campbell [mailto:ben@nostrum.com] >>>> Sent: den 18 juni 2015 22:57 >>>> To: draft-ietf-avtext-rtp-stream-pause.all@ietf.org; >> avtext@ietf.org >>>> Subject: Re: [avtext] AD Evaluation of >>>> draft-ietf-avtext-rtp-stream-pause-07 >>>> >>>> Hi, >>>> >>>> I have a few comments on further reflection: >>>> >>>> I notice that there are IPR declarations against the >> original version >>>> (prior to wg acceptance.) The license terms allow the >> possibility of >>>> royalties. I also see that the shepherd writeup mentions >> that avtext >>>> discussed these and are okay with them. However, this draft >>>> references some RTCWEB requirements as partial motivation. >> Have the >>>> IPR disclosures been discussed with RTCWEB, to confirm that they >>>> would be willing to use a mechanism with those disclosures? >>> [BoB] Use of this draft in RTCWEB context has been >> discussed, e.g. in >>> this thread >>> >> https://mailarchive.ietf.org/arch/msg/rtcweb/d95AfR5YthE7O4he4yaTCOj8h >>> 1o, clarifying that use in RTCWEB would mainly target the RFC >>> 5104-based TMMBR/TMMBN 0 mode, and one of the conclusions of the >>> discussion was to keep the functionality out of v1.0. The draft is >>> currently not referenced from any RTCWEB v1.0 specification. One of >>> the alternatives mentioned in the thread above was to use an >>> application-specific message in a DataChannel, but I cannot >> find that >>> there was ever any consensus on what to do in v1.0, or if >> it should be >>> specified at all. >> >> If this draft is not referenced by RTCWEB, is the mention of >> RTCWEB use cases still relevant? (Unless I am reading it >> wrong, the quoted use cases really only support the "paused" >> semantic.) >> >>> >>>> >>>> On my comments about the "config" parameter: >>>> >>>> The root of my concern is not the mechanism for >> negotiating partial >>>> support, but the number of config "profiles". It >>>> seems like this could encourage implementations that >> cannot use the >>>> mechanism interoperably. >>>> For example, the draft shows use cases where a conference bridge >>>> might need to ask an endpoint to pause. If people >>>> build endpoints that only support 2 or 3, then this would not be >>>> possible. >>> [BoB] Let me try to answer by highlighting and summarizing the >>> underlying reasons for those different config "profiles". >>> >>> Config=1 is the "full" implementation. >>> >>> Config=2 and 4 are intended for the RTP stream receiver >> that wants to >>> pause/resume the remote sender's stream, but sees no use of letting >>> anyone pause/resume its own sent RTP streams (if any). This may >>> typically be implemented by a conference bridge. Config=4 >> differs from >>> 2 only in that config=4 has no PAUSED support. To implement >> config=2 >>> or 4 in an endpoint supposed to be connected to a conference bridge >>> would obviously not work and would in my mind be a mistake or >>> misunderstanding of the draft text rather than a deliberate >> design. Do >>> you think that a clarification is needed in this respect? >>> >>> Config=3 and 5 are intended for the RTP stream sender that wants to >>> leave pause/resume control to a remote RTP stream receiver, >> but has no >>> desire to control anyone else's RTP streams. This may typically be >>> implemented by an endpoint participating in a group call through a >>> conference bridge. 5 differs from 3 only in that it has no PAUSED >>> support. Similar to above, implementing config=3 or 5 in a >> conference >>> bridge could be a misunderstanding or mistake. Do you >> clarification is >>> needed? >> >> (In reference to the last sentence of each paragraph): In general, I >> think this is an issue of balancing interoperability against >> the ability >> of implemntors that don't (think they) need to support all >> use cases to >> implement profiles. That's been a general issue for the IETF >> more than >> once, and I'm not sure we've ever gotten it right. A few paragraphs >> about the interoperability considerations among the various >> modes would >> be helpful. >>> >>> Config=6-8 all deal only with PAUSED (sendrecv/recvonly/sendonly >>> capability, respectively). If I remember correctly, it was >> brought up >>> during an IETF meeting (forgot which and by whom) that it >> could be a >>> useful functionality in itself to indicate local pause. I >> then assumed >>> that the it was not desirable to require the rest of pause/resume >>> functionality to be able to use that, which is why config=6-8 are >>> there in the draft. Implementations of config=6-8 are obviously not >>> able to get any pause/resume functionality, but assumedly >> also don't >>> wish to, and are in any case "interoperable" with other config >>> supporting PAUSED. >> >> I'm skeptical about adding modes because they "might be useful", vs >> demonstrably needed. To some degree, the "might be useful" argument >> supports Paul's suggestion of indicating support on a >> per-method basis. >> But it's a bit late in the process to push on that (the "might be >> useful) part, so I will not do so further. >> >>> >>> Regarding config=4 and 5, not supporting PAUSED is not >> detrimental to >>> pause/resume functionality and is in that sense "backwards >>> compatible", but having explicit indication of PAUSED >> support allows >>> to avoid some heuristics and delays in pause/resume implementation >>> control logic, in addition to saving the bandwidth for sending >>> unnecessary PAUSED. >>> >>> As a side comment, use of pause/resume in a conference bridge >>> cascading scenario would likely require config=1 between the >>> conference bridges to provide sufficient functionality. >> >> That would be worth a mention in the aforementioned interop >> considerations. >> >>> >>>> >>>> So my real question is, does the mechanism really need all >> 8 modes? >>>> Are there known situations where an implementer >>>> would choose not to implement this mechanism if one of the modes >>>> didn't exist? Some of them seem to have fairly >>>> subtle differences (e.g. whether the device may locally pause or >>>> not.) >>> [BoB] I'd rather say that if there were no configurations at all, >>> there's a risk that implementations may anyway choose to >> implement a >>> subset of the full functionality because it sees no use for >> the rest >>> (correctly or not), like a conference bridge that sees no point in >>> pausing its sent RTP streams. Is it not better from an >>> interoperability perspective to specify how this subset restriction >>> must be made to achieve a certain desirable functionality, >> instead of >>> leaving it to individual implementations to decide what >> parts of the >>> specification can and what cannot be omitted (admittedly in >> violation >>> of the specification), to still have a reasonably working and >>> interoperable implementation? >> >> Have potential implementors indicated they would do that? >> >>> >>> Are there too many configurations? I don't see how this can be >>> determined with any certainty until there is a significant >> number of >>> implementations in several different contexts. The number >> of config's >>> _can_ certainly be reduced if you change the preconditions. >> If you for >>> example were to require that all implementations must >> support PAUSED, >>> _and_ that no implementations are allowed to _only_ support PAUSED, >>> the number of configurations that are supported by any reasonable >>> remaining use case would immediately drop to three (configurations >>> 1-3). >> >> I guess I was thinking more in terms of whether all the modes are >> actually needed by use cases that people have thought about. But this >> also falls into the case of being too late in the process to >> push on it. >> >> [...] >> >> Thanks! >> >> Ben. >> From nobody Tue Jun 23 03:51:51 2015 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54E991B2AD6; Tue, 23 Jun 2015 03:51:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nqnEFQj1VNcY; Tue, 23 Jun 2015 03:51:47 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B0A9E1B2AD8; Tue, 23 Jun 2015 03:51:46 -0700 (PDT) X-AuditID: c1b4fb2d-f794d6d000004501-0c-55893a40746b Received: from ESESSHC016.ericsson.se (Unknown_Domain [153.88.253.125]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id B5.C9.17665.04A39855; Tue, 23 Jun 2015 12:51:45 +0200 (CEST) Received: from ESESSMB105.ericsson.se ([169.254.5.230]) by ESESSHC016.ericsson.se ([153.88.183.66]) with mapi id 14.03.0210.002; Tue, 23 Jun 2015 12:51:43 +0200 From: Bo Burman To: Ben Campbell Thread-Topic: [avtext] AD Evaluation of draft-ietf-avtext-rtp-stream-pause-07 Thread-Index: AQHQp+M1de23osNNK0+7Tf45n1U2852yoTUAgAXnfsCAAF6EAIAA1IGQ Date: Tue, 23 Jun 2015 10:51:43 +0000 Message-ID: References: <257ACC1A-936C-4C32-81E2-E2A88512B20A@nostrum.com> <14F5435A-E14C-48E3-BAC2-5BF2CB7D6F33@nostrum.com> <3A48DE66-626B-4CED-9F1A-E7E90557768F@nostrum.com> In-Reply-To: <3A48DE66-626B-4CED-9F1A-E7E90557768F@nostrum.com> Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.18] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrELMWRmVeSWpSXmKPExsUyM+Jvra6jVWeoQctpZouP926wWszvPM1u ce7DVFYHZo8lS34yecza+YQlgCmKyyYlNSezLLVI3y6BK+NG5xTGglmuFXMnrmduYNxv3sXI ySEhYCIx6dM0VghbTOLCvfVsXYxcHEICRxklps+ZywThLGGUuNn6FayKTUBDYv6Ou4wgtoiA ksTz5q0sIEXMAhMYJW5M3sEEkhAW8JFYcOUC0CgOoCJfiXfzdCDq3SR6by9gBQmzCKhKrD6f AmLyAlUc7jGAWPWGUeLilvlgqzgF7CVe72pnB7EZBWQl7n+/xwJiMwuIS9x6Mp8J4mgBiSV7 zjND2KISLx//g3pGUeLjq32MEPU6Egt2f2KDsLUlli18DVbPKyAocXLmE5YJjGKzkIydhaRl FpKWWUhaFjCyrGIULU4tLs5NNzLWSy3KTC4uzs/Ty0st2cQIjKSDW37r7mBc/drxEKMAB6MS D++CvR2hQqyJZcWVuYcYpTlYlMR5Z2zOCxUSSE8sSc1OTS1ILYovKs1JLT7EyMTBKdXAGFt6 42HTLk8n9rofOW8YRZ92iBlvqdVxXnzj5aZ4hpm7lspmXp0n4fV4VRuHFFeMieHLGTNkF/ay +jzda53J8tTT+nzyfaPNniLH1sq/UVOpcLrHsX/63qgEW7fwZ4t4mhQs7WYvWMFe4XzSg0tH 5r3sbzPt6t+yHpddkwM6zXbIKt9+qZ+sxFKckWioxVxUnAgAi23h9YUCAAA= Archived-At: Cc: "avtext@ietf.org" , "draft-ietf-avtext-rtp-stream-pause.all@ietf.org" Subject: Re: [avtext] AD Evaluation of draft-ietf-avtext-rtp-stream-pause-07 X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jun 2015 10:51:50 -0000 Please find a few more comments inline. Cheers, Bo > -----Original Message----- > From: Ben Campbell [mailto:ben@nostrum.com] > Sent: den 22 juni 2015 22:45 > To: Bo Burman > Cc: draft-ietf-avtext-rtp-stream-pause.all@ietf.org; avtext@ietf.org > Subject: Re: [avtext] AD Evaluation of draft-ietf-avtext-rtp-stream-pause= -07 >=20 > On 22 Jun 2015, at 11:42, Bo Burman wrote: >=20 > > Ben, all, > > > > Please see inline. > > > > Cheers, > > Bo > > > >> -----Original Message----- > >> From: Ben Campbell [mailto:ben@nostrum.com] > >> Sent: den 18 juni 2015 22:57 > >> To: draft-ietf-avtext-rtp-stream-pause.all@ietf.org; avtext@ietf.org > >> Subject: Re: [avtext] AD Evaluation of > >> draft-ietf-avtext-rtp-stream-pause-07 > >> > >> Hi, > >> > >> I have a few comments on further reflection: > >> > >> I notice that there are IPR declarations against the original version > >> (prior to wg acceptance.) The license terms allow the possibility of > >> royalties. I also see that the shepherd writeup mentions that avtext > >> discussed these and are okay with them. However, this draft > >> references some RTCWEB requirements as partial motivation. Have the > >> IPR disclosures been discussed with RTCWEB, to confirm that they > >> would be willing to use a mechanism with those disclosures? > > [BoB] Use of this draft in RTCWEB context has been discussed, e.g. in > > this thread > > https://mailarchive.ietf.org/arch/msg/rtcweb/d95AfR5YthE7O4he4yaTCOj8h > > 1o, clarifying that use in RTCWEB would mainly target the RFC > > 5104-based TMMBR/TMMBN 0 mode, and one of the conclusions of the > > discussion was to keep the functionality out of v1.0. The draft is > > currently not referenced from any RTCWEB v1.0 specification. One of > > the alternatives mentioned in the thread above was to use an > > application-specific message in a DataChannel, but I cannot find that > > there was ever any consensus on what to do in v1.0, or if it should be > > specified at all. >=20 > If this draft is not referenced by RTCWEB, is the mention of RTCWEB use = cases still relevant? (Unless I am reading it > wrong, the quoted use cases really only support the "paused" semantic.) [BoB] I think it is still relevant, especially since RTCWEB did not yet spe= cify any solution, which perhaps should be stated. I think you are right th= at the listed mandatory RTCWEB use cases only support the "paused" semantic= . >=20 > > > >> > >> On my comments about the "config" parameter: > >> > >> The root of my concern is not the mechanism for negotiating partial > >> support, but the number of config "profiles". It > >> seems like this could encourage implementations that cannot use the > >> mechanism interoperably. > >> For example, the draft shows use cases where a conference bridge > >> might need to ask an endpoint to pause. If people > >> build endpoints that only support 2 or 3, then this would not be > >> possible. > > [BoB] Let me try to answer by highlighting and summarizing the > > underlying reasons for those different config "profiles". > > > > Config=3D1 is the "full" implementation. > > > > Config=3D2 and 4 are intended for the RTP stream receiver that wants to > > pause/resume the remote sender's stream, but sees no use of letting > > anyone pause/resume its own sent RTP streams (if any). This may > > typically be implemented by a conference bridge. Config=3D4 differs fro= m > > 2 only in that config=3D4 has no PAUSED support. To implement config=3D= 2 > > or 4 in an endpoint supposed to be connected to a conference bridge > > would obviously not work and would in my mind be a mistake or > > misunderstanding of the draft text rather than a deliberate design. Do > > you think that a clarification is needed in this respect? > > > > Config=3D3 and 5 are intended for the RTP stream sender that wants to > > leave pause/resume control to a remote RTP stream receiver, but has no > > desire to control anyone else's RTP streams. This may typically be > > implemented by an endpoint participating in a group call through a > > conference bridge. 5 differs from 3 only in that it has no PAUSED > > support. Similar to above, implementing config=3D3 or 5 in a conference > > bridge could be a misunderstanding or mistake. Do you clarification is > > needed? >=20 > (In reference to the last sentence of each paragraph): In general, I > think this is an issue of balancing interoperability against the ability > of implemntors that don't (think they) need to support all use cases to > implement profiles. That's been a general issue for the IETF more than > once, and I'm not sure we've ever gotten it right. A few paragraphs > about the interoperability considerations among the various modes would > be helpful. [BoB] OK. I'll add that. > > > > Config=3D6-8 all deal only with PAUSED (sendrecv/recvonly/sendonly > > capability, respectively). If I remember correctly, it was brought up > > during an IETF meeting (forgot which and by whom) that it could be a > > useful functionality in itself to indicate local pause. I then assumed > > that the it was not desirable to require the rest of pause/resume > > functionality to be able to use that, which is why config=3D6-8 are > > there in the draft. Implementations of config=3D6-8 are obviously not > > able to get any pause/resume functionality, but assumedly also don't > > wish to, and are in any case "interoperable" with other config > > supporting PAUSED. >=20 > I'm skeptical about adding modes because they "might be useful", vs > demonstrably needed. To some degree, the "might be useful" argument > supports Paul's suggestion of indicating support on a per-method basis. > But it's a bit late in the process to push on that (the "might be > useful) part, so I will not do so further. >=20 > > > > Regarding config=3D4 and 5, not supporting PAUSED is not detrimental to > > pause/resume functionality and is in that sense "backwards > > compatible", but having explicit indication of PAUSED support allows > > to avoid some heuristics and delays in pause/resume implementation > > control logic, in addition to saving the bandwidth for sending > > unnecessary PAUSED. > > > > As a side comment, use of pause/resume in a conference bridge > > cascading scenario would likely require config=3D1 between the > > conference bridges to provide sufficient functionality. >=20 > That would be worth a mention in the aforementioned interop > considerations. [BoB] OK. >=20 > > > >> > >> So my real question is, does the mechanism really need all 8 modes? > >> Are there known situations where an implementer > >> would choose not to implement this mechanism if one of the modes > >> didn't exist? Some of them seem to have fairly > >> subtle differences (e.g. whether the device may locally pause or > >> not.) > > [BoB] I'd rather say that if there were no configurations at all, > > there's a risk that implementations may anyway choose to implement a > > subset of the full functionality because it sees no use for the rest > > (correctly or not), like a conference bridge that sees no point in > > pausing its sent RTP streams. Is it not better from an > > interoperability perspective to specify how this subset restriction > > must be made to achieve a certain desirable functionality, instead of > > leaving it to individual implementations to decide what parts of the > > specification can and what cannot be omitted (admittedly in violation > > of the specification), to still have a reasonably working and > > interoperable implementation? >=20 > Have potential implementors indicated they would do that? [BoB] Not explicitly. This is more of a concern among the authors along the= lines of your comment above, pro-actively trying to support finding a bala= nce between interoperability and the need to support all use cases. >=20 > > > > Are there too many configurations? I don't see how this can be > > determined with any certainty until there is a significant number of > > implementations in several different contexts. The number of config's > > _can_ certainly be reduced if you change the preconditions. If you for > > example were to require that all implementations must support PAUSED, > > _and_ that no implementations are allowed to _only_ support PAUSED, > > the number of configurations that are supported by any reasonable > > remaining use case would immediately drop to three (configurations > > 1-3). >=20 > I guess I was thinking more in terms of whether all the modes are > actually needed by use cases that people have thought about. But this > also falls into the case of being too late in the process to push on it. >=20 > [...] >=20 > Thanks! >=20 > Ben. From nobody Tue Jun 23 06:03:34 2015 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B038D1A0387; Tue, 23 Jun 2015 06:03:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7z_e2s2aU1Bf; Tue, 23 Jun 2015 06:03:24 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E5A981A0383; Tue, 23 Jun 2015 06:03:24 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.0.3.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150623130324.19703.72133.idtracker@ietfa.amsl.com> Date: Tue, 23 Jun 2015 06:03:24 -0700 Archived-At: Cc: avtext@ietf.org Subject: [avtext] I-D Action: draft-ietf-avtext-rtp-grouping-taxonomy-07.txt X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.15 List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jun 2015 13:03:30 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Extensions Working Group of the IETF. Title : A Taxonomy of Semantics and Mechanisms for Real-Time Transport Protocol (RTP) Sources Authors : Jonathan Lennox Kevin Gross Suhas Nandakumar Gonzalo Salgueiro Bo Burman Filename : draft-ietf-avtext-rtp-grouping-taxonomy-07.txt Pages : 47 Date : 2015-06-23 Abstract: The terminology about, and associations among, Real-Time Transport Protocol (RTP) sources can be complex and somewhat opaque. This document describes a number of existing and proposed properties and relationships among RTP sources, and defines common terminology for discussing protocol entities and their relationships. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-avtext-rtp-grouping-taxonomy/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-avtext-rtp-grouping-taxonomy-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-avtext-rtp-grouping-taxonomy-07 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 Jun 23 06:10:51 2015 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54A4F1A1A8A for ; Tue, 23 Jun 2015 06:10:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u26Hi4a3yd-B for ; Tue, 23 Jun 2015 06:10:47 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D5A351A1A7D for ; Tue, 23 Jun 2015 06:10:45 -0700 (PDT) X-AuditID: c1b4fb2d-f794d6d000004501-a2-55895ad37f22 Received: from ESESSHC019.ericsson.se (Unknown_Domain [153.88.253.125]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 9F.F8.17665.3DA59855; Tue, 23 Jun 2015 15:10:44 +0200 (CEST) Received: from ESESSMB105.ericsson.se ([169.254.5.230]) by ESESSHC019.ericsson.se ([153.88.183.75]) with mapi id 14.03.0210.002; Tue, 23 Jun 2015 15:10:43 +0200 From: Bo Burman To: "avtext@ietf.org" Thread-Topic: I-D Action: draft-ietf-avtext-rtp-grouping-taxonomy-07.txt Thread-Index: AQHQrbUKaH8VIOJSakuiz6VASOgm/526Duxw Date: Tue, 23 Jun 2015 13:10:41 +0000 Message-ID: References: <20150623130324.19703.72133.idtracker@ietfa.amsl.com> In-Reply-To: <20150623130324.19703.72133.idtracker@ietfa.amsl.com> Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.18] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrBLMWRmVeSWpSXmKPExsUyM+Jvre6VqM5Qg7PrGS0+3rvB6sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujOtrG9kL7slV3F5ymLGBsVOii5GTQ0LARGLJgkfMELaYxIV7 69m6GLk4hASOMkr8n7ydCcJZwigx+dhudpAqNgENifk77jKC2CIC6hJ3pl9gA7GFBdwlnmw+ xwYR95DYcHoVO4RtJPG0owMsziKgKrFs5WsWEJtXwFdi1to7TCC2kICjxJVNR8Gu4BRwkjjT exjMZhSQlbj//R5YPbOAuMStJ/OZIC4VkFiy5zzU1aISLx//Y4WwFSU+vtrHCFGvI7Fg9yc2 CFtbYtnC18wQewUlTs58wjKBUXQWkrGzkLTMQtIyC0nLAkaWVYyixanFxbnpRsZ6qUWZycXF +Xl6eaklmxiBUXFwy2/dHYyrXzseYhTgYFTi4V2wtyNUiDWxrLgy9xCjNAeLkjjvjM15oUIC 6YklqdmpqQWpRfFFpTmpxYcYmTg4pRoYZ5q8WWGmE3qwyYx/zZE7Tze+Trrkb+VbxBChs7W/ dJP7bDOWrVatO1dutdybKGO2iMuSVzSt+NYlJ/0Nhxf/t9m0fR+/3EpjN4e04z2x3iuP5z9U CDl7IDN33bkr/9UO3U06HfxOV5Rlovr5TRZ86lreCl+enTS2++K3mf33lqar76V05Y1rlFiK MxINtZiLihMBYEQLs2sCAAA= Archived-At: Subject: Re: [avtext] I-D Action: draft-ietf-avtext-rtp-grouping-taxonomy-07.txt X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jun 2015 13:10:49 -0000 This version should address all received AD review and GenArt review commen= ts. I've created a few additional sections to handle the GenArt review comment = about not mentioning anything about security and SRTP. I've named the forwa= rd transformation "RTP-based Security", even though "RTP-based Encryption" = was discussed and more or less agreed here on the list. While editing I fou= nd having "Encryption" in the name to be misleading, since I think the conc= ept must cover both confidentiality (encryption), authentication and integr= ity protection. I think "security" is then a more general and better word. = I then chose "RTP-based Validation" as reverse transform, which was the bes= t I could come up with that was still reasonably short. List of changes from -06 version (also in the document), for your convenien= ce: o Added RTP-based Security and RTP-based Validation transform sections, as well as Secured RTP Stream and Received Secured RTP Stream sections. o Improved wording in Abstract and Introduction sections. o Clarified what is considered "media" in section 2.1.2 Media Capture. o Changed a number of "Characteristics" lists to more suitable prose text. o Re-worded text around use of Encoded and Dependent RTP Streams in section 2.1.9 Media Packetizer. o Clarified description of Source RTP Stream in section 2.1.10. o Clarified motivation to use separate Media Transports for Simulcast in section 3.6. o Added local descriptions of terms imported from CLUE framework. o Editorial improvements. Cheers, Bo > -----Original Message----- > From: I-D-Announce [mailto:i-d-announce-bounces@ietf.org] On Behalf Of in= ternet-drafts@ietf.org > Sent: den 23 juni 2015 15:03 > To: i-d-announce@ietf.org > Cc: avtext@ietf.org > Subject: I-D Action: draft-ietf-avtext-rtp-grouping-taxonomy-07.txt >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the Audio/Video Transport Extensions Workin= g Group of the IETF. >=20 > Title : A Taxonomy of Semantics and Mechanisms for Real= -Time Transport Protocol (RTP) Sources > Authors : Jonathan Lennox > Kevin Gross > Suhas Nandakumar > Gonzalo Salgueiro > Bo Burman > Filename : draft-ietf-avtext-rtp-grouping-taxonomy-07.txt > Pages : 47 > Date : 2015-06-23 >=20 > Abstract: > The terminology about, and associations among, Real-Time Transport > Protocol (RTP) sources can be complex and somewhat opaque. This > document describes a number of existing and proposed properties and > relationships among RTP sources, and defines common terminology for > discussing protocol entities and their relationships. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-avtext-rtp-grouping-taxonomy/ >=20 > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-avtext-rtp-grouping-taxonomy-07 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-avtext-rtp-grouping-taxono= my-07 >=20 >=20 > Please note that it may take a couple of minutes from the time of submiss= ion until the htmlized version and diff are > available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.= ietf.org/ietf/1shadow-sites.txt From nobody Tue Jun 23 07:24:14 2015 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B2091A9039; Tue, 23 Jun 2015 07:24:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KwoVI1GPecHU; Tue, 23 Jun 2015 07:24:08 -0700 (PDT) Received: from BLU004-OMC2S34.hotmail.com (blu004-omc2s34.hotmail.com [65.55.111.109]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E270E1A8F42; Tue, 23 Jun 2015 07:24:07 -0700 (PDT) Received: from BLU406-EAS242 ([65.55.111.71]) by BLU004-OMC2S34.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.22751); Tue, 23 Jun 2015 07:24:07 -0700 X-TMN: [ueVE78GCdqtlbi5TH65Ixv7mgwIzlztB] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable From: Bernard Aboba MIME-Version: 1.0 (1.0) Date: Tue, 23 Jun 2015 07:24:05 -0700 References: <257ACC1A-936C-4C32-81E2-E2A88512B20A@nostrum.com> <14F5435A-E14C-48E3-BAC2-5BF2CB7D6F33@nostrum.com> <3A48DE66-626B-4CED-9F1A-E7E90557768F@nostrum.com> <949EF20990823C4C85C18D59AA11AD8B6973118C@FR712WXCHMBA11.zeu.alcatel-lucent.com> To: "DRAGE, Keith (Keith)" In-Reply-To: <949EF20990823C4C85C18D59AA11AD8B6973118C@FR712WXCHMBA11.zeu.alcatel-lucent.com> X-OriginalArrivalTime: 23 Jun 2015 14:24:07.0297 (UTC) FILETIME=[4395EF10:01D0ADC0] Archived-At: Cc: "avtext@ietf.org" , "draft-ietf-avtext-rtp-stream-pause.all@ietf.org" Subject: Re: [avtext] AD Evaluation of draft-ietf-avtext-rtp-stream-pause-07 X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jun 2015 14:24:11 -0000 Agree with Keith here. As far as I know, there are no WebRTC implementations= that support pause/resume, nor are any in progress, nor is the document ref= erenced in any IETF RTCWEB or W3C specification. About the only link that I c= an find is a reference to TMMBR/TMMBN in the RTP usage document. > On Jun 22, 2015, at 4:42 PM, DRAGE, Keith (Keith) wrote: >=20 > I'd note there are drafts all over IETF that could potentially be used in R= TCWEB implementations, even though they are not directly referenced. We coul= d start with all PAYLOAD deliverables, all XRBLOCK deliverables, all CLUE de= liverables .... >=20 > Your initial comment is effectively asking for RTCWEB to be included in th= e WGLC of all those documents. >=20 > Regards >=20 > Keith >=20 >=20 >> -----Original Message----- >> From: Ben Campbell [mailto:ben@nostrum.com]=20 >> Sent: 22 June 2015 21:45 >> To: Bo Burman >> Cc: draft-ietf-avtext-rtp-stream-pause.all@ietf.org; avtext@ietf.org >> Subject: Re: [avtext] AD Evaluation of=20 >> draft-ietf-avtext-rtp-stream-pause-07 >>=20 >>> On 22 Jun 2015, at 11:42, Bo Burman wrote: >>>=20 >>> Ben, all, >>>=20 >>> Please see inline. >>>=20 >>> Cheers, >>> Bo >>>=20 >>>> -----Original Message----- >>>> From: Ben Campbell [mailto:ben@nostrum.com] >>>> Sent: den 18 juni 2015 22:57 >>>> To: draft-ietf-avtext-rtp-stream-pause.all@ietf.org;=20 >> avtext@ietf.org >>>> Subject: Re: [avtext] AD Evaluation of >>>> draft-ietf-avtext-rtp-stream-pause-07 >>>>=20 >>>> Hi, >>>>=20 >>>> I have a few comments on further reflection: >>>>=20 >>>> I notice that there are IPR declarations against the=20 >> original version=20 >>>> (prior to wg acceptance.) The license terms allow the=20 >> possibility of=20 >>>> royalties. I also see that the shepherd writeup mentions=20 >> that avtext=20 >>>> discussed these and are okay with them. However, this draft=20 >>>> references some RTCWEB requirements as partial motivation.=20 >> Have the=20 >>>> IPR disclosures been discussed with RTCWEB, to confirm that they=20 >>>> would be willing to use a mechanism with those disclosures? >>> [BoB] Use of this draft in RTCWEB context has been=20 >> discussed, e.g. in=20 >>> this thread=20 >>>=20 >> https://mailarchive.ietf.org/arch/msg/rtcweb/d95AfR5YthE7O4he4yaTCOj8h >>> 1o, clarifying that use in RTCWEB would mainly target the RFC=20 >>> 5104-based TMMBR/TMMBN 0 mode, and one of the conclusions of the=20 >>> discussion was to keep the functionality out of v1.0. The draft is=20 >>> currently not referenced from any RTCWEB v1.0 specification. One of=20 >>> the alternatives mentioned in the thread above was to use an=20 >>> application-specific message in a DataChannel, but I cannot=20 >> find that=20 >>> there was ever any consensus on what to do in v1.0, or if=20 >> it should be=20 >>> specified at all. >>=20 >> If this draft is not referenced by RTCWEB, is the mention of=20 >> RTCWEB use cases still relevant? (Unless I am reading it=20 >> wrong, the quoted use cases really only support the "paused"=20 >> semantic.) >>=20 >>>=20 >>>>=20 >>>> On my comments about the "config" parameter: >>>>=20 >>>> The root of my concern is not the mechanism for=20 >> negotiating partial=20 >>>> support, but the number of config "profiles". It >>>> seems like this could encourage implementations that=20 >> cannot use the=20 >>>> mechanism interoperably. >>>> For example, the draft shows use cases where a conference bridge=20 >>>> might need to ask an endpoint to pause. If people >>>> build endpoints that only support 2 or 3, then this would not be=20 >>>> possible. >>> [BoB] Let me try to answer by highlighting and summarizing the=20 >>> underlying reasons for those different config "profiles". >>>=20 >>> Config=3D1 is the "full" implementation. >>>=20 >>> Config=3D2 and 4 are intended for the RTP stream receiver=20 >> that wants to=20 >>> pause/resume the remote sender's stream, but sees no use of letting=20 >>> anyone pause/resume its own sent RTP streams (if any). This may=20 >>> typically be implemented by a conference bridge. Config=3D4=20 >> differs from=20 >>> 2 only in that config=3D4 has no PAUSED support. To implement=20 >> config=3D2=20 >>> or 4 in an endpoint supposed to be connected to a conference bridge=20 >>> would obviously not work and would in my mind be a mistake or=20 >>> misunderstanding of the draft text rather than a deliberate=20 >> design. Do=20 >>> you think that a clarification is needed in this respect? >>>=20 >>> Config=3D3 and 5 are intended for the RTP stream sender that wants to=20= >>> leave pause/resume control to a remote RTP stream receiver,=20 >> but has no=20 >>> desire to control anyone else's RTP streams. This may typically be=20 >>> implemented by an endpoint participating in a group call through a=20 >>> conference bridge. 5 differs from 3 only in that it has no PAUSED=20 >>> support. Similar to above, implementing config=3D3 or 5 in a=20 >> conference=20 >>> bridge could be a misunderstanding or mistake. Do you=20 >> clarification is=20 >>> needed? >>=20 >> (In reference to the last sentence of each paragraph): In general, I=20 >> think this is an issue of balancing interoperability against=20 >> the ability=20 >> of implemntors that don't (think they) need to support all=20 >> use cases to=20 >> implement profiles. That's been a general issue for the IETF=20 >> more than=20 >> once, and I'm not sure we've ever gotten it right. A few paragraphs=20 >> about the interoperability considerations among the various=20 >> modes would=20 >> be helpful. >>>=20 >>> Config=3D6-8 all deal only with PAUSED (sendrecv/recvonly/sendonly=20 >>> capability, respectively). If I remember correctly, it was=20 >> brought up=20 >>> during an IETF meeting (forgot which and by whom) that it=20 >> could be a=20 >>> useful functionality in itself to indicate local pause. I=20 >> then assumed=20 >>> that the it was not desirable to require the rest of pause/resume=20 >>> functionality to be able to use that, which is why config=3D6-8 are=20 >>> there in the draft. Implementations of config=3D6-8 are obviously not=20= >>> able to get any pause/resume functionality, but assumedly=20 >> also don't=20 >>> wish to, and are in any case "interoperable" with other config=20 >>> supporting PAUSED. >>=20 >> I'm skeptical about adding modes because they "might be useful", vs=20 >> demonstrably needed. To some degree, the "might be useful" argument=20 >> supports Paul's suggestion of indicating support on a=20 >> per-method basis.=20 >> But it's a bit late in the process to push on that (the "might be=20 >> useful) part, so I will not do so further. >>=20 >>>=20 >>> Regarding config=3D4 and 5, not supporting PAUSED is not=20 >> detrimental to=20 >>> pause/resume functionality and is in that sense "backwards=20 >>> compatible", but having explicit indication of PAUSED=20 >> support allows=20 >>> to avoid some heuristics and delays in pause/resume implementation=20 >>> control logic, in addition to saving the bandwidth for sending=20 >>> unnecessary PAUSED. >>>=20 >>> As a side comment, use of pause/resume in a conference bridge=20 >>> cascading scenario would likely require config=3D1 between the=20 >>> conference bridges to provide sufficient functionality. >>=20 >> That would be worth a mention in the aforementioned interop=20 >> considerations. >>=20 >>>=20 >>>>=20 >>>> So my real question is, does the mechanism really need all=20 >> 8 modes?=20 >>>> Are there known situations where an implementer >>>> would choose not to implement this mechanism if one of the modes=20 >>>> didn't exist? Some of them seem to have fairly >>>> subtle differences (e.g. whether the device may locally pause or=20 >>>> not.) >>> [BoB] I'd rather say that if there were no configurations at all,=20 >>> there's a risk that implementations may anyway choose to=20 >> implement a=20 >>> subset of the full functionality because it sees no use for=20 >> the rest=20 >>> (correctly or not), like a conference bridge that sees no point in=20 >>> pausing its sent RTP streams. Is it not better from an=20 >>> interoperability perspective to specify how this subset restriction=20 >>> must be made to achieve a certain desirable functionality,=20 >> instead of=20 >>> leaving it to individual implementations to decide what=20 >> parts of the=20 >>> specification can and what cannot be omitted (admittedly in=20 >> violation=20 >>> of the specification), to still have a reasonably working and=20 >>> interoperable implementation? >>=20 >> Have potential implementors indicated they would do that? >>=20 >>>=20 >>> Are there too many configurations? I don't see how this can be=20 >>> determined with any certainty until there is a significant=20 >> number of=20 >>> implementations in several different contexts. The number=20 >> of config's=20 >>> _can_ certainly be reduced if you change the preconditions.=20 >> If you for=20 >>> example were to require that all implementations must=20 >> support PAUSED,=20 >>> _and_ that no implementations are allowed to _only_ support PAUSED,=20 >>> the number of configurations that are supported by any reasonable=20 >>> remaining use case would immediately drop to three (configurations=20 >>> 1-3). >>=20 >> I guess I was thinking more in terms of whether all the modes are=20 >> actually needed by use cases that people have thought about. But this=20 >> also falls into the case of being too late in the process to=20 >> push on it. >>=20 >> [...] >>=20 >> Thanks! >>=20 >> Ben. >>=20 > _______________________________________________ > avtext mailing list > avtext@ietf.org > https://www.ietf.org/mailman/listinfo/avtext From nobody Tue Jun 30 07:58:43 2015 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3C951AC3C7 for ; Tue, 30 Jun 2015 07:58:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.797 X-Spam-Level: X-Spam-Status: No, score=-0.797 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_WEB=0.77, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zi4Tj8WTAjNL for ; Tue, 30 Jun 2015 07:58:40 -0700 (PDT) Received: from mx0b-00198e01.pphosted.com (mx0b-00198e01.pphosted.com [67.231.157.197]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8AB121AC3C1 for ; Tue, 30 Jun 2015 07:58:40 -0700 (PDT) Received: from pps.filterd (m0073110.ppops.net [127.0.0.1]) by mx0b-00198e01.pphosted.com (8.15.0.59/8.14.7) with SMTP id t5UEwdiT020146 for ; Tue, 30 Jun 2015 10:58:39 -0400 Received: from mail.vidyo.com ([162.209.16.214]) by mx0b-00198e01.pphosted.com with ESMTP id 1vbhnk08gj-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Tue, 30 Jun 2015 10:58:39 -0400 Received: from 492132-EXCH1.vidyo.com ([fe80::50:56ff:fe85:4f77]) by 492133-EXCH2.vidyo.com ([fe80::50:56ff:fe85:6b62%13]) with mapi id 14.03.0195.001; Tue, 30 Jun 2015 09:58:39 -0500 From: Jonathan Lennox To: "avtext@ietf.org" Thread-Topic: Call for agenda requests for IETF 93 Thread-Index: AQHQs0U+5rkwWqwlukGzBeRmE1gYvA== Date: Tue, 30 Jun 2015 14:58:38 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [160.79.219.114] Content-Type: text/plain; charset="us-ascii" Content-ID: <42A74AA90F68C948B9AE4139DE73C330@vidyo.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.14.151, 1.0.33, 0.0.0000 definitions=2015-06-30_07:2015-06-29,2015-06-30,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1506180000 definitions=main-1506300229 Archived-At: Subject: [avtext] Call for agenda requests for IETF 93 X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2015 14:58:41 -0000 The AVTEXT working group is currently scheduled to meet at IETF 93 as follo= ws. Note that the agenda is subject to change. THURSDAY, July 23, 2015 1740-1910 Afternoon Session III Berlin/Brussels ART avtext Audio/Video Transport Extensions WG Please send the chairs your request for agenda items.=