From nobody Wed Dec 9 16:26:19 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 2BBB61A1F70 for ; Wed, 9 Dec 2015 16:26:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-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 H2mNXgIIZq1H for ; Wed, 9 Dec 2015 16:26:16 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0146.outbound.protection.outlook.com [65.55.169.146]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CFF061A1F20 for ; Wed, 9 Dec 2015 16:26:15 -0800 (PST) Received: from CO2PR07MB619.namprd07.prod.outlook.com (10.141.228.151) by CO2PR07MB620.namprd07.prod.outlook.com (10.141.228.156) with Microsoft SMTP Server (TLS) id 15.1.337.19; Thu, 10 Dec 2015 00:26:11 +0000 Received: from CO2PR07MB619.namprd07.prod.outlook.com ([10.141.228.151]) by CO2PR07MB619.namprd07.prod.outlook.com ([10.141.228.151]) with mapi id 15.01.0337.015; Thu, 10 Dec 2015 00:26:12 +0000 From: Stephan Wenger To: "avtext@ietf.org" Thread-Topic: New Version Notification for draft-wenger-avtext-avpf-ccm-layered-00.txt Thread-Index: AQHRMuDsi+dpfWcqiEWlvywAWZfURp7C1t4A Date: Thu, 10 Dec 2015 00:26:11 +0000 Message-ID: <5F628A35-BFAC-4EEB-9A39-0CA3806E8399@stewe.org> References: <20151210002255.8328.49582.idtracker@ietfa.amsl.com> In-Reply-To: <20151210002255.8328.49582.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=stewe@stewe.org; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [24.4.139.61] x-microsoft-exchange-diagnostics: 1; CO2PR07MB620; 5:tQt3J9Hiu2G8pQ9MHX2sVkPLFMopp1RdsdZeiOmGBA1JLXUfIgudZ/ccdTfBhT1w6lhtTKieFqbG5BqHRHM030SLm2bMOU4jQBToiNf3ixJp5LHwSRChycLzxy6DUnRPKbgXw7UJ0XmwkD/8qm4Kjw==; 24:PayhiZDGCuGkDW3zmoVaYT7GyA5d2iNmPSoMiwSodv3tcIxnQ9YJqCh7ry0G29BwHhHO8+ZFoD2fzIkG0H0nXsZBqsX+STKhtSY8n2oTlCU= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CO2PR07MB620; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(520078)(8121501046)(3002001)(10201501046); SRVR:CO2PR07MB620; BCL:0; PCL:0; RULEID:; SRVR:CO2PR07MB620; x-forefront-prvs: 078693968A x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(199003)(189002)(164054003)(24454002)(479174004)(377424004)(5004730100002)(82746002)(110136002)(83716003)(2900100001)(92566002)(230783001)(450100001)(99286002)(50986999)(66066001)(33656002)(77096005)(2351001)(107886002)(54356999)(122556002)(86362001)(5001960100002)(15975445007)(97736004)(2501003)(36756003)(101416001)(76176999)(81156007)(40100003)(189998001)(1220700001)(106116001)(19580395003)(2950100001)(105586002)(106356001)(19580405001)(10400500002)(1096002)(586003)(87936001)(3846002)(102836003)(5008740100001)(6116002)(5002640100001)(1730700001)(42262002)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:CO2PR07MB620; H:CO2PR07MB619.namprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:0; MX:1; LANG:en; received-spf: None (protection.outlook.com: stewe.org does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: stewe.org X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Dec 2015 00:26:11.8140 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 865fc51c-5fae-4322-98ef-0121a85df0b6 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO2PR07MB620 Archived-At: Subject: [avtext] FW: New Version Notification for draft-wenger-avtext-avpf-ccm-layered-00.txt X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Dec 2015 00:26:18 -0000 Rm9sa3MsDQpKb25hdGhhbiwgQm8sIE1hZ251cywgYW5kIG15c2VsZiB0aHJldyB0b2dldGhlciB0 aGUgSS1EIHJlZmVyZW5jZWQgYmVsb3cgdGhhdCBjbGFyaWZpZXMgdGhlIHJlbGF0aW9uc2hpcCBv ZiBGdWxsIEludHJhIFJlcXVlc3QgYW5kIGxheWVyZWQgY29kZWNzIChhbmQgYWxzbyBjb21tZW50 cyBvbiB0aGUgdXNlIG9mIG90aGVyIGNvZGVjIGNvbnRyb2wgbWVzc2FnZXMgZGVmaW5lZCBpbiBS RkMgNTEwNCBhbmQgUkZDIDQ1ODUpLiAgSXTigJlzIGEgc2hvcnQgZHJhZnQuICBQbGVhc2UgY29t bWVudC4gIExldOKAmXMgdHJ5IHRvIHNldCBhIHJlY29yZCBmcm9tIC0wMCBJRCB0byBwdWJsaWNh dGlvbiBvZiB0aGUgUkZDIDotKQ0KVGhhbmtzLA0KU3RlcGhhbg0KDQoNCg0KDQpPbiAxMi85LzE1 LCAxNjoyMiwgImludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyIgPGludGVybmV0LWRyYWZ0c0BpZXRm Lm9yZz4gd3JvdGU6DQoNCj4NCj5BIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtd2VuZ2VyLWF2 dGV4dC1hdnBmLWNjbS1sYXllcmVkLTAwLnR4dA0KPmhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJt aXR0ZWQgYnkgU3RlcGhhbiBXZW5nZXIgYW5kIHBvc3RlZCB0byB0aGUNCj5JRVRGIHJlcG9zaXRv cnkuDQo+DQo+TmFtZToJCWRyYWZ0LXdlbmdlci1hdnRleHQtYXZwZi1jY20tbGF5ZXJlZA0KPlJl dmlzaW9uOgkwMA0KPlRpdGxlOgkJVXNpbmcgQ29kZWMgQ29udHJvbCBNZXNzYWdlcyBpbiB0aGUg UlRQIEF1ZGlvLVZpc3VhbCBQcm9maWxlIHdpdGggRmVlZGJhY2sgd2l0aCBMYXllcmVkIENvZGVj cw0KPkRvY3VtZW50IGRhdGU6CTIwMTUtMTItMDkNCj5Hcm91cDoJCUluZGl2aWR1YWwgU3VibWlz c2lvbg0KPlBhZ2VzOgkJMTANCj5VUkw6ICAgICAgICAgICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcv aW50ZXJuZXQtZHJhZnRzL2RyYWZ0LXdlbmdlci1hdnRleHQtYXZwZi1jY20tbGF5ZXJlZC0wMC50 eHQNCj5TdGF0dXM6ICAgICAgICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJh ZnQtd2VuZ2VyLWF2dGV4dC1hdnBmLWNjbS1sYXllcmVkLw0KPkh0bWxpemVkOiAgICAgICBodHRw czovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtd2VuZ2VyLWF2dGV4dC1hdnBmLWNjbS1sYXll cmVkLTAwDQo+DQo+DQo+QWJzdHJhY3Q6DQo+ICAgVGhpcyBkb2N1bWVudCBmaXhlcyBhIHNob3J0 Y29taW5nIGluIHRoZSBzcGVjaWZpY2F0aW9uIGxhbmd1YWdlIG9mDQo+ICAgdGhlIENvZGVjIENv bnRyb2wgTWVzc2FnZSBGdWxsIEludHJhIFJlcXVlc3QgKEZJUikgYXMgZGVmaW5lZCBpbg0KPiAg IFJGQzUxMDQgd2hlbiB1c2luZyB3aXRoIGxheWVyZWQgY29kZWNzLiAgSW4gcGFydGljdWxhciwg YSBEZWNvZGVyDQo+ICAgUmVmcmVzaCBQb2ludCBuZWVkcyB0byBiZSBzZW50IGJ5IGEgbWVkaWEg c2VuZGVyIHdoZW4gYSBGSVIgaXMNCj4gICByZWNlaXZlZCBvbiBhbnkgbGF5ZXIgb2YgdGhlIGxh eWVyZWQgYml0c3RyZWFtLCByZWdhcmRsZXNzIG9uIHdoZXRoZXINCj4gICB0aG9zZSBsYXllcnMg YXJlIGJlaW5nIHNlbnQgaW4gYSBzaW5nbGUgb3IgaW4gbXVsdGlwbGUgUlRQIGZsb3dzLg0KPiAg IFRoZSBvdGhlciBwYXlsb2FkLXNwZWNpZmljIGZlZWRiYWNrIG1lc3NhZ2VzIGRlZmluZWQgaW4g UkZDIDUxMDQgYW5kDQo+ICAgUkZDIDQ1ODUgYXMgdXBkYXRlZCBieSBSRkMgNTUwNiBoYXZlIGFs c28gYmVlbiBhbmFseXplZCwgYW5kIG5vDQo+ICAgY29ycmVzcG9uZGluZyBzaG9ydGNvbWluZ3Mg aGF2ZSBiZWVuIGZvdW5kLg0KPg0KPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCj4NCj4NCj5Q bGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUg dGltZSBvZiBzdWJtaXNzaW9uDQo+dW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYg YXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy4NCj4NCj5UaGUgSUVURiBTZWNyZXRhcmlh dA0KPg0K From nobody Thu Dec 10 15:01:49 2015 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E661D1B2D81 for ; Thu, 10 Dec 2015 15:01:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-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 EgvcOXcUOBpq for ; Thu, 10 Dec 2015 15:01:44 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0705.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:705]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF7891B2D72 for ; Thu, 10 Dec 2015 15:01:37 -0800 (PST) Received: from CO2PR07MB619.namprd07.prod.outlook.com (10.141.228.151) by CO2PR07MB617.namprd07.prod.outlook.com (10.141.228.143) with Microsoft SMTP Server (TLS) id 15.1.337.19; Thu, 10 Dec 2015 23:01:17 +0000 Received: from CO2PR07MB619.namprd07.prod.outlook.com ([10.141.228.151]) by CO2PR07MB619.namprd07.prod.outlook.com ([10.141.228.151]) with mapi id 15.01.0337.015; Thu, 10 Dec 2015 23:01:17 +0000 From: Stephan Wenger To: Adam Roach , "avtext@ietf.org" Thread-Topic: [avtext] Fwd: New Version Notification for draft-roach-avtext-rid-00.txt Thread-Index: AQHRM56s7PuSoMSsIECzAQMKYYIi1Q== Date: Thu, 10 Dec 2015 23:01:16 +0000 Message-ID: References: <20151130183802.21578.17213.idtracker@ietfa.amsl.com> <565C9C12.80004@nostrum.com> In-Reply-To: <565C9C12.80004@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=stewe@stewe.org; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [24.4.139.61] x-microsoft-exchange-diagnostics: 1; CO2PR07MB617; 5:9wp9deSBUDtk2F6COjCLq25scbaTdw+azdPzHyem2rg2KeGqO5h9xMhSbbWll9o8zzjcM5uB7GxtkkpnYbe9Jg6510mBDWKtJv9YhkvOMywihozhm8VqzGQYsbqXli4X75lqB0e3rEd5Kyy0CH44AQ==; 24:+5eP27eD+vcwMtl8F3hrdE6lX9a6+tYk2t025+NcrsbBICWib3GsmRqtc2+mfL1hGMsHnTxVSextecQwooKA37+A33NwcQuvgs29xxOEsak= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CO2PR07MB617; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(95692535739014); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(520078)(8121501046)(5005006)(10201501046)(3002001); SRVR:CO2PR07MB617; BCL:0; PCL:0; RULEID:; SRVR:CO2PR07MB617; x-forefront-prvs: 078693968A x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(2473001)(189002)(377424004)(199003)(479174004)(24454002)(33656002)(54356999)(1220700001)(92566002)(586003)(2900100001)(82746002)(2501003)(66066001)(19580405001)(102836003)(3846002)(19580395003)(5004730100002)(6116002)(15975445007)(87936001)(36756003)(5008740100001)(2950100001)(83716003)(5002640100001)(40100003)(106356001)(106116001)(86362001)(77096005)(81156007)(101416001)(189998001)(11100500001)(10400500002)(230783001)(99286002)(1096002)(4001150100001)(76176999)(50986999)(107886002)(122556002)(97736004)(105586002)(5001770100001)(5001960100002)(104396002)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:CO2PR07MB617; H:CO2PR07MB619.namprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:0; LANG:en; received-spf: None (protection.outlook.com: stewe.org does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <53830C13663E0A43A2908BD6C62A6BE6@namprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: stewe.org X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Dec 2015 23:01:17.0034 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 865fc51c-5fae-4322-98ef-0121a85df0b6 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO2PR07MB617 Archived-At: Subject: Re: [avtext] Fwd: New Version Notification for draft-roach-avtext-rid-00.txt X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Dec 2015 23:01:48 -0000 SGksDQoNClRocmVlIG1pbm9yIGNvbW1lbnRzOg0KDQoxKSBUaGUgbGFzdCBzZW50ZW5jZSBvZiBz ZWN0aW9uIDEsIHNlY29uZCBwYXJhZ3JhcGgsIHJlYWRzOiDigJxUaGlzIG5lZWQgZm9yIHVuaXF1 ZSBpZGVudGlmaWNhdGlvbiBleHRlbmRzIHRvIERlcGVuZGVudCBTdHJlYW1zIChpLmUuLCBzaW11 bGNhc3QgbGF5ZXJzIHVzZWQgYnkgYSBsYXllcmVkIGNvZGVjKS7igJ0NCg0KSeKAmW0gbm90IHN1 cmUgYWJvdXQgdGhlIGV4YW1wbGUgZm9yIERlcGVuZGVudCBTdHJlYW1zIChzaW11bGNhc3QgbGF5 ZXJzIG9mIGEgbGF5ZXJlZCBjb2RlYykuICBUaGUgcHJvYmxlbSBoZXJlIG1heSBiZSB0ZXJtaW5v bG9neSwgYnV0IHRoZSB0ZXJtIOKAnHNpbXVsY2FzdOKAnSBpcyBjb21tb25seSB1bmRlcnN0b29k IGFzIHNpbXVsdGFuZW91cyB0cmFuc21pc3Npb24gb2Ygc3R1ZmYgdGhhdCBpcyBpbmRlcGVuZGVu dCBmcm9tIGVhY2ggb3RoZXIuICBHaXZpbmcgaXQgYSBuZXcgbWVhbmluZyBoZXJlIG1heSBiZSBj b25mdXNpbmcuICBJdCBtYXkgYmUgYmV0dGVyIHRvIHJlbW92ZSB0aGUgd29yZCDigJxzaW11bGNh c3TigJ0gYW5kIHNpbXBseSBzYXkg4oCcKGkuZS4sIGxheWVycyB1c2VkIGJ5IGEgbGF5ZXJlZCBj b2RlYyBjb252ZXllZCBpbiB0aGVpciBvd24gc3RyZWFtKeKAnS4NCg0KMikgSSB3b3VsZCBtb3Zl IHRoZSBmaXJzdCBwYXJhIG9mIHNlY3Rpb24gMyBzb21ld2hlcmUgZWFybHkgaW50byBzZWN0aW9u IDEsIGJlY2F1c2Ugb3RoZXJ3aXNlIHRoZSBjYXBpdGFsaXplZCB0ZXJtIOKAnERlcGVuZGVudCBT dHJlYW3igJ0gaXMgdW5kZWZpbmVkLiAgDQoNCjMpIHNob3VsZCDigJxFbmNvZGVkIFN0cmVhbeKA nSBhbmQg4oCcRGVwZW5kZW50IFN0cmVhbeKAnSBpbiB0aGUgYWJzdHJhY3QgYmUgY2FwaXRhbGl6 ZWQ/DQoNClN0ZXBoYW4NCg0KDQoNCk9uIDExLzMwLzE1LCAxMDo1NywgImF2dGV4dCBvbiBiZWhh bGYgb2YgQWRhbSBSb2FjaCIgPGF2dGV4dC1ib3VuY2VzQGlldGYub3JnIG9uIGJlaGFsZiBvZiBh ZGFtQG5vc3RydW0uY29tPiB3cm90ZToNCg0KPkEgd2UgZGlzY3Vzc2VkIGluIFlva29oYW1hLCBo ZXJlJ3MgdGhlIEFWVEVYVCB2ZXJzaW9uIG9mIGEgUklEIGRvY3VtZW50LiANCj5JIHRyaWVkIHRv IHRha2UgaW50byBhY2NvdW50IGFsbCBvZiB0aGUgc3VnZ2VzdGlvbnMgdGhhdCB3ZXJlIG1hZGUg YXQgDQo+dGhlIG1pY3JvcGhvbmUgLS0gcGxlYXNlIGxvb2sgdGhpcyBvdmVyIGFuZCBsZXQgbWUg a25vdyB3aGV0aGVyIGl0IA0KPm1hdGNoZXMgd2hhdCB5b3UgZXhwZWN0ZWQuDQo+DQo+L2ENCj4N Cj4NCj4tLS0tLS0tLSBGb3J3YXJkZWQgTWVzc2FnZSAtLS0tLS0tLQ0KPlN1YmplY3Q6IAlOZXcg VmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LXJvYWNoLWF2dGV4dC1yaWQtMDAudHh0DQo+ RGF0ZTogCU1vbiwgMzAgTm92IDIwMTUgMTA6Mzg6MDIgLTA4MDANCj5Gcm9tOiAJaW50ZXJuZXQt ZHJhZnRzQGlldGYub3JnDQo+VG86IAlTdWhhcyBOYW5kYWt1bWFyIDxzbmFuZGFrdUBjaXNjby5j b20+LCBQZXRlciBUaGF0Y2hlciANCj48cHRoYXRjaGVyQGdvb2dsZS5jb20+LCBBZGFtIFJvYWNo IDxhZGFtQG5vc3RydW0uY29tPg0KPg0KPg0KPg0KPkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFm dC1yb2FjaC1hdnRleHQtcmlkLTAwLnR4dA0KPmhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0 ZWQgYnkgQWRhbSBSb2FjaCBhbmQgcG9zdGVkIHRvIHRoZQ0KPklFVEYgcmVwb3NpdG9yeS4NCj4N Cj5OYW1lOgkJZHJhZnQtcm9hY2gtYXZ0ZXh0LXJpZA0KPlJldmlzaW9uOgkwMA0KPlRpdGxlOgkJ UlRQIFBheWxvYWQgRm9ybWF0IENvbnN0cmFpbnRzDQo+RG9jdW1lbnQgZGF0ZToJMjAxNS0xMS0z MA0KPkdyb3VwOgkJSW5kaXZpZHVhbCBTdWJtaXNzaW9uDQo+UGFnZXM6CQk2DQo+VVJMOiAgICAg ICAgICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1yb2FjaC1h dnRleHQtcmlkLTAwLnR4dA0KPlN0YXR1czogICAgICAgICBodHRwczovL2RhdGF0cmFja2VyLmll dGYub3JnL2RvYy9kcmFmdC1yb2FjaC1hdnRleHQtcmlkLw0KPkh0bWxpemVkOiAgICAgICBodHRw czovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtcm9hY2gtYXZ0ZXh0LXJpZC0wMA0KPg0KPg0K PkFic3RyYWN0Og0KPiAgICBUaGlzIGRvY3VtZW50IGRlZmluZXMgYW5kIHJlZ2lzdGVycyBhbiBS VENQIFNERVMgaXRlbSwgUklELCBmb3INCj4gICAgaWRlbnRpZmljYXRpb24gb2YgUlRQIHN0cmVh bXMgYXNzb2NpYXRlZCB3aXRoIGVuY29kZWQgYW5kIGRlcGVuZGVudA0KPiAgICBzdHJlYW1zLg0K Pg0KPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDQo+DQo+DQo+UGxlYXNlIG5vdGUgdGhhdCBp dCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlzc2lv bg0KPnVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQg dG9vbHMuaWV0Zi5vcmcuDQo+DQo+VGhlIElFVEYgU2VjcmV0YXJpYXQNCj4NCj4NCj4NCj5fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPmF2dGV4dCBtYWls aW5nIGxpc3QNCj5hdnRleHRAaWV0Zi5vcmcNCj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL2F2dGV4dA0K From nobody Fri Dec 11 20:12:04 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 80C8E1ACEA0; Fri, 11 Dec 2015 20:12:03 -0800 (PST) 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 lzdqlgJPJ0uh; Fri, 11 Dec 2015 20:12:01 -0800 (PST) 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 BE4471ACE9D; Fri, 11 Dec 2015 20:11:58 -0800 (PST) Received: from [10.0.1.10] (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 tBC4BvPR099888 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Fri, 11 Dec 2015 22:11:58 -0600 (CST) (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.10] From: "Ben Campbell" To: draft-ietf-avtext-sdes-hdr-ext.all@ietf.org, avtext@ietf.org Date: Fri, 11 Dec 2015 22:11:57 -0600 Message-ID: <3E1623EC-9FDB-40CE-BE9D-308D4D3BDBF4@nostrum.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Mailer: MailMate (1.9.3r5187) Archived-At: Subject: [avtext] AD Evaluation of draft-ietf-avtext-sdes-hdr-ext-02 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: Sat, 12 Dec 2015 04:12:03 -0000 Hi, Here is my AD evaluation of draft-ietf-avtext-sdes-hdr-ext-02. I have a few questions and comments that I would like to resolve prior to IETF last call, as well as some editorial comments that can be handled whenever is convenient: Thanks! Ben. === Substantive: - 4.2.1, last paragraph: The guidance about RTP middleboxes seems to apply to header extensions in general. Is this not already documented somewhere else? - 4.2.6, 2nd paragraph: "... issues can be avoid by performing ..." Do you mean "... the receiver performing..."? - 5.1: Please elaborate on what you mean by sub-space. I don't think RFC 5285 contemplated this idea. How would IANA indicate that things in this sub-space have additional rules beyond those of 5285? Or more concretely, how do we indicate that urn:ietf:params:rtp-hdrext:sdes:cname is bound by the rules for urn:ietf:params:rtp-hdrext:sdes? Paragraph 2 says "preferably in a publically available reference." I think that's a hard requirement in 5285. This seems to relax that--I assume that is not the intent. Security considerations are also already required by 5285 (but there is no mention of privacy considerations.) -6, general: The requirements here are pretty abstract. Would it make sense to say something to the effect of "If you SRTP it you MUST encrypt the RTP extension header"? -6, paragraph 2: - "In RTP sessions where any type of confidentiality protection is enabled for RTCP, the SDES item header extensions MUST also be protected per default. " Why “per default”? That tells me that an implementation would, if not configured otherwise, protect the header extension if it protected RTCP. Do you intend to allow the “configured otherwise” loophole? - "users of SRTP need to implement encrypted header extensions" Do you mean to say “implementers must also implement” or “users must also use”? Or both? - "Commonly, it is expected that the same security level is applied to RTCP packets carrying SDES items, and to an RTP header extension containing SDES items. " The phrase “Commonly, it is expected…” seems to water down the guidance. Any reason not to say SHOULD or MUST here? - 6, paragraph 3: - "there SHOULD be strong requirements on integrity and source authentication" What needs to have that strong requirement? The specs for extensions in the sub-space? Or does this mean to say that "there SHOULD be strong integrity protection and source authentication"? === Editorial: - General: There's a fair number of instances of noun/verb agreement issues. I will point out the ones I found, but there's enough that I would suggest proofreading for more. - 1, 2nd paragraph: --"Some SDES items performs binding or identifies synchronization context" Singular/plural disagreements among [items, performs, identifies, context] -- "No use case has identified where this information is required at the same time as the first RTP packets arrive." I think it would be helpful to mention that this extension actually allows information deliver in the first RTP packets in the first paragraph. Leaving it to an in-passing remark here sort of buries the lede. -1, last paragraph: With the heavy use of passive voice in this paragraph, it was not immediately obvious to me that it talked about the following sections of the document itself. Please consider something more of the form of “Section 2 defines requirements language and terminology…” -3, 2nd paragraph: "because an end-point is adding" s/is adding/adds -3, 3rd paragraph: "Thus an RTP header extension for carrying SDES items like CNAME is a powerful combination..." What combination do you have in mind? When in combination with 6051? Or do you just mean to say it's a powerful tool? -3, 4th paragraph: s/does provide/provides -3, 2nd to last paragraph: You mean to say that that the MID spec already defines the header extension, not that _this_ draft defined it, right? -4.2.2, 2nd paragraph:"If the packet expansion cannot be taken into account..." Do you mean "... is not taken into account..."? -5, first bullet: Consider reordering this a bit: “… the URN sub-space…for SDES items”" -5.1, first paragraph:"some additional considerations are provided here that needs to be considered" noun/verb disagreement (considerations is plural, needs is singular) - 5.1, 2nd paragraph: "security and privacy consideration" s/consideration/considerations -6, 2nd paragraph: "If the security level is different, it is important to consider the security properties as the worst in each aspect for the different configurations." I find this sentence hard to understand. I _think_ you are saying that the protection of the SDES item is equal to the protection of RTCP or that of the RTP header extension, whichever is lower? From nobody Mon Dec 14 08:29: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 806971A916C; Mon, 14 Dec 2015 08:29:40 -0800 (PST) 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 t4xxjXX0-bbw; Mon, 14 Dec 2015 08:29:33 -0800 (PST) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 58EA21A906A; Mon, 14 Dec 2015 08:29:32 -0800 (PST) X-AuditID: c1b4fb30-f79296d00000141d-8f-566eee6ac0bf Received: from ESESSHC004.ericsson.se (Unknown_Domain [153.88.183.30]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id E1.69.05149.A6EEE665; Mon, 14 Dec 2015 17:29:30 +0100 (CET) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.32) with Microsoft SMTP Server id 14.3.248.2; Mon, 14 Dec 2015 17:29:30 +0100 To: Ben Campbell , , References: <3E1623EC-9FDB-40CE-BE9D-308D4D3BDBF4@nostrum.com> From: Magnus Westerlund Message-ID: <566EEE69.20500@ericsson.com> Date: Mon, 14 Dec 2015 17:29:29 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: <3E1623EC-9FDB-40CE-BE9D-308D4D3BDBF4@nostrum.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrFLMWRmVeSWpSXmKPExsUyM2K7nG7Wu7wwg+ZLyhYf791gtZjfeZrd YsaUA8wOzB5Llvxk8pi18wlLAFMUl01Kak5mWWqRvl0CV0bXmmbGgoteFU9nNbA3MM627mLk 5JAQMJF4eXgnG4QtJnHh3nogm4tDSOAwo8SBc7dZIZzljBLH+76AVQkL2Es0fvoOZosIpEks nnGWEcQWErCT2L9kIjOIzSZgIXHzRyNYDa+ApsTB5/fA4iwCqhIrzl8Di4sKxEg8XryVFaJG UOLkzCcsIDYn0PwdM3aD1TMDzZk5/zwjhC0v0bx1NjPELm2JhqYO1gmMArOQtM9C0jILScsC RuZVjKLFqcVJuelGRnqpRZnJxcX5eXp5qSWbGIEhenDLb4MdjC+fOx5iFOBgVOLhNTiQGybE mlhWXJl7iFGCg1lJhHfTzbwwId6UxMqq1KL8+KLSnNTiQ4zSHCxK4rzNTA9ChQTSE0tSs1NT C1KLYLJMHJxSDYzJVqfssiutVLbONfpeztvzff+0Na+V1kazSYSE7/5r/v9VILv2pybfuU13 Hz2cNDsn7+vp6V/ndU7Wrp4jppB/7fffrw+v39r6Qvk58xF5k17DytzYCRGddeu6Z1+8v5ll 577tE5uq0jQkVVWUd+XcniGwS2pxbr3jlW8xl+eKH/uv+nGqwXljJZbijERDLeai4kQAs4yt vU0CAAA= Archived-At: Subject: Re: [avtext] AD Evaluation of draft-ietf-avtext-sdes-hdr-ext-02 X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Dec 2015 16:29:40 -0000 Hi Ben, See below my answer and feedback on your evaluation. I think it is fairly clear that we need to do a new revision prior to the IETF last call. Den 2015-12-12 kl. 05:11, skrev Ben Campbell: > Hi, > > Here is my AD evaluation of draft-ietf-avtext-sdes-hdr-ext-02. I have a > few questions and comments that I would like to resolve prior to IETF > last call, as well as some editorial comments that can be handled > whenever is convenient: > > Thanks! > > Ben. > > === Substantive: > > - 4.2.1, last paragraph: > The guidance about RTP middleboxes seems to apply to header extensions > in general. Is this not already documented somewhere else? Not, what I can remember. It is definitely not in RFC5285, and this should be considered to be added to RFC5285bis draft. > > - 4.2.6, 2nd paragraph: "... issues can be avoid by performing ..." > > Do you mean "... the receiver performing..."? Yes, these are all receiver side actions. > > - 5.1: > > Please elaborate on what you mean by sub-space. I don't think RFC 5285 > contemplated this idea. How would IANA indicate that things in this > sub-space have additional rules beyond those of 5285? Or more > concretely, how do we indicate that > urn:ietf:params:rtp-hdrext:sdes:cname is bound by the rules for > urn:ietf:params:rtp-hdrext:sdes? > What I mean is that any URN starting with "urn:ietf:params:rtp-hdrext:sdes" is under these rules. And I think that IANA is already handling different set of rules for different parts of the URN space. The rules for "urn:ietf" is different from the ones for "urn:ietf:params:rtp-hdrext". > Paragraph 2 says "preferably in a publically available reference." I > think that's a hard requirement in 5285. This seems to relax that--I > assume that is not the intent. Security considerations are also already > required by 5285 (but there is no mention of privacy considerations.) Yes, you are right, for RTP header extensions RFC5285 do require publicly available specification. I think we might have primarily looked at the rules for SDES items which are according to RFC3550: To facilitate review of requests and to promote shared use of new types among multiple applications, requests for registration of new values must be documented in an RFC or other permanent and readily available reference such as the product of another cooperative standards body (e.g., ITU-T). Other requests may also be accepted, under the advice of a "designated expert." Which gives some leeway for non public available references which RFC5285 do. I think the easy fix here is to be clear that it must fulfil the rules of RFC5285, and then have this document in addition note the need for 1) being a registered SDES item (implies following the rules in RFC3550 for SDES items), 2) being explicit about privacy considerations and 3) the motivation for timely deliver. > > -6, general: > > The requirements here are pretty abstract. Would it make sense to say > something to the effect of "If you SRTP it you MUST encrypt the RTP > extension header"? In RTP sessions where any type of confidentiality protection is enabled for RTCP, the SDES item header extensions MUST also be protected per default. This implies that to provide confidentiality, users of SRTP need to implement encrypted header extensions per [RFC6904]. I thought the above was basically saying this, with the exception that it gates on encrypting RTCP, rather than using SRTP. And I think you actually want to consider if using just SRTP for integrity protection, i.e. null encryption shall force encryption on the SDES header extension. I am fine to edit this to say that if you confidentiality protect either RTP or RTCP, then you MUST confidentiality protect also this header extension. But, I think for the SRTP parties, if we want to be clearer then we should simpley add "and use" to the second sentence. > > -6, paragraph 2: > - "In RTP sessions where any type of confidentiality protection is > enabled for RTCP, the SDES item header extensions MUST also be > protected per default. " > > Why “per default”? That tells me that an implementation would, if not > configured otherwise, protect the header extension if it protected RTCP. > Do you intend to allow the “configured otherwise” loophole? I am happy to loose the "per default" here. I can't remember a reason for it. > > - "users of SRTP need to implement encrypted header extensions" > Do you mean to say “implementers must also implement” or “users must > also use”? Or both? The first sentence says you must use it if RTCP is protected. If using SRTP, then this implies that you must implement and use RFC6904 to achieve the normative statement. And as said above, I am happy to clarify that this is really implement and use. > > - "Commonly, it is expected that the same security level is > applied to RTCP packets carrying SDES items, and to an RTP header > extension containing SDES items. " > > The phrase “Commonly, it is expected…” seems to water down the guidance. > Any reason not to say SHOULD or MUST here? Yes, we can loose the "commonly ..." part. I think SHOULD is good, and and basically ask the ones trying to invoke the exception to motivate themselves. > > - 6, paragraph 3: > - "there SHOULD be strong > requirements on integrity and source authentication" > > What needs to have that strong requirement? The specs for extensions in > the sub-space? Or does this mean to say that "there SHOULD be strong > integrity protection and source authentication"? The later. > > === Editorial: > > - General: There's a fair number of instances of noun/verb agreement > issues. I will point out the ones I found, but there's enough that I > would suggest proofreading for more. Noted. I will press my native speaking co-authors to do this. > > - 1, 2nd paragraph: > > --"Some SDES items performs binding or identifies synchronization context" > Singular/plural disagreements among [items, performs, identifies, context] > > -- "No use case has identified where this information is required at the > same time as the first RTP packets arrive." > I think it would be helpful to mention that this extension actually > allows information deliver in the first RTP packets in the first > paragraph. Leaving it to an in-passing remark here sort of buries the lede. Yes, that should be added as a new sentence after the one ending with "... can be optimized". > > -1, last paragraph: > With the heavy use of passive voice in this paragraph, it was not > immediately obvious to me that it talked about the following sections of > the document itself. Please consider something more of the form of > “Section 2 defines requirements language and terminology…” > Yes, can do. > -3, 2nd paragraph: "because an end-point is adding" > s/is adding/adds > > -3, 3rd paragraph: "Thus an RTP header extension for carrying SDES items > like CNAME is a powerful combination..." > What combination do you have in mind? When in combination with 6051? Or > do you just mean to say it's a powerful tool? Actually the combination of CNAME and RFC6051. I guess, that last sentence should be focused on only motivating CNAME, rather than attempting to state that certain SDES items are very useful at startup, for example see CNAME. > > -3, 4th paragraph: > s/does provide/provides > > -3, 2nd to last paragraph: > > You mean to say that that the MID spec already defines the header > extension, not that _this_ draft defined it, right? Yes. > > -4.2.2, 2nd paragraph:"If the packet expansion cannot be taken into > account..." > Do you mean "... is not taken into account..."? Nope, but we should rewrite the sentence. If the header extension is not taken into account its packet expansion can cause MTU issue. > > -5, first bullet: > Consider reordering this a bit: “… the URN sub-space…for SDES items”" > > -5.1, first paragraph:"some additional considerations are provided here > that needs to be considered" > noun/verb disagreement (considerations is plural, needs is singular) > > - 5.1, 2nd paragraph: "security and privacy consideration" > s/consideration/considerations > > -6, 2nd paragraph: > "If the security level is different, > it is important to consider the security properties as the worst in > each aspect for the different configurations." > > I find this sentence hard to understand. I _think_ you are saying that > the protection of the SDES item is equal to the protection of RTCP or > that of the RTP header extension, whichever is lower? > Yes, if different the one that provides lower protection per aspect is the one that gives that particular aspect. Then one have to combine the aspects to consider the complete properties. 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 Mon Dec 14 18:13:06 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 2A3B11AD371 for ; Mon, 14 Dec 2015 18:13:06 -0800 (PST) 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 ZpqSO-MR3mHE for ; Mon, 14 Dec 2015 18:13:04 -0800 (PST) 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 0E24F1AD363 for ; Mon, 14 Dec 2015 18:13:03 -0800 (PST) Received: from [10.0.1.10] (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 tBF2CwYQ053457 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 14 Dec 2015 20:12:59 -0600 (CST) (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.10] From: "Ben Campbell" To: Huangyihong Date: Mon, 14 Dec 2015 20:12:59 -0600 Message-ID: In-Reply-To: <51E6A56BD6A85142B9D172C87FC3ABBB8649E7A2@nkgeml501-mbs.china.huawei.com> References: <51E6A56BD6A85142B9D172C87FC3ABBB8649E7A2@nkgeml501-mbs.china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed Content-Transfer-Encoding: quoted-printable X-Mailer: MailMate (1.9.3r5187) Archived-At: Cc: "avtext@ietf.org" Subject: Re: [avtext] New Version Notification for draft-ietf-avtext-splicing-notification-03.txt X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Dec 2015 02:13:06 -0000 Hi Rachel, Apologies, I missed your email about the update until this afternoon. In general, I don't think you have completely succeeded in removing the = need for a normative dependency on RFC 6828. There is text that says a = splicer can be a 6828 mixer, but there's no provision for cases where it = is not. That text needs clarification to say that 6828 is an example of = how one might do splicing, but other approaches would still need the = splicing interval information, and can still use this draft. 1.1: This section still depends on 6828 for terminology. If that terminology = is required to understand this draft, then you still need a normative = dependency. If you wish to avoid that, you will need to define the terms = in this draft. - section 2: -- general: I'm still not entirely comfortable with the assumption of = the existence of a way to get the interval to the substitutive source. = Yes, there may be proprietary interfaces, or the substitutive source = could be integrated with either the main source or the splicer. But do = such interfaces already exist? Are we expecting people to do something = they aren't already doing? It comes down to the question, do you think = people will deploy this solution if we don't define the other part? I assume the answer is yes, in which case it would be useful to have = some text about _why_ we think this is useful without a standardized = "source to substitutive source" interface. It might also be worth = considering why, if such things already exist, they can't also be used = for the "source-to-splicer" interface. -- paragraph 3: I see the new sentence about the clock depending on the = codec. Does this mean the requirements for clock resolution and skew = limits depend on the codec? - 3.2: Does "in-band NTP formatted timestamps" mean intervals sent in the RTP = header extension? - 5: -- 3rd paragraph: The text "If a mixer works as the splicer [RFC6828] = still seems to depend on RFC 6828 to define what a splicer is. -- 4th paragraph: Am I correct to assume any such translation or = reporting would be the responsibility of the mixer? Is the mixer = expected to know if the senders want to detect problems? -- 5th paragraph: This talks about the splicer detecting a failure. The = previous paragraph talked about senders detecting failures. Is that an = intentional shift in perspective? Do you really expect out-of-band = signaling here, or is falling back to payload specific mechanisms or = abandonment not more likely? - 7: -- 1st paragraph: This still depends on 6828 for security = considerations. And now that we have the possibility that 6828 is _not_ = used, what are there not similar considerations for whatever other = mechanism is used? Since those are not documented elsewhere, they will = need to be documented here. -- 2nd paragraph: The text says that SRTP does not encrypt header = extensions. But it can, as mentioned in paragraph 3. -- 3rd paragraph: The phrase "To avoid invalid substitutive contents are = inserted..." still does not make sense. Consider "To avoid the = insertion of invalid substitutive content..." On 26 Nov 2015, at 21:10, Huangyihong (Rachel) wrote: > Dear all, > > This new version aims to solve the comments during the AD review. > > BR, > Rachel > > > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: Friday, November 27, 2015 11:00 AM > To: Deng Lingli; Roni Even; Xiajinwei; Huangyihong (Rachel); Lingli = > Deng > Subject: New Version Notification for = > draft-ietf-avtext-splicing-notification-03.txt > > > A new version of I-D, draft-ietf-avtext-splicing-notification-03.txt > has been successfully submitted by Rachel Huang and posted to the IETF = > repository. > > Name: draft-ietf-avtext-splicing-notification > Revision: 03 > Title: RTP/RTCP extension for RTP Splicing Notification > Document date: 2015-11-27 > Group: avtext > Pages: 18 > URL: = > https://www.ietf.org/internet-drafts/draft-ietf-avtext-splicing-notific= ation-03.txt > Status: = > https://datatracker.ietf.org/doc/draft-ietf-avtext-splicing-notificatio= n/ > Htmlized: = > https://tools.ietf.org/html/draft-ietf-avtext-splicing-notification-03 > Diff: = > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-avtext-splicing-notifica= tion-03 > > Abstract: > Content splicing is a process that replaces the content of a main > multimedia stream with other multimedia content, and delivers the > substitutive multimedia content to the receivers for a period of > time. The splicer is designed to handle RTP splicing and needs to > know when to start and end the splicing. > > This memo defines two RTP/RTCP extensions to indicate the splicing > related information to the splicer: an RTP header extension that > conveys the information in-band and an RTCP packet that conveys the > information out-of-band. > > > > > Please note that it may take a couple of minutes from the time of = > submission until the htmlized version and diff are available at = > tools.ietf.org. > > The IETF Secretariat > > _______________________________________________ > avtext mailing list > avtext@ietf.org > https://www.ietf.org/mailman/listinfo/avtext From nobody Mon Dec 14 22:52:13 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 654FE1B2B9B; Mon, 14 Dec 2015 22:52:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IOd9xHeCn7bd; Mon, 14 Dec 2015 22:52:09 -0800 (PST) Received: from mail-wm0-x22e.google.com (mail-wm0-x22e.google.com [IPv6:2a00:1450:400c:c09::22e]) (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 887CB1B2B9A; Mon, 14 Dec 2015 22:52:09 -0800 (PST) Received: by mail-wm0-x22e.google.com with SMTP id n186so10933933wmn.0; Mon, 14 Dec 2015 22:52:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:content-transfer-encoding:thread-index :content-language; bh=JAVCa3cmxOleCTxV6v9Jp6FTNzFBQabDub5vsTlm45k=; b=luMV6piPv1/HvscSnVnZ8mszuocvONbYVShb7gtZh1Jp9udiSaa05Z8u8ev+9C1o+T Flh1Tyw0J7OjYa6/sz7b2rgIukYYroxf3PkGMt7l1Q2cfzWYoW0ZNUOCc6TVqN++yPvR pPd5YGJTvQ5Sa3RCpfVWx/F2MZ+WGGYcxxdm1p8lp5M3LMZhaXFgDFX+547ABbTO/lC6 hqTmfDZMvBivuSCBpuFqyJPFS8lx8sNoAuefkdOlghROvQGxrKN3hRvzBmjtcnWLwmgl ueSYB3ntvcyRricCnPOmCplnvi1f3NM9GcPr+uJj55y02mvv+akA9OwKkA+BxJ4no9PM KSUQ== X-Received: by 10.28.131.141 with SMTP id f135mr2714218wmd.1.1450162328231; Mon, 14 Dec 2015 22:52:08 -0800 (PST) Received: from RoniPC (bzq-79-177-166-72.red.bezeqint.net. [79.177.166.72]) by smtp.gmail.com with ESMTPSA id w141sm19369897wmw.24.2015.12.14.22.52.06 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 14 Dec 2015 22:52:07 -0800 (PST) From: "Roni Even" To: "'Magnus Westerlund'" , "'Ben Campbell'" , , References: <3E1623EC-9FDB-40CE-BE9D-308D4D3BDBF4@nostrum.com> <566EEE69.20500@ericsson.com> In-Reply-To: <566EEE69.20500@ericsson.com> Date: Tue, 15 Dec 2015 08:52:04 +0200 Message-ID: <012f01d13705$1c877aa0$55966fe0$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQD7D6lOXC1Csv9UF9hSsRIL9rX2ewLgS4NUoGDmNsA= Content-Language: he Archived-At: Subject: Re: [avtext] AD Evaluation of draft-ietf-avtext-sdes-hdr-ext-02 X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Dec 2015 06:52:11 -0000 Inline Roni > > =3D=3D=3D Substantive: > > > > - 4.2.1, last paragraph: > > The guidance about RTP middleboxes seems to apply to header = extensions > > in general. Is this not already documented somewhere else? >=20 > Not, what I can remember. It is definitely not in RFC5285, and this = should be > considered to be added to RFC5285bis draft. >=20 > > [Roni Even] RFC5285bis allows mixing of one byte and two bytes header = extensions in the same RTP stream but not in the same RTP packet so I = think the issue here is that if an intermediary needs to add an header = extension to an existing packet it may be limited by current header = extensions, maybe it will be good to discuss it as guidelines for = senders in the RFC5285bis document Roni From nobody Tue Dec 15 03:49:02 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 A5B701A8755 for ; Tue, 15 Dec 2015 03:49:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 Ec3x30CcljmS for ; Tue, 15 Dec 2015 03:48:57 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 87C021A872F for ; Tue, 15 Dec 2015 03:48:56 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CFM01588; Tue, 15 Dec 2015 11:48:53 +0000 (GMT) Received: from LHREML707-CAH.china.huawei.com (10.201.5.199) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.235.1; Tue, 15 Dec 2015 11:48:52 +0000 Received: from NKGEML402-HUB.china.huawei.com (10.98.56.33) by lhreml707-cah.china.huawei.com (10.201.5.199) with Microsoft SMTP Server (TLS) id 14.3.235.1; Tue, 15 Dec 2015 11:48:52 +0000 Received: from NKGEML513-MBX.china.huawei.com ([169.254.1.252]) by nkgeml402-hub.china.huawei.com ([10.98.56.33]) with mapi id 14.03.0235.001; Tue, 15 Dec 2015 19:48:48 +0800 From: "Huangyihong (Rachel)" To: Ben Campbell Thread-Topic: [avtext] New Version Notification for draft-ietf-avtext-splicing-notification-03.txt Thread-Index: AQHRNt4m3XkdErjQP0SXYPQ3EJ3j657Lwreg Date: Tue, 15 Dec 2015 11:48:47 +0000 Message-ID: <51E6A56BD6A85142B9D172C87FC3ABBB86E75E67@nkgeml513-mbx.china.huawei.com> References: <51E6A56BD6A85142B9D172C87FC3ABBB8649E7A2@nkgeml501-mbs.china.huawei.com> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.136.79.29] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020206.566FFE26.00A4, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.1.252, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 3c05e6644ee076aebeafa51468bee895 Archived-At: Cc: "avtext@ietf.org" Subject: Re: [avtext] New Version Notification for draft-ietf-avtext-splicing-notification-03.txt X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Dec 2015 11:49:00 -0000 Hi Ben, Please see my replies inline. BR, Rachel > -----Original Message----- > From: Ben Campbell [mailto:ben@nostrum.com] > Sent: Tuesday, December 15, 2015 10:13 AM > To: Huangyihong (Rachel) > Cc: avtext@ietf.org > Subject: Re: [avtext] New Version Notification for > draft-ietf-avtext-splicing-notification-03.txt >=20 > Hi Rachel, >=20 > Apologies, I missed your email about the update until this afternoon. >=20 > In general, I don't think you have completely succeeded in removing the n= eed > for a normative dependency on RFC 6828. There is text that says a splicer= can > be a 6828 mixer, but there's no provision for cases where it is not. That= text > needs clarification to say that 6828 is an example of how one might do sp= licing, > but other approaches would still need the splicing interval information, = and can > still use this draft. [Rachel]: Ok. Here are my proposal changes to address this issue: 1. In section 1, 2nd paragraph. I'll remove the reference, and give some = descriptions of the splicing scenario. 2. Section 1.1 , I will define some necessary terms and remove the refere= nce of 6828. 3. I'll leave the references in section 2, 1st paragraph and section 5, 3= rd paragraph as they are, because they are just described as examples. 4. Section 7, I'll remove the reference. See the reply to the 7th comment= s. What do you think? >=20 > 1.1: >=20 > This section still depends on 6828 for terminology. If that terminology > is required to understand this draft, then you still need a normative > dependency. If you wish to avoid that, you will need to define the terms > in this draft. >=20 [Rachel]: Ok. I will define some necessary terms and remove the reference o= f 6828 from section 1.1. > - section 2: >=20 > -- general: I'm still not entirely comfortable with the assumption of > the existence of a way to get the interval to the substitutive source. > Yes, there may be proprietary interfaces, or the substitutive source > could be integrated with either the main source or the splicer. But do > such interfaces already exist? Are we expecting people to do something > they aren't already doing? It comes down to the question, do you think > people will deploy this solution if we don't define the other part? >=20 > I assume the answer is yes, in which case it would be useful to have > some text about _why_ we think this is useful without a standardized > "source to substitutive source" interface. It might also be worth > considering why, if such things already exist, they can't also be used > for the "source-to-splicer" interface. [Rachel]: In implementations, both substitutive RTP sender and RTP sender a= re all ISP servers and controlled by the same ISP. There's no business mode= l that substitutive source will be provided by a 3rd-party due to security = issues. That's why we think it could be a proprietary interface between 2 s= ervers. However, for a splicer, it could be a network node, e.g., a mixer, = implemented near end users, which may be provided by a different access net= work provider, and can forward different advertisements to different users.= Standardizing this part will easily for operators to interact with these n= etwork nodes without complex proprietary negotiation between different part= ies. Does it make sense to you? I can propose some texts if you think it's usefu= l. >=20 >=20 > -- paragraph 3: I see the new sentence about the clock depending on the > codec. Does this mean the requirements for clock resolution and skew > limits depend on the codec? [Rachel]: Yes. They depend on the encoder the application is using. >=20 > - 3.2: >=20 > Does "in-band NTP formatted timestamps" mean intervals sent in the RTP > header extension? [Rachel]: Yes. >=20 > - 5: > -- 3rd paragraph: The text "If a mixer works as the splicer [RFC6828] > still seems to depend on RFC 6828 to define what a splicer is. [Rachel]: How about the following changing: " If a mixer works as the splicer as described in [RFC6828] and it follows = [RFC3550], " >=20 > -- 4th paragraph: Am I correct to assume any such translation or > reporting would be the responsibility of the mixer? Is the mixer > expected to know if the senders want to detect problems? [Rachel]: It's the responsibility of the splicer to detect a splicing failu= re. And if the senders want to detect problems is an implementation issue. = When a mixer works as a splicer, it's easy because failure can be detected = anyway as specified in [RFC6828]. When other middle boxes like translator w= ork as splicer, they should consider such translation if the implementation= requires the failure should be reported to the server. However, no such tr= anslations will not break the whole system. So we will specify it in this d= ocument. >=20 > -- 5th paragraph: This talks about the splicer detecting a failure. The > previous paragraph talked about senders detecting failures. Is that an > intentional shift in perspective? Do you really expect out-of-band > signaling here, or is falling back to payload specific mechanisms or > abandonment not more likely? [Rachel]: It's always the splicer detecting a failure. The previous paragra= ph talks about how to make the senders learn the failure. This paragraph ta= lks about when learning the failure, what they should do. When learning the failure, there are 3 options here: one is to leave as it = is. Two, the sender stops inserting any splicing intervals. Three, the send= er negotiates with the splicer to fall back to payload specific mechanism. = This negotiation is expected to be out-of-band signaling. >=20 > - 7: >=20 > -- 1st paragraph: This still depends on 6828 for security > considerations. And now that we have the possibility that 6828 is _not_ > used, what are there not similar considerations for whatever other > mechanism is used? Since those are not documented elsewhere, they will > need to be documented here. [Rachel]: Good point. Actually, I think the splicer will be either a mixer = of a translator.=20 How about the following texts adding to Section 7 as the 2nd paragraph? OLD " The security considerations of the RTP specification [RFC3550] and the general mechanism for RTP header extensions [RFC5285] apply. If the RTP splicing mechanism described in [RFC6828] is in use, its security considerations also apply. " NEW " The security considerations of the RTP specification [RFC3550] and the general mechanism for RTP header extensions [RFC5285] apply. The spl= icer MUST either be a mixer or a translator, and has all the security consi= derations on these two standard RTP intermediaries.=20 " >=20 > -- 2nd paragraph: The text says that SRTP does not encrypt header > extensions. But it can, as mentioned in paragraph 3. [Rachel]: How about the following change: OLD " In Secure Real-time Transport Protocol (SRTP)[RFC3711], RTP header extensions are authenticated but not encrypted. For a malicious endpoint without the key, it can observe the splicing time in the RTP header, and it can intercept the substitutive content and even replace it with a different one if the substitutive stream does not use any security like SRTP and the splicer does not authenticate the main and substitutive content sources. " NEW "=20 Since the mechanism introduced in this document is not dependent on any RTP= payload-level hints for finding the splicing in and out points, Secure Rea= l-Time Transport Protocol (SRTP) [3711] can be used to provide confidential= ity of the RTP payload while leaving the RTP header in the clear so that th= e splicer can still carry out splicing without keying materials. However, f= or a malicious endpoint without the key, it can observe the splicing time i= n the RTP header, and it can intercept the substitutive content and even re= place it with a different one if the substitutive stream does not use any s= ecurity like SRTP and the splicer does not authenticate the main and substi= tutive content sources. " >=20 > -- 3rd paragraph: The phrase "To avoid invalid substitutive contents are > inserted..." still does not make sense. Consider "To avoid the > insertion of invalid substitutive content..." [Rachel]: Will change it. >=20 >=20 > On 26 Nov 2015, at 21:10, Huangyihong (Rachel) wrote: >=20 > > Dear all, > > > > This new version aims to solve the comments during the AD review. > > > > BR, > > Rachel > > > > > > -----Original Message----- > > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > > Sent: Friday, November 27, 2015 11:00 AM > > To: Deng Lingli; Roni Even; Xiajinwei; Huangyihong (Rachel); Lingli > > Deng > > Subject: New Version Notification for > > draft-ietf-avtext-splicing-notification-03.txt > > > > > > A new version of I-D, draft-ietf-avtext-splicing-notification-03.txt > > has been successfully submitted by Rachel Huang and posted to the IETF > > repository. > > > > Name: draft-ietf-avtext-splicing-notification > > Revision: 03 > > Title: RTP/RTCP extension for RTP Splicing Notification > > Document date: 2015-11-27 > > Group: avtext > > Pages: 18 > > URL: > > > https://www.ietf.org/internet-drafts/draft-ietf-avtext-splicing-notificat= ion-03.t > xt > > Status: > > https://datatracker.ietf.org/doc/draft-ietf-avtext-splicing-notificatio= n/ > > Htmlized: > > https://tools.ietf.org/html/draft-ietf-avtext-splicing-notification-03 > > Diff: > > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-avtext-splicing-notifica= tion-03 > > > > Abstract: > > Content splicing is a process that replaces the content of a main > > multimedia stream with other multimedia content, and delivers the > > substitutive multimedia content to the receivers for a period of > > time. The splicer is designed to handle RTP splicing and needs to > > know when to start and end the splicing. > > > > This memo defines two RTP/RTCP extensions to indicate the splicing > > related information to the splicer: an RTP header extension that > > conveys the information in-band and an RTCP packet that conveys the > > information out-of-band. > > > > > > > > > > Please note that it may take a couple of minutes from the time of > > submission until the htmlized version and diff are available at > > tools.ietf.org. > > > > The IETF Secretariat > > > > _______________________________________________ > > avtext mailing list > > avtext@ietf.org > > https://www.ietf.org/mailman/listinfo/avtext From nobody Fri Dec 18 14:41:35 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 998481B3995; Fri, 18 Dec 2015 14:37:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 B6oWcFF0kIRb; Fri, 18 Dec 2015 14:37:35 -0800 (PST) Received: from alum-mailsec-scanner-4.mit.edu (alum-mailsec-scanner-4.mit.edu [18.7.68.15]) by ietfa.amsl.com (Postfix) with ESMTP id 63DAB1B39B4; Fri, 18 Dec 2015 14:37:27 -0800 (PST) X-AuditID: 1207440f-f79df6d000007c0f-4c-56748aa62911 Received: from outgoing-alum.mit.edu (OUTGOING-ALUM.MIT.EDU [18.7.68.33]) by alum-mailsec-scanner-4.mit.edu (Symantec Messaging Gateway) with SMTP id 5A.9C.31759.6AA84765; Fri, 18 Dec 2015 17:37:26 -0500 (EST) Received: from Paul-Kyzivats-MacBook-Pro.local (c-73-218-51-154.hsd1.ma.comcast.net [73.218.51.154]) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.13.8/8.12.4) with ESMTP id tBIMbPcs003063 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 18 Dec 2015 17:37:26 -0500 From: Paul Kyzivat To: draft-ietf-xrblock-independent-burst-gap-discard.all@ietf.org Message-ID: <56748AA4.4010105@alum.mit.edu> Date: Fri, 18 Dec 2015 17:37:24 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpgleLIzCtJLcpLzFFi42IRYndR1F3WVRJm8PGWocXHezdYLU5PkLKY uvwxi8XTRztYHFg8liz5yRTAGMVtk5RYUhacmZ6nb5fAnbHr6032gvvMFV1vbBsYvzJ1MXJy SAiYSEyf08sGYYtJXLi3Hsjm4hASuMwo8WFKN5TzlEni1s85LCBVbAJaEnMO/QezhQW8JO7N mMkIYosIOEr0tH9iBGlgFpjAKDFlzksgh4ODV0Bb4u2cIpAaFgFViecHvoD1igqkSUw93M0O YvMKCEqcnPkELM4sYCYxb/NDZghbXmL72znMExj5ZiEpm4WkbBaSsgWMzKsY5RJzSnN1cxMz c4pTk3WLkxPz8lKLdE30cjNL9FJTSjcxQkKQfwdj13qZQ4wCHIxKPLwGbMVhQqyJZcWVuYcY JTmYlER5t1aVhAnxJeWnVGYkFmfEF5XmpBYfYpTgYFYS4dXRAsrxpiRWVqUW5cOkpDlYlMR5 1Zeo+wkJpCeWpGanphakFsFkZTg4lCR473YANQoWpaanVqRl5pQgpJk4OEGGc0mJFKfmpaQW JZaWZMSDIi++GBh7ICkeoL2anSB7iwsSc4GiEK2nGHU5Fvy4vZZJiCUvPy9VSpyXEaRIAKQo ozQPbgUs4bxiFAf6WJj3E8glPMBkBTfpFdASJqAl83TBlpQkIqSkGhh3fN7xXKDk3+cTj7as sjVXPnut5/3brTaGG+fauc92W/1MaXk/P8fs3WqeQn4RHKcPnLpdozfhYfSa7Ov6qmq2XCIb wgtWrXZZ88F/s/63T5X3ty+rW7mJZdmyGIZDHw1+3fm570fkGa85chHVqTe7U1/bMm46t/Bl 6IkNn7VKnVN3JGiEeUxRUmIpzkg01GIuKk4EAPbHIj8TAwAA Archived-At: X-Mailman-Approved-At: Fri, 18 Dec 2015 14:41:33 -0800 Cc: SDP Directorate , "xrblock@ietf.org" , IETF MMUSIC WG Subject: [avtext] SDP review of draft-ietf-xrblock-independent-burst-gap-discard-00 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, 18 Dec 2015 22:37:36 -0000 I am the assigned SDP directorate reviewer for this draft. For background on the SDP directorate, please see the FAQ at http://www.ietf.org/iesg/directorate/sdp.html Summary: The SDP content of this draft is minimal: just two lines of SDP adding a new value as an alternative for a rule defined in RFC3611. Such as it is, this looks fine. As far as SDP is concerned this draft is ready to be published. Thanks, Paul Kyzivat, for the SDP Directorate From nobody Sun Dec 20 22:25:50 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 D5B841A89A2 for ; Sun, 20 Dec 2015 22:25:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 2grZSEzZtsHP for ; Sun, 20 Dec 2015 22:25:44 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0EFFE1A899F for ; Sun, 20 Dec 2015 22:25:43 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml406-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CFS17235; Mon, 21 Dec 2015 06:25:41 +0000 (GMT) Received: from LHREML708-CAH.china.huawei.com (10.201.5.202) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.235.1; Mon, 21 Dec 2015 06:25:40 +0000 Received: from nkgeml405-hub.china.huawei.com (10.98.56.36) by lhreml708-cah.china.huawei.com (10.201.5.202) with Microsoft SMTP Server (TLS) id 14.3.235.1; Mon, 21 Dec 2015 06:25:40 +0000 Received: from NKGEML513-MBX.china.huawei.com ([169.254.1.252]) by nkgeml405-hub.china.huawei.com ([10.98.56.36]) with mapi id 14.03.0235.001; Mon, 21 Dec 2015 14:25:35 +0800 From: "Huangyihong (Rachel)" To: Ben Campbell Thread-Topic: [avtext] New Version Notification for draft-ietf-avtext-splicing-notification-03.txt Thread-Index: AQHRNt4m3XkdErjQP0SXYPQ3EJ3j657LwreggAk0aXA= Date: Mon, 21 Dec 2015 06:25:34 +0000 Message-ID: <51E6A56BD6A85142B9D172C87FC3ABBB86E76EED@nkgeml513-mbx.china.huawei.com> References: <51E6A56BD6A85142B9D172C87FC3ABBB8649E7A2@nkgeml501-mbs.china.huawei.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.136.79.29] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020205.56779B66.000A, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.1.252, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 3c05e6644ee076aebeafa51468bee895 Archived-At: Cc: "avtext@ietf.org" Subject: Re: [avtext] New Version Notification for draft-ietf-avtext-splicing-notification-03.txt X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Dec 2015 06:25:49 -0000 Hi Ben, After some further considerations, some of the following proposals are upda= ted. Please see inline. I'll submit a new version if you agree with the changes. BR, Rachel > -----Original Message----- > From: Huangyihong (Rachel) > Sent: Tuesday, December 15, 2015 7:49 PM > To: 'Ben Campbell' > Cc: avtext@ietf.org > Subject: RE: [avtext] New Version Notification for > draft-ietf-avtext-splicing-notification-03.txt >=20 > Hi Ben, >=20 > Please see my replies inline. >=20 > BR, > Rachel >=20 >=20 > > -----Original Message----- > > From: Ben Campbell [mailto:ben@nostrum.com] > > Sent: Tuesday, December 15, 2015 10:13 AM > > To: Huangyihong (Rachel) > > Cc: avtext@ietf.org > > Subject: Re: [avtext] New Version Notification for > > draft-ietf-avtext-splicing-notification-03.txt > > > > Hi Rachel, > > > > Apologies, I missed your email about the update until this afternoon. > > > > In general, I don't think you have completely succeeded in removing > > the need for a normative dependency on RFC 6828. There is text that > > says a splicer can be a 6828 mixer, but there's no provision for cases > > where it is not. That text needs clarification to say that 6828 is an > > example of how one might do splicing, but other approaches would still > > need the splicing interval information, and can still use this draft. >=20 > [Rachel]: Ok. Here are my proposal changes to address this issue: >=20 > 1. In section 1, 2nd paragraph. I'll remove the reference, and give som= e > descriptions of the splicing scenario. [Rachel]: Maybe rephrasing it as RF6828 gives an example of how to do this = for RTP, rather than just removing the reference entirely. OLD: " [SCTE35] provides a method that encapsulates the Splicing Interval inside the MPEG2-TS layer in cable TV systems. But in the RTP splicing scenario described in [RFC6828], the mixer designed as the splicer has to decode the RTP packets and search for the Splicing Interval inside the payloads. The need for such processing increases the workload of the mixer and limits the number of RTP sessions the mixer can support. " NEW: " [SCTE35] provides a method that encapsulates the Splicing Interval inside the MPEG2-TS layer in cable TV systems. When transported in RTP, = an middle box designed as the splicer to decode the RTP packets and search = for the Splicing Interval inside the payloads is required. The middle box i= s either a translator or a mixer as described in [RFC6828]. The need for su= ch processing increases the workload of the middle box and limits the numbe= r of RTP sessions the middle box can support. " > 2. Section 1.1 , I will define some necessary terms and remove the refe= rence > of 6828. > 3. I'll leave the references in section 2, 1st paragraph and section 5,= 3rd > paragraph as they are, because they are just described as examples. > 4. Section 7, I'll remove the reference. See the reply to the 7th comme= nts. >=20 > What do you think? >=20 > > > > 1.1: > > > > This section still depends on 6828 for terminology. If that > > terminology is required to understand this draft, then you still need > > a normative dependency. If you wish to avoid that, you will need to > > define the terms in this draft. > > >=20 > [Rachel]: Ok. I will define some necessary terms and remove the reference= of > 6828 from section 1.1. >=20 > > - section 2: > > > > -- general: I'm still not entirely comfortable with the assumption of > > the existence of a way to get the interval to the substitutive source. > > Yes, there may be proprietary interfaces, or the substitutive source > > could be integrated with either the main source or the splicer. But do > > such interfaces already exist? Are we expecting people to do something > > they aren't already doing? It comes down to the question, do you think > > people will deploy this solution if we don't define the other part? > > > > I assume the answer is yes, in which case it would be useful to have > > some text about _why_ we think this is useful without a standardized > > "source to substitutive source" interface. It might also be worth > > considering why, if such things already exist, they can't also be used > > for the "source-to-splicer" interface. >=20 > [Rachel]: In implementations, both substitutive RTP sender and RTP sender= are > all ISP servers and controlled by the same ISP. There's no business model= that > substitutive source will be provided by a 3rd-party due to security issue= s. That's > why we think it could be a proprietary interface between 2 servers. Howev= er, > for a splicer, it could be a network node, e.g., a mixer, implemented nea= r end > users, which may be provided by a different access network provider, and = can > forward different advertisements to different users. Standardizing this p= art will > easily for operators to interact with these network nodes without complex > proprietary negotiation between different parties. >=20 > Does it make sense to you? I can propose some texts if you think it's use= ful. [Rachel]: After some discussions, we think it is still possible that substi= tutive RTP sender and main RTP sender are from different companies. These t= wo companies may have some business relationship. So maybe a standard proto= col for this interface would be good. However, it's okay not to have a stan= dard one because this interface might convey extra information rather than = just Splicing Interval. For example, some metadata about the stream of whic= h the content is being substituted, or the end users information. This kind= of information is proprietary and not something people want to standardize= . >=20 > > > > > > -- paragraph 3: I see the new sentence about the clock depending on > > the codec. Does this mean the requirements for clock resolution and > > skew limits depend on the codec? >=20 > [Rachel]: Yes. They depend on the encoder the application is using. > > > > - 3.2: > > > > Does "in-band NTP formatted timestamps" mean intervals sent in the RTP > > header extension? >=20 > [Rachel]: Yes. >=20 > > > > - 5: > > -- 3rd paragraph: The text "If a mixer works as the splicer [RFC6828] > > still seems to depend on RFC 6828 to define what a splicer is. >=20 > [Rachel]: How about the following changing: >=20 > " If a mixer works as the splicer as described in [RFC6828] and it follow= s > [RFC3550], " >=20 > > > > -- 4th paragraph: Am I correct to assume any such translation or > > reporting would be the responsibility of the mixer? Is the mixer > > expected to know if the senders want to detect problems? >=20 > [Rachel]: It's the responsibility of the splicer to detect a splicing fai= lure. And if > the senders want to detect problems is an implementation issue. When a mi= xer > works as a splicer, it's easy because failure can be detected anyway as > specified in [RFC6828]. When other middle boxes like translator work as s= plicer, > they should consider such translation if the implementation requires the = failure > should be reported to the server. However, no such translations will not = break > the whole system. So we will specify it in this document. >=20 > > > > -- 5th paragraph: This talks about the splicer detecting a failure. > > The previous paragraph talked about senders detecting failures. Is > > that an intentional shift in perspective? Do you really expect > > out-of-band signaling here, or is falling back to payload specific > > mechanisms or abandonment not more likely? >=20 > [Rachel]: It's always the splicer detecting a failure. The previous parag= raph > talks about how to make the senders learn the failure. This paragraph tal= ks > about when learning the failure, what they should do. > When learning the failure, there are 3 options here: one is to leave as i= t is. Two, > the sender stops inserting any splicing intervals. Three, the sender nego= tiates > with the splicer to fall back to payload specific mechanism. This negotia= tion is > expected to be out-of-band signaling. >=20 > > > > - 7: > > > > -- 1st paragraph: This still depends on 6828 for security > > considerations. And now that we have the possibility that 6828 is > > _not_ used, what are there not similar considerations for whatever > > other mechanism is used? Since those are not documented elsewhere, > > they will need to be documented here. >=20 > [Rachel]: Good point. Actually, I think the splicer will be either a mixe= r of a > translator. >=20 > How about the following texts adding to Section 7 as the 2nd paragraph? >=20 > OLD > " > The security considerations of the RTP specification [RFC3550] and > the general mechanism for RTP header extensions [RFC5285] apply. If > the RTP splicing mechanism described in [RFC6828] is in use, its > security considerations also apply. > " >=20 > NEW > " > The security considerations of the RTP specification [RFC3550] and > the general mechanism for RTP header extensions [RFC5285] apply. The > splicer MUST either be a mixer or a translator, and has all the security > considerations on these two standard RTP intermediaries. > " [Rachel]: We think the previous proposal is not good enough. Please see fol= lowing proposal NEW " The security considerations of the RTP specification [RFC3550] and the gene= ral mechanism for RTP header extensions [RFC5285] apply. The splicer MUST e= ither be a mixer or a translator, and has all the security considerations o= n these two standard RTP intermediaries. However, the splicer replaces some= content with other content in RTP packet, thus breaking any RTP-level end-= to-end security, such as source authentication and integrity protection. Security goals to have source authentication all the way from the RTP main = sender to the receiver through the splicer is not possible with splicing an= d any existing solutions. A new solution can theoretically be developed tha= t enables indentifying the participating entities and what each provides, i= .e., the different media sources, man and substituting, and the splicer pro= viding the RTP-level integration of the media payloads in a common timeline= and synchronization context. " And integrity protection is discussed in the text I proposed in previous ma= il for the next comment, plus the last 2 paragraphs of Section 6 in the dra= ft. > > > > -- 2nd paragraph: The text says that SRTP does not encrypt header > > extensions. But it can, as mentioned in paragraph 3. >=20 > [Rachel]: How about the following change: >=20 > OLD > " > In Secure Real-time Transport Protocol (SRTP)[RFC3711], RTP header > extensions are authenticated but not encrypted. For a malicious > endpoint without the key, it can observe the splicing time in the RTP > header, and it can intercept the substitutive content and even > replace it with a different one if the substitutive stream does not > use any security like SRTP and the splicer does not authenticate the > main and substitutive content sources. > " >=20 > NEW > " > Since the mechanism introduced in this document is not dependent on any R= TP > payload-level hints for finding the splicing in and out points, Secure Re= al-Time > Transport Protocol (SRTP) [3711] can be used to provide confidentiality o= f the > RTP payload while leaving the RTP header in the clear so that the splicer= can > still carry out splicing without keying materials. However, for a malicio= us > endpoint without the key, it can observe the splicing time in the RTP hea= der, > and it can intercept the substitutive content and even replace it with a = different > one if the substitutive stream does not use any security like SRTP and th= e > splicer does not authenticate the main and substitutive content sources. = " >=20 [Rachel]: This proposal will be the discussion for integrity protection iss= ue. > > > > -- 3rd paragraph: The phrase "To avoid invalid substitutive contents > > are inserted..." still does not make sense. Consider "To avoid the > > insertion of invalid substitutive content..." >=20 > [Rachel]: Will change it. >=20 > > > > > > On 26 Nov 2015, at 21:10, Huangyihong (Rachel) wrote: > > > > > Dear all, > > > > > > This new version aims to solve the comments during the AD review. > > > > > > BR, > > > Rachel > > > > > > > > > -----Original Message----- > > > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > > > Sent: Friday, November 27, 2015 11:00 AM > > > To: Deng Lingli; Roni Even; Xiajinwei; Huangyihong (Rachel); Lingli > > > Deng > > > Subject: New Version Notification for > > > draft-ietf-avtext-splicing-notification-03.txt > > > > > > > > > A new version of I-D, draft-ietf-avtext-splicing-notification-03.txt > > > has been successfully submitted by Rachel Huang and posted to the > > > IETF repository. > > > > > > Name: draft-ietf-avtext-splicing-notification > > > Revision: 03 > > > Title: RTP/RTCP extension for RTP Splicing Notification > > > Document date: 2015-11-27 > > > Group: avtext > > > Pages: 18 > > > URL: > > > > > https://www.ietf.org/internet-drafts/draft-ietf-avtext-splicing-notifi > > cation-03.t > > xt > > > Status: > > > https://datatracker.ietf.org/doc/draft-ietf-avtext-splicing-notifica > > > tion/ > > > Htmlized: > > > https://tools.ietf.org/html/draft-ietf-avtext-splicing-notification- > > > 03 > > > Diff: > > > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-avtext-splicing-notifi= c > > > ation-03 > > > > > > Abstract: > > > Content splicing is a process that replaces the content of a main > > > multimedia stream with other multimedia content, and delivers the > > > substitutive multimedia content to the receivers for a period of > > > time. The splicer is designed to handle RTP splicing and needs to > > > know when to start and end the splicing. > > > > > > This memo defines two RTP/RTCP extensions to indicate the splicing > > > related information to the splicer: an RTP header extension that > > > conveys the information in-band and an RTCP packet that conveys the > > > information out-of-band. > > > > > > > > > > > > > > > Please note that it may take a couple of minutes from the time of > > > submission until the htmlized version and diff are available at > > > tools.ietf.org. > > > > > > The IETF Secretariat > > > > > > _______________________________________________ > > > avtext mailing list > > > avtext@ietf.org > > > https://www.ietf.org/mailman/listinfo/avtext From nobody Mon Dec 21 16:51:30 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 992FD1ACC81 for ; Mon, 21 Dec 2015 16:51:27 -0800 (PST) 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 TiwPS7ZvS9uX for ; Mon, 21 Dec 2015 16:51:24 -0800 (PST) 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 38D3B1AC3D2 for ; Mon, 21 Dec 2015 16:51:24 -0800 (PST) Received: from [10.0.1.10] (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 tBM0pIuW005589 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 21 Dec 2015 18:51:18 -0600 (CST) (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.10] From: "Ben Campbell" To: Huangyihong Date: Mon, 21 Dec 2015 18:51:17 -0600 Message-ID: <96CAFAC8-4643-4234-BFB8-7ED4E1910272@nostrum.com> In-Reply-To: <51E6A56BD6A85142B9D172C87FC3ABBB86E76EED@nkgeml513-mbx.china.huawei.com> References: <51E6A56BD6A85142B9D172C87FC3ABBB8649E7A2@nkgeml501-mbs.china.huawei.com> <51E6A56BD6A85142B9D172C87FC3ABBB86E76EED@nkgeml513-mbx.china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.3r5187) Archived-At: Cc: "avtext@ietf.org" Subject: Re: [avtext] New Version Notification for draft-ietf-avtext-splicing-notification-03.txt X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Dec 2015 00:51:27 -0000 Hi Rachel, More comments inline: Thanks! Ben. On 21 Dec 2015, at 0:25, Huangyihong (Rachel) wrote: > Hi Ben, > > After some further considerations, some of the following proposals are > updated. Please see inline. > I'll submit a new version if you agree with the changes. > > BR, > Rachel > > >> -----Original Message----- >> From: Huangyihong (Rachel) >> Sent: Tuesday, December 15, 2015 7:49 PM >> To: 'Ben Campbell' >> Cc: avtext@ietf.org >> Subject: RE: [avtext] New Version Notification for >> draft-ietf-avtext-splicing-notification-03.txt >> >> Hi Ben, >> >> Please see my replies inline. >> >> BR, >> Rachel >> >> >>> -----Original Message----- >>> From: Ben Campbell [mailto:ben@nostrum.com] >>> Sent: Tuesday, December 15, 2015 10:13 AM >>> To: Huangyihong (Rachel) >>> Cc: avtext@ietf.org >>> Subject: Re: [avtext] New Version Notification for >>> draft-ietf-avtext-splicing-notification-03.txt >>> >>> Hi Rachel, >>> >>> Apologies, I missed your email about the update until this >>> afternoon. >>> >>> In general, I don't think you have completely succeeded in removing >>> the need for a normative dependency on RFC 6828. There is text that >>> says a splicer can be a 6828 mixer, but there's no provision for >>> cases >>> where it is not. That text needs clarification to say that 6828 is >>> an >>> example of how one might do splicing, but other approaches would >>> still >>> need the splicing interval information, and can still use this >>> draft. >> >> [Rachel]: Ok. Here are my proposal changes to address this issue: >> >> 1. In section 1, 2nd paragraph. I'll remove the reference, and give >> some >> descriptions of the splicing scenario. > > [Rachel]: Maybe rephrasing it as RF6828 gives an example of how to do > this for RTP, rather than just removing the reference entirely. > OLD: > " > [SCTE35] provides a method that encapsulates the Splicing Interval > inside the MPEG2-TS layer in cable TV systems. But in the RTP > splicing scenario described in [RFC6828], the mixer designed as the > splicer has to decode the RTP packets and search for the Splicing > Interval inside the payloads. The need for such processing increases > the workload of the mixer and limits the number of RTP sessions the > mixer can support. > " > > NEW: > " > [SCTE35] provides a method that encapsulates the Splicing Interval > inside the MPEG2-TS layer in cable TV systems. When transported in > RTP, an middle box designed as the splicer to decode the RTP packets > and search for the Splicing Interval inside the payloads is required. > The middle box is either a translator or a mixer as described in > [RFC6828]. The need for such processing increases the workload of the > middle box and limits the number of RTP sessions the middle box can > support. > " > I don't see how this change addresses the issue. But this particular citation is not the main problem. By itself, it could be read as and informational. The bigger problems are in 1.1, where this draft says the terminology in 6828 applies to this document. Maybe you removed the use of that terminoligy, but 1.1 still says it applies. The Splicing Interval is still defined in terms of 6828. The security considerations section removed the normative dependency by saying "If the...mechanisms applies...". But without the normative reference, I don't think the security considerations are complete. That is, the idea of splicing _in_general_ has security considerations documented in 6828. If you don't normatively depend on 6828, then they need to be normatively referenced from somewhere else, or they need to be described here. >> 2. Section 1.1 , I will define some necessary terms and remove the >> reference >> of 6828. >> 3. I'll leave the references in section 2, 1st paragraph and section >> 5, 3rd >> paragraph as they are, because they are just described as examples. >> 4. Section 7, I'll remove the reference. See the reply to the 7th >> comments. >> >> What do you think? >> >>> >>> 1.1: >>> >>> This section still depends on 6828 for terminology. If that >>> terminology is required to understand this draft, then you still >>> need >>> a normative dependency. If you wish to avoid that, you will need to >>> define the terms in this draft. >>> >> >> [Rachel]: Ok. I will define some necessary terms and remove the >> reference of >> 6828 from section 1.1. >> >>> - section 2: >>> >>> -- general: I'm still not entirely comfortable with the assumption >>> of >>> the existence of a way to get the interval to the substitutive >>> source. >>> Yes, there may be proprietary interfaces, or the substitutive source >>> could be integrated with either the main source or the splicer. But >>> do >>> such interfaces already exist? Are we expecting people to do >>> something >>> they aren't already doing? It comes down to the question, do you >>> think >>> people will deploy this solution if we don't define the other part? >>> >>> I assume the answer is yes, in which case it would be useful to have >>> some text about _why_ we think this is useful without a standardized >>> "source to substitutive source" interface. It might also be worth >>> considering why, if such things already exist, they can't also be >>> used >>> for the "source-to-splicer" interface. >> >> [Rachel]: In implementations, both substitutive RTP sender and RTP >> sender are >> all ISP servers and controlled by the same ISP. There's no business >> model that >> substitutive source will be provided by a 3rd-party due to security >> issues. That's >> why we think it could be a proprietary interface between 2 servers. >> However, >> for a splicer, it could be a network node, e.g., a mixer, implemented >> near end >> users, which may be provided by a different access network provider, >> and can >> forward different advertisements to different users. Standardizing >> this part will >> easily for operators to interact with these network nodes without >> complex >> proprietary negotiation between different parties. >> >> Does it make sense to you? I can propose some texts if you think it's >> useful. > > [Rachel]: After some discussions, we think it is still possible that > substitutive RTP sender and main RTP sender are from different > companies. These two companies may have some business relationship. So > maybe a standard protocol for this interface would be good. However, > it's okay not to have a standard one because this interface might > convey extra information rather than just Splicing Interval. For > example, some metadata about the stream of which the content is being > substituted, or the end users information. This kind of information is > proprietary and not something people want to standardize. Okay. Let's leave it that way for IETF last call, and see if anyone else comments on it. > >> >>> >>> >>> -- paragraph 3: I see the new sentence about the clock depending on >>> the codec. Does this mean the requirements for clock resolution and >>> skew limits depend on the codec? >> >> [Rachel]: Yes. They depend on the encoder the application is using. Then I suggest the following: OLD: The common reference clock depends on the codec the media content using. NEW: The requirements for the common reference clock (e.g. resolution, skew) depend on the codec used by the media content. >>> >>> - 3.2: >>> >>> Does "in-band NTP formatted timestamps" mean intervals sent in the >>> RTP >>> header extension? >> >> [Rachel]: Yes. I suggest: OLD: Whether the in-band NTP-format timestamps are included or not, the main RTP sender MUST send the RTCP splicing notification message to provide robustness in case of any splicing-unaware middlebox that might strip RTP header extensions. NEW: Whether or not the timestamps are included in the RTP header extension, the main RTP sender MUST send the RTCP splicing notification message. This provide robustness in the case where a middlebox strips RTP header extensions. >> >>> >>> - 5: >>> -- 3rd paragraph: The text "If a mixer works as the splicer >>> [RFC6828] >>> still seems to depend on RFC 6828 to define what a splicer is. >> >> [Rachel]: How about the following changing: >> >> " If a mixer works as the splicer as described in [RFC6828] and it >> follows >> [RFC3550], " Let's back up on this a bit. A reference needs to be normative if a reader needs to read that reference to understand and/or implement the protocol. If a reader doesn't read 6828, they will probably not understand this paragraph. Is that important for understanding and implementing the draft in general? (I think it probably is at least somewhat important.) Can you restate the paragraph in a way that describes the concept even if the reader doesn't read 6828? (It's okay to use it as an example, as long as the reader can likely understand things without the example.) >> >>> >>> -- 4th paragraph: Am I correct to assume any such translation or >>> reporting would be the responsibility of the mixer? Is the mixer >>> expected to know if the senders want to detect problems? >> >> [Rachel]: It's the responsibility of the splicer to detect a splicing >> failure. And if >> the senders want to detect problems is an implementation issue. When >> a mixer >> works as a splicer, it's easy because failure can be detected anyway >> as >> specified in [RFC6828]. When other middle boxes like translator work >> as splicer, >> they should consider such translation if the implementation requires >> the failure >> should be reported to the server. However, no such translations will >> not break >> the whole system. So we will specify it in this document. Okay. Also, I suspect most splicers will not care whether the sender needs the reports; they will either translate this or not (maybe as a configurable option). I suggest removing "if the senders want to detect splicing problems." >> >>> >>> -- 5th paragraph: This talks about the splicer detecting a failure. >>> The previous paragraph talked about senders detecting failures. Is >>> that an intentional shift in perspective? Do you really expect >>> out-of-band signaling here, or is falling back to payload specific >>> mechanisms or abandonment not more likely? >> >> [Rachel]: It's always the splicer detecting a failure. The previous >> paragraph >> talks about how to make the senders learn the failure. This paragraph >> talks >> about when learning the failure, what they should do. >> When learning the failure, there are 3 options here: one is to leave >> as it is. Two, >> the sender stops inserting any splicing intervals. Three, the sender >> negotiates >> with the splicer to fall back to payload specific mechanism. This >> negotiation is >> expected to be out-of-band signaling. Okay. >> >>> >>> - 7: >>> >>> -- 1st paragraph: This still depends on 6828 for security >>> considerations. And now that we have the possibility that 6828 is >>> _not_ used, what are there not similar considerations for whatever >>> other mechanism is used? Since those are not documented elsewhere, >>> they will need to be documented here. >> >> [Rachel]: Good point. Actually, I think the splicer will be either a >> mixer of a >> translator. >> >> How about the following texts adding to Section 7 as the 2nd >> paragraph? >> >> OLD >> " >> The security considerations of the RTP specification [RFC3550] and >> the general mechanism for RTP header extensions [RFC5285] apply. If >> the RTP splicing mechanism described in [RFC6828] is in use, its >> security considerations also apply. >> " >> >> NEW >> " >> The security considerations of the RTP specification [RFC3550] and >> the general mechanism for RTP header extensions [RFC5285] apply. The >> splicer MUST either be a mixer or a translator, and has all the >> security >> considerations on these two standard RTP intermediaries. >> " > > [Rachel]: We think the previous proposal is not good enough. Please > see following proposal > > NEW > " > The security considerations of the RTP specification [RFC3550] and the > general mechanism for RTP header extensions [RFC5285] apply. The > splicer MUST either be a mixer or a translator, and has all the > security considerations on these two standard RTP intermediaries. > However, the splicer replaces some content with other content in RTP > packet, thus breaking any RTP-level end-to-end security, such as > source authentication and integrity protection. This paragraph is helpful. Can you include a reference for "mixer" and "translator"? (I think this will be the first mention of "translator", and I'm not sure "mixer" has a reference or definition elsewhere in the draft.) > > Security goals to have source authentication all the way from the RTP > main sender to the receiver through the splicer is not possible with > splicing and any existing solutions. A new solution can theoretically > be developed that enables indentifying the participating entities and > what each provides, i.e., the different media sources, man and > substituting, and the splicer providing the RTP-level integration of > the media payloads in a common timeline and synchronization context. This is on the right track. For the first sentence, I suggest: "End to end source authentication is not possible with any known existing splicing solution." I'm not quite sure what properties you have in mind for the theoretical new solution. Also, does the work in PERC offer any value here? > " > And integrity protection is discussed in the text I proposed in > previous mail for the next comment, plus the last 2 paragraphs of > Section 6 in the draft. > >>> >>> -- 2nd paragraph: The text says that SRTP does not encrypt header >>> extensions. But it can, as mentioned in paragraph 3. >> >> [Rachel]: How about the following change: >> >> OLD >> " >> In Secure Real-time Transport Protocol (SRTP)[RFC3711], RTP header >> extensions are authenticated but not encrypted. For a malicious >> endpoint without the key, it can observe the splicing time in the RTP >> header, and it can intercept the substitutive content and even >> replace it with a different one if the substitutive stream does not >> use any security like SRTP and the splicer does not authenticate the >> main and substitutive content sources. >> " >> >> NEW >> " >> Since the mechanism introduced in this document is not dependent on >> any RTP >> payload-level hints for finding the splicing in and out points, >> Secure Real-Time >> Transport Protocol (SRTP) [3711] can be used to provide >> confidentiality of the >> RTP payload while leaving the RTP header in the clear so that the >> splicer can >> still carry out splicing without keying materials. However, for a >> malicious >> endpoint without the key, it can observe the splicing time in the RTP >> header, >> and it can intercept the substitutive content and even replace it >> with a different >> one if the substitutive stream does not use any security like SRTP >> and the >> splicer does not authenticate the main and substitutive content >> sources. " Does this assume both sources use the same SRTP key, or that the receiving endpoint is aware which key to use for any given packet? Are either ever likely to be the case? Doesn't the part about a malicious endpoint (should that be middlebox?) viewing the splicing time in the RTP header depend on the header extension that contains the splicing interval _not_ being encrypted? >> > > [Rachel]: This proposal will be the discussion for integrity > protection issue. > [...] From nobody Tue Dec 22 14:27:40 2015 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57BBC1A8902; Tue, 22 Dec 2015 14:27:39 -0800 (PST) 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 er5yWk47JCPF; Tue, 22 Dec 2015 14:27:37 -0800 (PST) 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 7897B1A6EFC; Tue, 22 Dec 2015 14:27:37 -0800 (PST) Received: from [10.0.1.10] (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 tBMMRXSX053855 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 22 Dec 2015 16:27:33 -0600 (CST) (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.10] From: "Ben Campbell" To: "Magnus Westerlund" Date: Tue, 22 Dec 2015 16:27:33 -0600 Message-ID: <5F9DEC6A-A6AC-4948-AE28-EE75978C1027@nostrum.com> In-Reply-To: <566EEE69.20500@ericsson.com> References: <3E1623EC-9FDB-40CE-BE9D-308D4D3BDBF4@nostrum.com> <566EEE69.20500@ericsson.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Mailer: MailMate (1.9.3r5187) Archived-At: Cc: draft-ietf-avtext-sdes-hdr-ext.all@ietf.org, avtext@ietf.org Subject: Re: [avtext] AD Evaluation of draft-ietf-avtext-sdes-hdr-ext-02 X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Dec 2015 22:27:39 -0000 On 14 Dec 2015, at 10:29, Magnus Westerlund wrote: > Hi Ben, > > See below my answer and feedback on your evaluation. I think it is > fairly clear that we need to do a new revision prior to the IETF last > call. > > Den 2015-12-12 kl. 05:11, skrev Ben Campbell: >> Hi, >> >> Here is my AD evaluation of draft-ietf-avtext-sdes-hdr-ext-02. I have >> a >> few questions and comments that I would like to resolve prior to IETF >> last call, as well as some editorial comments that can be handled >> whenever is convenient: >> >> Thanks! >> >> Ben. >> >> === Substantive: >> >> - 4.2.1, last paragraph: >> The guidance about RTP middleboxes seems to apply to header >> extensions >> in general. Is this not already documented somewhere else? > > Not, what I can remember. It is definitely not in RFC5285, and this > should be considered to be added to RFC5285bis draft. > Okay. >> >> - 4.2.6, 2nd paragraph: "... issues can be avoid by performing ..." >> >> Do you mean "... the receiver performing..."? > > Yes, these are all receiver side actions. That's probably obvious, but it wouldn't hurt to be explicit. > >> >> - 5.1: >> >> Please elaborate on what you mean by sub-space. I don't think RFC >> 5285 >> contemplated this idea. How would IANA indicate that things in this >> sub-space have additional rules beyond those of 5285? Or more >> concretely, how do we indicate that >> urn:ietf:params:rtp-hdrext:sdes:cname is bound by the rules for >> urn:ietf:params:rtp-hdrext:sdes? >> > > What I mean is that any URN starting with > "urn:ietf:params:rtp-hdrext:sdes" is under these rules. And I think > that IANA is already handling different set of rules for different > parts of the URN space. The rules for "urn:ietf" is different from the > ones for "urn:ietf:params:rtp-hdrext". Okay, let me take another approach. RFC 5285 has a set of registration rules for the RTP compact header extension registry. This draft says that some entries that contain the string "hdrext:sdes"..." will have additional rules. But this doesn't create a new registry, does it? Is there some expectation that a new registrant who wants to register "...hdrext:sdes:foo" will even read this draft? I'm curious why the group did not define a new table for things like "urn:ietf:params:rtp-hdrext:sdes:foo", with the additional registration rules from this draft. > >> Paragraph 2 says "preferably in a publically available reference." I >> think that's a hard requirement in 5285. This seems to relax that--I >> assume that is not the intent. Security considerations are also >> already >> required by 5285 (but there is no mention of privacy considerations.) > > Yes, you are right, for RTP header extensions RFC5285 do require > publicly available specification. I think we might have primarily > looked at the rules for SDES items which are according to RFC3550: > > To facilitate review of requests and to > promote shared use of new types among multiple applications, requests > for registration of new values must be documented in an RFC or other > permanent and readily available reference such as the product of > another cooperative standards body (e.g., ITU-T). Other requests may > also be accepted, under the advice of a "designated expert." > > Which gives some leeway for non public available references which > RFC5285 do. > > I think the easy fix here is to be clear that it must fulfil the rules > of RFC5285, and then have this document in addition note the need for > 1) being a registered SDES item (implies following the rules in > RFC3550 for SDES items), 2) being explicit about privacy > considerations and 3) the motivation for timely deliver. I agree. > >> >> -6, general: >> >> The requirements here are pretty abstract. Would it make sense to say >> something to the effect of "If you SRTP it you MUST encrypt the RTP >> extension header"? > > In RTP sessions where any type of confidentiality protection is > enabled for RTCP, the SDES item header extensions MUST also be > protected per default. This implies that to provide confidentiality, > users of SRTP need to implement encrypted header extensions per > [RFC6904]. > > I thought the above was basically saying this, with the exception that > it gates on encrypting RTCP, rather than using SRTP. And I think you > actually want to consider if using just SRTP for integrity protection, > i.e. null encryption shall force encryption on the SDES header > extension. I am fine to edit this to say that if you confidentiality > protect either RTP or RTCP, then you MUST confidentiality protect also > this header extension. > > But, I think for the SRTP parties, if we want to be clearer then we > should simpley add "and use" to the second sentence. That works for me. > >> >> -6, paragraph 2: >> - "In RTP sessions where any type of confidentiality protection is >> enabled for RTCP, the SDES item header extensions MUST also be >> protected per default. " >> >> Why “per default”? That tells me that an implementation would, if >> not >> configured otherwise, protect the header extension if it protected >> RTCP. >> Do you intend to allow the “configured otherwise” loophole? > > I am happy to loose the "per default" here. I can't remember a reason > for it. Okay. > >> >> - "users of SRTP need to implement encrypted header extensions" >> Do you mean to say “implementers must also implement” or “users >> must >> also use”? Or both? > > The first sentence says you must use it if RTCP is protected. If using > SRTP, then this implies that you must implement and use RFC6904 to > achieve the normative statement. And as said above, I am happy to > clarify that this is really implement and use. Okay. > >> >> - "Commonly, it is expected that the same security level is >> applied to RTCP packets carrying SDES items, and to an RTP header >> extension containing SDES items. " >> >> The phrase “Commonly, it is expected…” seems to water down the >> guidance. >> Any reason not to say SHOULD or MUST here? > > Yes, we can loose the "commonly ..." part. I think SHOULD is good, and > and basically ask the ones trying to invoke the exception to motivate > themselves. Okay. > >> >> - 6, paragraph 3: >> - "there SHOULD be strong >> requirements on integrity and source authentication" >> >> What needs to have that strong requirement? The specs for extensions >> in >> the sub-space? Or does this mean to say that "there SHOULD be strong >> integrity protection and source authentication"? > > The later. Okay. If it's not obvious, I propose removing "requirements on" [...] From nobody Tue Dec 22 18:02: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 B18AE1A6F82 for ; Tue, 22 Dec 2015 18:02:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 YvVqiEZrKqJF for ; Tue, 22 Dec 2015 18:02:40 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3135B1A1BDC for ; Tue, 22 Dec 2015 18:02:39 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CFU62163; Wed, 23 Dec 2015 02:02:36 +0000 (GMT) Received: from NKGEML402-HUB.china.huawei.com (10.98.56.33) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.235.1; Wed, 23 Dec 2015 02:02:35 +0000 Received: from NKGEML513-MBX.china.huawei.com ([169.254.1.252]) by nkgeml402-hub.china.huawei.com ([10.98.56.33]) with mapi id 14.03.0235.001; Wed, 23 Dec 2015 10:02:29 +0800 From: "Huangyihong (Rachel)" To: Ben Campbell Thread-Topic: [avtext] New Version Notification for draft-ietf-avtext-splicing-notification-03.txt Thread-Index: AQHRNt4m3XkdErjQP0SXYPQ3EJ3j657LwreggAk0aXCAALrCgIAAqqTw Date: Wed, 23 Dec 2015 02:02:28 +0000 Message-ID: <51E6A56BD6A85142B9D172C87FC3ABBB86E77423@nkgeml513-mbx.china.huawei.com> References: <51E6A56BD6A85142B9D172C87FC3ABBB8649E7A2@nkgeml501-mbs.china.huawei.com> <51E6A56BD6A85142B9D172C87FC3ABBB86E76EED@nkgeml513-mbx.china.huawei.com> <96CAFAC8-4643-4234-BFB8-7ED4E1910272@nostrum.com> In-Reply-To: <96CAFAC8-4643-4234-BFB8-7ED4E1910272@nostrum.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.136.79.29] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020205.567A00BD.0095, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.1.252, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 3c05e6644ee076aebeafa51468bee895 Archived-At: Cc: "avtext@ietf.org" Subject: Re: [avtext] New Version Notification for draft-ietf-avtext-splicing-notification-03.txt X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Dec 2015 02:02:44 -0000 Hi Ben, Inline, please. BR, Rachel > -----Original Message----- > From: Ben Campbell [mailto:ben@nostrum.com] > Sent: Tuesday, December 22, 2015 8:51 AM > To: Huangyihong (Rachel) > Cc: avtext@ietf.org > Subject: Re: [avtext] New Version Notification for > draft-ietf-avtext-splicing-notification-03.txt >=20 > Hi Rachel, >=20 > More comments inline: >=20 > Thanks! >=20 > Ben. >=20 > On 21 Dec 2015, at 0:25, Huangyihong (Rachel) wrote: >=20 > > Hi Ben, > > > > After some further considerations, some of the following proposals are > > updated. Please see inline. > > I'll submit a new version if you agree with the changes. > > > > BR, > > Rachel > > > > > >> -----Original Message----- > >> From: Huangyihong (Rachel) > >> Sent: Tuesday, December 15, 2015 7:49 PM > >> To: 'Ben Campbell' > >> Cc: avtext@ietf.org > >> Subject: RE: [avtext] New Version Notification for > >> draft-ietf-avtext-splicing-notification-03.txt > >> > >> Hi Ben, > >> > >> Please see my replies inline. > >> > >> BR, > >> Rachel > >> > >> > >>> -----Original Message----- > >>> From: Ben Campbell [mailto:ben@nostrum.com] > >>> Sent: Tuesday, December 15, 2015 10:13 AM > >>> To: Huangyihong (Rachel) > >>> Cc: avtext@ietf.org > >>> Subject: Re: [avtext] New Version Notification for > >>> draft-ietf-avtext-splicing-notification-03.txt > >>> > >>> Hi Rachel, > >>> > >>> Apologies, I missed your email about the update until this > >>> afternoon. > >>> > >>> In general, I don't think you have completely succeeded in removing > >>> the need for a normative dependency on RFC 6828. There is text that > >>> says a splicer can be a 6828 mixer, but there's no provision for > >>> cases where it is not. That text needs clarification to say that > >>> 6828 is an example of how one might do splicing, but other > >>> approaches would still need the splicing interval information, and > >>> can still use this draft. > >> > >> [Rachel]: Ok. Here are my proposal changes to address this issue: > >> > >> 1. In section 1, 2nd paragraph. I'll remove the reference, and give > >> some descriptions of the splicing scenario. > > > > [Rachel]: Maybe rephrasing it as RF6828 gives an example of how to do > > this for RTP, rather than just removing the reference entirely. > > OLD: > > " > > [SCTE35] provides a method that encapsulates the Splicing Interval > > inside the MPEG2-TS layer in cable TV systems. But in the RTP splicing > > scenario described in [RFC6828], the mixer designed as the splicer has > > to decode the RTP packets and search for the Splicing Interval inside > > the payloads. The need for such processing increases the workload of > > the mixer and limits the number of RTP sessions the mixer can support. > > " > > > > NEW: > > " > > [SCTE35] provides a method that encapsulates the Splicing Interval > > inside the MPEG2-TS layer in cable TV systems. When transported in > > RTP, an middle box designed as the splicer to decode the RTP packets > > and search for the Splicing Interval inside the payloads is required. > > The middle box is either a translator or a mixer as described in > > [RFC6828]. The need for such processing increases the workload of the > > middle box and limits the number of RTP sessions the middle box can > > support. > > " > > >=20 > I don't see how this change addresses the issue. But this particular cita= tion is > not the main problem. By itself, it could be read as and informational. T= he > bigger problems are in 1.1, where this draft says the terminology in 6828 > applies to this document. Maybe you removed the use of that terminoligy, = but > 1.1 still says it applies. The Splicing Interval is still defined in term= s of 6828. [Rachel]: Will removing the use of terminology in Section 1.1, and adding s= ome necessary terms like "Splicing-In Point, Splicing-Out Point, Splicer, M= ain RTP sender, substitutive RTP sender" in this document. >=20 > The security considerations section removed the normative dependency by > saying "If the...mechanisms applies...". But without the normative refere= nce, I > don't think the security considerations are complete. That is, the idea o= f > splicing _in_general_ has security considerations documented in 6828. If = you > don't normatively depend on 6828, then they need to be normatively > referenced from somewhere else, or they need to be described here. [Rachel]: I have described some security considerations explicitly in this = document due to the splicing in general mechanisms, which I already propose= d in the last mail. Actually 6828 introduce a solution on how to splice, an= d this document specifies a mechanism on when to splice. The security consi= deration for them are different. So it is possible for the security conside= ration of when to splice to independent on the security consideration of ho= w to splice, provided it is normatively stated that there will be some secu= rity considerations of how to splice that need to be taken into account. >=20 > >> 2. Section 1.1 , I will define some necessary terms and remove the > >> reference of 6828. > >> 3. I'll leave the references in section 2, 1st paragraph and section > >> 5, 3rd paragraph as they are, because they are just described as > >> examples. > >> 4. Section 7, I'll remove the reference. See the reply to the 7th > >> comments. > >> > >> What do you think? > >> > >>> > >>> 1.1: > >>> > >>> This section still depends on 6828 for terminology. If that > >>> terminology is required to understand this draft, then you still > >>> need a normative dependency. If you wish to avoid that, you will > >>> need to define the terms in this draft. > >>> > >> > >> [Rachel]: Ok. I will define some necessary terms and remove the > >> reference of > >> 6828 from section 1.1. > >> > >>> - section 2: > >>> > >>> -- general: I'm still not entirely comfortable with the assumption > >>> of the existence of a way to get the interval to the substitutive > >>> source. > >>> Yes, there may be proprietary interfaces, or the substitutive source > >>> could be integrated with either the main source or the splicer. But > >>> do such interfaces already exist? Are we expecting people to do > >>> something they aren't already doing? It comes down to the question, > >>> do you think people will deploy this solution if we don't define the > >>> other part? > >>> > >>> I assume the answer is yes, in which case it would be useful to have > >>> some text about _why_ we think this is useful without a standardized > >>> "source to substitutive source" interface. It might also be worth > >>> considering why, if such things already exist, they can't also be > >>> used for the "source-to-splicer" interface. > >> > >> [Rachel]: In implementations, both substitutive RTP sender and RTP > >> sender are all ISP servers and controlled by the same ISP. There's no > >> business model that substitutive source will be provided by a > >> 3rd-party due to security issues. That's why we think it could be a > >> proprietary interface between 2 servers. > >> However, > >> for a splicer, it could be a network node, e.g., a mixer, implemented > >> near end users, which may be provided by a different access network > >> provider, and can forward different advertisements to different > >> users. Standardizing this part will easily for operators to interact > >> with these network nodes without complex proprietary negotiation > >> between different parties. > >> > >> Does it make sense to you? I can propose some texts if you think it's > >> useful. > > > > [Rachel]: After some discussions, we think it is still possible that > > substitutive RTP sender and main RTP sender are from different > > companies. These two companies may have some business relationship. So > > maybe a standard protocol for this interface would be good. However, > > it's okay not to have a standard one because this interface might > > convey extra information rather than just Splicing Interval. For > > example, some metadata about the stream of which the content is being > > substituted, or the end users information. This kind of information is > > proprietary and not something people want to standardize. >=20 > Okay. Let's leave it that way for IETF last call, and see if anyone else = comments > on it. > [Rachel]: Okay. > > > >> > >>> > >>> > >>> -- paragraph 3: I see the new sentence about the clock depending on > >>> the codec. Does this mean the requirements for clock resolution and > >>> skew limits depend on the codec? > >> > >> [Rachel]: Yes. They depend on the encoder the application is using. >=20 > Then I suggest the following: > OLD: > The common reference clock depends on the codec the media content using. > NEW: > The requirements for the common reference clock (e.g. resolution, skew) > depend on the codec used by the media content. [Rachel]: Okay. >=20 >=20 > >>> > >>> - 3.2: > >>> > >>> Does "in-band NTP formatted timestamps" mean intervals sent in the > >>> RTP > >>> header extension? > >> > >> [Rachel]: Yes. >=20 > I suggest: > OLD: > Whether the in-band NTP-format timestamps are included or not, the main > RTP sender MUST send the RTCP splicing notification message to provide > robustness in case of any splicing-unaware middlebox that might strip > RTP header extensions. > NEW: > Whether or not the timestamps are included in the RTP header extension, > the main RTP sender MUST send the RTCP splicing notification message. > This provide robustness in the case where a middlebox strips RTP header > extensions. [Rachel]: Okay. Thanks for the suggestion. >=20 > >> > >>> > >>> - 5: > >>> -- 3rd paragraph: The text "If a mixer works as the splicer > >>> [RFC6828] > >>> still seems to depend on RFC 6828 to define what a splicer is. > >> > >> [Rachel]: How about the following changing: > >> > >> " If a mixer works as the splicer as described in [RFC6828] and it > >> follows > >> [RFC3550], " >=20 > Let's back up on this a bit. A reference needs to be normative if a > reader needs to read that reference to understand and/or implement the > protocol. If a reader doesn't read 6828, they will probably not > understand this paragraph. Is that important for understanding and > implementing the draft in general? (I think it probably is at least > somewhat important.) Can you restate the paragraph in a way that > describes the concept even if the reader doesn't read 6828? (It's okay > to use it as an example, as long as the reader can likely understand > things without the example.) >=20 > [Rachel]: How about following proposed rephrasing? OLD " If a mixer works as the splicer [RFC6828] and it follows [RFC3550], the RTP sender whose content is being passed to a downstream receiver will see the reception quality of its stream as received by the mixer and the reception quality of the processed stream as received by the receiver; The RTP sender whose content is not being passed to a downstream receiver will only see the reception quality of its stream as received by the mixer. In such a case, the main RTP sender can learn that splicing failed if it still sees the RTCP RR packets sent from downstream receivers when the splicing starts; In a similar manner, the substitutive sender can also learn that splicing failed if it does not receive any RTCP RR packets from downstream receivers when the splicing starts. Other cases where senders and receivers are in different RTCP domains may require translation of RTCP reports, or additional reporting, if the senders want to detect splicing problems. " NEW " The splicer can be implemented to have its own SSRC, and send RTCP receptio= n reports to the senders of the main and substitutive RTP streams. This all= ows the senders to detect problems on the path to the splicer. Alternativel= y, it is possible to implement the splicer such that it has no SSRC, and do= es not send RTCP reports; this prevents the senders from being able to moni= tor the quality to the path to the splicer.=20 If the splicer has an SSRC and sends its own RTCP reports, it can choose no= t to pass RTCP reports it receives from the receivers to the senders. This = will stop the senders from being able to monitor the quality of the paths f= rom the splicer to the receivers.=20 A splicer that has an SSRC can choose to pass RTCP reception reports from t= he receivers back to the senders, after modifications to account for the sp= licing. This will allow the senders the monitor the quality of the paths fr= om the splicer to the receivers. A splicer that does not have its own SSRC = has to forward and translation RTCP reports from the receiver, otherwise th= e senders will not see any receivers in the RTP session.=20 If the splicer is implemented following [RFC6828], it will have its own SSR= C and will send its own RTCP reports, and will forward translated RTCP repo= rts from the receivers. " > >> > >>> > >>> -- 4th paragraph: Am I correct to assume any such translation or > >>> reporting would be the responsibility of the mixer? Is the mixer > >>> expected to know if the senders want to detect problems? > >> > >> [Rachel]: It's the responsibility of the splicer to detect a splicing > >> failure. And if > >> the senders want to detect problems is an implementation issue. When > >> a mixer > >> works as a splicer, it's easy because failure can be detected anyway > >> as > >> specified in [RFC6828]. When other middle boxes like translator work > >> as splicer, > >> they should consider such translation if the implementation requires > >> the failure > >> should be reported to the server. However, no such translations will > >> not break > >> the whole system. So we will specify it in this document. >=20 > Okay. Also, I suspect most splicers will not care whether the sender > needs the reports; they will either translate this or not (maybe as a > configurable option). I suggest removing "if the senders want to detect > splicing problems." >=20 [Rachel]: Make sense to me. > >> > >>> > >>> -- 5th paragraph: This talks about the splicer detecting a failure. > >>> The previous paragraph talked about senders detecting failures. Is > >>> that an intentional shift in perspective? Do you really expect > >>> out-of-band signaling here, or is falling back to payload specific > >>> mechanisms or abandonment not more likely? > >> > >> [Rachel]: It's always the splicer detecting a failure. The previous > >> paragraph > >> talks about how to make the senders learn the failure. This paragraph > >> talks > >> about when learning the failure, what they should do. > >> When learning the failure, there are 3 options here: one is to leave > >> as it is. Two, > >> the sender stops inserting any splicing intervals. Three, the sender > >> negotiates > >> with the splicer to fall back to payload specific mechanism. This > >> negotiation is > >> expected to be out-of-band signaling. >=20 > Okay. >=20 > >> > >>> > >>> - 7: > >>> > >>> -- 1st paragraph: This still depends on 6828 for security > >>> considerations. And now that we have the possibility that 6828 is > >>> _not_ used, what are there not similar considerations for whatever > >>> other mechanism is used? Since those are not documented elsewhere, > >>> they will need to be documented here. > >> > >> [Rachel]: Good point. Actually, I think the splicer will be either a > >> mixer of a > >> translator. > >> > >> How about the following texts adding to Section 7 as the 2nd > >> paragraph? > >> > >> OLD > >> " > >> The security considerations of the RTP specification [RFC3550] and > >> the general mechanism for RTP header extensions [RFC5285] apply. If > >> the RTP splicing mechanism described in [RFC6828] is in use, its > >> security considerations also apply. > >> " > >> > >> NEW > >> " > >> The security considerations of the RTP specification [RFC3550] and > >> the general mechanism for RTP header extensions [RFC5285] apply. The > >> splicer MUST either be a mixer or a translator, and has all the > >> security > >> considerations on these two standard RTP intermediaries. > >> " > > > > [Rachel]: We think the previous proposal is not good enough. Please > > see following proposal > > > > NEW > > " > > The security considerations of the RTP specification [RFC3550] and the > > general mechanism for RTP header extensions [RFC5285] apply. The > > splicer MUST either be a mixer or a translator, and has all the > > security considerations on these two standard RTP intermediaries. > > However, the splicer replaces some content with other content in RTP > > packet, thus breaking any RTP-level end-to-end security, such as > > source authentication and integrity protection. >=20 > This paragraph is helpful. Can you include a reference for "mixer" and > "translator"? (I think this will be the first mention of "translator", > and I'm not sure "mixer" has a reference or definition elsewhere in the > draft.) [Rachel]: Mixer and translator are specified in RFC3550, it's already a nor= mative reference. I'll reference RFC3550 section 7 for clarity. > > > > Security goals to have source authentication all the way from the RTP > > main sender to the receiver through the splicer is not possible with > > splicing and any existing solutions. A new solution can theoretically > > be developed that enables indentifying the participating entities and > > what each provides, i.e., the different media sources, main and > > substituting, and the splicer providing the RTP-level integration of > > the media payloads in a common timeline and synchronization context. >=20 > This is on the right track. For the first sentence, I suggest: > "End to end source authentication is not possible with any known > existing splicing solution." [Rachel]: Good suggestion. >=20 > I'm not quite sure what properties you have in mind for the theoretical > new solution. Also, does the work in PERC offer any value here? [Rachel]: No, PERC is about protection from against stream modification and= impersonation by RTP middleboxes. A splicer is supposed to be a trusted mi= ddle box which can modify and impersonate the stream.=20 >=20 >=20 > > " > > And integrity protection is discussed in the text I proposed in > > previous mail for the next comment, plus the last 2 paragraphs of > > Section 6 in the draft. > > > >>> > >>> -- 2nd paragraph: The text says that SRTP does not encrypt header > >>> extensions. But it can, as mentioned in paragraph 3. > >> > >> [Rachel]: How about the following change: > >> > >> OLD > >> " > >> In Secure Real-time Transport Protocol (SRTP)[RFC3711], RTP header > >> extensions are authenticated but not encrypted. For a malicious > >> endpoint without the key, it can observe the splicing time in the RTP > >> header, and it can intercept the substitutive content and even > >> replace it with a different one if the substitutive stream does not > >> use any security like SRTP and the splicer does not authenticate the > >> main and substitutive content sources. > >> " > >> > >> NEW > >> " > >> Since the mechanism introduced in this document is not dependent on > >> any RTP > >> payload-level hints for finding the splicing in and out points, > >> Secure Real-Time > >> Transport Protocol (SRTP) [3711] can be used to provide > >> confidentiality of the > >> RTP payload while leaving the RTP header in the clear so that the > >> splicer can > >> still carry out splicing without keying materials. However, for a > >> malicious > >> endpoint without the key, it can observe the splicing time in the RTP > >> header, > >> and it can intercept the substitutive content and even replace it > >> with a different > >> one if the substitutive stream does not use any security like SRTP > >> and the > >> splicer does not authenticate the main and substitutive content > >> sources. " >=20 > Does this assume both sources use the same SRTP key, or that the > receiving endpoint is aware which key to use for any given packet? Are > either ever likely to be the case? [Rachel]: Either both sources use the same SRTP key, or the splicer decrypt= s and re-encrypts with a single key. >=20 > Doesn't the part about a malicious endpoint (should that be middlebox?) > viewing the splicing time in the RTP header depend on the header > extension that contains the splicing interval _not_ being encrypted? [Rachel]: Yes. Header extensions are not encrypted by default in SRTP. So t= his paragraph talks the case header extensions are not encrypted. And 3rd p= aragraph of section 7 talks about header extension encryption [RFC6904]. >=20 > >> > > > > [Rachel]: This proposal will be the discussion for integrity > > protection issue. > > >=20 > [...]