From nobody Thu Aug 13 09:27:25 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 C1E601A010D for ; Thu, 13 Aug 2015 09:27:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.402 X-Spam-Level: X-Spam-Status: No, score=0.402 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_WEB=0.77, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V0EDQ_nlOBvH for ; Thu, 13 Aug 2015 09:27:22 -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 4740E1A00F4 for ; Thu, 13 Aug 2015 09:27:22 -0700 (PDT) Received: from pps.filterd (m0073109.ppops.net [127.0.0.1]) by mx0a-00198e01.pphosted.com (8.15.0.59/8.14.7) with SMTP id t7DGRMIo015640 for ; Thu, 13 Aug 2015 12:27:22 -0400 Received: from mail.vidyo.com ([162.209.16.214]) by mx0a-00198e01.pphosted.com with ESMTP id 1w1e1wnp9c-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Thu, 13 Aug 2015 12:27:21 -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; Thu, 13 Aug 2015 11:27:20 -0500 From: Jonathan Lennox To: "avtext@ietf.org" Thread-Topic: AVTEXT Minutes for IETF 93 Thread-Index: AQHQ1eTt06i2FYjgE02WeqZuJO90tw== Date: Thu, 13 Aug 2015 16:27:20 +0000 Message-ID: <71FDF98A-ECAE-4580-A1FA-27953CF5CF42@vidyo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [160.79.219.114] Content-Type: text/plain; charset="utf-8" Content-ID: <0E9D30238FBED54C9B1A382AF86A2D6E@vidyo.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.14.151, 1.0.33, 0.0.0000 definitions=2015-08-13_07:2015-08-13,2015-08-13,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-1508130248 Archived-At: Subject: [avtext] AVTEXT Minutes 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: Thu, 13 Aug 2015 16:27:24 -0000 SGVyZSBhcmUgdGhlIG1pbnV0ZXMgZm9yIEFWVEVYVCA5MyBpbiBQcmFndWUuICBQbGVhc2Ugc2Vu ZCB0aGUgY2hhaXJzIGFueSBjb3JyZWN0aW9ucyBvciBhZGRpdGlvbnMuDQoNCkFWVEVYVCBBdWRp by9WaWRlbyBUcmFuc3BvcnQgRXh0ZW5zaW9ucw0KDQpUaHVyc2RheSwgMjQgSnVseSwgMjAxNSAx Nzo0MCAtIDE5OjEwIENFU1QgKFJvb206IEJlcmxpbi9CcnVzc2VscykNCg0KQ2hhaXJzOiBKb25h dGhhbiBMZW5ub3ggYW5kIE1hZ251cyBXZXN0ZXJsdW5kIChmaWxsaW5nIGluIGZvciBLZWl0aCBE cmFnZSkNClJlc3BvbnNpYmxlIEFyZWEgRGlyZWN0b3I6IEJlbiBDYW1wYmVsbA0KTm90ZXRha2Vy czogRW1pbCBJdm92LCBWYXJ1biBTaW5naA0KDQpBZ2VuZGEgYmFzaCBhbmQgc3RhdHVzIHVwZGF0 ZQ0KPT09PT0NCg0KV0cgc3RhdHVzOg0KICAgIGdyb3VwaW5nIHRheG9ub215IGFwcHJvdmVkDQog ICAgc3RyZWFtIHBhdXNlIHJlcXVpcmVzIGEgZmV3IGNoYW5nZXMgYWZ0ZXIgQUQgcmV2aWV3DQog ICAgc3BsaWNpbmcgbm90aWZpY2F0aW9uOiByZWFkeSBmb3IgcHViIHJlcSwgd2lsbCBwcm9jZWVk IG9uY2UgcGF1c2UgaXMgYWR2YW5jZWQNCg0KQWN0aW9uIEl0ZW06IEJlbiB0byBjb25maXJtIHRo YXQgQm8gcmVzcG9uZGVkIHRvIGFsbCBoaXMgQUQgcmV2aWV3DQppdGVtcyBmb3Igc3RyZWFtIHBh dXNlLCBzZW5kIHRvIElFVEYgbGFzdCBjYWxsDQoNCg0KPT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09DQpSVFAgSGVhZGVyIEV4dGVuc2lvbiBmb3Igc291cmNlIGRlc2Ny aXB0aW9uDQpNYWdudXMgV2VzdGVybHVuZCwgcHJlc2VudGluZw0KPT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09DQoNClN0YXR1czogUmVhZHkgZm9yIFdHTEMNCg0KQWN0 aW9uIEl0ZW1zOg0KU2ltb24gUGVycmF1bHQgd2lsbCByZXZpZXcgZHJhZnQNCk1hZ251cyBhbmQv b3IgUm9uaSB3aWxsIHN1Ym1pdCA1Mjg1YmlzIHRvIEFWVENPUkUNCg0KRGlzY3Vzc2lvbjoNCg0K SXNzdWU6IHN3aXRjaGluZyBiZXR3ZWVuIG9uZSBhbmQgdHdvIGJ5dGUgaGVhZGVyIGV4dGVuc2lv biBmb3JtYXQgaXMgbm90IGNsZWFyIGluIFJGQyA1Mjg1DQpNbyBaYW5hdHk6IHRoZSBpc3N1ZSBp cyBldmVuIHdvcnNlIGJlY2F1c2UgdHdvLWJ5dGUgaGVhZGVyIHN1cHBvcnQgaXMgbm90IG5vdCBt YW5kYXRvcnkNCk1hZ251czogd2Ugc3VnZ2VzdCB3ZSBjbGFyaWZ5IDUyODUNClJvbmkgRXZlbjog KzENCkNvbGluIFBlcmtpbnM6ICsxDQpTdGVwaGFuIFdlbmdlcjogRGVwcmVjYXRlIHRoZSBvbmUt Ynl0ZSBoZWFkZXJzPyBJcyB0aGVyZSBtdWNoIGRlcGxveW1lbnQgb2YgaXQ/DQpNYW55IHBlb3Bs ZTogeWVzLg0KSm9uYXRoYW46IE1vc3QgY3VycmVudCBkZXBsb3ltZW50IGlzIG9uZS1ieXRlLCBu b3QgY2xlYXIgdGhlcmUgaXMgZGVwbG95bWVudCBvZiB0d28tYnl0ZQ0KTW86IFN1Z2dlc3QgdG8g bWFuZGF0ZSBzdXBwb3J0IGZvciBib3RoIGV4dGVuc2lvbnMgYW5kIHRoZW4gcmVxdWlyZSB0aGF0 IHR3byBieXRlIGhlYWRlciBleHRlbnNpb25zIHVzZQ0KSURzIGJpZ2dlciB0aGFuIDE1IHNvIHRo YXQgdGhleSBjYW4gYmUgbmVnb3RpYXRlZC4NCk1hZ251cyBvciBSb25pIHdpbGwgc3VibWl0IDUy ODViaXMgdG8gQVZUQ09SRQ0KDQpKb25hdGhhbjogV2hvIHJlYWQgdGhpcz8NCjUvNiBoYW5kcw0K Sm9uYXRoYW46IFdobyB3aWxsIHJldmlldz8NClNpbW9uIFBlcnJlYXVsdA0KDQpKb25hdGhhbjog bWFueSB0aGluZ3Mgd291bGQgbGlrZWx5IHdhbnQgdG8gdXNlIHRoaXMuDQpSb25pOiB0aGVyZeKA mXMgYWxzbyBhIGRlcGVuZGVuY3kgaW4gY2x1ZQ0KQ29saW46IFdlIHNob3VsZCBjaGVjayBpZiBz b21ldGhpbmcgaW4gYnVuZGxlIHdvdWxkIGFsc28gbmVlZCB0byBiZSBmaXhlZCB0byBhZGRyZXNz IHRoZSBpc3N1ZXMgTWFnbnVzIHBvaW50ZWQgb3V0DQoNCkpvbmF0aGFuOiBPSywgd2UgYXJlIHJl YWR5IGZvciBsYXN0IGNhbGwhDQoNCg0KPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09DQpMYXllciBSZWZyZXNoIFJlcXVlc3QgKExSUikgUlRDUCBmZWVkYmFjayBtZXNz YWdlDQpKb25hdGhhbiBMZW5ub3gNCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PQ0KDQpBY3Rpb24gSXRlbXM6DQpCZXJuYXJkIEFib2JhIGFuZCBNbyBaYW5hdHkgdG8g cmV2aWV3IEguMjY0LVNWQyBsYXllciByZWZyZXNoIHRleHQuDQpTdGVwaGFuIHRvIHdvcmsgd2l0 aCBKQ1QgaWYgYSBuZXcgU0VJIG1lc3NhZ2UgaXMgbmVlZGVkIHdpdGggSC4yNjUgZm9yIHRlbXBv cmFsIGxheWVyIHJlZnJlc2guDQpKb25hdGhhbiB3aWxsIHdvcmsgd2l0aCBjby1hdXRob3JzIGZv ciBWUDggdGV4dC4NCg0KSm9uYXRoYW4gdG8gc2VuZCB0ZXh0IHRvIHRoZSBsaXN0IGFib3V0IHdo YXQgRklSIG1lYW5zIGZvciBNUlNUL01STVQuDQoNCkRpc2N1c3Npb246DQoNCkpvbmF0aGFuOiB0 aGlzIGlzIG5vdyBhIFdHIGRvY3VtZW50DQpEZWx0YXM6IG5vdCBtYW55LiBtYWluIG9uZTogcmVj b2duaXppbmcgbGF5ZXIgcmVmcmVzaCBwb2ludA0KSC4yNjQvU1ZDIGlzIGNvbXBsZXRlDQpBQ1RJ T046IEJlcm5hcmQgQS4gYW5kIE1vIFouIGFyZSB2b2x1bnRlZXJpbmcgZm9yIHJldmlld3Mgb2Yg dGhpcyBwYXJ0DQpILjI2NQ0KU3RlcGhlbiBXZW5nZXI6IGlzIGFueW9uZSBpbnRlcmVzdGVkIGF0 IGFsbCBpbiBub24tc2NhbGFibGUgbmVzdGVkIGNvZGluZyBzdHJ1Y3R1cmVzPw0KSm9uYXRoYW46 IHllcyBmb3IgVlA4IGFuZCBWUDkuDQpTdGVwaGVuOiBnaXZlbiBjdXJyZW50IHBhY2VzIG9mIFNE T3MsIHRoYXTigJlzIGxpa2VseSBnb2luZyB0byBleGlzdCBpbiBILjI2NSBhcyB3ZWxsIHNvIEkg dm9sdW50ZWVyIGRvaW5nIHRoYXQuDQpBQ1RJT04gSVRFTTogU3RlcGhhbiB3aWxsIHRha2Ugb2Yg dGhpcyBmb3IgSkNUDQpBQ1RJT04gSVRFTTogSm9uYXRoYW4gd2lsbCBudWRnZSBjb2xsZWFndWVz IHRvIGRvIHJldmlld3MgZm9yIFZQOA0KQUNUSU9OIElURU06IHJldmlldyB0aGUgZGVzY3JpcHRp b24gb2YgaG93IHlvdSByZWNvZ25pemUgbGF5ZXIgcmVmcmVzaD8NCg0KTW86IG5vdCBjbGVhciB0 aGUgVlA4IFkgYml0IGlzIHN1ZmZpY2llbnQgdG8gcmVjb2duaXplIGFsbCB0ZW1wb3JhbCBzeW5j IHBvaW50cy4NCkpvbmF0aGFuOiBmYWxzZSBuZWdhdGl2ZXMgYXJlbid0IHRoZSBlbmQgb2YgdGhl IHdvcmxkLCBmYWxzZSBwb3NpdGl2ZXMgYXJlIGJhZC4NCg0KTmV4dCBzbGlkZTogVGVtcG9yYWwg c3dpdGNoIHBvaW50cyBhcmUgY29tcGxpY2F0ZWQhDQpKdXN0aW4gZ2V0cyB1cCB0byBleHBsYWlu IOKApiBzYXlzIGhl4oCZcyBjb25mdXNlZA0KTW8gZXhwbGFpbnM6IHRoZXNlIGFyZSBqdXN0IHRo cmVlIGxheWVycyBvZiByZWZlcmVuY2UgZnJhbWVzDQoNCk9wZW4gaXNzdWU6IHdoYXQgZG9lcyBG SVIgbWVhbiBmb3Igc3BhdGlhbCBNdWx0aSBzdHJlYW0gc2NhbGFiaWxpdHkNClFVRVNUSU9OIHRv IFdHOg0KUmVmcmVzaCBsYXllciBvciByZWZyZXNoIHRoZSB3aG9sZSBzb3VyY2U/IE9ubHkgcmVs ZXZhbnQgZm9yIEguMjY0LVNWQy4gUXVlc3Rpb246IGRvIHdlIHdhbnQgdG8gZGVmaW5lIHRoaXM/ IERvIHdlIHdhbnQgdG8gZG8gdGhpcyBoZXJlPw0KDQpTdGVwaGFuIFdlbmdlcjogd2FzbuKAmXQg dGhlcmUgc29tZSBraW5kIG9mIGNvbnNlbnN1cyBzb21ld2hlcmUgKHBheWxvYWQpIHRoYXQgbmV3 IHBheWxvYWQgZm9ybWF0cyBzaG91bGQgaGF2ZSBzb21lIGZvcm0gb2YgRklSIG1hcHBpbmcuDQpK b25hdGhhbjogc2hha2VzIGhlYWQNClN0ZXBoYW46IGFuIGlzc3VlIGZvciBTSFZDIHBheWxvYWQg Zm9ybWF0LiANClN0ZXBoYW46IEkgd2lsbCB0YWxrIHRvIFllLUt1aS4NCkpvbmF0aGFuOiBUd28g aXNzdWVzOiB3aGF0IHNob3VsZCB0aGUgc2VtYW50aWMgYmUsIGFuZCBob3cgaXMgaXQgaW5zdGFu dGlhdGVkIGZvciBhbnkgZ2l2ZW4gY29kZWMuDQpNeSByZWNvbW1lbmRhdGlvbjogRklSIG1lYW5z IHJlZnJlc2ggYWxsIGxheWVycyBhbmQgd2UgbmVlZCB0byBkZWZpbmUgc29tZXRoaW5nIGVsc2Ug Zm9yIHBlciBsYXllci4NCk1vOiBJIHNvcnQgb2YgdGhvdWdodCB0aGF04oCZcyB3aGF0IGl0IG1l YW50IGFscmVhZHkuIEFmdGVyIGFsbCBpdOKAmXMgYSBGVUxMIGludHJhIHJlZnJlc2gNCkJlcm5h cmQ6IEZvciBJTVRDIHN0cnVjdHVyZXMgaXQgZG9lc24ndCBtYWtlIGEgZGlmZmVyZW5jZS4NCg0K Sm9uYXRoYW46IElmIG5vIG9uZSBpcyBjdXJyZW50bHkgZG9pbmcgYW55dGhpbmcgd2hlcmUgaXQg bWFrZXMgYSBkaWZmZXJlbmNlLCBub3QgYW4gaXNzdWUuDQoNCkNPTlNFTlNVUzogRklSIGlzIGEg ZnVsbCByZWZyZXNoLg0KDQpKb25hdGhhbiBRdWVzdGlvbjogd2hlcmUgZG8gd2Ugc2F5IHRoYXQ/ DQpNbzogbGV04oCZcyBqdXN0IGhhdmUgdGhpcyBkb2MgdXBkYXRlIDYxOTANCkpvbmF0aGFuOiBw cm9iYWJseSB1cGRhdGUgQ0NNLCBub3QgNjE5MC4NCg0KU29tZSBtb3JlIGRpc2N1c3Npb25zIHNo b3dpbmcgdGhlcmXigJlzIGFjdHVhbGx5IG5vIGNvbnNlbnN1cy4NCg0KSnVzdGluOiBEb2VzIHRo aXMgbWVhbiB0aGF0IEZJUiBoYXMgZGlmZmVyZW50IGJlaGF2aW9yIGZvciBNUlNUIHRoYW4gZm9y IHNpbXVsY2FzdD8NCkpvbmF0aGFuOiBZZXMuDQpKdXN0aW46IEkgdGhpbmsgdGhhdCdzIGNvbmZ1 c2luZyBhbmQgYXdrd2FyZC4NCk1vOiBNYXliZSBoYXZlIEZJUiByZWZyZXNoIGFsbCBzaW11bGNh c3Qgc3RyZWFtcz8NCltVbmhhcHBpbmVzc10NClN0ZXBoYW46IE11bHRpcGxlIHByZWRpY3Rpb24g Y29kaW5nIGNvbWluZy4NCkpvbmF0aGFuOiBNeSBpbmNsaW5hdGlvbiBpcyB0byBzYXkgdGhhdCBN UlNUIGFuZCBzaW11bGNhc3QgYXJlIGRpZmZlcmVudCwgZGVzcGl0ZSB0aGUgYXN5bW1ldHJ5Lg0K U3RlcGhhbjogUG9zc2libHkgcmVjb21tZW5kIHRoYXQgRklSIGJlIHNlbnQgZm9yIGFsbCBsYXll cnMgc2ltdWx0YW5lb3VzbHkuDQpKdXN0aW46IENhbiB3ZSBqdXN0IHNheSB0aGF0IExJUiBpcyBw ZXItbGF5ZXIgYW5kIEZJUiBpcyBwZXItU1NSQz8NCkpvbmF0aGFuOiBGb3IgTVJTVC9NUk1UIHRo b3NlIGFyZSB0aGUgc2FtZSB0aGluZy4gU3RlcGhhbidzIHN1Z2dlc3Rpb24gd291bGQgYmUgc3Ry YWlnaHRmb3J3YXJkIGZvcg0KTVJTVCwgYnV0IGZvciBNUk1UIHRoZSBtdWx0aXBsZSBGSVJzIHdp bGwgbm90IGJlIHRoZSBzYW1lIHBhY2tldCBzbyB0aGVyZSBtaWdodCBiZSBzeW5jIGlzc3Vlcy4N Cg0KTWFnbnVzOiB3cml0ZSBpdCB1cCBhbmQgc2VuZCB0aGlzIHRvIHRoZSBsaXN0IChBQ1RJT04g SVRFTSkNClN0ZXBoYW4gYWdyZWVkDQpKb25hdGhhbiBhZ3JlZTogd2lsbCBkbyENCg0KPT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09DQpSVENQIGZlZWRiYWNrIG1lc3Nh Z2UgZm9yIGltYWdlIGNvbnRyb2wNClJvbmkgRXZlbg0KPT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09DQoNCkFjdGlvbiBpdGVtczoNClJvbmk6IENvbnNpZGVyIHRpbWVz dGFtcCBmb3Igd2hpY2ggcGljdHVyZSByZXF1ZXN0IGlzIHJlbGF0aXZlIHRvDQpSb25pIHdpbGwg ZHJhZnQgYSBsaWFpc29uIHN0YXRlbWVudCBmb3IgM0dQUA0KDQoNCkRpc2N1c3Npb246DQoNCk1v dGl2YXRpb25zOiBhIHBpY3R1cmUgb2YgTWF0dCBEYW1vbg0KYWxzbzogZ2V0IGEgZGV0YWlsZWQg aW1hZ2UgZm9yIHBhcnQgb2YgYW4gaW1hZ2UuIGNhbWVyYSB6b29tIGFuZCBtb3ZlLiB6b29tIG9u IHBhcnRpY2lwYW50IGluIGFuIE1DVQ0KDQpQcm9wb3NhbDogaGF2ZSBhbiBSVENQIG1lc3NhZ2Ug dGhlIGRlc2NyaWJlcyB0aGUgYXJlYSB0aGV5IHdhbnQgem9vbWVkIG9yIG1vdmVkLiBSZXF1aXJl cyBjb25zZW50IG9mIHNlbmRlci4NClJlZmVyZW5jZSBpcyBiYXNlZCBvbiBjdXJyZW50IHBpY3R1 cmUvcXVhbGl0eSByYXRlDQoNClRoZXJl4oCZcyBhbHNvIGEgbm90aWZpY2F0aW9uL2FjayBtZXNz YWdlIGZyb20gdGhlIHNlbmRlcg0KDQpNbzogcXVlc3Rpb24uIHlvdSBzaG91bGRu4oCZdCBkbyB0 aGlzIHdpdGggYWJzb2x1dGVzIGJ1dCB3aXRoIHJlbGF0aXZlcyBiZWNhdXNlIHJlc29sdXRpb25z IGNoYW5nZS4NClJvbmk6IGlkZWEgaXMgdG8gaGF2ZSBwaXhlbHMgYmFzZWQgb24gdGhlIGN1cnJl bnQgdmlldy4NCk1vOiBidXQgdGhlcmXigJlzIG5vIHdheSB0byBrbm93IHdoaWNoIGZyYW1lIHRo aXMgcmVsYXRlcyB0bw0KUmFuZGVsbCBKICh0aHJvdWdoIEphYmJlcik6IHNhbWUgcXVlc3Rpb24g cG9pbnRpbmcgb3V0IHRoZSByYWNlIGNvbmRpdGlvbnMNCg0KQmVuOiBjb29yZGluYXRlcyBhcmUg dW5zaWduZWQ/DQpSb25pOiBjYW4gYmUgbmVnYXRpdmUgc28gdGhhdCB5b3UgY2FuIG1vdmUgb3V0 c2lkZSBvZiB5b3VyIHZpZXcNCg0KU3RlcGhlbjogdXNpbmcgcmVmZXJlbmNlIHRpbWVzdGFtcHMg c2hvdWxkIGZpeCBtb3N0IG9mIHRoZSByYWNlIGNvbmRpdGlvbnMNClJvbmk6IEFncmVlZCwgd2Ug d2lsbCBjb25zaWRlciB0aGlzIChBQ1RJT04gSVRFTSkNCg0KUmFuZGVsbDogb2Zmc2V0cyBjb3Vs ZCBiZSBtYWRlIGZsb2F0cyAoMC0xIG9mIHRoZSBzb3VyY2Ugd2lkdGgpIGFuZCBiZSByZWxhdGl2 ZSB0byB0aGUgYWJzb2x1dGUgc291cmNlDQoNClBldGVyIFQuIHF1ZXN0aW9uOiBJcyB0aGlzIGEg ZmVlZGJhY2sgb3IgYSBjb250cm9sIG1lc3NhZ2U/DQpSb25pOiBpdOKAmXMgYm90aA0KUGV0ZXI6 IGlzIHRoaXMgd2VpcmQ/DQpSb25pOiBubw0KUGV0ZXI6IGhvdyBkbyB5b3UgZG8gcmVsaWFiaWxp dHk/DQpSb25pOiB3ZSBoYXZlIGFuIElDTiByZXNwb25zZSBtZXNzYWdlLiBhbHNvDQpDb2xpbjog YWxzbyB0aGVyZeKAmXMgYSBzdGFuZGFyZCBjb252ZW50aW9uIGZvciBkb2luZyB0aGlzDQpSb25p OiB5ZXMsIHRoYXTigJlzIHdoYXQgd2UgYXJlIHVzaW5nIGhlcmUNCg0KUGV0ZXIgVDogaG93IGFy ZSB5b3UgcmVmZXJyaW5nIHRvIHRoZSBzdHJlYW0gdGhhdCB5b3UgbWVhbj8NClJvbmk6IGJ5IFNT UkMNClBldGVyOiB3aGF0IGlmIHRoZSBTU1JDIGNoYW5nZXM/DQpSb25pOiB0aGVuIHlvdSdyZSBy ZWNlaXZpbmcgYSBuZXcgc3RyZWFtIHNvIHlvdSBoYXZlIGEgbmV3IHZpZXcNClJvbmk6IFJlbGF0 ZWRseSwgaW4gbXVsdGlwb2ludCBCRkNQIGFsbG93cyB5b3UgdG8gc2F5IHdobyBjb250cm9scyB0 aGUgY2FtZXJhDQoNClN0ZXBoYW4gV2VuZ2VyOiBJIHRoaW5rIHRoZSBkb2N1bWVudCBpcyB1bmRl cnNwZWNpZmllZC4gWW91IG5lZWQgdG8NCnNheSB3aGV0aGVyIHlvdXIgc291cmNlIHdpbmRvdyBp cyB3aXRoIHJlc3BlY3QgdG8gZGVjb2RlZCBiaXRzIG9yIG9ubHkNCndpdGggcmVzcGVjdCB0byBi aXRzIHRoYXQgYXJlIG1lYW50IGZvciBodW1hbiBjb25zdW1wdGlvbg0KDQpCZW4gQy46IGNsYXJp ZmljYXRpb24gb24gdGhlIElBTkEgaXNzdWUgLSB0aGV5IHJlZ2lzdGVyZWQgcGFyYW1ldGVycyB3 aXRoIElBTkEsIGJ1dCB0aGV5J3JlIGhlbGQgdXANCmJlY2F1c2Ugd2UgZG9uJ3QgaGF2ZSBleHBl cnQgcmV2aWV3ZXJzLg0KUm9uaTogeWVzLCBJIHdhcyBqdXN0IHNheWluZyB0aGlzIGlzIHdoeSBJ IGRpZG4ndCBrbm93IHRoZXkgaGFkIGRvbmUgaXQuDQpCZW4gQy46IFdlIGFsc28gbmVlZCB0byB0 aGluayBhYm91dCB3aGV0aGVyIHdlIHdhbnQgdG8gY29udGludWUgd29yayB0aGF0J3MgZGl2ZXJn ZW50IGZyb20gd2hhdCB0aGV5J3ZlIGRvbmUsIHdoZXRoZXIgdGhlcmUncyBoYXJtIGRvbmUgYnkg aGF2aW5nIHR3byB3YXlzIG9mIGRvaW5nIHRoaW5ncy4NCg0KTWFnbnVzOiB3ZSBuZWVkIHRvIGZl ZWRiYWNrIG91ciBjcml0aWNpc20gdG8gdGhlIG9yaWdpbmFsIGF1dGhvcnMgYmVmb3JlIHdlIHN0 YXJ0IHRoaXMgd29yaw0KDQpCZW46IElzIHRoaXMgaW4gYSByZWxlYXNlPw0KTWFnbnVzOiBZZXMs IGJ1dCB0aGV5IGhhdmUgYSBwcm9jZXNzIGZvciBmaXhpbmcgaXQuDQoNCk1vOiBzdWdnZXN0aW9u IGFib3V0IHNlbWFudGljcyBvbiB0aGUgSUNOIG1lc3NhZ2U6IHdvdWxkIGJlIHVzZWZ1bCBpZiBz ZW5kZXIgZ2F2ZSBjdXJyZW50IHZpZXdwb3J0DQpSb25pOiBtYWtlcyBzZW5zZQ0KDQpSYW5kZWxs ICh2aWEgSmFiYmVyKTogd2UgYWxyZWFkeSBkbyBkeW5hbWljIHJlc29sdXRpb24gc2NhbGUgaW4g RmlyZWZveCwgc28gdXNpbmcgbm9uLXBpeGVsLWJhc2VkIHZhbHVlcyBpcyBhIHdpbi4gQWxzbyBt ZWFucyB5b3UgZG9uJ3QgaGF2ZSB0byBoYXZlIG1lbW9yeSBvZiBzaXplcywgYW5kIGF2b2lkcyBj b25mdXNpbmcgd2hlbiB1c2luZyBsYXllcmVkIGVuY29kaW5ncy4NCg0KSm9uYXRoYW46IEkgdGhp bmsgd2UgYXJlIGJldHRlciBvZmYgaGVscGluZyAzR1BQIGZpeCB0aGVpciBvd24gbWVzc2FnZSB0 aGFuIGRvaW5nIG91ciBvd24gY29tcGV0aXRpdmUNCm1lc3NhZ2UsIGlmIHBvc3NpYmxlLg0KQ3Vs bGVuOiArMQ0KSm9uYXRoYW46IFJhY2hlbCBhbmQgUm9uaSwgZ28gdG8gYSAzR1BQIG1lZXRpbmcg YW5kIGhlbHAgdGhlbSBmaXggdGhpcy4gQWxzbywgcGxlYXNlIGRyYWZ0IHRleHQgb2YgYQ0KbGlh aXNvbiBzdGF0ZW1lbnQuDQoNClJvbmk6IGNhbiB3ZSBhc2sgaWYgcGVvcGxlIGNhcmUgYWJvdXQg dGhpcz8NCk1hZ251czogb2ssIFdHIFFVRVNUSU9OOiBXSE8gQ0FSRVMgQUJPVVQgVEhJUyBBVCBB TEw/DQpDdWxsZW46IG1heWJlIHNvbWUgb2Ygb3VyIHZpZGVvIHN1cnZlaWxsYW5jZSBwZW9wbGUg d291bGQuDQpCbzogbWF5YmUgSSBjYXJlIHRvby4gQnV0IEkgdGhpbmsgd2Ugc2hvdWxkIHRyeSB0 byB3b3JrIGl0IG91dCBpbiAzR1BQLiAgKFBST01JU0UpDQpKb25hdGhhbjogeW91IGNvdWxkIGJl IHRoZSBwZXJzb24gd2hvIGNhdGNoZXMgdGhlIGxpYWlzb24gc3RhdGVtZW50IGluIDNHUFA/DQpC bzogTXlzZWxmIG9yIGEgY2xvc2UgY29sbGVhZ3VlLg0KDQpTdGVwaGFuIFdlbmdlcjogTGV04oCZ cyBzdG9wIHVzaW5nIHBvb3IgZGVzaWduIG9mIEguMjgxIGFzIGFuIGV4Y3VzZS4gTm8gb25lIGhh cyBnaXZlbiB2YWxpZCByZWFzb25zIGZvciByZXBsYWNpbmcgaXQuDQpKb25hdGhhbjogVGhlIDNH UFAgc3BlYyByZWNvbW1lbnRzIGJvdGggSC4yODEgYW5kIGFuIFJUQ1AgZmVlZGJhY2sgbWVzc2Fn ZSwgcHJlc3VtYWJseSBmb3IgZGlmZmVyZW50DQpjaXJjdW1zdGFuY2VzLg0KU3RlcGhlbiBCb3R6 a286IHdlIHRyaWVkIHRvIHJlcGxhY2UgdGhpcyB3aXRoIEguMjgyIGJ1dCBubyBvbmUgaW1wbGVt ZW50ZWQgaXQuIFNvIEkgYWdyZWUgd2l0aCBTdGVwaGFuLg0KDQpBQ1RJT04gSVRFTSBBTkQgQ09O U0VOU1VTOiBSb25pIHdpbGwgd3JpdGUgYSBsaWFpc29uIHRvIDNHUFAgYW5kIHdl4oCZbGwgc2Vl IHdoYXQgaGFwcGVucyB0aGVyZQ0KDQoNCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PQ0KVmlkZW8gRnJhbWUgSW5mbyAoUlRQIEhlYWRlciBFeHRlbnNpb24pDQpNbyBa YW5hdHkNCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0KDQpTdGF0 dXM6IENvbnNlbnN1cyB0byBhZG9wdCBhcyBXRyBkb2N1bWVudC4NCkFjdGlvbiBJdGVtOiBDaGFp cnMgdG8gd29yayB3aXRoIEFEcyB0byBhZGQgbWlsZXN0b25lLg0KDQpEaXNjdXNzaW9uOg0KDQpN b3RpdmF0aW9uOiB3ZSBuZWVkIHBheWxvYWQgYWdub3N0aWMgUlRQIHN3aXRjaGluZyAobGlrZSBp biBTRlVzKS4gVGhlIHJlYXNvbiBpcyB0aGF0IHBheWxvYWQgaXMgb2Z0ZW4gZW5jcnlwdGVkIGFu ZCBldmVuIGlmIG5vdCBpdCBjb3VsZCBiZSBhbiB1bmtub3duIGZvcm1hdC4NCg0KUGV0ZXIgVGhh dGNoZXI6IG9yaWdpbmFsIGlkZWEgd2FzIHRvIGJlIGNvZGVjLWFnbm9zdGljLCBidXQgdGhlcmUg aXMgY29kZWMtc3BlY2lmaWMgaW5mb3JtYXRpb24/DQpNbzogSWYgeW91IG5lZWQgc3BhdGlhbC9x dWFsaXR5IGluZm9ybWF0aW9uLCB5ZXMuICBILjI2NSdzIGNvbWJpbmVkIGxheWVySWQgZm9yY2Vz IHRoaXMuDQpQZXRlcjogV291bGQgaXQgYmUgcG9zc2libGUgdG8gaGF2ZSBzb21lIHdheSB0byBz cGVjaWZ5IHRoZSBzZW1hbnRpYyBleHBsaWNpdGx5Pw0KTW86IEknbSBub3Qgc3VyZSBob3cgdGhh dCdzIGVhc2llciB0aGFuIGRvaW5nIGl0IHBlci1wYXlsb2FkLXR5cGUuIFBlcmhhcHMgd2UgY291 bGQgd3JpdGUNCnJlY29tbWVuZGF0aW9ucyBmb3IgaG93IGZ1dHVyZSBjb2RlY3MgZG8gdGhpbmdz Lg0KDQpTdGVwaGFuIFdlbmdlcjogU29tZSBzdHVmZiBpcyBzdGlsbCBtaXNzaW5nIGluIHRoaXMg ZG9jdW1lbnQuDQpEZXNpZ24gc3VnZ2VzdGlvbjogbGV04oCZcyBqdXN0IHNheSwgeW91IGdyYWIg dGhlIGZpcnN0IE4gYml0cyBvZiB5b3VyIGNvZGVjIHBhY2tldCBhbmQgY29weSBpdCBoZXJlLg0K VGhpcyBpcyBub3QgZnV0dXJlIHByb29mIGFuZCB3ZSBjYW4gbWFrZSBpdCBmdXR1cmUgcHJvb2YN Cg0KSm9uYXRoYW46IHlvdSB3b3VsZCBjZXJ0YWlubHkgbmVlZCBUTDAgcGljIGluZGV4LiAgRm9y IHNwYXRpYWwgc2NhbGFiaWxpdHkgd291bGQgYWxzbyBuZWVkIHNvbWV0aGluZyBlcXVpdmFsZW50 IHRvIHRoZSBWUDkgc2NhbGFiaWxpdHkgc3RydWN0dXJlIC8gc2NhbGFiaWxpdHkgdXBkYXRlIHdo aWNoIHRlbGxzIHlvdSB3aGF0IGxheWVycyB5b3UgY2FuIGJlIGV4cGVjdGluZyB0byByZWNlaXZl Lg0KQWxzbyBzdWdnZXN0aW9uOiAgeW91IGNvdWxkIHJlc3RyaWN0IHRoaXMgdG8gdGVtcG9yYWwg b25seSBhcyB0aGUgYmVoYXZpb3IgaXMgbXVjaCBiZXR0ZXIgZGVmaW5lZCBhbmQgdW5kZXJzdG9v ZC4NCklmIHdlIGRvIGtlZXAgdGhlc2UgbGF5ZXIgSURzLCB3ZSBjb3VsZCBhcnJhbmdlIHRoaW5n cyBzbyB0aGV5IGFyZSB0aGUgc2FtZSBhcyBpbiB0aGUgTFJSIHNwZWMuDQoNCkJlcm5hcmQgQWJv YmE6ICsxIG9uIHRoZSBUTDAgcGljIGluZGV4Lg0KTW86IE9LLCBJ4oCZbGwgdGFrZSB0aGlzIHVw IG9uIHRoZSBsaXN0DQoNCkpvbmF0aGFuOiBob3cgbWFueSBwZW9wbGUga25vdyB3aGF0IHRoaXMg aXMgYWJvdXQ/IE1BTlkNCiAgICAgICAgICBob3cgbWFueSBwZW9wbGUgdGhpbmsgd2Ugc2hvdWxk IHdvcmsgb24gaXQ/IE1BTlkNCiAgICAgICAgICBhbnlvbmUgdGhpbmtpbmcgd2Ugc2hvdWxkbuKA mXQ/DQoNClN0ZXBoYW46IFdlIG5lZWQgdG8gdW5kZXJzdGFuZCBTZWxlY3RpdmUgRm9yd2FyZGlu ZyBVbml0IGFyY2hpdGVjdHVyZSBiZXR0ZXIgYmVmb3JlIHdlIHdvcmsgb24gaXQuDQpCZXJuYXJk OiBXZSBuZWVkIHRoaXMgdG9kYXksIGhhdmUgbXVsdGlwbGUgcHJvcHJpZXRhcnkgaW1wbGVtZW50 YXRpb25zIG9mIGl0LCBhbmQgd2UgY2FuIGxlYXJuIG1vcmUNCndvcmtpbmcgb24gaXQuDQpNbzog YmVybmFyZOKAmXMgZG9jdW1lbnQgb3V0bGluZXMgYSBwcm9ibGVtLCB0aGlzIGRvY3VtZW50IGNh biBiZSB2aWV3ZWQgYXMgYSBzb2x1dGlvbiB0byB0aGF0IHByb2JsZW0NClN0ZXBoYW46IHdlIHNo b3VsZG7igJl0IHdvcmsgb24gdGhpcyB1bnRpbCB3ZSBzdHVkeSBpdCB3ZWxsIGFuZCBrbm93IGV4 YWN0bHkgd2hhdCB3ZSB3YW50IHRvIGRvLg0KQ3VsbGVuOiBJIGFtIG9uIHRoZSBvdGhlciBlbmQu IGxldOKAmXMganVzdCBnZXQgaXQgZG9uZSB0byBhZGRyZXNzIHRvZGF54oCZcyBwcm9ibGVtcy4N CkJlcm5hcmQ6IFRoZSBwcm9wcmlldGFyeSBhcmNoZXMgb25seSBzb2x2ZSB0aGUgdGVtcG9yYWwg Y2FzZS4gVGhpcyBkcmFmdCBhZGRyZXNzZXMgdG9kYXnigJlzIHByb2JsZW1zIGFuZA0KZXZlbiBn b2VzIGEgYml0IGJleW9uZC4gU28gdGhhdOKAmXMgZ29vZCBlbm91Z2guDQoNCk1hZ251czogV2hv IHN1cHBvcnRzIHRoaXMgYXMgYSBXRyBkb2M/IDEwIFBMVVMgSEFORFMNCk1hZ251czogQWdhaW5z dD8gbm9uZQ0KDQpNYWdudXM6IHdpbGwgd29yayB3aXRoIEFEcyB0byBhZGQgbWlsZXN0b25lDQoN Cg== From nobody Tue Aug 18 20:16: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 E10DF1AC422; Tue, 18 Aug 2015 20:16:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=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 OrEOMZQ2NOBW; Tue, 18 Aug 2015 20:16:36 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E9A4A1AC41B; Tue, 18 Aug 2015 20:16:36 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Spencer Dawkins" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.4.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150819031636.31652.86423.idtracker@ietfa.amsl.com> Date: Tue, 18 Aug 2015 20:16:36 -0700 Archived-At: Cc: jonathan@vidyo.com, avtext@ietf.org, avtext-chairs@ietf.org, draft-ietf-avtext-rtp-stream-pause@ietf.org, draft-ietf-avtext-rtp-stream-pause.ad@ietf.org, draft-ietf-avtext-rtp-stream-pause.shepherd@ietf.org Subject: [avtext] Spencer Dawkins' Yes on draft-ietf-avtext-rtp-stream-pause-08: (with COMMENT) X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.15 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, 19 Aug 2015 03:16:39 -0000 Spencer Dawkins has entered the following ballot position for draft-ietf-avtext-rtp-stream-pause-08: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-avtext-rtp-stream-pause/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- This draft was really easy for me to read (with some background in RTP/RTCP, but I'm no expert on the topic). Thank you for the work on it - the results show. I have some questions, but nothing is a show-stopper. In this text: 3.3. RTP Mixer to Media Sender in Point-to-Multipoint In this use case there are several receivers of a stream and special care must be taken as not to pause a stream that is still wanted by some receivers. I'm assuming that the Mixer is taking special care, but this is passive enough that I'm filling in blanks. If you like passive voice, perhaps something like In this use case there are several receivers of a stream and special care must be taken by the Mixer so as not to pause a stream that is ^^^^^^^^^^^^^^^ still wanted by some receivers. would be easier to parse. If you can do active voice, perhaps In this use case there are several receivers of a stream and the Mixer must take special care so as not to pause a stream that is still ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ wanted by some receivers. In this text: 8. Message Details Any references to PAUSE, PAUSED, RESUME and REFUSED in this section SHALL be taken to apply to the extent possible also when TMMBR/TMMBN are used (Section 5.6) for this functionality. TMMBR/TMMBN MAY be ^^^ used instead of the messages defined in this specification when the effective topology is point-to-point. If either sender or receiver learns that the topology is not point-to-point, TMMBR/TMMBN MUST NOT be used for pause/resume functionality. If the messages defined in this specification are supported in addition to TMMBR/TMMBN by all involved parties, pause/resume signaling MUST use messages from this specification. If the topology is not point-to-point and the messages defined in this specification are not supported, pause/ resume functionality with TMMBR/TMMBN MUST NOT be used. All of this makes sense to me, except that I'm not understanding why TMMBR/TMMBN is a MAY. There's a lot of text that says you really need to use the messages from this specification in this case, and in that case, and ... but here, you MAY do something else. I understand that TMMBR/TMMBN works in a point-to-point topology, but is there a reason to prefer TMMBR/TMMBN in that topology? If so, it would probably be good to explain why. And as I read futher, I see this, in section 9: Note: When TMMBR 0 / TMMBN 0 are used to implement pause and resume functionality (with the restrictions described in this specification), signaling rtcp-fb attribute with ccm tmmbr parameter is sufficient and no further signaling is necessary. There is however no guarantee that TMMBR/TMMBN implementations ^^^^^^^^^^^^ pre-dating this specification work exactly as described here when used with a bitrate value of 0. and that really makes me wonder why this specification is also describing TMMBR/TMMBN. I'm sure there's a good reason, but can you understand my confusion? Finally, I see this, in section 9.1, If both "pause" and "tmmbr" are present in the offer, both MAY be included also in the answer, in which case TMMBR/TMMBN MUST NOT be used for pause/resume purposes (with a bitrate value of 0), to avoid signaling ambiguity. and in section 9.2, If both "pause" and "tmmbr" are present in the SDP, TMMBR/TMMBN MUST NOT be used for pause/resume purposes (with a bitrate value of 0), to avoid signaling ambiguity. I'm now wondering if the description of TMMBR/TMMBN in this specification just for interworking with older implementations that don't support PAUSE/RESUME but figured out how to get a similar effect with TMMBR/TMMBN? I'm guessing, of course :-) In this text: 8.5. Transmission Rules o PAUSE SHOULD use Early or Immediate timing, except for retransmissions that SHOULD use Regular timing. ^ I understand this one. o The first transmission of PAUSED for each (non-wrapped) PauseID SHOULD be sent with Immediate or Early timing, while subsequent PAUSED for that PauseID SHOULD use Regular timing. Unsolicited PAUSED (sent when entering Local Paused State (Section 6.4)) SHOULD always use Immediate or Early timing, until PAUSED for that PauseID is considered delivered at least once to all receivers of the paused RTP stream, after which it SHOULD use Regular timing. ^ I'm wondering why these are SHOULDs. Are they MUSTs except that some implementations don't do it, or recommendations but nothing breaks if you don't do them, or something else? o RESUME SHOULD always use Immediate or Early timing. ^ I wonder why this is SHOULD. Is there any guidance you can provide about why RESUME would use Regular timing? o The first transmission of REFUSED for each (non-wrapped) PauseID SHOULD be sent with Immediate or Early timing, while subsequent REFUSED for that PauseID SHOULD use Regular timing. ^ I am, of course, wondering about the corresponding SHOULDs for REFUSED. In this text: 9. Signaling When signaling a config value other than 1, an implementation MUST ignore non-supported messages on reception, and MAY omit sending non- supported messages. is this saying that an implementation might send non-supported messages? I'm confused here. From nobody Wed Aug 19 04:32:33 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 748CB1A7005; Tue, 18 Aug 2015 18:20:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=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 6ds7o75kcPKu; Tue, 18 Aug 2015 18:20:39 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 25AAD1A7002; Tue, 18 Aug 2015 18:20:39 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Kathleen Moriarty" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.4.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150819012039.25238.64368.idtracker@ietfa.amsl.com> Date: Tue, 18 Aug 2015 18:20:39 -0700 Archived-At: X-Mailman-Approved-At: Wed, 19 Aug 2015 04:32:32 -0700 Cc: jonathan@vidyo.com, avtext@ietf.org, avtext-chairs@ietf.org, draft-ietf-avtext-rtp-stream-pause@ietf.org, draft-ietf-avtext-rtp-stream-pause.ad@ietf.org, draft-ietf-avtext-rtp-stream-pause.shepherd@ietf.org Subject: [avtext] Kathleen Moriarty's No Objection on draft-ietf-avtext-rtp-stream-pause-08: (with COMMENT) 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: Wed, 19 Aug 2015 01:20:40 -0000 Kathleen Moriarty has entered the following ballot position for draft-ietf-avtext-rtp-stream-pause-08: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-avtext-rtp-stream-pause/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- The SecDir review brought up a couple of attack types and at least the first should be mentioned in the security considerations section, replay protection. For the second, does it apply? https://www.ietf.org/mail-archive/web/secdir/current/msg05921.html Thank you. From nobody Wed Aug 19 09:58:07 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 D6D751A1B17; Wed, 19 Aug 2015 09:58:05 -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 hKzaVa7O7vuX; Wed, 19 Aug 2015 09:58:04 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 164AD1A1B21; Wed, 19 Aug 2015 09:58:04 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Stephen Farrell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.4.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150819165804.2051.78164.idtracker@ietfa.amsl.com> Date: Wed, 19 Aug 2015 09:58:04 -0700 Archived-At: Cc: jonathan@vidyo.com, avtext@ietf.org, avtext-chairs@ietf.org, draft-ietf-avtext-rtp-stream-pause@ietf.org, draft-ietf-avtext-rtp-stream-pause.ad@ietf.org, draft-ietf-avtext-rtp-stream-pause.shepherd@ietf.org Subject: [avtext] Stephen Farrell's No Objection on draft-ietf-avtext-rtp-stream-pause-08: (with COMMENT) 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: Wed, 19 Aug 2015 16:58:06 -0000 Stephen Farrell has entered the following ballot position for draft-ietf-avtext-rtp-stream-pause-08: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-avtext-rtp-stream-pause/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- - 58 pages! There is quite a bit of repetition here but too late to change now. - I see there are 2 IPR declarations, both with possible royalty/fee and neither that I can see actually specifying what patent (or other property) is involved despite both declarations being some years old. (And there was me thinking remote controls were almost older than me, but I guess what do I know and the USPTO must always be right;-) Anyway, can someone point me at where the working group said they were ok with this situation? (The shepherd write up says that happened so I hope it's not hard to get that pointer.) - Section 7: in a multiparty call, say participant#1 hits pause with PauseID = 0x0001, and stuff is resumed some time later, is participant#2 supposed to use a PauseID of 0x0002 subsequently? In other words does the SHALL there apply to everyone on the call or just to the participant who sent out the last PAUSE message? If the former, does that create a race condition? Or maybe that's a harmless race? I guess you could reduce the probability of a race by recommending that PauseID be randomly selected between last-PauseID-seen and last-PauseID-seen+(2^14) or something like that? (And apologies if all this is obvious to someone expert in RTP, I am not that person:-) From nobody Wed Aug 19 12:23: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 529BB1A89BB; Wed, 19 Aug 2015 12:23:33 -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 JBYZ6YpVHXxu; Wed, 19 Aug 2015 12:23:31 -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 3BC7F1A8A4F; Wed, 19 Aug 2015 12:23:22 -0700 (PDT) Received: from [10.0.1.23] (cpe-70-119-203-4.tx.res.rr.com [70.119.203.4]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id t7JJN87P076305 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 19 Aug 2015 14:23:19 -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: "Stephen Farrell" Date: Wed, 19 Aug 2015 14:23:08 -0500 Message-ID: <43F9367C-8DC6-4183-8488-11E6E91F7142@nostrum.com> In-Reply-To: <20150819165804.2051.78164.idtracker@ietfa.amsl.com> References: <20150819165804.2051.78164.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.2r5107) Archived-At: Cc: jonathan@vidyo.com, avtext@ietf.org, avtext-chairs@ietf.org, draft-ietf-avtext-rtp-stream-pause@ietf.org, The IESG , draft-ietf-avtext-rtp-stream-pause.ad@ietf.org, draft-ietf-avtext-rtp-stream-pause.shepherd@ietf.org Subject: Re: [avtext] Stephen Farrell's No Objection on draft-ietf-avtext-rtp-stream-pause-08: (with COMMENT) X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Aug 2015 19:23:33 -0000 On 19 Aug 2015, at 11:58, Stephen Farrell wrote: > - I see there are 2 IPR declarations, both with possible > royalty/fee and neither that I can see actually specifying > what patent (or other property) is involved despite both > declarations being some years old. (And there was me thinking > remote controls were almost older than me, but I guess what do > I know and the USPTO must always be right;-) Anyway, can > someone point me at where the working group said they were ok > with this situation? (The shepherd write up says that > happened so I hope it's not hard to get that pointer.) Hi Stephen, The wg was at least reminded of the IPR disclosures in HNL[1][2]. I can't say if that led to actual discussion, but people in the room had a chance to object. (disclaimer: This predates my AD-ness, and I was not in the IETF 91 avtext meeting) I do not see evidence of a similar discussion on the avtext list, at least not an explicit "are we okay with this" call. Keith/Jonathan/Authors: Do any of you have further input? [1]http://www.ietf.org/proceedings/91/slides/slides-91-avtext-1.pdf (page 2) [2]http://www.ietf.org/proceedings/91/minutes/minutes-91-avtext Thanks! Ben. From nobody Wed Aug 19 12:37: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 159181A8A1A; Wed, 19 Aug 2015 12:37:32 -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 3CRyBZQd5ifr; Wed, 19 Aug 2015 12:37:30 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E05E1A8A05; Wed, 19 Aug 2015 12:37:30 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Barry Leiba" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.4.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150819193730.2872.16228.idtracker@ietfa.amsl.com> Date: Wed, 19 Aug 2015 12:37:30 -0700 Archived-At: Cc: jonathan@vidyo.com, avtext@ietf.org, avtext-chairs@ietf.org, draft-ietf-avtext-rtp-stream-pause@ietf.org, draft-ietf-avtext-rtp-stream-pause.ad@ietf.org, draft-ietf-avtext-rtp-stream-pause.shepherd@ietf.org Subject: [avtext] Barry Leiba's No Objection on draft-ietf-avtext-rtp-stream-pause-08: (with COMMENT) 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: Wed, 19 Aug 2015 19:37:32 -0000 Barry Leiba has entered the following ballot position for draft-ietf-avtext-rtp-stream-pause-08: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-avtext-rtp-stream-pause/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I have a meta-question about why this "updates" 5104. It appears to be an extension to 5104, using normal extension mechanisms -- someone implementing 5104 and not intending to implement this would have no reason to look at this document, as far as I can tell. I don't see anything that describes a *change* to 5104 (though perhaps I've missed it). What's the reasoning behind specifying "updates"? From nobody Thu Aug 20 07:23:26 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 60E311ACEE3; Thu, 20 Aug 2015 07:23:25 -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 HIHDCAsgd3oR; Thu, 20 Aug 2015 07:23:23 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 003691ACEFA; Thu, 20 Aug 2015 07:21:55 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Ben Campbell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.4.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150820142154.5439.18178.idtracker@ietfa.amsl.com> Date: Thu, 20 Aug 2015 07:21:54 -0700 Archived-At: Cc: jonathan@vidyo.com, avtext@ietf.org, avtext-chairs@ietf.org, draft-ietf-avtext-rtp-stream-pause@ietf.org, draft-ietf-avtext-rtp-stream-pause.ad@ietf.org, draft-ietf-avtext-rtp-stream-pause.shepherd@ietf.org Subject: [avtext] Ben Campbell's Discuss on draft-ietf-avtext-rtp-stream-pause-08: (with DISCUSS) X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.15 List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Aug 2015 14:23:25 -0000 Ben Campbell has entered the following ballot position for draft-ietf-avtext-rtp-stream-pause-08: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-avtext-rtp-stream-pause/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- This is just a process discuss: We need a designated expert for the registry impacted, and the resulting expert review, prior to approval. From nobody Thu Aug 27 04:28:47 2015 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5880E1ACEBD; Thu, 27 Aug 2015 04:28:46 -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 N5L7IQtDj3NZ; Thu, 27 Aug 2015 04:28:43 -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 C27A11B2D5C; Thu, 27 Aug 2015 04:28:41 -0700 (PDT) X-AuditID: c1b4fb25-f79a26d00000149a-f8-55def4675f29 Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id D6.D8.05274.764FED55; Thu, 27 Aug 2015 13:28:40 +0200 (CEST) Received: from ESESSMB105.ericsson.se ([169.254.5.220]) by ESESSHC007.ericsson.se ([153.88.183.39]) with mapi id 14.03.0210.002; Thu, 27 Aug 2015 13:28:39 +0200 From: Bo Burman To: Spencer Dawkins , The IESG Thread-Topic: Spencer Dawkins' Yes on draft-ietf-avtext-rtp-stream-pause-08: (with COMMENT) Thread-Index: AQHQ2i14cHa9zh/TA0q/GOwjYo3IwZ4fnZbw Date: Thu, 27 Aug 2015 11:28:39 +0000 Message-ID: References: <20150819031636.31652.86423.idtracker@ietfa.amsl.com> In-Reply-To: <20150819031636.31652.86423.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.146] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupnkeLIzCtJLcpLzFFi42KZGfG3Rjfjy71Qg223WC3az51gsfh47war xdJZXawWu29MZrHoermD2WLGn4nMFvsXn2e2WDZlD7MDh8fOWXfZPZYs+cnk0fbsDnsAcxSX TUpqTmZZapG+XQJXxv73+5kKNmVXHJ49m7GB8UJGFyMnh4SAicSb7XPYIWwxiQv31rN1MXJx CAkcZZT4feorlLOEUeL+ohYmkCo2AQ2J+TvuMoLYIgK+ElcmLwUrYhY4xCwxccd5sFHCAjES lxqeMEMUxUocPLkbqIgDyDaSmLdWByTMIqAqsf1vB1g5L9Ccf8tusoHYQgKOEp/mvAabzyng JLHz8wqwGkYBWYn73++xgNjMAuISt57MZ4K4WkBiyZ7zzBC2qMTLx/9YIWwliR8bLrGArGUW 0JRYv0sfolVRYkr3Q6i1ghInZz5hmcAoNgvJ1FkIHbOQdMxC0rGAkWUVo2hxanFSbrqRsV5q UWZycXF+nl5easkmRmAMHtzyW3UH4+U3jocYBTgYlXh4FfLvhQqxJpYVV+YeYpTmYFES5z19 HSgkkJ5YkpqdmlqQWhRfVJqTWnyIkYmDU6qBseflIY0Uk4x7e7S/zGLc9ax3pd2mVQHTTyUI JVfLXWwoV5dmXltbvu1Z6NnHl/JvXTvm9Uo8PWa3XvxsnzNrDnY5Zkms2Hf0ZJJKZ6e62vtr LDlaSX1V/sU2j76/WZ8eXjnrHtcPq6tznqc8OC1x2te0j3PFz2bJPWbOhbp3fpq1WW7sud/4 TYmlOCPRUIu5qDgRAP2IEiWiAgAA Archived-At: Cc: "jonathan@vidyo.com" , "avtext@ietf.org" , "avtext-chairs@ietf.org" , "draft-ietf-avtext-rtp-stream-pause@ietf.org" , "draft-ietf-avtext-rtp-stream-pause.ad@ietf.org" , "draft-ietf-avtext-rtp-stream-pause.shepherd@ietf.org" Subject: Re: [avtext] Spencer Dawkins' Yes on draft-ietf-avtext-rtp-stream-pause-08: (with COMMENT) X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Aug 2015 11:28:46 -0000 VGhhbmsgeW91IGZvciBnb29kIGFuZCBjb25zdHJ1Y3RpdmUgY29tbWVudHMuIFBsZWFzZSBmaW5k IHJlc3BvbnNlcyB0byB5b3VyIHF1ZXN0aW9ucyBpbmxpbmUgYmVsb3cuDQpDaGVlcnMsDQpCbw0K DQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IFNwZW5jZXIgRGF3a2lucyBb bWFpbHRvOnNwZW5jZXJkYXdraW5zLmlldGZAZ21haWwuY29tXQ0KPiBTZW50OiBkZW4gMTkgYXVn dXN0aSAyMDE1IDA1OjE3DQo+IFRvOiBUaGUgSUVTRw0KPiBDYzogZHJhZnQtaWV0Zi1hdnRleHQt cnRwLXN0cmVhbS1wYXVzZUBpZXRmLm9yZzsgZHJhZnQtaWV0Zi1hdnRleHQtcnRwLXN0cmVhbS1w YXVzZS5hZEBpZXRmLm9yZzsgam9uYXRoYW5AdmlkeW8uY29tOw0KPiBkcmFmdC1pZXRmLWF2dGV4 dC1ydHAtc3RyZWFtLXBhdXNlLnNoZXBoZXJkQGlldGYub3JnOyBhdnRleHQtY2hhaXJzQGlldGYu b3JnOyBhdnRleHRAaWV0Zi5vcmcNCj4gU3ViamVjdDogU3BlbmNlciBEYXdraW5zJyBZZXMgb24g ZHJhZnQtaWV0Zi1hdnRleHQtcnRwLXN0cmVhbS1wYXVzZS0wODogKHdpdGggQ09NTUVOVCkNCj4g DQo+IFNwZW5jZXIgRGF3a2lucyBoYXMgZW50ZXJlZCB0aGUgZm9sbG93aW5nIGJhbGxvdCBwb3Np dGlvbiBmb3INCj4gZHJhZnQtaWV0Zi1hdnRleHQtcnRwLXN0cmVhbS1wYXVzZS0wODogWWVzDQo+ IA0KPiBXaGVuIHJlc3BvbmRpbmcsIHBsZWFzZSBrZWVwIHRoZSBzdWJqZWN0IGxpbmUgaW50YWN0 IGFuZCByZXBseSB0byBhbGwgZW1haWwgYWRkcmVzc2VzIGluY2x1ZGVkIGluIHRoZSBUbyBhbmQg Q0MgbGluZXMuDQo+IChGZWVsIGZyZWUgdG8gY3V0IHRoaXMgaW50cm9kdWN0b3J5IHBhcmFncmFw aCwgaG93ZXZlci4pDQo+IA0KPiANCj4gUGxlYXNlIHJlZmVyIHRvIGh0dHBzOi8vd3d3LmlldGYu b3JnL2llc2cvc3RhdGVtZW50L2Rpc2N1c3MtY3JpdGVyaWEuaHRtbA0KPiBmb3IgbW9yZSBpbmZv cm1hdGlvbiBhYm91dCBJRVNHIERJU0NVU1MgYW5kIENPTU1FTlQgcG9zaXRpb25zLg0KPiANCj4g DQo+IFRoZSBkb2N1bWVudCwgYWxvbmcgd2l0aCBvdGhlciBiYWxsb3QgcG9zaXRpb25zLCBjYW4g YmUgZm91bmQgaGVyZToNCj4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQt aWV0Zi1hdnRleHQtcnRwLXN0cmVhbS1wYXVzZS8NCj4gDQo+IA0KPiANCj4gLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LQ0KPiBDT01NRU5UOg0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IA0KPiBUaGlzIGRyYWZ0IHdhcyByZWFs bHkgZWFzeSBmb3IgbWUgdG8gcmVhZCAod2l0aCBzb21lIGJhY2tncm91bmQgaW4gUlRQL1JUQ1As IGJ1dCBJJ20gbm8gZXhwZXJ0IG9uIHRoZSB0b3BpYykuIFRoYW5rIHlvdQ0KPiBmb3IgdGhlIHdv cmsgb24gaXQgLSB0aGUgcmVzdWx0cyBzaG93Lg0KPiANCj4gSSBoYXZlIHNvbWUgcXVlc3Rpb25z LCBidXQgbm90aGluZyBpcyBhIHNob3ctc3RvcHBlci4NCj4gDQo+IEluIHRoaXMgdGV4dDoNCj4g DQo+IDMuMy4gIFJUUCBNaXhlciB0byBNZWRpYSBTZW5kZXIgaW4gUG9pbnQtdG8tTXVsdGlwb2lu dA0KPiANCj4gICAgSW4gdGhpcyB1c2UgY2FzZSB0aGVyZSBhcmUgc2V2ZXJhbCByZWNlaXZlcnMg b2YgYSBzdHJlYW0gYW5kIHNwZWNpYWwNCj4gICAgY2FyZSBtdXN0IGJlIHRha2VuIGFzIG5vdCB0 byBwYXVzZSBhIHN0cmVhbSB0aGF0IGlzIHN0aWxsIHdhbnRlZCBieQ0KPiAgICBzb21lIHJlY2Vp dmVycy4NCj4gDQo+IEknbSBhc3N1bWluZyB0aGF0IHRoZSBNaXhlciBpcyB0YWtpbmcgc3BlY2lh bCBjYXJlLCBidXQgdGhpcyBpcyBwYXNzaXZlIGVub3VnaCB0aGF0IEknbSBmaWxsaW5nIGluIGJs YW5rcy4gSWYgeW91IGxpa2UgcGFzc2l2ZQ0KPiB2b2ljZSwgcGVyaGFwcyBzb21ldGhpbmcgbGlr ZQ0KPiANCj4gICAgSW4gdGhpcyB1c2UgY2FzZSB0aGVyZSBhcmUgc2V2ZXJhbCByZWNlaXZlcnMg b2YgYSBzdHJlYW0gYW5kIHNwZWNpYWwNCj4gICAgY2FyZSBtdXN0IGJlIHRha2VuIGJ5IHRoZSBN aXhlciBzbyBhcyBub3QgdG8gcGF1c2UgYSBzdHJlYW0gdGhhdCBpcw0KPiAgICAgICAgICAgICAg ICAgICAgICAgXl5eXl5eXl5eXl5eXl5eDQo+ICAgIHN0aWxsIHdhbnRlZCBieSBzb21lIHJlY2Vp dmVycy4NCj4gDQo+IHdvdWxkIGJlIGVhc2llciB0byBwYXJzZS4NCj4gDQo+IElmIHlvdSBjYW4g ZG8gYWN0aXZlIHZvaWNlLCBwZXJoYXBzDQo+IA0KPiAgICBJbiB0aGlzIHVzZSBjYXNlIHRoZXJl IGFyZSBzZXZlcmFsIHJlY2VpdmVycyBvZiBhIHN0cmVhbSBhbmQgdGhlDQo+ICAgIE1peGVyIG11 c3QgdGFrZSBzcGVjaWFsIGNhcmUgc28gYXMgbm90IHRvIHBhdXNlIGEgc3RyZWFtIHRoYXQgaXMg c3RpbGwNCj4gDQo+ICAgIF5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl4NCj4gICAgd2Fu dGVkIGJ5IHNvbWUgcmVjZWl2ZXJzLg0KW0JvQl0gVGhhbmtzLCB5b3VyIGFzc3VtcHRpb24gaXMg Y29ycmVjdCwgYW5kIEkgdGhpbmsgdGhpcyBhY3RpdmUgdm9pY2UgaXMgZWFzaWVyIHRvIHJlYWQu DQoNCj4gDQo+IEluIHRoaXMgdGV4dDoNCj4gDQo+IDguICBNZXNzYWdlIERldGFpbHMNCj4gDQo+ ICAgIEFueSByZWZlcmVuY2VzIHRvIFBBVVNFLCBQQVVTRUQsIFJFU1VNRSBhbmQgUkVGVVNFRCBp biB0aGlzIHNlY3Rpb24NCj4gICAgU0hBTEwgYmUgdGFrZW4gdG8gYXBwbHkgdG8gdGhlIGV4dGVu dCBwb3NzaWJsZSBhbHNvIHdoZW4gVE1NQlIvVE1NQk4NCj4gICAgYXJlIHVzZWQgKFNlY3Rpb24g NS42KSBmb3IgdGhpcyBmdW5jdGlvbmFsaXR5LiAgVE1NQlIvVE1NQk4gTUFZIGJlDQo+ICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IF5eXg0KPiAgICB1c2VkIGluc3RlYWQgb2YgdGhlIG1lc3NhZ2VzIGRlZmluZWQgaW4gdGhpcyBz cGVjaWZpY2F0aW9uIHdoZW4gdGhlDQo+ICAgIGVmZmVjdGl2ZSB0b3BvbG9neSBpcyBwb2ludC10 by1wb2ludC4gIElmIGVpdGhlciBzZW5kZXIgb3IgcmVjZWl2ZXINCj4gICAgbGVhcm5zIHRoYXQg dGhlIHRvcG9sb2d5IGlzIG5vdCBwb2ludC10by1wb2ludCwgVE1NQlIvVE1NQk4gTVVTVCBOT1QN Cj4gICAgYmUgdXNlZCBmb3IgcGF1c2UvcmVzdW1lIGZ1bmN0aW9uYWxpdHkuICBJZiB0aGUgbWVz c2FnZXMgZGVmaW5lZCBpbg0KPiAgICB0aGlzIHNwZWNpZmljYXRpb24gYXJlIHN1cHBvcnRlZCBp biBhZGRpdGlvbiB0byBUTU1CUi9UTU1CTiBieSBhbGwNCj4gICAgaW52b2x2ZWQgcGFydGllcywg cGF1c2UvcmVzdW1lIHNpZ25hbGluZyBNVVNUIHVzZSBtZXNzYWdlcyBmcm9tIHRoaXMNCj4gICAg c3BlY2lmaWNhdGlvbi4gIElmIHRoZSB0b3BvbG9neSBpcyBub3QgcG9pbnQtdG8tcG9pbnQgYW5k IHRoZQ0KPiAgICBtZXNzYWdlcyBkZWZpbmVkIGluIHRoaXMgc3BlY2lmaWNhdGlvbiBhcmUgbm90 IHN1cHBvcnRlZCwgcGF1c2UvDQo+ICAgIHJlc3VtZSBmdW5jdGlvbmFsaXR5IHdpdGggVE1NQlIv VE1NQk4gTVVTVCBOT1QgYmUgdXNlZC4NCj4gDQo+IEFsbCBvZiB0aGlzIG1ha2VzIHNlbnNlIHRv IG1lLCBleGNlcHQgdGhhdCBJJ20gbm90IHVuZGVyc3RhbmRpbmcgd2h5IFRNTUJSL1RNTUJOIGlz IGEgTUFZLiBUaGVyZSdzIGEgbG90IG9mIHRleHQgdGhhdA0KPiBzYXlzIHlvdSByZWFsbHkgbmVl ZCB0byB1c2UgdGhlIG1lc3NhZ2VzIGZyb20gdGhpcyBzcGVjaWZpY2F0aW9uIGluIHRoaXMgY2Fz ZSwgYW5kIGluIHRoYXQgY2FzZSwgYW5kIC4uLiBidXQgaGVyZSwgeW91IE1BWQ0KPiBkbyBzb21l dGhpbmcgZWxzZS4NCj4gDQo+IEkgdW5kZXJzdGFuZCB0aGF0IFRNTUJSL1RNTUJOIHdvcmtzIGlu IGEgcG9pbnQtdG8tcG9pbnQgdG9wb2xvZ3ksIGJ1dCBpcyB0aGVyZSBhIHJlYXNvbiB0byBwcmVm ZXIgVE1NQlIvVE1NQk4NCj4gaW4gdGhhdCB0b3BvbG9neT8gSWYgc28sIGl0IHdvdWxkIHByb2Jh Ymx5IGJlIGdvb2QgdG8gZXhwbGFpbiB3aHkuDQo+IA0KPiBBbmQgYXMgSSByZWFkIGZ1dGhlciwg SSBzZWUgdGhpcywgaW4gc2VjdGlvbiA5Og0KPiANCj4gICAgICAgTm90ZTogV2hlbiBUTU1CUiAw IC8gVE1NQk4gMCBhcmUgdXNlZCB0byBpbXBsZW1lbnQgcGF1c2UgYW5kDQo+ICAgICAgIHJlc3Vt ZSBmdW5jdGlvbmFsaXR5ICh3aXRoIHRoZSByZXN0cmljdGlvbnMgZGVzY3JpYmVkIGluIHRoaXMN Cj4gICAgICAgc3BlY2lmaWNhdGlvbiksIHNpZ25hbGluZyBydGNwLWZiIGF0dHJpYnV0ZSB3aXRo IGNjbSB0bW1icg0KPiAgICAgICBwYXJhbWV0ZXIgaXMgc3VmZmljaWVudCBhbmQgbm8gZnVydGhl ciBzaWduYWxpbmcgaXMgbmVjZXNzYXJ5Lg0KPiAgICAgICBUaGVyZSBpcyBob3dldmVyIG5vIGd1 YXJhbnRlZSB0aGF0IFRNTUJSL1RNTUJOIGltcGxlbWVudGF0aW9ucw0KPiAgICAgICAgICAgICAg ICAgICAgICAgIF5eXl5eXl5eXl5eXg0KPiAgICAgICBwcmUtZGF0aW5nIHRoaXMgc3BlY2lmaWNh dGlvbiB3b3JrIGV4YWN0bHkgYXMgZGVzY3JpYmVkIGhlcmUgd2hlbg0KPiAgICAgICB1c2VkIHdp dGggYSBiaXRyYXRlIHZhbHVlIG9mIDAuDQo+IA0KPiBhbmQgdGhhdCByZWFsbHkgbWFrZXMgbWUg d29uZGVyIHdoeSB0aGlzIHNwZWNpZmljYXRpb24gaXMgYWxzbyBkZXNjcmliaW5nIFRNTUJSL1RN TUJOLiBJJ20gc3VyZSB0aGVyZSdzIGEgZ29vZA0KPiByZWFzb24sIGJ1dCBjYW4geW91IHVuZGVy c3RhbmQgbXkgY29uZnVzaW9uPw0KPiANCj4gRmluYWxseSwgSSBzZWUgdGhpcywgaW4gc2VjdGlv biA5LjEsDQo+IA0KPiAgICBJZiBib3RoICJwYXVzZSIgYW5kICJ0bW1iciIgYXJlIHByZXNlbnQg aW4gdGhlIG9mZmVyLCBib3RoIE1BWSBiZQ0KPiAgICBpbmNsdWRlZCBhbHNvIGluIHRoZSBhbnN3 ZXIsIGluIHdoaWNoIGNhc2UgVE1NQlIvVE1NQk4gTVVTVCBOT1QgYmUNCj4gICAgdXNlZCBmb3Ig cGF1c2UvcmVzdW1lIHB1cnBvc2VzICh3aXRoIGEgYml0cmF0ZSB2YWx1ZSBvZiAwKSwgdG8gYXZv aWQNCj4gICAgc2lnbmFsaW5nIGFtYmlndWl0eS4NCj4gDQo+IGFuZCBpbiBzZWN0aW9uIDkuMiwN Cj4gDQo+ICAgIElmIGJvdGggInBhdXNlIiBhbmQgInRtbWJyIiBhcmUgcHJlc2VudCBpbiB0aGUg U0RQLCBUTU1CUi9UTU1CTiBNVVNUDQo+ICAgIE5PVCBiZSB1c2VkIGZvciBwYXVzZS9yZXN1bWUg cHVycG9zZXMgKHdpdGggYSBiaXRyYXRlIHZhbHVlIG9mIDApLCB0bw0KPiAgICBhdm9pZCBzaWdu YWxpbmcgYW1iaWd1aXR5Lg0KPiANCj4gSSdtIG5vdyB3b25kZXJpbmcgaWYgdGhlIGRlc2NyaXB0 aW9uIG9mIFRNTUJSL1RNTUJOIGluIHRoaXMgc3BlY2lmaWNhdGlvbiBqdXN0IGZvciBpbnRlcndv cmtpbmcgd2l0aCBvbGRlcg0KPiBpbXBsZW1lbnRhdGlvbnMgdGhhdCBkb24ndCBzdXBwb3J0IFBB VVNFL1JFU1VNRSBidXQgZmlndXJlZCBvdXQgaG93IHRvIGdldCBhIHNpbWlsYXIgZWZmZWN0IHdp dGggVE1NQlIvVE1NQk4/DQo+IA0KPiBJJ20gZ3Vlc3NpbmcsIG9mIGNvdXJzZSA6LSkNCltCb0Jd IFlvdXIgZ3Vlc3MgaXMgY29ycmVjdC4gVGhpcyBpcyBoaW50ZWQgYWxyZWFkeSB3aXRoIHRoZSBs YXN0IHR3byBzZW50ZW5jZXMgaW4gdGhlIEludHJvZHVjdGlvbiBzZWN0aW9uICJUaGUgVGVtcG9y YXJ5IE1heGltdW0gTWVkaWEgQml0cmF0ZSBSZXF1ZXN0IChUTU1CUikgbWVzc2FnZSBvZiBDQ00g aXMgdXNlZCBieSB2aWRlbyBjb25mZXJlbmNpbmcgc3lzdGVtcyBmb3IgZmxvdyBjb250cm9sLiBJ dCBpcyBkZXNpcmFibGUgdG8gYmUgYWJsZSB0byB1c2UgdGhhdCBtZXRob2Qgd2l0aCBhIGJpdHJh dGUgdmFsdWUgb2YgemVybyBmb3IgcGF1c2UsIHdoZW5ldmVyIHBvc3NpYmxlIi4gRG8geW91IHRo aW5rIHRoaXMgbmVlZHMgdG8gYmUgbW9yZSBleHBsaWNpdGx5IHN0YXRlZCwgbWF5YmUgaW4gc2Vj dGlvbiA1LjYgb24gVE1NQlIvVE1NQk4gY29uc2lkZXJhdGlvbnM/IFNheSwgc29tZXRoaW5nIHNp bWlsYXIgdG8gd2hhdCB5b3Ugc2FpZCBhYm92ZTogIlRoaXMgdXNlIGlzIGV4cGVjdGVkIHRvIGJl IG1haW5seSBmb3IgaW50ZXJ3b3JraW5nIHdpdGggaW1wbGVtZW50YXRpb25zIHRoYXQgZG9uJ3Qg c3VwcG9ydCBQQVVTRS9SRVNVTUUsIGJ1dCBtYWtlIHVzZSBvZiBUTU1CUi9UTU1CTiB0byBhY2hp ZXZlIGEgc2ltaWxhciBlZmZlY3QiLiBEbyB5b3UgdGhpbmsgc29tZXRoaW5nIG5lZWRzIHRvIGJl IHNhaWQgaW4gc2VjdGlvbiA4IHRvbz8NCg0KPiANCj4gSW4gdGhpcyB0ZXh0Og0KPiANCj4gOC41 LiAgVHJhbnNtaXNzaW9uIFJ1bGVzDQo+IA0KPiAgICBvICBQQVVTRSBTSE9VTEQgdXNlIEVhcmx5 IG9yIEltbWVkaWF0ZSB0aW1pbmcsIGV4Y2VwdCBmb3INCj4gICAgICAgcmV0cmFuc21pc3Npb25z IHRoYXQgU0hPVUxEIHVzZSBSZWd1bGFyIHRpbWluZy4NCj4gDQo+IF4gSSB1bmRlcnN0YW5kIHRo aXMgb25lLg0KPiANCj4gICAgbyAgVGhlIGZpcnN0IHRyYW5zbWlzc2lvbiBvZiBQQVVTRUQgZm9y IGVhY2ggKG5vbi13cmFwcGVkKSBQYXVzZUlEDQo+ICAgICAgIFNIT1VMRCBiZSBzZW50IHdpdGgg SW1tZWRpYXRlIG9yIEVhcmx5IHRpbWluZywgd2hpbGUgc3Vic2VxdWVudA0KPiAgICAgICBQQVVT RUQgZm9yIHRoYXQgUGF1c2VJRCBTSE9VTEQgdXNlIFJlZ3VsYXIgdGltaW5nLiAgVW5zb2xpY2l0 ZWQNCj4gICAgICAgUEFVU0VEIChzZW50IHdoZW4gZW50ZXJpbmcgTG9jYWwgUGF1c2VkIFN0YXRl IChTZWN0aW9uIDYuNCkpDQo+ICAgICAgIFNIT1VMRCBhbHdheXMgdXNlIEltbWVkaWF0ZSBvciBF YXJseSB0aW1pbmcsIHVudGlsIFBBVVNFRCBmb3IgdGhhdA0KPiAgICAgICBQYXVzZUlEIGlzIGNv bnNpZGVyZWQgZGVsaXZlcmVkIGF0IGxlYXN0IG9uY2UgdG8gYWxsIHJlY2VpdmVycyBvZg0KPiAg ICAgICB0aGUgcGF1c2VkIFJUUCBzdHJlYW0sIGFmdGVyIHdoaWNoIGl0IFNIT1VMRCB1c2UgUmVn dWxhciB0aW1pbmcuDQo+IA0KPiBeIEknbSB3b25kZXJpbmcgd2h5IHRoZXNlIGFyZSBTSE9VTERz LiBBcmUgdGhleSBNVVNUcyBleGNlcHQgdGhhdCBzb21lIGltcGxlbWVudGF0aW9ucyBkb24ndCBk byBpdCwgb3INCj4gcmVjb21tZW5kYXRpb25zIGJ1dCBub3RoaW5nIGJyZWFrcyBpZiB5b3UgZG9u J3QgZG8gdGhlbSwgb3Igc29tZXRoaW5nIGVsc2U/DQpbQm9CXSBJdCBpcyByZWNvbW1lbmRhdGlv bnMsIG1lYW5pbmcgdGhhdCBpZiB5b3UgZG9uJ3QgZm9sbG93IHRoZW0sIG5vdGhpbmcgd2lsbCBy ZWFsbHkgYnJlYWssIGJ1dCB5b3UnbGwgZ2V0IHdvcnNlIHBlcmZvcm1hbmNlIGluIG9uZSB3YXkg b3IgdGhlIG90aGVyLiBUaGUgU0hPVUxEcyBmb3IgRWFybHkgb3IgSW1tZWRpYXRlIGlzIHRvIHBy b3ZpZGUgZ29vZCB0aW1lbGluZXNzIGFuZCByZXNwb25zaXZlbmVzcyBvZiB0aGUgYXBwbGljYXRp b24gbWFraW5nIHVzZSBvZiB0aGUgbWVzc2FnZXMsIHdoaWxlIHRoZSBTSE9VTERzIGZvciBSZWd1 bGFyIGFyZSB0byBhdm9pZCBleGNlc3NpdmUgYmFuZHdpZHRoIGNvbnN1bXB0aW9uLg0KDQo+IA0K PiAgICBvICBSRVNVTUUgU0hPVUxEIGFsd2F5cyB1c2UgSW1tZWRpYXRlIG9yIEVhcmx5IHRpbWlu Zy4NCj4gDQo+IF4gSSB3b25kZXIgd2h5IHRoaXMgaXMgU0hPVUxELiBJcyB0aGVyZSBhbnkgZ3Vp ZGFuY2UgeW91IGNhbiBwcm92aWRlIGFib3V0IHdoeSBSRVNVTUUgd291bGQgdXNlIFJlZ3VsYXIg dGltaW5nPw0KW0JvQl0gVGhlIG9ubHkgY2FzZSBJIGNhbiBjb21lIHRvIHRoaW5rIG9mIGlzIHdo ZW4gb3RoZXIgUlRDUCBtZXNzYWdlcyB1c2VkIGJ5IHRoZSBhcHBsaWNhdGlvbiBsYXllciAobm90 IFBBVVNFL1JFU1VNRSkgYXJlIHNvbWVob3cgY29uc2lkZXJlZCBtb3JlIGltcG9ydGFudCB0aGFu IHJlc3VtaW5nIG1lZGlhIHN0cmVhbXMgaW4gdGhhdCBzcGVjaWZpYyBhcHBsaWNhdGlvbiBjb250 ZXh0LiBBZ2Fpbiwgbm90aGluZyB3b3VsZCByZWFsbHkgYnJlYWsgd2l0aCByZWd1bGFyIHRpbWlu ZywgYnV0IHBlcmZvcm1hbmNlIHdvdWxkIGNlcnRhaW5seSBzdWZmZXIgYmFkbHkuIE1heWJlIHN1 Y2ggYXBwbGljYXRpb24tbGV2ZWwgY29uc2lkZXJhdGlvbiBpcyBzdWZmaWNpZW50bHkgImV4dHJl bWUiIHRoYXQgaXQgaXMgbW90aXZhdGVkIGNoYW5naW5nIHRvIGEgTVVTVCwgZm9yY2luZyBzdWNo IHNpdHVhdGlvbnMgdG8gYnJlYWsgY29tcGxpYW5jZT8NCg0KPiANCj4gICAgbyAgVGhlIGZpcnN0 IHRyYW5zbWlzc2lvbiBvZiBSRUZVU0VEIGZvciBlYWNoIChub24td3JhcHBlZCkgUGF1c2VJRA0K PiAgICAgICBTSE9VTEQgYmUgc2VudCB3aXRoIEltbWVkaWF0ZSBvciBFYXJseSB0aW1pbmcsIHdo aWxlIHN1YnNlcXVlbnQNCj4gICAgICAgUkVGVVNFRCBmb3IgdGhhdCBQYXVzZUlEIFNIT1VMRCB1 c2UgUmVndWxhciB0aW1pbmcuDQo+IA0KPiBeIEkgYW0sIG9mIGNvdXJzZSwgd29uZGVyaW5nIGFi b3V0IHRoZSBjb3JyZXNwb25kaW5nIFNIT1VMRHMgZm9yIFJFRlVTRUQuDQpbQm9CXSBUaW1lbHkg dHJhbnNtaXNzaW9uIG9mIFJFRlVTRUQgY2FuIHN0b3AgdW5uZWNlc3NhcnkgcmVwZXRpdGlvbnMg b2YgUEFVU0Ugb3IgUkVTVU1FLCB3aGljaCBJIGJlbGlldmUgbW90aXZhdGVzIHJlY29tbWVuZGlu ZyBJbW1lZGlhdGUgb3IgRWFybHkgZm9yIHRoZSBmaXJzdCB0cmFuc21pc3Npb24gdG8gc2F2ZSBz b21lIFJUQ1AgYmFuZHdpZHRoLiBUaGF0IGlzIGhvd2V2ZXIgbm90IGNvbnNpZGVyZWQgY3JpdGlj YWwgZW5vdWdoIHRvIG1vdGl2YXRlIHJlY29tbWVuZGluZyByZXBldGl0aW9ucyBvZiB0aGUgc2Ft ZSBpbmRpY2F0aW9uIHRvIGJlIHNlbnQgd2l0aCBvdGhlciB0aGFuIFJlZ3VsYXIgdGltaW5nLiBO b3RoaW5nIHdvdWxkIGJyZWFrIGlmIHJlcGV0aXRpb25zIGFyZSBzZW50IHdpdGggRWFybHkgb3Ig SW1tZWRpYXRlIHRpbWluZywgYnV0IGl0IHdvdWxkIHBvdGVudGlhbGx5IHdhc3RlIHNvbWUgdHJh bnNtaXNzaW9uIG9wcG9ydHVuaXRpZXMgZm9yIG90aGVyIFJUQ1AgKEZCKSBtZXNzYWdlcy4gRG8g eW91IHRoaW5rIGl0IG1vdGl2YXRlZCB0byBhZGQgbW9yZSB0ZXh0IG9uIHN1Y2ggY29uc2lkZXJh dGlvbnM/DQoNCj4gDQo+IEluIHRoaXMgdGV4dDoNCj4gDQo+IDkuICBTaWduYWxpbmcNCj4gDQo+ ICAgIFdoZW4gc2lnbmFsaW5nIGEgY29uZmlnIHZhbHVlIG90aGVyIHRoYW4gMSwgYW4gaW1wbGVt ZW50YXRpb24gTVVTVA0KPiAgICBpZ25vcmUgbm9uLXN1cHBvcnRlZCBtZXNzYWdlcyBvbiByZWNl cHRpb24sIGFuZCBNQVkgb21pdCBzZW5kaW5nIG5vbi0NCj4gICAgc3VwcG9ydGVkIG1lc3NhZ2Vz Lg0KPiANCj4gaXMgdGhpcyBzYXlpbmcgdGhhdCBhbiBpbXBsZW1lbnRhdGlvbiBtaWdodCBzZW5k IG5vbi1zdXBwb3J0ZWQgbWVzc2FnZXM/DQo+IEknbSBjb25mdXNlZCBoZXJlLg0KW0JvQl0gVGhh dCBzaG91bGQgaGF2ZSBiZWVuICIuLi4gTUFZIG9taXQgc2VuZGluZyBtZXNzYWdlcyBub3Qgc3Vw cG9ydGVkIGJ5IHRoZSByZW1vdGUgcGVlciIuIEkgcmVhbGl6ZSB0aGF0IGZ1cnRoZXIgZG93biBp dCBpcyBzYWlkICIuLi4gU0hPVUxEIE5PVCBiZSB1c2VkIHRvd2FyZHMgcmVjZWl2ZXJzIHRoYXQg ZGlkIG5vdCBkZWNsYXJlIGNhcGFiaWxpdHkgdG8gcmVjZWl2ZSB0aG9zZSBtZXNzYWdlcyIsIHNv IEkgZ3Vlc3MgdGhhdCBNQVkgc2hvdWxkIGJlIGNoYW5nZWQgdG8gYSBTSE9VTEQgdG8gYmUgY29u c2lzdGVudC4gSW4gYW55IGNhc2UsIG5vdCBoYXZpbmcgTVVTVHMgaGVyZSBhbGxvd3MgYSBtaXgg b2YgZGlmZmVyZW50IGNhcGFiaWxpdGllcyBhbW9uZyByZWNlaXZlcnMgaW4gYSBtdWx0aS1yZWNl aXZlciBjYXNlIHdpdGhvdXQgbGV0dGluZyB0aGUgbGVhc3QgY2FwYWJsZSByZWNlaXZlciBzZXQg dGhlIGxldmVsIG9mIFAvUiBmdW5jdGlvbmFsaXR5IGZvciBhbGwgdGhlIG90aGVycy4gV2l0aCB0 aGF0IGluIG1pbmQsIGRvIHlvdSB0aGluayAiU0hPVUxEIG9taXQiIGlzIGEgdG9vIHN0cm9uZyB3 b3JkaW5nPw0KDQo= From nobody Thu Aug 27 05:37:03 2015 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B51621B3AD4; Thu, 27 Aug 2015 05:36:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0WdfhaBQdBgK; Thu, 27 Aug 2015 05:36:51 -0700 (PDT) Received: from mail-vk0-x230.google.com (mail-vk0-x230.google.com [IPv6:2607:f8b0:400c:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A85821B3ACE; Thu, 27 Aug 2015 05:36:45 -0700 (PDT) Received: by vkm66 with SMTP id 66so8268637vkm.1; Thu, 27 Aug 2015 05:36:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=xT3DolNuj5fHuo17khpdcRmGtso60448mzkRONIhwTs=; b=aPkazDt2eTWVggssYZfDUf/49/uTGwc88/Bc6lwnP/oXDjDHPSQs09dltoEroRYzDn ZB+6KCLaEAl9ZvcUkUt00Z6LiDaahrPsrtUvj9pqgEMv882x89EEz8J8//k5ytixKZEE xP3ayuP25OH8VpEWMY4lt6cY/hVLA1uRdVy1AN7J17p5l4sX7y0JVUmoLWH7w60qdtiv y6NnFBvWQ7SpjitQMrU+njUKLPeoNnBZuau4zKkIQ8sH4oF/96TP+uJaLBg02vW5q4m+ n7uB3Rs6cL+n0CunrFLZNBHWevFCqHoUeGtRr03Si0LohxeXaCYbsMzt8lTIfaOBVJ7w 71YQ== MIME-Version: 1.0 X-Received: by 10.52.163.50 with SMTP id yf18mr4165286vdb.93.1440679004775; Thu, 27 Aug 2015 05:36:44 -0700 (PDT) Received: by 10.31.63.1 with HTTP; Thu, 27 Aug 2015 05:36:44 -0700 (PDT) In-Reply-To: References: <20150819031636.31652.86423.idtracker@ietfa.amsl.com> Date: Thu, 27 Aug 2015 07:36:44 -0500 Message-ID: From: Spencer Dawkins at IETF To: Bo Burman Content-Type: multipart/alternative; boundary=001a11c2ce3850a9d4051e4a386f Archived-At: Cc: "jonathan@vidyo.com" , "avtext@ietf.org" , "avtext-chairs@ietf.org" , "draft-ietf-avtext-rtp-stream-pause@ietf.org" , The IESG , "draft-ietf-avtext-rtp-stream-pause.ad@ietf.org" , "draft-ietf-avtext-rtp-stream-pause.shepherd@ietf.org" Subject: Re: [avtext] Spencer Dawkins' Yes on draft-ietf-avtext-rtp-stream-pause-08: (with COMMENT) X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Aug 2015 12:36:56 -0000 --001a11c2ce3850a9d4051e4a386f Content-Type: text/plain; charset=UTF-8 Hi, Bo, On Thu, Aug 27, 2015 at 6:28 AM, Bo Burman wrote: > Thank you for good and constructive comments. Please find responses to > your questions inline below. > Cheers, > Bo > > > -----Original Message----- > > From: Spencer Dawkins [mailto:spencerdawkins.ietf@gmail.com] > > Sent: den 19 augusti 2015 05:17 > > To: The IESG > > Cc: draft-ietf-avtext-rtp-stream-pause@ietf.org; > draft-ietf-avtext-rtp-stream-pause.ad@ietf.org; jonathan@vidyo.com; > > draft-ietf-avtext-rtp-stream-pause.shepherd@ietf.org; > avtext-chairs@ietf.org; avtext@ietf.org > > Subject: Spencer Dawkins' Yes on draft-ietf-avtext-rtp-stream-pause-08: > (with COMMENT) > > > > Spencer Dawkins has entered the following ballot position for > > draft-ietf-avtext-rtp-stream-pause-08: Yes > > > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. > > (Feel free to cut this introductory paragraph, however.) > > > > > > Please refer to > https://www.ietf.org/iesg/statement/discuss-criteria.html > > for more information about IESG DISCUSS and COMMENT positions. > > > > > > The document, along with other ballot positions, can be found here: > > https://datatracker.ietf.org/doc/draft-ietf-avtext-rtp-stream-pause/ > > > > > > > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > > This draft was really easy for me to read (with some background in > RTP/RTCP, but I'm no expert on the topic). Thank you > > for the work on it - the results show. > > > > I have some questions, but nothing is a show-stopper. > > > > In this text: > > > > 3.3. RTP Mixer to Media Sender in Point-to-Multipoint > > > > In this use case there are several receivers of a stream and special > > care must be taken as not to pause a stream that is still wanted by > > some receivers. > > > > I'm assuming that the Mixer is taking special care, but this is passive > enough that I'm filling in blanks. If you like passive > > voice, perhaps something like > > > > In this use case there are several receivers of a stream and special > > care must be taken by the Mixer so as not to pause a stream that is > > ^^^^^^^^^^^^^^^ > > still wanted by some receivers. > > > > would be easier to parse. > > > > If you can do active voice, perhaps > > > > In this use case there are several receivers of a stream and the > > Mixer must take special care so as not to pause a stream that is still > > > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > wanted by some receivers. > [BoB] Thanks, your assumption is correct, and I think this active voice is > easier to read. Great. > > > > In this text: > > > > 8. Message Details > > > > Any references to PAUSE, PAUSED, RESUME and REFUSED in this section > > SHALL be taken to apply to the extent possible also when TMMBR/TMMBN > > are used (Section 5.6) for this functionality. TMMBR/TMMBN MAY be > > ^^^ > > used instead of the messages defined in this specification when the > > effective topology is point-to-point. If either sender or receiver > > learns that the topology is not point-to-point, TMMBR/TMMBN MUST NOT > > be used for pause/resume functionality. If the messages defined in > > this specification are supported in addition to TMMBR/TMMBN by all > > involved parties, pause/resume signaling MUST use messages from this > > specification. If the topology is not point-to-point and the > > messages defined in this specification are not supported, pause/ > > resume functionality with TMMBR/TMMBN MUST NOT be used. > > > > All of this makes sense to me, except that I'm not understanding why > TMMBR/TMMBN is a MAY. There's a lot of text that > > says you really need to use the messages from this specification in this > case, and in that case, and ... but here, you MAY > > do something else. > > > > I understand that TMMBR/TMMBN works in a point-to-point topology, but is > there a reason to prefer TMMBR/TMMBN > > in that topology? If so, it would probably be good to explain why. > > > > And as I read futher, I see this, in section 9: > > > > Note: When TMMBR 0 / TMMBN 0 are used to implement pause and > > resume functionality (with the restrictions described in this > > specification), signaling rtcp-fb attribute with ccm tmmbr > > parameter is sufficient and no further signaling is necessary. > > There is however no guarantee that TMMBR/TMMBN implementations > > ^^^^^^^^^^^^ > > pre-dating this specification work exactly as described here when > > used with a bitrate value of 0. > > > > and that really makes me wonder why this specification is also > describing TMMBR/TMMBN. I'm sure there's a good > > reason, but can you understand my confusion? > > > > Finally, I see this, in section 9.1, > > > > If both "pause" and "tmmbr" are present in the offer, both MAY be > > included also in the answer, in which case TMMBR/TMMBN MUST NOT be > > used for pause/resume purposes (with a bitrate value of 0), to avoid > > signaling ambiguity. > > > > and in section 9.2, > > > > If both "pause" and "tmmbr" are present in the SDP, TMMBR/TMMBN MUST > > NOT be used for pause/resume purposes (with a bitrate value of 0), to > > avoid signaling ambiguity. > > > > I'm now wondering if the description of TMMBR/TMMBN in this > specification just for interworking with older > > implementations that don't support PAUSE/RESUME but figured out how to > get a similar effect with TMMBR/TMMBN? > > > > I'm guessing, of course :-) > [BoB] Your guess is correct. This is hinted already with the last two > sentences in the Introduction section "The Temporary Maximum Media Bitrate > Request (TMMBR) message of CCM is used by video conferencing systems for > flow control. It is desirable to be able to use that method with a bitrate > value of zero for pause, whenever possible". Do you think this needs to be > more explicitly stated, maybe in section 5.6 on TMMBR/TMMBN considerations? > Say, something similar to what you said above: "This use is expected to be > mainly for interworking with implementations that don't support > PAUSE/RESUME, but make use of TMMBR/TMMBN to achieve a similar effect". Do > you think something needs to be said in section 8 too? I do think that short explanations about motivation are helpful. > > > > In this text: > > > > 8.5. Transmission Rules > > > > o PAUSE SHOULD use Early or Immediate timing, except for > > retransmissions that SHOULD use Regular timing. > > > > ^ I understand this one. > > > > o The first transmission of PAUSED for each (non-wrapped) PauseID > > SHOULD be sent with Immediate or Early timing, while subsequent > > PAUSED for that PauseID SHOULD use Regular timing. Unsolicited > > PAUSED (sent when entering Local Paused State (Section 6.4)) > > SHOULD always use Immediate or Early timing, until PAUSED for that > > PauseID is considered delivered at least once to all receivers of > > the paused RTP stream, after which it SHOULD use Regular timing. > > > > ^ I'm wondering why these are SHOULDs. Are they MUSTs except that some > implementations don't do it, or > > recommendations but nothing breaks if you don't do them, or something > else? > [BoB] It is recommendations, meaning that if you don't follow them, > nothing will really break, but you'll get worse performance in one way or > the other. The SHOULDs for Early or Immediate is to provide good timeliness > and responsiveness of the application making use of the messages, while the > SHOULDs for Regular are to avoid excessive bandwidth consumption. > > > > > o RESUME SHOULD always use Immediate or Early timing. > > > > ^ I wonder why this is SHOULD. Is there any guidance you can provide > about why RESUME would use Regular timing? > [BoB] The only case I can come to think of is when other RTCP messages > used by the application layer (not PAUSE/RESUME) are somehow considered > more important than resuming media streams in that specific application > context. Again, nothing would really break with regular timing, but > performance would certainly suffer badly. Maybe such application-level > consideration is sufficiently "extreme" that it is motivated changing to a > MUST, forcing such situations to break compliance? > > > > > o The first transmission of REFUSED for each (non-wrapped) PauseID > > SHOULD be sent with Immediate or Early timing, while subsequent > > REFUSED for that PauseID SHOULD use Regular timing. > > > > ^ I am, of course, wondering about the corresponding SHOULDs for REFUSED. > [BoB] Timely transmission of REFUSED can stop unnecessary repetitions of > PAUSE or RESUME, which I believe motivates recommending Immediate or Early > for the first transmission to save some RTCP bandwidth. That is however not > considered critical enough to motivate recommending repetitions of the same > indication to be sent with other than Regular timing. Nothing would break > if repetitions are sent with Early or Immediate timing, but it would > potentially waste some transmission opportunities for other RTCP (FB) > messages. Do you think it motivated to add more text on such considerations? I'd have a preference for text that explains the strategy, rather than using RFC 2119 language when this isn't actually about interworking. > > > > In this text: > > > > 9. Signaling > > > > When signaling a config value other than 1, an implementation MUST > > ignore non-supported messages on reception, and MAY omit sending non- > > supported messages. > > > > is this saying that an implementation might send non-supported messages? > > I'm confused here. > [BoB] That should have been "... MAY omit sending messages not supported > by the remote peer". I realize that further down it is said "... SHOULD NOT > be used towards receivers that did not declare capability to receive those > messages", so I guess that MAY should be changed to a SHOULD to be > consistent. In any case, not having MUSTs here allows a mix of different > capabilities among receivers in a multi-receiver case without letting the > least capable receiver set the level of P/R functionality for all the > others. With that in mind, do you think "SHOULD omit" is a too strong > wording? > Making it clear who isn't supporting the non-supported messages seems helpful. I'd be OK with either MAY or SHOULD in both places (you guys are the experts), but it sounds like they should match. Thanks! Spencer --001a11c2ce3850a9d4051e4a386f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi, Bo,

On Thu, Aug 27, 2015 at 6:28 AM, Bo Burman <= ;bo.burman@eric= sson.com> wrote:
Thank yo= u for good and constructive comments. Please find responses to your questio= ns inline below.
Cheers,
Bo

> -----Original Message-----
> From: Spencer Dawkins [mailto:spencerdawkins.ietf@gmail.com]
> Sent: den 19 augusti 2015 05:17
> To: The IESG
> Cc: dra= ft-ietf-avtext-rtp-stream-pause@ietf.org; draft-ietf-avtext-rtp-stream-pause.ad@= ietf.org; jonathan@vidyo.com;=
> draft-ietf-avtext-rtp-stream-pause.shepherd@ietf.org; avtext-chairs@ietf.org; avtext@ietf.org
> Subject: Spencer Dawkins' Yes on draft-ietf-avtext-rtp-stream-paus= e-08: (with COMMENT)
>
> Spencer Dawkins has entered the following ballot position for
> draft-ietf-avtext-rtp-stream-pause-08: Yes
>
> When responding, please keep the subject line intact and reply to all = email addresses included in the To and CC lines.
> (Feel free to cut this introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/i= esg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here: > https://datatracker.ietf.or= g/doc/draft-ietf-avtext-rtp-stream-pause/
>
>
>
> ----------------------------------------------------------------------=
> COMMENT:
> ----------------------------------------------------------------------=
>
> This draft was really easy for me to read (with some background in RTP= /RTCP, but I'm no expert on the topic). Thank you
> for the work on it - the results show.
>
> I have some questions, but nothing is a show-stopper.
>
> In this text:
>
> 3.3.=C2=A0 RTP Mixer to Media Sender in Point-to-Multipoint
>
>=C2=A0 =C2=A0 In this use case there are several receivers of a stream = and special
>=C2=A0 =C2=A0 care must be taken as not to pause a stream that is still= wanted by
>=C2=A0 =C2=A0 some receivers.
>
> I'm assuming that the Mixer is taking special care, but this is pa= ssive enough that I'm filling in blanks. If you like passive
> voice, perhaps something like
>
>=C2=A0 =C2=A0 In this use case there are several receivers of a stream = and special
>=C2=A0 =C2=A0 care must be taken by the Mixer so as not to pause a stre= am that is
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0^^^^^^^^^^^^^^^
>=C2=A0 =C2=A0 still wanted by some receivers.
>
> would be easier to parse.
>
> If you can do active voice, perhaps
>
>=C2=A0 =C2=A0 In this use case there are several receivers of a stream = and the
>=C2=A0 =C2=A0 Mixer must take special care so as not to pause a stream = that is still
>
>=C2=A0 =C2=A0 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>=C2=A0 =C2=A0 wanted by some receivers.
[BoB] Thanks, your assumption is correct, and I think this acti= ve voice is easier to read.

Great.
=C2=A0
>
> In this text:
>
> 8.=C2=A0 Message Details
>
>=C2=A0 =C2=A0 Any references to PAUSE, PAUSED, RESUME and REFUSED in th= is section
>=C2=A0 =C2=A0 SHALL be taken to apply to the extent possible also when = TMMBR/TMMBN
>=C2=A0 =C2=A0 are used (Section 5.6) for this functionality.=C2=A0 TMMB= R/TMMBN MAY be
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 ^^^
>=C2=A0 =C2=A0 used instead of the messages defined in this specificatio= n when the
>=C2=A0 =C2=A0 effective topology is point-to-point.=C2=A0 If either sen= der or receiver
>=C2=A0 =C2=A0 learns that the topology is not point-to-point, TMMBR/TMM= BN MUST NOT
>=C2=A0 =C2=A0 be used for pause/resume functionality.=C2=A0 If the mess= ages defined in
>=C2=A0 =C2=A0 this specification are supported in addition to TMMBR/TMM= BN by all
>=C2=A0 =C2=A0 involved parties, pause/resume signaling MUST use message= s from this
>=C2=A0 =C2=A0 specification.=C2=A0 If the topology is not point-to-poin= t and the
>=C2=A0 =C2=A0 messages defined in this specification are not supported,= pause/
>=C2=A0 =C2=A0 resume functionality with TMMBR/TMMBN MUST NOT be used. >
> All of this makes sense to me, except that I'm not understanding w= hy TMMBR/TMMBN is a MAY. There's a lot of text that
> says you really need to use the messages from this specification in th= is case, and in that case, and ... but here, you MAY
> do something else.
>
> I understand that TMMBR/TMMBN works in a point-to-point topology, but = is there a reason to prefer TMMBR/TMMBN
> in that topology? If so, it would probably be good to explain why.
>
> And as I read futher, I see this, in section 9:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Note: When TMMBR 0 / TMMBN 0 are used to imp= lement pause and
>=C2=A0 =C2=A0 =C2=A0 =C2=A0resume functionality (with the restrictions = described in this
>=C2=A0 =C2=A0 =C2=A0 =C2=A0specification), signaling rtcp-fb attribute = with ccm tmmbr
>=C2=A0 =C2=A0 =C2=A0 =C2=A0parameter is sufficient and no further signa= ling is necessary.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0There is however no guarantee that TMMBR/TMM= BN implementations
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 ^^^^^^^^^^^^
>=C2=A0 =C2=A0 =C2=A0 =C2=A0pre-dating this specification work exactly a= s described here when
>=C2=A0 =C2=A0 =C2=A0 =C2=A0used with a bitrate value of 0.
>
> and that really makes me wonder why this specification is also describ= ing TMMBR/TMMBN. I'm sure there's a good
> reason, but can you understand my confusion?
>
> Finally, I see this, in section 9.1,
>
>=C2=A0 =C2=A0 If both "pause" and "tmmbr" are prese= nt in the offer, both MAY be
>=C2=A0 =C2=A0 included also in the answer, in which case TMMBR/TMMBN MU= ST NOT be
>=C2=A0 =C2=A0 used for pause/resume purposes (with a bitrate value of 0= ), to avoid
>=C2=A0 =C2=A0 signaling ambiguity.
>
> and in section 9.2,
>
>=C2=A0 =C2=A0 If both "pause" and "tmmbr" are prese= nt in the SDP, TMMBR/TMMBN MUST
>=C2=A0 =C2=A0 NOT be used for pause/resume purposes (with a bitrate val= ue of 0), to
>=C2=A0 =C2=A0 avoid signaling ambiguity.
>
> I'm now wondering if the description of TMMBR/TMMBN in this specif= ication just for interworking with older
> implementations that don't support PAUSE/RESUME but figured out ho= w to get a similar effect with TMMBR/TMMBN?
>
> I'm guessing, of course :-)
[BoB] Your guess is correct. This is hinted already with the la= st two sentences in the Introduction section "The Temporary Maximum Me= dia Bitrate Request (TMMBR) message of CCM is used by video conferencing sy= stems for flow control. It is desirable to be able to use that method with = a bitrate value of zero for pause, whenever possible". Do you think th= is needs to be more explicitly stated, maybe in section 5.6 on TMMBR/TMMBN = considerations? Say, something similar to what you said above: "This u= se is expected to be mainly for interworking with implementations that don&= #39;t support PAUSE/RESUME, but make use of TMMBR/TMMBN to achieve a simila= r effect". Do you think something needs to be said in section 8 too?

I do think that short explanations about mot= ivation are helpful.
=C2=A0
<= span class=3D"">>
> In this text:
>
> 8.5.=C2=A0 Transmission Rules
>
>=C2=A0 =C2=A0 o=C2=A0 PAUSE SHOULD use Early or Immediate timing, excep= t for
>=C2=A0 =C2=A0 =C2=A0 =C2=A0retransmissions that SHOULD use Regular timi= ng.
>
> ^ I understand this one.
>
>=C2=A0 =C2=A0 o=C2=A0 The first transmission of PAUSED for each (non-wr= apped) PauseID
>=C2=A0 =C2=A0 =C2=A0 =C2=A0SHOULD be sent with Immediate or Early timin= g, while subsequent
>=C2=A0 =C2=A0 =C2=A0 =C2=A0PAUSED for that PauseID SHOULD use Regular t= iming.=C2=A0 Unsolicited
>=C2=A0 =C2=A0 =C2=A0 =C2=A0PAUSED (sent when entering Local Paused Stat= e (Section 6.4))
>=C2=A0 =C2=A0 =C2=A0 =C2=A0SHOULD always use Immediate or Early timing,= until PAUSED for that
>=C2=A0 =C2=A0 =C2=A0 =C2=A0PauseID is considered delivered at least onc= e to all receivers of
>=C2=A0 =C2=A0 =C2=A0 =C2=A0the paused RTP stream, after which it SHOULD= use Regular timing.
>
> ^ I'm wondering why these are SHOULDs. Are they MUSTs except that = some implementations don't do it, or
> recommendations but nothing breaks if you don't do them, or someth= ing else?
[BoB] It is recommendations, meaning that if you don't follow th= em, nothing will really break, but you'll get worse performance in one = way or the other. The SHOULDs for Early or Immediate is to provide good tim= eliness and responsiveness of the application making use of the messages, w= hile the SHOULDs for Regular are to avoid excessive bandwidth consumption.<= br>
>
>=C2=A0 =C2=A0 o=C2=A0 RESUME SHOULD always use Immediate or Early timin= g.
>
> ^ I wonder why this is SHOULD. Is there any guidance you can provide a= bout why RESUME would use Regular timing?
[BoB] The only case I can come to think of is when other RTCP messag= es used by the application layer (not PAUSE/RESUME) are somehow considered = more important than resuming media streams in that specific application con= text. Again, nothing would really break with regular timing, but performanc= e would certainly suffer badly. Maybe such application-level consideration = is sufficiently "extreme" that it is motivated changing to a MUST= , forcing such situations to break compliance?

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

I'd have a preference for text that explai= ns the strategy, rather than using RFC 2119 language when this isn't ac= tually about interworking.
=C2=A0
>
> In this text:
>
> 9.=C2=A0 Signaling
>
>=C2=A0 =C2=A0 When signaling a config value other than 1, an implementa= tion MUST
>=C2=A0 =C2=A0 ignore non-supported messages on reception, and MAY omit = sending non-
>=C2=A0 =C2=A0 supported messages.
>
> is this saying that an implementation might send non-supported message= s?
> I'm confused here.
[BoB] That should have been "... MAY omit sending messages not = supported by the remote peer". I realize that further down it is said = "... SHOULD NOT be used towards receivers that did not declare capabil= ity to receive those messages", so I guess that MAY should be changed = to a SHOULD to be consistent. In any case, not having MUSTs here allows a m= ix of different capabilities among receivers in a multi-receiver case witho= ut letting the least capable receiver set the level of P/R functionality fo= r all the others. With that in mind, do you think "SHOULD omit" i= s a too strong wording?

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

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

Thanks!

Spencer=C2=A0
--001a11c2ce3850a9d4051e4a386f-- From nobody Thu Aug 27 23:47:46 2015 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BE351A8AD3; Thu, 27 Aug 2015 23:47:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D6KtaB49TeJI; Thu, 27 Aug 2015 23:47:43 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 297931A893E; Thu, 27 Aug 2015 23:47:42 -0700 (PDT) X-AuditID: c1b4fb3a-f79136d0000071e2-0c-55e0040c5754 Received: from ESESSHC010.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 2A.85.29154.C0400E55; Fri, 28 Aug 2015 08:47:40 +0200 (CEST) Received: from ESESSMB105.ericsson.se ([169.254.5.220]) by ESESSHC010.ericsson.se ([153.88.183.48]) with mapi id 14.03.0210.002; Fri, 28 Aug 2015 08:47:39 +0200 From: Bo Burman To: Stephen Farrell , The IESG Thread-Topic: Stephen Farrell's No Objection on draft-ietf-avtext-rtp-stream-pause-08: (with COMMENT) Thread-Index: AQHQ2qA51HvdBzK24U+/hIaK31v0RJ4fxYNw Date: Fri, 28 Aug 2015 06:47:38 +0000 Message-ID: References: <20150819165804.2051.78164.idtracker@ietfa.amsl.com> In-Reply-To: <20150819165804.2051.78164.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.17] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupjkeLIzCtJLcpLzFFi42KZGfG3RpeH5UGowcE5whbt506wWHy8d4PV YumsLlaL3Tcms1h0vdzBbDHjz0Rmi/2LzzNbTN97jd2Bw2Nt91U2jyVLfjJ5tD27wx7AHMVl k5Kak1mWWqRvl8CVcep2B3PBOaWK+WeWMDYw3lHsYuTkkBAwkVhxYhsThC0mceHeerYuRi4O IYGjjBI7pixhgnCWMEocb73DBlLFJqAhMX/HXUYQW0TAU+Jh3ykWkCJmgUPMEhN3nGfvYuTg EBZIkzj02AKiJl3ie89SdgjbSKK/dTfYHBYBVYmew6tYQGxeAV+JrcdPMoPYQgIOEguWzACb zyngKHF7ylEwm1FAVuL+93tg9cwC4hK3nsyHulpAYsme88wQtqjEy8f/WEFOkBBQlFjeLwdi MgtoSqzfpQ/RqSgxpfshO8RWQYmTM5+wTGAUm4Vk6CyEjllIOmYh6VjAyLKKUbQ4tbg4N93I SC+1KDO5uDg/Ty8vtWQTIzACD275bbWD8eBzx0OMAhyMSjy8Cw7cDxViTSwrrsw9xCjNwaIk ztvM9CBUSCA9sSQ1OzW1ILUovqg0J7X4ECMTB6dUAyPTpnBR02neq05EdXr8VKqe8KzUruSM xt2a1Uf8Zzxtqyl7IJcpzMjmkBet3cHcrTtHVSVdac6RBW/37Xma0zhDjo//99UVV6ubjJ40 tpy9929NuJCB+vMUgfLIxu5osddOc65PM2DKMtjdxr3rc9tlvwMTtSZoGG97uY1lPd+8jwYS 62/sfqvEUpyRaKjFXFScCABUDUjnoQIAAA== Archived-At: Cc: "jonathan@vidyo.com" , "avtext@ietf.org" , "avtext-chairs@ietf.org" , "draft-ietf-avtext-rtp-stream-pause@ietf.org" , "draft-ietf-avtext-rtp-stream-pause.ad@ietf.org" , "draft-ietf-avtext-rtp-stream-pause.shepherd@ietf.org" Subject: Re: [avtext] Stephen Farrell's No Objection on draft-ietf-avtext-rtp-stream-pause-08: (with COMMENT) X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Aug 2015 06:47:45 -0000 UGxlYXNlIGZpbmQgbXkgcmVzcG9uc2VzIHRvIHlvdXIgY29tbWVudHMgaW5saW5lIGJlbG93Lg0K Q2hlZXJzLA0KQm8NCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBTdGVw aGVuIEZhcnJlbGwgW21haWx0bzpzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllXQ0KPiBTZW50OiBk ZW4gMTkgYXVndXN0aSAyMDE1IDE4OjU4DQo+IFRvOiBUaGUgSUVTRw0KPiBDYzogZHJhZnQtaWV0 Zi1hdnRleHQtcnRwLXN0cmVhbS1wYXVzZUBpZXRmLm9yZzsgZHJhZnQtaWV0Zi1hdnRleHQtcnRw LXN0cmVhbS1wYXVzZS5hZEBpZXRmLm9yZzsgam9uYXRoYW5AdmlkeW8uY29tOw0KPiBkcmFmdC1p ZXRmLWF2dGV4dC1ydHAtc3RyZWFtLXBhdXNlLnNoZXBoZXJkQGlldGYub3JnOyBhdnRleHQtY2hh aXJzQGlldGYub3JnOyBhdnRleHRAaWV0Zi5vcmcNCj4gU3ViamVjdDogU3RlcGhlbiBGYXJyZWxs J3MgTm8gT2JqZWN0aW9uIG9uIGRyYWZ0LWlldGYtYXZ0ZXh0LXJ0cC1zdHJlYW0tcGF1c2UtMDg6 ICh3aXRoIENPTU1FTlQpDQo+IA0KPiBTdGVwaGVuIEZhcnJlbGwgaGFzIGVudGVyZWQgdGhlIGZv bGxvd2luZyBiYWxsb3QgcG9zaXRpb24gZm9yDQo+IGRyYWZ0LWlldGYtYXZ0ZXh0LXJ0cC1zdHJl YW0tcGF1c2UtMDg6IE5vIE9iamVjdGlvbg0KPiANCj4gV2hlbiByZXNwb25kaW5nLCBwbGVhc2Ug a2VlcCB0aGUgc3ViamVjdCBsaW5lIGludGFjdCBhbmQgcmVwbHkgdG8gYWxsIGVtYWlsIGFkZHJl c3NlcyBpbmNsdWRlZCBpbiB0aGUgVG8gYW5kIENDIGxpbmVzLg0KPiAoRmVlbCBmcmVlIHRvIGN1 dCB0aGlzIGludHJvZHVjdG9yeSBwYXJhZ3JhcGgsIGhvd2V2ZXIuKQ0KPiANCj4gDQo+IFBsZWFz ZSByZWZlciB0byBodHRwczovL3d3dy5pZXRmLm9yZy9pZXNnL3N0YXRlbWVudC9kaXNjdXNzLWNy aXRlcmlhLmh0bWwNCj4gZm9yIG1vcmUgaW5mb3JtYXRpb24gYWJvdXQgSUVTRyBESVNDVVNTIGFu ZCBDT01NRU5UIHBvc2l0aW9ucy4NCj4gDQo+IA0KPiBUaGUgZG9jdW1lbnQsIGFsb25nIHdpdGgg b3RoZXIgYmFsbG90IHBvc2l0aW9ucywgY2FuIGJlIGZvdW5kIGhlcmU6DQo+IGh0dHBzOi8vZGF0 YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtYXZ0ZXh0LXJ0cC1zdHJlYW0tcGF1c2Uv DQo+IA0KPiANCj4gDQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gQ09NTUVOVDoNCj4gLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LQ0KPiANCj4gDQo+IC0gNTggcGFnZXMhIFRoZXJlIGlzIHF1aXRlIGEgYml0IG9mIHJlcGV0aXRp b24gaGVyZSBidXQgdG9vIGxhdGUgdG8gY2hhbmdlIG5vdy4NCj4gDQo+IC0gSSBzZWUgdGhlcmUg YXJlIDIgSVBSIGRlY2xhcmF0aW9ucywgYm90aCB3aXRoIHBvc3NpYmxlIHJveWFsdHkvZmVlIGFu ZCBuZWl0aGVyIHRoYXQgSSBjYW4gc2VlIGFjdHVhbGx5IHNwZWNpZnlpbmcgd2hhdA0KPiBwYXRl bnQgKG9yIG90aGVyIHByb3BlcnR5KSBpcyBpbnZvbHZlZCBkZXNwaXRlIGJvdGggZGVjbGFyYXRp b25zIGJlaW5nIHNvbWUgeWVhcnMgb2xkLiAgKEFuZCB0aGVyZSB3YXMgbWUgdGhpbmtpbmcNCj4g cmVtb3RlIGNvbnRyb2xzIHdlcmUgYWxtb3N0IG9sZGVyIHRoYW4gbWUsIGJ1dCBJIGd1ZXNzIHdo YXQgZG8gSSBrbm93IGFuZCB0aGUgVVNQVE8gbXVzdCBhbHdheXMgYmUgcmlnaHQ7LSkgQW55d2F5 LA0KPiBjYW4gc29tZW9uZSBwb2ludCBtZSBhdCB3aGVyZSB0aGUgd29ya2luZyBncm91cCBzYWlk IHRoZXkgd2VyZSBvayB3aXRoIHRoaXMgc2l0dWF0aW9uPyAgKFRoZSBzaGVwaGVyZCB3cml0ZSB1 cCBzYXlzDQo+IHRoYXQgaGFwcGVuZWQgc28gSSBob3BlIGl0J3Mgbm90IGhhcmQgdG8gZ2V0IHRo YXQgcG9pbnRlci4pDQpbQm9CXSBUaGF0IGF0IGxlYXN0IGhhcHBlbmVkIHdoZW4gdGhlIGRyYWZ0 IHdhcyBhZG9wdGVkIGFzIGEgV0cgZHJhZnQsIGF0IElFVEYgODggQVZURVhUIHNlc3Npb24gaW4g QmVybGluOg0KaHR0cDovL3d3dy5pZXRmLm9yZy9wcm9jZWVkaW5ncy84OS9taW51dGVzL21pbnV0 ZXMtODktYXZ0ZXh0DQoNCj4gDQo+IC0gU2VjdGlvbiA3OiBpbiBhIG11bHRpcGFydHkgY2FsbCwg c2F5IHBhcnRpY2lwYW50IzEgaGl0cyBwYXVzZSB3aXRoIFBhdXNlSUQgPSAweDAwMDEsIGFuZCBz dHVmZiBpcyByZXN1bWVkIHNvbWUgdGltZSBsYXRlciwNCj4gaXMgcGFydGljaXBhbnQjMiBzdXBw b3NlZCB0byB1c2UgYSBQYXVzZUlEIG9mIDB4MDAwMiBzdWJzZXF1ZW50bHk/IA0KW0JvQl0gWWVz Lg0KDQpJbiBvdGhlciB3b3JkcyBkb2VzIHRoZSBTSEFMTCB0aGVyZSBhcHBseSB0bw0KPiBldmVy eW9uZSBvbiB0aGUgY2FsbCBvciBqdXN0IHRvIHRoZSBwYXJ0aWNpcGFudCB3aG8gc2VudCBvdXQg dGhlIGxhc3QgUEFVU0UgbWVzc2FnZT8gIA0KW0JvQl0gSXQgYXBwbGllcyB0byBldmVyeW9uZSBp biB0aGUgUlRQIHNlc3Npb24uDQoNCklmIHRoZSBmb3JtZXIsIGRvZXMgdGhhdCBjcmVhdGUgYQ0K PiByYWNlIGNvbmRpdGlvbj8gT3IgbWF5YmUgdGhhdCdzIGEgaGFybWxlc3MgcmFjZT8gDQpbQm9C XSBJIHdvdWxkIG5vdCBzYXkgaXQgaXMgYSByYWNlLCBhbmQgaXQgaXMgaW4gYW55IGNhc2UgaGFy bWxlc3MuIElmIG1vcmUgdGhhbiBvbmUgcGFydGljaXBhbnQgc2VuZHMgYSBQQVVTRSB3aXRoIHRo ZSBzYW1lIChjdXJyZW50KSBQYXVzZUlELCB0aGUgUlRQIHN0cmVhbSBzZW5kZXIgd2lsbCBpZ25v cmUgYWxsIGJ1dCB0aGUgZmlyc3QgaXQgcmVjZWl2ZXMgKGxhc3Qgc2VudGVuY2Ugb2Ygc2VjdGlv biA4LjEpLg0KDQpJIGd1ZXNzIHlvdSBjb3VsZCByZWR1Y2UgdGhlIHByb2JhYmlsaXR5IG9mIGEg cmFjZSBieSByZWNvbW1lbmRpbmcNCj4gdGhhdCBQYXVzZUlEIGJlIHJhbmRvbWx5IHNlbGVjdGVk IGJldHdlZW4gbGFzdC1QYXVzZUlELXNlZW4gYW5kDQo+IGxhc3QtUGF1c2VJRC1zZWVuKygyXjE0 KSBvciBzb21ldGhpbmcgbGlrZSB0aGF0PyAgKEFuZA0KPiBhcG9sb2dpZXMgaWYgYWxsIHRoaXMg aXMgb2J2aW91cyB0byBzb21lb25lIGV4cGVydCBpbiBSVFAsIEkgYW0gbm90IHRoYXQgcGVyc29u Oi0pDQo+IA0KW0JvQl0gVGhlcmUgaXMgbm8gcmFjZSwgc28gZXZlbiBpZiBzdWNoIGFwcHJvYWNo IHdvdWxkIGxpa2VseSB3b3JrLCBpdCBpcyBub3QgbmVjZXNzYXJ5Lg0KDQo= From nobody Fri Aug 28 02:34:12 2015 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1B901A039A; Fri, 28 Aug 2015 02:34:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, 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 CMTFFspVUbWY; Fri, 28 Aug 2015 02:34:09 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E0E51ACEBE; Fri, 28 Aug 2015 02:34:09 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 404E1BE7B; Fri, 28 Aug 2015 10:34:07 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j_giOvKt8ZQF; Fri, 28 Aug 2015 10:34:05 +0100 (IST) Received: from [10.87.48.73] (unknown [86.46.29.89]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 44744BE75; Fri, 28 Aug 2015 10:34:05 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1440754445; bh=7ki0pKm8QJonTPtlIFHatIZaEkk1PebauRJKZc+pOtM=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=wLTRITiZJpZYSP0eREuallb3j/LYa97v1p+KF/iwOSxTlkPaBBaS3JXSRMqWPXl/l NteOrXZGggYyC49u0v/P8M6UusAWMHKm/C3vli051NUn622ctXByJuhzRM9KGSUbSo yudCoq/Y/INt9yoGst4GQAfuAXbOdJUA7rN1ePCg= To: Bo Burman , The IESG References: <20150819165804.2051.78164.idtracker@ietfa.amsl.com> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <55E02B0C.4050406@cs.tcd.ie> Date: Fri, 28 Aug 2015 10:34:04 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "jonathan@vidyo.com" , "avtext@ietf.org" , "avtext-chairs@ietf.org" , "draft-ietf-avtext-rtp-stream-pause@ietf.org" , "draft-ietf-avtext-rtp-stream-pause.ad@ietf.org" , "draft-ietf-avtext-rtp-stream-pause.shepherd@ietf.org" Subject: Re: [avtext] Stephen Farrell's No Objection on draft-ietf-avtext-rtp-stream-pause-08: (with COMMENT) X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Aug 2015 09:34:11 -0000 Hiya, Those are all fine, for this document. Thanks, S. On 28/08/15 07:47, Bo Burman wrote: > Please find my responses to your comments inline below. > Cheers, > Bo > >> -----Original Message----- >> From: Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie] >> Sent: den 19 augusti 2015 18:58 >> To: The IESG >> Cc: draft-ietf-avtext-rtp-stream-pause@ietf.org; draft-ietf-avtext-rtp-stream-pause.ad@ietf.org; jonathan@vidyo.com; >> draft-ietf-avtext-rtp-stream-pause.shepherd@ietf.org; avtext-chairs@ietf.org; avtext@ietf.org >> Subject: Stephen Farrell's No Objection on draft-ietf-avtext-rtp-stream-pause-08: (with COMMENT) >> >> Stephen Farrell has entered the following ballot position for >> draft-ietf-avtext-rtp-stream-pause-08: No Objection >> >> When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. >> (Feel free to cut this introductory paragraph, however.) >> >> >> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html >> for more information about IESG DISCUSS and COMMENT positions. >> >> >> The document, along with other ballot positions, can be found here: >> https://datatracker.ietf.org/doc/draft-ietf-avtext-rtp-stream-pause/ >> >> >> >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> >> - 58 pages! There is quite a bit of repetition here but too late to change now. >> >> - I see there are 2 IPR declarations, both with possible royalty/fee and neither that I can see actually specifying what >> patent (or other property) is involved despite both declarations being some years old. (And there was me thinking >> remote controls were almost older than me, but I guess what do I know and the USPTO must always be right;-) Anyway, >> can someone point me at where the working group said they were ok with this situation? (The shepherd write up says >> that happened so I hope it's not hard to get that pointer.) > [BoB] That at least happened when the draft was adopted as a WG draft, at IETF 88 AVTEXT session in Berlin: > http://www.ietf.org/proceedings/89/minutes/minutes-89-avtext > >> >> - Section 7: in a multiparty call, say participant#1 hits pause with PauseID = 0x0001, and stuff is resumed some time later, >> is participant#2 supposed to use a PauseID of 0x0002 subsequently? > [BoB] Yes. > > In other words does the SHALL there apply to >> everyone on the call or just to the participant who sent out the last PAUSE message? > [BoB] It applies to everyone in the RTP session. > > If the former, does that create a >> race condition? Or maybe that's a harmless race? > [BoB] I would not say it is a race, and it is in any case harmless. If more than one participant sends a PAUSE with the same (current) PauseID, the RTP stream sender will ignore all but the first it receives (last sentence of section 8.1). > > I guess you could reduce the probability of a race by recommending >> that PauseID be randomly selected between last-PauseID-seen and >> last-PauseID-seen+(2^14) or something like that? (And >> apologies if all this is obvious to someone expert in RTP, I am not that person:-) >> > [BoB] There is no race, so even if such approach would likely work, it is not necessary. > From nobody Fri Aug 28 05:30: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 6CF8E1B2AF6; Fri, 28 Aug 2015 05:30:09 -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 HFWCCBrcx8vQ; Fri, 28 Aug 2015 05:30:07 -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 8AC401ACD2F; Fri, 28 Aug 2015 05:30:00 -0700 (PDT) X-AuditID: c1b4fb2d-f79626d000004282-8f-55e054455636 Received: from ESESSHC009.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 7A.E0.17026.54450E55; Fri, 28 Aug 2015 14:29:57 +0200 (CEST) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.47) with Microsoft SMTP Server id 14.3.210.2; Fri, 28 Aug 2015 14:29:56 +0200 To: Barry Leiba , The IESG References: <20150819193730.2872.16228.idtracker@ietfa.amsl.com> From: Magnus Westerlund Message-ID: <55E05444.2030502@ericsson.com> Date: Fri, 28 Aug 2015 14:29:56 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: <20150819193730.2872.16228.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrJLMWRmVeSWpSXmKPExsUyM+Jvja5ryINQg0X3LC3az51gsfh47war xaHFl1gtls7qYrXYfWMyi0XXyx3MFjP+TGS22L/4PLMDh0fLql5mjyVLfjJ5tD27wx7AHMVl k5Kak1mWWqRvl8CVcbRlLWPBdb6KKaduMzYwfuXuYuTkkBAwkTi55AArhC0mceHeerYuRi4O IYGjjBK9f85BOcsZJdrnfmMHqRIWSJI4fauVGcQWEXCWeHPpDxOILSTgILGz9x07SAOzwBNG iedXO8DGsglYSNz80cgGYvMKaEv8774DNohFQFXiVvdKsGZRgRiJ+SumM0PUCEqcnPmEpYuR g4NTwFFibbsbSJgZaMzM+ecZIWx5ieats5kh9mpLNDR1sE5gFJyFpHsWkpZZSFoWMDKvYhQt Ti0uzk03MtZLLcpMLi7Oz9PLSy3ZxAgM+4NbfuvuYFz92vEQowAHoxIP74ID90OFWBPLiitz DzFKc7AoifO2MD0IFRJITyxJzU5NLUgtii8qzUktPsTIxMEp1cCoob7ilPdiy09Ty/c7GZ8S //WpV5ihkkn0yfaw7Ocy7x91bd/1+8r2/+0TftU6535X92UP/rTb5agXZ8PUD2FtK/hjfi1r n6d6pjb71aerRy2jTa9UiR4xKxI8mRLyQkL72JlfB5rMrA5f8K2pb2ibxv977qZc8R39yxgl A9adPrDIySW1WKJZiaU4I9FQi7moOBEANGNJVFwCAAA= Archived-At: Cc: jonathan@vidyo.com, avtext@ietf.org, avtext-chairs@ietf.org, draft-ietf-avtext-rtp-stream-pause@ietf.org, draft-ietf-avtext-rtp-stream-pause.ad@ietf.org, draft-ietf-avtext-rtp-stream-pause.shepherd@ietf.org Subject: Re: [avtext] Barry Leiba's No Objection on draft-ietf-avtext-rtp-stream-pause-08: (with COMMENT) X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Aug 2015 12:30:09 -0000 Den 2015-08-19 kl. 21:37, skrev Barry Leiba: > Barry Leiba has entered the following ballot position for > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > I have a meta-question about why this "updates" 5104. It appears to be > an extension to 5104, using normal extension mechanisms -- someone > implementing 5104 and not intending to implement this would have no > reason to look at this document, as far as I can tell. I don't see > anything that describes a *change* to 5104 (though perhaps I've missed > it). What's the reasoning behind specifying "updates"? > The reason this documents Updates RFC5104 is that it clarifies that the TMMBR message that is defined in 5104 can also be used for pause if one sets bandwidth to 0. This is important to know also for anyone not intending to implement PAUSE and Resume semantics. I realize that this is not clearly stated in the introduction. Perhaps something we should address by adding a sentence or two to this paragraph from Section 1. The Temporary Maximum Media Bitrate Request (TMMBR) message of CCM is used by video conferencing systems for flow control. It is desirable to be able to use that method with a bitrate value of zero for pause, whenever possible. Cheers Magnus Westerlund ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From nobody Fri Aug 28 06:09:10 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 76BF01B2C3B; Fri, 28 Aug 2015 06:09:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, 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 CoY1vq6-pIiU; Fri, 28 Aug 2015 06:09:01 -0700 (PDT) Received: from mail-vk0-x22b.google.com (mail-vk0-x22b.google.com [IPv6:2607:f8b0:400c:c05::22b]) (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 CAC421B2B64; Fri, 28 Aug 2015 06:09:00 -0700 (PDT) Received: by vkaw128 with SMTP id w128so9070780vka.2; Fri, 28 Aug 2015 06:09:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=oS6wlgzuZhpsg5pA+RobtWhBf+/3h9nBc+4mf201xgg=; b=aYdi9eHY22ynlkEEE6EpW3ae7GyUjKzFK2f8qzJ91EGhRxDra+3IfiTm1mwMtPPZOV 9mH4WAlx7uPug8bspbleqLiheaU66iEEpOWLuCDvydYlp3ZunHN1AcAKC63u6yVNgWPP 9o7VqTobfTYEG1QgDhtWKrpZTQ3DJwefU71oN92NZVVKJqN1pfQ5O6Qc5Fsh0iFNHzMX Wglel4N5BIn9x+8OirQ8j9Rgs7cIaAVPflfbMRfON4Ab7G+ZwCoTzXPaxfmCbigGbleh R4ORUtCZFuOX7QUaU1QwsE3pzaQ/sNJI5Fggtu1HHq3wxr3/q3gVlotsklymCj8Q44Tz P8Kw== MIME-Version: 1.0 X-Received: by 10.52.108.233 with SMTP id hn9mr4101249vdb.27.1440767340028; Fri, 28 Aug 2015 06:09:00 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.31.88.196 with HTTP; Fri, 28 Aug 2015 06:08:59 -0700 (PDT) In-Reply-To: <55E05444.2030502@ericsson.com> References: <20150819193730.2872.16228.idtracker@ietfa.amsl.com> <55E05444.2030502@ericsson.com> Date: Fri, 28 Aug 2015 09:08:59 -0400 X-Google-Sender-Auth: _XAwhFWrjngc3wNflicoxnpy520 Message-ID: From: Barry Leiba To: Magnus Westerlund Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Jonathan Lennox , avtext@ietf.org, avtext-chairs@ietf.org, draft-ietf-avtext-rtp-stream-pause@ietf.org, The IESG , draft-ietf-avtext-rtp-stream-pause.ad@ietf.org, draft-ietf-avtext-rtp-stream-pause.shepherd@ietf.org Subject: Re: [avtext] Barry Leiba's No Objection on draft-ietf-avtext-rtp-stream-pause-08: (with COMMENT) X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Aug 2015 13:09:06 -0000 Hi, Magnus; thanks for the response and explanation. Yes, adding a sentence to that paragraph would be good, along the line of "This updates RFC 5104 to add the new Pause and Resume semantics to the TMMBR message." Minor thing, though... if you think it's clear enough as it is, I'm not worried further. Barry On Fri, Aug 28, 2015 at 8:29 AM, Magnus Westerlund wrote: > Den 2015-08-19 kl. 21:37, skrev Barry Leiba: >> >> Barry Leiba has entered the following ballot position for > > >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> I have a meta-question about why this "updates" 5104. It appears to be >> an extension to 5104, using normal extension mechanisms -- someone >> implementing 5104 and not intending to implement this would have no >> reason to look at this document, as far as I can tell. I don't see >> anything that describes a *change* to 5104 (though perhaps I've missed >> it). What's the reasoning behind specifying "updates"? >> > > The reason this documents Updates RFC5104 is that it clarifies that the > TMMBR message that is defined in 5104 can also be used for pause if one s= ets > bandwidth to 0. This is important to know also for anyone not intending t= o > implement PAUSE and Resume semantics. > > I realize that this is not clearly stated in the introduction. Perhaps > something we should address by adding a sentence or two to this paragraph > from Section 1. > > The Temporary Maximum Media Bitrate Request (TMMBR) message of CCM is > used by video conferencing systems for flow control. It is desirable > to be able to use that method with a bitrate value of zero for pause, > whenever possible. > > Cheers > > Magnus Westerlund > > ---------------------------------------------------------------------- > Services, Media and Network features, Ericsson Research EAB/TXM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > F=C3=A4r=C3=B6gatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- >