From nobody Sun Jul 2 17:50:38 2017 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAD9D12FEEB for ; Sun, 2 Jul 2017 17:50:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AkPwixmh7QWz for ; Sun, 2 Jul 2017 17:50:34 -0700 (PDT) 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 1A458127601 for ; Sun, 2 Jul 2017 17:50:33 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml705-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DJP60803; Mon, 03 Jul 2017 00:50:31 +0000 (GMT) Received: from NKGEML412-HUB.china.huawei.com (10.98.56.73) by lhreml705-cah.china.huawei.com (10.201.108.46) with Microsoft SMTP Server (TLS) id 14.3.301.0; Mon, 3 Jul 2017 01:50:30 +0100 Received: from NKGEML513-MBX.china.huawei.com ([169.254.1.25]) by nkgeml412-hub.china.huawei.com ([10.98.56.73]) with mapi id 14.03.0235.001; Mon, 3 Jul 2017 08:50:18 +0800 From: "Huangyihong (Rachel)" To: "Huangyihong (Rachel)" , "avt@ietf.org" Thread-Topic: [avtcore] WGLC for mux-category issue of draft-ietf-avtcore-rfc5285-bis-12 Thread-Index: AQHS85ZW2dPi4MG5PUypUr7A3hzISQ== Date: Mon, 3 Jul 2017 00:50:17 +0000 Message-ID: <51E6A56BD6A85142B9D172C87FC3ABBB9C4CD971@nkgeml513-mbx.china.huawei.com> References: <51E6A56BD6A85142B9D172C87FC3ABBB9C4CBF80@nkgeml513-mbx.china.huawei.com> In-Reply-To: <51E6A56BD6A85142B9D172C87FC3ABBB9C4CBF80@nkgeml513-mbx.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.240] Content-Type: multipart/alternative; boundary="_000_51E6A56BD6A85142B9D172C87FC3ABBB9C4CD971nkgeml513mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090204.595994D8.0016, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.1.25, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: e92e8bc03813e4d580bade7ff07ea0d1 Archived-At: Subject: Re: [AVTCORE] [avtcore] WGLC for mux-category issue of draft-ietf-avtcore-rfc5285-bis-12 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jul 2017 00:50:37 -0000 --_000_51E6A56BD6A85142B9D172C87FC3ABBB9C4CD971nkgeml513mbxchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Folks, Sorry about the typo. It should be draft-ietf-avtcore-rfc5285-bis-12. BR, Rachel From: avt [mailto:avt-bounces@ietf.org] On Behalf Of Huangyihong (Rachel) Sent: Thursday, June 29, 2017 2:05 PM To: avt@ietf.org Subject: [AVTCORE] [avtcore] WGLC for mux-category issue of draft-ietf-avtc= ore-rfc5282-bis-12 Hi Folks, As you may notice that there was a discussion for the mux category selectio= n for a=3Dextmap-allow-mixed in draft-ietf-avtcore-rfc5282-bis-12. This iss= ue was raised by Magnus when he was doing the shepherd work. See https://ma= ilarchive.ietf.org/arch/msg/avt/BaElJmDlmDtOaAcXKV_Rk5fARgk. This discussio= n happened after the WGLC and no formal conclusion was made then. And now the discussion is restarted in IESG review of this draft. The autho= r thinks it should be Normal to cover multiple cases, while some people thi= nk it's better to be Identical to make things simple. So this email is to have a one-week WGLC for this issue and deliver a forma= l conclusion to IESG: If you do not agree that "Normal" mux category should be used for a=3Dextma= p-allow-mixed, please express it in the mailing list before 8th July. Thanks. BR, Rachel (as the co-chair) --_000_51E6A56BD6A85142B9D172C87FC3ABBB9C4CD971nkgeml513mbxchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Folk= s,

&n= bsp;

Sorry a= bout the typo. It should be draft-ietf-avtcore-rfc5285-bis-12.

&n= bsp;

BR,

Rachel<= o:p>

&n= bsp;

From: avt [mailto:= avt-bounces@ietf.org] On Behalf Of Huangyihong (Rachel)
Sent: Thursday, June 29, 2017 2:05 PM
To: avt@ietf.org
Subject: [AVTCORE] [avtcore] WGLC for mux-category issue of draft-ie= tf-avtcore-rfc5282-bis-12

 

Hi Folks,

 

As you may notice that there wa= s a discussion for the mux category selection for a=3Dextmap-allow-mixed in= draft-ietf-avtcore-rfc5282-bis-12. This issue was raised by Magnus when he= was doing the shepherd work. See https://mailarchive.ietf.org/arch/msg/avt/BaElJmDlmDtOaAcXKV_Rk5fARg= k. This discussion happened after the WGLC and no formal conclusion was= made then.

 

And now the discussion is resta= rted in IESG review of this draft. The author thinks it should be Normal to= cover multiple cases, while some people think it’s better to be Iden= tical to make things simple.

 

So this email is to have a one-= week WGLC for this issue and deliver a formal conclusion to IESG:

 

If you do not agree that “= ;Normal” mux category should be used for a=3Dextmap-allow-mixed, plea= se express it in the mailing list before 8th July.

 

Thanks.

 

BR,

Rachel (as the co-chair)

--_000_51E6A56BD6A85142B9D172C87FC3ABBB9C4CD971nkgeml513mbxchi_-- From nobody Mon Jul 3 16:30:22 2017 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0078F1317E0 for ; Mon, 3 Jul 2017 16:30:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zWOEoC3uc--8 for ; Mon, 3 Jul 2017 16:30:18 -0700 (PDT) Received: from mx0b-00198e01.pphosted.com (mx0b-00198e01.pphosted.com [67.231.157.197]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B435A1317ED for ; Mon, 3 Jul 2017 16:29:54 -0700 (PDT) Received: from pps.filterd (m0073110.ppops.net [127.0.0.1]) by mx0b-00198e01.pphosted.com (8.16.0.20/8.16.0.20) with SMTP id v63NTsC0003649 for ; Mon, 3 Jul 2017 19:29:54 -0400 Received: from mail.vidyo.com (mail2.vidyo.com [162.209.16.214]) by mx0b-00198e01.pphosted.com with ESMTP id 2be6g41d6p-1 (version=TLSv1 cipher=AES128-SHA bits=128 verify=NOT) for ; Mon, 03 Jul 2017 19:29:53 -0400 Received: from 492132-EXCH1.vidyo.com ([fe80::50:56ff:fe85:4f77]) by 492133-EXCH2.vidyo.com ([fe80::50:56ff:fe85:6b62%13]) with mapi id 14.03.0195.001; Mon, 3 Jul 2017 18:29:53 -0500 From: Jonathan Lennox To: IETF AVTCore WG Thread-Topic: I-D Action: draft-lennox-avtcore-dtls-srtp-bigaes-01.txt Thread-Index: AQHS9FQCWmbl1to8BkWwHPYxiCWsBA== Date: Mon, 3 Jul 2017 23:29:52 +0000 Message-ID: <4C7A3DDB-861F-41CE-9EF6-BEC257A660CE@vidyo.com> References: <149912432290.16083.16328153067683186831@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [100.35.229.243] Content-Type: multipart/alternative; boundary="_000_4C7A3DDB861F41CE9EF6BEC257A660CEvidyocom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-03_14:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1707030384 Archived-At: Subject: [AVTCORE] Fwd: I-D Action: draft-lennox-avtcore-dtls-srtp-bigaes-01.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jul 2017 23:30:20 -0000 --_000_4C7A3DDB861F41CE9EF6BEC257A660CEvidyocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksIGFsbCDigJQNCg0KVGhpcyB1cGRhdGVzIHRoZSBkb2N1bWVudCB0aGF0IEkgYnJvdWdodCAo YXQgdGhlIGxhc3QgbWludXRlKSBhdCB0aGUgQ2hpY2FnbyBtZWV0aW5nLiAgVGhlIG9ubHkgY2hh bmdlIGZyb20gdmVyc2lvbiAtMDAgaXMgdG8gbWFrZSBpdHMgaW50ZW5kZWQgc3RhdHVzIEluZm9y bWF0aW9uYWwgcmF0aGVyIHRoYW4gUHJvcG9zZWQgU3RhbmRhcmQuDQoNCkNvbW1lbnRzIGFyZSB3 ZWxjb21lLg0KDQpCZWdpbiBmb3J3YXJkZWQgbWVzc2FnZToNCg0KRnJvbTogPGludGVybmV0LWRy YWZ0c0BpZXRmLm9yZzxtYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPj4NClN1YmplY3Q6 IEktRCBBY3Rpb246IGRyYWZ0LWxlbm5veC1hdnRjb3JlLWR0bHMtc3J0cC1iaWdhZXMtMDEudHh0 DQpEYXRlOiBKdWx5IDMsIDIwMTcgYXQgNzoyNToyMiBQTSBFRFQNClRvOiA8aS1kLWFubm91bmNl QGlldGYub3JnPG1haWx0bzppLWQtYW5ub3VuY2VAaWV0Zi5vcmc+Pg0KUmVzZW50LUZyb206IEpv bmF0aGFuIExlbm5veCA8bGVubm94QGNzLmNvbHVtYmlhLmVkdTxtYWlsdG86bGVubm94QGNzLmNv bHVtYmlhLmVkdT4+DQpSZXNlbnQtVG86IDxqb25hdGhhbkB2aWR5by5jb208bWFpbHRvOmpvbmF0 aGFuQHZpZHlvLmNvbT4+DQpSZXBseS1UbzogPGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZzxtYWls dG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPj4NCg0KDQpBIE5ldyBJbnRlcm5ldC1EcmFmdCBp cyBhdmFpbGFibGUgZnJvbSB0aGUgb24tbGluZSBJbnRlcm5ldC1EcmFmdHMgZGlyZWN0b3JpZXMu DQoNCg0KICAgICAgIFRpdGxlICAgICAgICAgICA6IERUTFMvU1JUUCBQcm90ZWN0aW9uIFByb2Zp bGVzIGZvciAyNTYtYml0IEFFUy1DVFIgRW5jcnlwdGlvbg0KICAgICAgIEF1dGhvciAgICAgICAg ICA6IEpvbmF0aGFuIExlbm5veA0KRmlsZW5hbWUgICAgICAgIDogZHJhZnQtbGVubm94LWF2dGNv cmUtZHRscy1zcnRwLWJpZ2Flcy0wMS50eHQNClBhZ2VzICAgICAgICAgICA6IDUNCkRhdGUgICAg ICAgICAgICA6IDIwMTctMDctMDMNCg0KQWJzdHJhY3Q6DQogIFRoaXMgbWVtbyBkZWZpbmVzIERh dGFncmFtIFRyYW5zcG9ydCBMYXllciBTZWN1cml0eSAoRFRMUykgU2VjdXJlDQogIFJlYWwtdGlt ZSBUcmFuc3BvcnQgUHJvdG9jb2wgKFNSVFApIFByb3RlY3Rpb24gUHJvZmlsZXMgZm9yIDI1Ni1i aXQNCiAgQWR2YW5jZWQgRW5jcnlwdGlvbiBTdGFuZGFyZCAoQUVTKSBDb3VudGVyIE1vZGUuDQoN Cg0KVGhlIElFVEYgZGF0YXRyYWNrZXIgc3RhdHVzIHBhZ2UgZm9yIHRoaXMgZHJhZnQgaXM6DQpo dHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1sZW5ub3gtYXZ0Y29yZS1kdGxz LXNydHAtYmlnYWVzLw0KDQpUaGVyZSBhcmUgYWxzbyBodG1saXplZCB2ZXJzaW9ucyBhdmFpbGFi bGUgYXQ6DQpodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtbGVubm94LWF2dGNvcmUt ZHRscy1zcnRwLWJpZ2Flcy0wMQ0KaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRt bC9kcmFmdC1sZW5ub3gtYXZ0Y29yZS1kdGxzLXNydHAtYmlnYWVzLTAxDQoNCkEgZGlmZiBmcm9t IHRoZSBwcmV2aW91cyB2ZXJzaW9uIGlzIGF2YWlsYWJsZSBhdDoNCmh0dHBzOi8vd3d3LmlldGYu b3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1sZW5ub3gtYXZ0Y29yZS1kdGxzLXNydHAtYmlnYWVzLTAx DQoNCg0KUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZy b20gdGhlIHRpbWUgb2Ygc3VibWlzc2lvbg0KdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5k IGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy4NCg0KSW50ZXJuZXQtRHJhZnRz IGFyZSBhbHNvIGF2YWlsYWJsZSBieSBhbm9ueW1vdXMgRlRQIGF0Og0KZnRwOi8vZnRwLmlldGYu b3JnL2ludGVybmV0LWRyYWZ0cy8NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCkktRC1Bbm5vdW5jZSBtYWlsaW5nIGxpc3QNCkktRC1Bbm5vdW5jZUBp ZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pLWQtYW5ub3Vu Y2UNCkludGVybmV0LURyYWZ0IGRpcmVjdG9yaWVzOiBodHRwOi8vd3d3LmlldGYub3JnL3NoYWRv dy5odG1sDQpvciBmdHA6Ly9mdHAuaWV0Zi5vcmcvaWV0Zi8xc2hhZG93LXNpdGVzLnR4dA0KDQoN Cg== --_000_4C7A3DDB861F41CE9EF6BEC257A660CEvidyocom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KSGksIGFsbCDigJQNCjxkaXYgY2xh c3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPlRoaXMgdXBkYXRlcyB0 aGUgZG9jdW1lbnQgdGhhdCBJIGJyb3VnaHQgKGF0IHRoZSBsYXN0IG1pbnV0ZSkgYXQgdGhlIENo aWNhZ28gbWVldGluZy4gJm5ic3A7VGhlIG9ubHkgY2hhbmdlIGZyb20gdmVyc2lvbiAtMDAgaXMg dG8gbWFrZSBpdHMgaW50ZW5kZWQgc3RhdHVzIEluZm9ybWF0aW9uYWwgcmF0aGVyIHRoYW4gUHJv cG9zZWQgU3RhbmRhcmQuPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2 Pg0KPGRpdiBjbGFzcz0iIj5Db21tZW50cyBhcmUgd2VsY29tZS48YnIgY2xhc3M9IiI+DQo8ZGl2 PjxiciBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGRpdiBj bGFzcz0iIj5CZWdpbiBmb3J3YXJkZWQgbWVzc2FnZTo8L2Rpdj4NCjxiciBjbGFzcz0iQXBwbGUt aW50ZXJjaGFuZ2UtbmV3bGluZSI+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tdG9wOiAwcHg7IG1hcmdp bi1yaWdodDogMHB4OyBtYXJnaW4tYm90dG9tOiAwcHg7IG1hcmdpbi1sZWZ0OiAwcHg7IiBjbGFz cz0iIj4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogLXdlYmtpdC1zeXN0ZW0tZm9udCwgSGVs dmV0aWNhIE5ldWUsIEhlbHZldGljYSwgc2Fucy1zZXJpZjsgY29sb3I6cmdiYSgwLCAwLCAwLCAx LjApOyIgY2xhc3M9IiI+PGIgY2xhc3M9IiI+RnJvbToNCjwvYj48L3NwYW4+PHNwYW4gc3R5bGU9 ImZvbnQtZmFtaWx5OiAtd2Via2l0LXN5c3RlbS1mb250LCBIZWx2ZXRpY2EgTmV1ZSwgSGVsdmV0 aWNhLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+Jmx0OzxhIGhyZWY9Im1haWx0bzppbnRlcm5ldC1k cmFmdHNAaWV0Zi5vcmciIGNsYXNzPSIiPmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZzwvYT4mZ3Q7 PGJyIGNsYXNzPSIiPg0KPC9zcGFuPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLXRvcDogMHB4 OyBtYXJnaW4tcmlnaHQ6IDBweDsgbWFyZ2luLWJvdHRvbTogMHB4OyBtYXJnaW4tbGVmdDogMHB4 OyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IC13ZWJraXQtc3lzdGVtLWZv bnQsIEhlbHZldGljYSBOZXVlLCBIZWx2ZXRpY2EsIHNhbnMtc2VyaWY7IGNvbG9yOnJnYmEoMCwg MCwgMCwgMS4wKTsiIGNsYXNzPSIiPjxiIGNsYXNzPSIiPlN1YmplY3Q6DQo8L2I+PC9zcGFuPjxz cGFuIHN0eWxlPSJmb250LWZhbWlseTogLXdlYmtpdC1zeXN0ZW0tZm9udCwgSGVsdmV0aWNhIE5l dWUsIEhlbHZldGljYSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPjxiIGNsYXNzPSIiPkktRCBBY3Rp b246IGRyYWZ0LWxlbm5veC1hdnRjb3JlLWR0bHMtc3J0cC1iaWdhZXMtMDEudHh0PC9iPjxiciBj bGFzcz0iIj4NCjwvc3Bhbj48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi10b3A6IDBweDsgbWFy Z2luLXJpZ2h0OiAwcHg7IG1hcmdpbi1ib3R0b206IDBweDsgbWFyZ2luLWxlZnQ6IDBweDsiIGNs YXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiAtd2Via2l0LXN5c3RlbS1mb250LCBI ZWx2ZXRpY2EgTmV1ZSwgSGVsdmV0aWNhLCBzYW5zLXNlcmlmOyBjb2xvcjpyZ2JhKDAsIDAsIDAs IDEuMCk7IiBjbGFzcz0iIj48YiBjbGFzcz0iIj5EYXRlOg0KPC9iPjwvc3Bhbj48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6IC13ZWJraXQtc3lzdGVtLWZvbnQsIEhlbHZldGljYSBOZXVlLCBIZWx2 ZXRpY2EsIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj5KdWx5IDMsIDIwMTcgYXQgNzoyNToyMiBQTSBF RFQ8YnIgY2xhc3M9IiI+DQo8L3NwYW4+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tdG9wOiAw cHg7IG1hcmdpbi1yaWdodDogMHB4OyBtYXJnaW4tYm90dG9tOiAwcHg7IG1hcmdpbi1sZWZ0OiAw cHg7IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogLXdlYmtpdC1zeXN0ZW0t Zm9udCwgSGVsdmV0aWNhIE5ldWUsIEhlbHZldGljYSwgc2Fucy1zZXJpZjsgY29sb3I6cmdiYSgw LCAwLCAwLCAxLjApOyIgY2xhc3M9IiI+PGIgY2xhc3M9IiI+VG86DQo8L2I+PC9zcGFuPjxzcGFu IHN0eWxlPSJmb250LWZhbWlseTogLXdlYmtpdC1zeXN0ZW0tZm9udCwgSGVsdmV0aWNhIE5ldWUs IEhlbHZldGljYSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPiZsdDs8YSBocmVmPSJtYWlsdG86aS1k LWFubm91bmNlQGlldGYub3JnIiBjbGFzcz0iIj5pLWQtYW5ub3VuY2VAaWV0Zi5vcmc8L2E+Jmd0 OzxiciBjbGFzcz0iIj4NCjwvc3Bhbj48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi10b3A6IDBw eDsgbWFyZ2luLXJpZ2h0OiAwcHg7IG1hcmdpbi1ib3R0b206IDBweDsgbWFyZ2luLWxlZnQ6IDBw eDsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiAtd2Via2l0LXN5c3RlbS1m b250LCBIZWx2ZXRpY2EgTmV1ZSwgSGVsdmV0aWNhLCBzYW5zLXNlcmlmOyBjb2xvcjpyZ2JhKDAs IDAsIDAsIDEuMCk7IiBjbGFzcz0iIj48YiBjbGFzcz0iIj5SZXNlbnQtRnJvbToNCjwvYj48L3Nw YW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiAtd2Via2l0LXN5c3RlbS1mb250LCBIZWx2ZXRp Y2EgTmV1ZSwgSGVsdmV0aWNhLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+Sm9uYXRoYW4gTGVubm94 ICZsdDs8YSBocmVmPSJtYWlsdG86bGVubm94QGNzLmNvbHVtYmlhLmVkdSIgY2xhc3M9IiI+bGVu bm94QGNzLmNvbHVtYmlhLmVkdTwvYT4mZ3Q7PGJyIGNsYXNzPSIiPg0KPC9zcGFuPjwvZGl2Pg0K PGRpdiBzdHlsZT0ibWFyZ2luLXRvcDogMHB4OyBtYXJnaW4tcmlnaHQ6IDBweDsgbWFyZ2luLWJv dHRvbTogMHB4OyBtYXJnaW4tbGVmdDogMHB4OyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9u dC1mYW1pbHk6IC13ZWJraXQtc3lzdGVtLWZvbnQsIEhlbHZldGljYSBOZXVlLCBIZWx2ZXRpY2Es IHNhbnMtc2VyaWY7IGNvbG9yOnJnYmEoMCwgMCwgMCwgMS4wKTsiIGNsYXNzPSIiPjxiIGNsYXNz PSIiPlJlc2VudC1UbzoNCjwvYj48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiAtd2Vi a2l0LXN5c3RlbS1mb250LCBIZWx2ZXRpY2EgTmV1ZSwgSGVsdmV0aWNhLCBzYW5zLXNlcmlmOyIg Y2xhc3M9IiI+Jmx0OzxhIGhyZWY9Im1haWx0bzpqb25hdGhhbkB2aWR5by5jb20iIGNsYXNzPSIi PmpvbmF0aGFuQHZpZHlvLmNvbTwvYT4mZ3Q7PGJyIGNsYXNzPSIiPg0KPC9zcGFuPjwvZGl2Pg0K PGRpdiBzdHlsZT0ibWFyZ2luLXRvcDogMHB4OyBtYXJnaW4tcmlnaHQ6IDBweDsgbWFyZ2luLWJv dHRvbTogMHB4OyBtYXJnaW4tbGVmdDogMHB4OyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9u dC1mYW1pbHk6IC13ZWJraXQtc3lzdGVtLWZvbnQsIEhlbHZldGljYSBOZXVlLCBIZWx2ZXRpY2Es IHNhbnMtc2VyaWY7IGNvbG9yOnJnYmEoMCwgMCwgMCwgMS4wKTsiIGNsYXNzPSIiPjxiIGNsYXNz PSIiPlJlcGx5LVRvOg0KPC9iPjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IC13ZWJr aXQtc3lzdGVtLWZvbnQsIEhlbHZldGljYSBOZXVlLCBIZWx2ZXRpY2EsIHNhbnMtc2VyaWY7IiBj bGFzcz0iIj4mbHQ7PGEgaHJlZj0ibWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyIgY2xh c3M9IiI+aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPC9hPiZndDs8YnIgY2xhc3M9IiI+DQo8L3Nw YW4+PC9kaXY+DQo8YnIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj48 YnIgY2xhc3M9IiI+DQpBIE5ldyBJbnRlcm5ldC1EcmFmdCBpcyBhdmFpbGFibGUgZnJvbSB0aGUg b24tbGluZSBJbnRlcm5ldC1EcmFmdHMgZGlyZWN0b3JpZXMuPGJyIGNsYXNzPSIiPg0KPGJyIGNs YXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7VGl0bGUgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7OiBEVExTL1NSVFAgUHJvdGVjdGlvbiBQcm9maWxlcyBmb3IgMjU2 LWJpdCBBRVMtQ1RSIEVuY3J5cHRpb248YnIgY2xhc3M9IiI+DQombmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtBdXRob3IgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7OiBKb25hdGhhbiBMZW5ub3g8YnIgY2xhc3M9IiI+ DQo8c3BhbiBjbGFzcz0iQXBwbGUtdGFiLXNwYW4iIHN0eWxlPSJ3aGl0ZS1zcGFjZTpwcmUiPjwv c3Bhbj5GaWxlbmFtZSAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs6 IGRyYWZ0LWxlbm5veC1hdnRjb3JlLWR0bHMtc3J0cC1iaWdhZXMtMDEudHh0PGJyIGNsYXNzPSIi Pg0KPHNwYW4gY2xhc3M9IkFwcGxlLXRhYi1zcGFuIiBzdHlsZT0id2hpdGUtc3BhY2U6cHJlIj48 L3NwYW4+UGFnZXMgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7OiA1PGJyIGNsYXNzPSIiPg0KPHNwYW4gY2xhc3M9IkFwcGxlLXRhYi1z cGFuIiBzdHlsZT0id2hpdGUtc3BhY2U6cHJlIj48L3NwYW4+RGF0ZSAmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs6IDIwMTct MDctMDM8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpBYnN0cmFjdDo8YnIgY2xhc3M9IiI+ DQombmJzcDsmbmJzcDtUaGlzIG1lbW8gZGVmaW5lcyBEYXRhZ3JhbSBUcmFuc3BvcnQgTGF5ZXIg U2VjdXJpdHkgKERUTFMpIFNlY3VyZTxiciBjbGFzcz0iIj4NCiZuYnNwOyZuYnNwO1JlYWwtdGlt ZSBUcmFuc3BvcnQgUHJvdG9jb2wgKFNSVFApIFByb3RlY3Rpb24gUHJvZmlsZXMgZm9yIDI1Ni1i aXQ8YnIgY2xhc3M9IiI+DQombmJzcDsmbmJzcDtBZHZhbmNlZCBFbmNyeXB0aW9uIFN0YW5kYXJk IChBRVMpIENvdW50ZXIgTW9kZS48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8YnIgY2xh c3M9IiI+DQpUaGUgSUVURiBkYXRhdHJhY2tlciBzdGF0dXMgcGFnZSBmb3IgdGhpcyBkcmFmdCBp czo8YnIgY2xhc3M9IiI+DQo8YSBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2Rv Yy9kcmFmdC1sZW5ub3gtYXZ0Y29yZS1kdGxzLXNydHAtYmlnYWVzLyIgY2xhc3M9IiI+aHR0cHM6 Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtbGVubm94LWF2dGNvcmUtZHRscy1zcnRw LWJpZ2Flcy88L2E+PGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KVGhlcmUgYXJlIGFsc28g aHRtbGl6ZWQgdmVyc2lvbnMgYXZhaWxhYmxlIGF0OjxiciBjbGFzcz0iIj4NCmh0dHBzOi8vdG9v bHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1sZW5ub3gtYXZ0Y29yZS1kdGxzLXNydHAtYmlnYWVzLTAx PGJyIGNsYXNzPSIiPg0KaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFm dC1sZW5ub3gtYXZ0Y29yZS1kdGxzLXNydHAtYmlnYWVzLTAxPGJyIGNsYXNzPSIiPg0KPGJyIGNs YXNzPSIiPg0KQSBkaWZmIGZyb20gdGhlIHByZXZpb3VzIHZlcnNpb24gaXMgYXZhaWxhYmxlIGF0 OjxiciBjbGFzcz0iIj4NCmh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1s ZW5ub3gtYXZ0Y29yZS1kdGxzLXNydHAtYmlnYWVzLTAxPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNz PSIiPg0KPGJyIGNsYXNzPSIiPg0KUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBs ZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlzc2lvbjxiciBjbGFzcz0iIj4NCnVu dGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMu aWV0Zi5vcmcuPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KSW50ZXJuZXQtRHJhZnRzIGFy ZSBhbHNvIGF2YWlsYWJsZSBieSBhbm9ueW1vdXMgRlRQIGF0OjxiciBjbGFzcz0iIj4NCmZ0cDov L2Z0cC5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIi Pg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnIgY2xh c3M9IiI+DQpJLUQtQW5ub3VuY2UgbWFpbGluZyBsaXN0PGJyIGNsYXNzPSIiPg0KSS1ELUFubm91 bmNlQGlldGYub3JnPGJyIGNsYXNzPSIiPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9pLWQtYW5ub3VuY2U8YnIgY2xhc3M9IiI+DQpJbnRlcm5ldC1EcmFmdCBkaXJlY3Rv cmllczogaHR0cDovL3d3dy5pZXRmLm9yZy9zaGFkb3cuaHRtbDxiciBjbGFzcz0iIj4NCm9yIGZ0 cDovL2Z0cC5pZXRmLm9yZy9pZXRmLzFzaGFkb3ctc2l0ZXMudHh0PGJyIGNsYXNzPSIiPg0KPGJy IGNsYXNzPSIiPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGJyIGNs YXNzPSIiPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_4C7A3DDB861F41CE9EF6BEC257A660CEvidyocom_-- From nobody Tue Jul 4 06:39:59 2017 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C22E1318A3 for ; Tue, 4 Jul 2017 06:39:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B21Ed8jDhR9k for ; Tue, 4 Jul 2017 06:39:56 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D9EBC13188C for ; Tue, 4 Jul 2017 06:39:55 -0700 (PDT) X-AuditID: c1b4fb30-aeec49c000001664-bb-595b9aaad0a1 Received: from ESESSHC001.ericsson.se (Unknown_Domain [153.88.183.21]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id CA.B9.05732.AAA9B595; Tue, 4 Jul 2017 15:39:54 +0200 (CEST) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.23) with Microsoft SMTP Server id 14.3.352.0; Tue, 4 Jul 2017 15:38:55 +0200 To: "Huangyihong (Rachel)" , "avt@ietf.org" References: <51E6A56BD6A85142B9D172C87FC3ABBB9C4CBF80@nkgeml513-mbx.china.huawei.com> From: Magnus Westerlund Message-ID: <71a9b15b-dd7e-f736-5be2-dd2bb88cad63@ericsson.com> Date: Tue, 4 Jul 2017 15:38:54 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <51E6A56BD6A85142B9D172C87FC3ABBB9C4CBF80@nkgeml513-mbx.china.huawei.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms090407050409040809070108" X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprCIsWRmVeSWpSXmKPExsUyM2K7qO6qWdGRBltW8Fq87FnJbrG08xS7 A5NHy5G3rB5LlvxkCmCK4rJJSc3JLEst0rdL4Mq4vaWo4OMCxoqWlgdMDYyr2hm7GDk5JARM JOZt/8vaxcjFISRwhFHideteJpCEkMAyRolLS5hBbGGBZImNp84DFXFwiAiESjS81IAoCZVY 1dICNodNwELi5o9GNhCbV8Be4v6k9awgNouAisT62dPBbFGBGIlrM++wQtQISpyc+YQFxOYU CJPYPvk3M8gNzALdjBI3P89nhVigLdHQ1ME6gZFvFpKeWcjqZgHdxAw04MNBGZAaZgFxiVtP 5jNB2GYS8zY/ZIawtSWWLXzNDFGuJrGsVQlVGMS2lpjx6yAbhK0oMaX7ITuEbSrx+uhHRgjb SOLdnkb2BYw8qxhFi1OLk3LTjYz0Uosyk4uL8/P08lJLNjEC4+fglt8GOxhfPnc8xCjAwajE w7tgZnSkEGtiWXFl7iFGFaA5jzasvsAoxZKXn5eqJMLLNRUozZuSWFmVWpQfX1Sak1p8iFGa g0VJnNdx34UIIYH0xJLU7NTUgtQimCwTB6dUAyPrjyiWc9MvirUv+/RGZ0rp6+LoQ0/dzW/l dHpFXbV/ciTJJrRX+sLz2SvOSBytk9SOOps2Qyrc+H3/R3bHJVvfXi76Z7vx1fnE2iuyudxu e39OrHwaxNh0hXV9VP2pCqPoM67P3hb630+atERRpD6htea7XvOWkDecItsN2VeVB+3abidS W6fEUpyRaKjFXFScCABerOdOpwIAAA== Archived-At: Subject: Re: [AVTCORE] [avtcore] WGLC for mux-category issue of draft-ietf-avtcore-rfc5282-bis-12 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jul 2017 13:39:58 -0000 --------------ms090407050409040809070108 Content-Type: multipart/alternative; boundary="------------26AC3912250262D1EE1FA7C3" Content-Language: en-US This is a multi-part message in MIME format. --------------26AC3912250262D1EE1FA7C3 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Hi, As one of the people who raised this before I want to explain why I=20 think it should identical makes more sense in this case. So first the assumptions. We are talking about offers in the context of=20 BUNDLE, i.e. multiple m=3D blocks are part of the same RTP session. Thus,= =20 these RTP streams generated will be received and sent by a particular=20 endpoint on the same transport port. Thus, the RTP stack processing will = be done by a single implementation. The single RTP stack implementation in a BUNDLE context is the basis for = my argument why it makes sense to use identical for extmap-allow-mixed.=20 The reason is that the entity on the specified IP address + port will be = a single implementation. Thus, I assume it is capable of handling the=20 switching between one and two-byte extension header formats without=20 issues. From this perspective identical appears very reasonable. The argument that David Singer brought to the table is that one may have = different capabilities for audio and video in an endpoint. So from my=20 perspective, this can only really work if the RTP payload content is=20 forwarded from the media producing entity and processed by the RTP stack = in such a way that they fulfill the RTP protocol specification. If=20 necessary, then rewriting could happen in that forwarding. But, that=20 should really not be needed. First the signaling that enable RTP header=20 extension usage can control its side of the negotiation and what IDs are = used. Remember that the ID space becomes joint over all extensions in=20 the RTP session, but different RTP streams and media blocks may have=20 only a subset of all header extensions configured. Thus, if audio stream = generator have this limitation that it only can process one-byte header=20 extensions, only IDs that fits the short can be assigned, if at all=20 possible. Thus, the only threat would be a sender that uses two-byte=20 headers when it is not needed. So the benefits as I see with identical is the following. For an BUNDLE=20 capable implementation where the implementation that adds header=20 extensions to the RTP packets is common, there is consistent=20 configuration for the RTP session, and the possibility to switch at any=20 point reduces the complexity of the code-base as no attempt to predict=20 or determine future needs are needed. Use what is currently needed. No=20 extra complexity for this modern implementations to deal with legacy=20 implementations into bundle scenario. That complexity of ensuring which IDs are used, and dealing with=20 adopting a legacy implementation to BUNDLE ends up with the ones doing=20 that choice, not everyone else. And this is for a case I at least see as = strange as all RTP streams will flow over the same 5-tuple for the=20 different media types. Thus, only implementation that attempts to=20 forward RTP packets without rewriting will have this issue. If one allows Normal, then one pushes the complexities of having to be=20 able to restrict some RTP streams in an RTP session to not switch=20 between one and two-byte headers. This will require code, and also more=20 signaling logic to deal with cases where this is offered. Thus, I think=20 using identical would simplify the system in general. And allow modern=20 BUNDLE capable implementations to becomes simpler, for a little cost for = the implementers that attempt to integrate legacy packet generators into = a single RTP session without a translation layer, or back to back RTP=20 sessions. Cheers Magnus Den 2017-06-29 kl. 08:05, skrev Huangyihong (Rachel): > > Hi Folks, > > As you may notice that there was a discussion for the mux category=20 > selection for a=3Dextmap-allow-mixed in=20 > draft-ietf-avtcore-rfc5282-bis-12. This issue was raised by Magnus=20 > when he was doing the shepherd work. See=20 > https://mailarchive.ietf.org/arch/msg/avt/BaElJmDlmDtOaAcXKV_Rk5fARgk. = > This discussion happened after the WGLC and no formal conclusion was=20 > made then. > > And now the discussion is restarted in IESG review of this draft. The=20 > author thinks it should be Normal to cover multiple cases, while some=20 > people think it=E2=80=99s better to be Identical to make things simple.= > > So this email is to have a one-week WGLC for this issue and deliver a=20 > formal conclusion to IESG: > > If you do not agree that =E2=80=9CNormal=E2=80=9D mux category should b= e used for=20 > a=3Dextmap-allow-mixed, please express it in the mailing list before=20 > 8^th July. > > Thanks. > > BR, > > Rachel (as the co-chair) > --=20 Magnus Westerlund ---------------------------------------------------------------------- Media Technologies, Ericsson Research ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Torshamnsgatan 23 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- --------------26AC3912250262D1EE1FA7C3 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Hi,

As one of the people who raised this before I want to explain why I think it should identical makes more sense in this case.

So first the assumptions. We are talking about offers in the context of BUNDLE, i.e. multiple m=3D blocks are part of the same RTP session. Thus, these RTP streams generated will be received and sent by a particular endpoint on the same transport port. Thus, the RTP stack processing will be done by a single implementation.

The single RTP stack implementation in a BUNDLE context is the basis for my argument why it makes sense to use identical for extmap-allow-mixed. The reason is that the entity on the specified IP address + port will be a single implementation. Thus, I assume it is capable of handling the switching between one and two-byte extension header formats without issues. From this perspective identical appears very reasonable.

The argument that David Singer brought to the table is that one may have different capabilities for audio and video in an endpoint. So from my perspective, this can only really work if the RTP payload content is forwarded from the media producing entity and processed by the RTP stack in such a way that they fulfill the RTP protocol specification. If necessary, then rewriting could happen in that forwarding. But, that should really not be needed. First the signaling that enable RTP header extension usage can control its side of the negotiation and what IDs are used. Remember that the ID space becomes joint over all extensions in the RTP session, but different RTP streams and media blocks may have only a subset of all header extensions configured. Thus, if audio stream generator have this limitation that it only can process one-byte header extensions, only IDs that fits the short can be assigned, if at all possible. Thus, the only threat would be a sender that uses two-byte headers when it is not needed.

So the benefits as I see with identical is the following. For an BUNDLE capable implementation where the implementation that adds header extensions to the RTP packets is common, there is consistent configuration for the RTP session, and the possibility to switch at any point reduces the complexity of the code-base as no attempt to predict or determine future needs are needed. Use what is currently needed. No extra complexity for this modern implementations to deal with legacy implementations into bundle scenario.

That complexity of ensuring which IDs are used, and dealing with adopting a legacy implementation to BUNDLE ends up with the ones doing that choice, not everyone else. And this is for a case I at least see as strange as all RTP streams will flow over the same 5-tuple for the different media types. Thus, only implementation that attempts to forward RTP packets without rewriting will have this issue.

If one allows Normal, then one pushes the complexities of having to be able to restrict some RTP streams in an RTP session to not switch between one and two-byte headers. This will require code, and also more signaling logic to deal with cases where this is offered. Thus, I think using identical would simplify the system in general. And allow modern BUNDLE capable implementations to becomes simpler, for a little cost for the implementers that attempt to integrate legacy packet generators into a single RTP session without a translation layer, or back to back RTP sessions.

Cheers

Magnus

Den 2017-06-29 kl. 08:05, skrev Huangyihong (Rachel):

Hi Folks,<= /span>

=C2=A0

As you may notice tha= t there was a discussion for the mux category selection for a=3Dextmap-allow-mixed in draft-ietf-avtcore-rfc5282-bis-12. This issue was raised by Magnus when he was doing the shepherd work. See https://mailarchive.ietf.org/arch/= msg/avt/BaElJmDlmDtOaAcXKV_Rk5fARgk. This discussion happened after the WGLC and no formal conclusion was made then.

=C2=A0

And now the discussio= n is restarted in IESG review of this draft. The author thinks it should be Normal to cover multiple cases, while some people think it=E2=80=99s better to be Identical to make thin= gs simple.

=C2=A0

So this email is to h= ave a one-week WGLC for this issue and deliver a formal conclusion to IESG:

=C2=A0

If you do not agree t= hat =E2=80=9CNormal=E2=80=9D mux category should be used for a=3Dextmap-allow-mixed, please express it in the mailing list= before 8th July.

=C2=A0

Thanks.

=C2=A0

BR,=

Rachel (as the co-cha= ir)


--=20

Magnus Westerlund=20

----------------------------------------------------------------------
Media Technologies, Ericsson Research
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Torshamnsgatan 23           | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@erics=
son.com
----------------------------------------------------------------------
  


--------------26AC3912250262D1EE1FA7C3--

--------------ms090407050409040809070108
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME-kryptografisk signatur

MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC
DLkwggX7MIID46ADAgECAhEA75oIXW3eBHJH2u7brn5gnDANBgkqhkiG9w0BAQUFADA6MREw
DwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2
MjAeFw0xNTAxMjMwODUwNTdaFw0xODAxMjMwODUwNTdaMHAxETAPBgNVBAoMCEVyaWNzc29u
MRowGAYDVQQDDBFNYWdudXMgV2VzdGVybHVuZDEtMCsGCSqGSIb3DQEJARYebWFnbnVzLndl
c3Rlcmx1bmRAZXJpY3Nzb24uY29tMRAwDgYDVQQFEwdlcmFtc3dkMIIBIjANBgkqhkiG9w0B
AQEFAAOCAQ8AMIIBCgKCAQEAkULrp/ViIWFfDbY2Ycew0bXJc2In2WNQbPORLyFXNpRhjhmg
ot5P/0w90T4HY0H6QayjIPK6qIGt1DBXwkq/QHoRsFZiDK9JDnk2WUDcqbJaHqMXvkhj4Jl4
KvonZ31T3NF/8OlcEjumVc8AUA6iccOeUva3TvL/EOqY3f4bsem4ER3KAcY/lTPWivSY+/Aw
vS64JjaANOHVhZ0LUj10JTe9CpdXB+1nMpqLFYkjse/2ahQuKyaBKhKJs35pSYijh3Ln+vMv
YUNEna2LjHvkCPVo5Oihylxjmd1OSDXND7125tgo/kB08RtaJ9u6PNw0CoUgA+d23UzVzlYg
aSJbhwIDAQABo4IBxDCCAcAwSAYDVR0fBEEwPzA9oDugOYY3aHR0cDovL2NybC50cnVzdC50
ZWxpYS5jb20vZXJpY3Nzb25ubGluZGl2aWR1YWxjYXYyLmNybDCBggYIKwYBBQUHAQEEdjB0
MCgGCCsGAQUFBzABhhxodHRwOi8vb2NzcDIudHJ1c3QudGVsaWEuY29tMEgGCCsGAQUFBzAC
hjxodHRwOi8vY2EudHJ1c3QudGVsaWFzb25lcmEuY29tL2VyaWNzc29ubmxpbmRpdmlkdWFs
Y2F2Mi5jZXIwKQYDVR0RBCIwIIEebWFnbnVzLndlc3Rlcmx1bmRAZXJpY3Nzb24uY29tMFUG
A1UdIAROMEwwSgYMKwYBBAGCDwIDAQESMDowOAYIKwYBBQUHAgEWLGh0dHBzOi8vcmVwb3Np
dG9yeS50cnVzdC50ZWxpYXNvbmVyYS5jb20vQ1BTMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggr
BgEFBQcDAjAdBgNVHQ4EFgQUwff+Y5pMEPJX7xortCv8deSKeQEwHwYDVR0jBBgwFoAUsQ3K
1Ea3r4YCwy9vBsoOdnF/SzcwDgYDVR0PAQH/BAQDAgWgMA0GCSqGSIb3DQEBBQUAA4ICAQBy
rk0JhGgu9Fd/0Fg1cMhSa882HMQZWQLT1V4PFQpU6t2an8xaqT5JsxOpuxb+WxwpKG+UDbzQ
cWgcb/DPW3Mc0AvhTFII1qAYf6Smkq6SOD/8TACjH+dy7JrbcNYJcTlVNBlC/V/C+waICkER
wuMC/8QjXs0ExJekAD3i/3GUok9WnvEHsohIL04qk1lbvJN4WGHCHFercX11Ch+UjStHwtyw
zyFWi64CqD48kKqPwEne3Lj7ozxzuwCCaJI9fmCQgLfSL+UcDgEb7cQucMAnB/Zxlz6U6ohd
PRlQHaLevAYD2UK+BlhZKLAv/DNUz0nk6fx4CiJF5DIRteUdzGoeGcnWMWO9hv5PkEJC1WkZ
gYXZ/91HMUjsYUuy5/EsmkqvkCalRudoqe6Pex3A34iFGNvDhI3fCrbvmRS4FARPse5D8BLu
e/PIvAPNUC7xl8UcfnTNVgy5ITzWNiY9hIrbAzfPbTXyZSIdMD+HTNg33ziMbu2Iry/2eS1X
/whXkApnQNpHplvzf1xMEeNPlDKtL8OOg+9y4ESdn27EKxeeaaFXsrhb3z1woIjQxXINft5W
EPXWnks/YBCvrLTH8kRCLZgH17zDxb+MLqKj1XUQtBKgDhb+VswJM6GF+dDeBJoEYjvLR1Sx
l5yfaRj0F7HYkjRUwyehwSHgTVqtgnT9QjCCBrYwggSeoAMCAQICEQCgDMvMm5mY7OI6cPR8
wcBZMA0GCSqGSIb3DQEBBQUAMDcxFDASBgNVBAoMC1RlbGlhU29uZXJhMR8wHQYDVQQDDBZU
ZWxpYVNvbmVyYSBSb290IENBIHYxMB4XDTE0MDUyNzA3NDYyMVoXDTI0MDUyNzA3NDYyMVow
OjERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIEluZGl2aWR1YWwg
Q0EgdjIwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQDaulPrX0iWU5+JOOqjddx4
Gnl17DJhklkoXOgOSBMhW6FzGVt5RR7KPv+rjt2YpbwdoqWSYa4VPkS/72vuQoWsvz2avWWX
hPTdNzrB3zs5cJO7sKIyd+LRy4l/8kKK4iPm+Q18XyGF0xTuc5WS3WiMScJSxEKdIOP8xehB
raHZabrGh9OxQHC4iBHkzD0YF3J/vBqBTr7blRzYf1h3j5a7qVIHCPfz+eCE175mResXDQRI
7LvMiZtVaqitBl0oAJiJyeBmvEujBNsIEgUQ6JcQFG5ny0EazLywv7clwb7izvLgoXc6SFrd
0D7TGJtkdldVJtMwDYXpyFMGAijT6uf8h2kuPIwrDgQFNEyIQZ4q52ZpRGwugC6sMxgHEDGj
A/CxX9aC5Vi1EMRJiOGF6gV3T+V5yHDHSBBeQbVAXm8wSTDBfXQwdro/AXqET0mG6Rpe4q2F
GBaauE8qHEO6qR3WAEgvjVfFU2k6xZx1qmvwhkXadxh6ZIMXzgb6WpjivLnR0GEKNrgN2DXd
vo+6eAt45Bhvmeka2TrJDxMLWiBy8QYgNeNXYQsuREnDsjWo6wF0LqbA5769om9nn/uJzmzx
b3nT1iHue5co9J93ta06kxiASHvcIzZwAOjKnmk0vR3IT7Qbzq2of3E1s18xo8DM9D91Cak0
Nq+RALtdv1uZKQIDAQABo4IBuDCCAbQwgYoGCCsGAQUFBwEBBH4wfDAtBggrBgEFBQcwAYYh
aHR0cDovL29jc3AudHJ1c3QudGVsaWFzb25lcmEuY29tMEsGCCsGAQUFBzAChj9odHRwOi8v
cmVwb3NpdG9yeS50cnVzdC50ZWxpYXNvbmVyYS5jb20vdGVsaWFzb25lcmFyb290Y2F2MS5j
ZXIwEgYDVR0TAQH/BAgwBgEB/wIBADBVBgNVHSAETjBMMEoGDCsGAQQBgg8CAwEBAjA6MDgG
CCsGAQUFBwIBFixodHRwczovL3JlcG9zaXRvcnkudHJ1c3QudGVsaWFzb25lcmEuY29tL0NQ
UzBLBgNVHR8ERDBCMECgPqA8hjpodHRwOi8vY3JsLTMudHJ1c3QudGVsaWFzb25lcmEuY29t
L3RlbGlhc29uZXJhcm9vdGNhdjEuY3JsMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcD
BDAOBgNVHQ8BAf8EBAMCAQYwHQYDVR0OBBYEFLENytRGt6+GAsMvbwbKDnZxf0s3MB8GA1Ud
IwQYMBaAFPCPWTgAs/WPmpYM1ev6e6oX6BMSMA0GCSqGSIb3DQEBBQUAA4ICAQBuByBsr6x3
PZBCsmGbcSZ/XL+0tnVMblInoJgL1Bh3PiRicgdo8l+6cvWp/ArBwMYNwSNyrvY9IewyaV8n
65c5oN+l2JDUuzrdANVKnYxha7ZyCEiPmY98sB2bnZgxfJLXQYoRwI7pOOwfyoP2fCYVCd+x
hsfysYiIl4ORzE3TpeppQ2yWkyBBmoHUXJh97ue6+bJ2fqnVUoOVMVnYYEtvsz67v7w2z3fv
dcy04/RnoylxSenxADi1tY9iIydHMgyOu3dfzsxU8AivMGG4aKStsCfUEyg0LlkbhqMrdnes
s3e1qAEueSRNASLfpFwyRmzmiuNh9onzuhER2yYhK/6IeCs4HQHrPhkY8JUmhtmdL2uErOZW
Os38FQhGWHWXI0g6SgdDObU0GEHju0MkDziOhm+BVwPZKN7B7wD7OPj6vlLVo6d8vLGK9byw
hEfXjxLIC3Qhtu5lJPTgIo5Bup+aBBjiJ/u9BfqryqZpudnWfG+wxC327rpNAq2OKdFsR92w
behSZD3mSSAemDVwGB2Yu0XHQYyyYfpWsGyGEyRSHKFhRwJdINPzWLI89wy4Wc+PgqyekkEm
Jqe6g4XSQFj4mqtwvqhP4dg2QCcKM/bh62RwfM7GeSS/LFGe84KmJjTDfvT8c2rK8nEyZ/em
OtwCGXQ6tZCByMNLxeDwU1TGbTGCAxcwggMTAgEBME8wOjERMA8GA1UECgwIRXJpY3Nzb24x
JTAjBgNVBAMMHEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjICEQDvmghdbd4Eckfa7tuu
fmCcMA0GCWCGSAFlAwQCAQUAoIIBmTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG
SIb3DQEJBTEPFw0xNzA3MDQxMzM4NTRaMC8GCSqGSIb3DQEJBDEiBCBOIBWiNsYZCHlix8nV
jt10kiNzsxjo7WRGwm0YEyr1rjBeBgkrBgEEAYI3EAQxUTBPMDoxETAPBgNVBAoMCEVyaWNz
c29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYyAhEA75oIXW3eBHJH
2u7brn5gnDBgBgsqhkiG9w0BCRACCzFRoE8wOjERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNV
BAMMHEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjICEQDvmghdbd4Eckfa7tuufmCcMGwG
CSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAO
BggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgw
DQYJKoZIhvcNAQEBBQAEggEAOKNHcsohf/A5+1Nv2bUU9m46JeNZmT/2viilbN3C/aHJ9UGJ
Uo37fz367xsswfRqQxzgJWccJhsdaem5XNQHofGY5H97Stw5XMjaxZmkAatk8aTBEvGBR5Qc
0oZ920+xYnq2NSQQho0dQORBCsnXU2LJW/y+Ljcsq7NqaHUqlrtaOZl+4NZAcTIvTjLv4zLg
XB/eBdExKDE/tH/A4jHr4Q5ePhT0qUsX2HiZlNeqZUiTLpDiCytuFntB1PsvmI01i6Iy5pDP
lgOliKLSCpJv2eQhE68KlkaUbhy+9KvL08ICD5lyit//DXb9YSn42smSCl7R6EDiUrFeb3aC
w+5dtwAAAAAAAA==
--------------ms090407050409040809070108--


From nobody Wed Jul  5 08:59:50 2017
Return-Path: 
X-Original-To: avt@ietfa.amsl.com
Delivered-To: avt@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12F0E131948 for ; Wed,  5 Jul 2017 08:59:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.099
X-Spam-Level: 
X-Spam-Status: No, score=-1.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_WEB=1.5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lffqVvGPY-in for ; Wed,  5 Jul 2017 08:59:47 -0700 (PDT)
Received: from mx0b-00198e01.pphosted.com (mx0b-00198e01.pphosted.com [67.231.157.197]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 501B9131545 for ; Wed,  5 Jul 2017 08:59:47 -0700 (PDT)
Received: from pps.filterd (m0073110.ppops.net [127.0.0.1]) by mx0b-00198e01.pphosted.com (8.16.0.20/8.16.0.20) with SMTP id v65FwY7J012616; Wed, 5 Jul 2017 11:59:42 -0400
Received: from mail.vidyo.com (mail2.vidyo.com [162.209.16.214]) by mx0b-00198e01.pphosted.com with ESMTP id 2be6g43h2g-1 (version=TLSv1 cipher=AES128-SHA bits=128 verify=NOT); Wed, 05 Jul 2017 11:59:41 -0400
Received: from 492132-EXCH1.vidyo.com ([fe80::50:56ff:fe85:4f77]) by 492133-EXCH2.vidyo.com ([fe80::50:56ff:fe85:6b62%13]) with mapi id 14.03.0195.001; Wed, 5 Jul 2017 10:59:41 -0500
From: Jonathan Lennox 
To: IETF AVTCore WG 
CC: Kaustubh Inamdar , "Ram Mohan R (rmohanr)" , Varun Singh 
Thread-Topic: [Ice] FW: New Version Notification for draft-kaustubh-mprtp-dtls-srtp-01.txt
Thread-Index: AQHS8U+Wig5GBNOOx0ifcFXwH4/eDA==
Date: Wed, 5 Jul 2017 15:59:40 +0000
Message-ID: <92081436-669A-4CB1-964E-7211DEF951EF@vidyo.com>
References: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [160.79.219.114]
Content-Type: multipart/alternative; boundary="_000_92081436669A4CB1964E7211DEF951EFvidyocom_"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-05_10:, , signatures=0
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1707050269
Archived-At: 
Subject: [AVTCORE] Fwd: [Ice] FW: New Version Notification for draft-kaustubh-mprtp-dtls-srtp-01.txt
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Audio/Video Transport Core Maintenance 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 05 Jul 2017 15:59:49 -0000

--_000_92081436669A4CB1964E7211DEF951EFvidyocom_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

This is in the scope of the AVTCORE working group (in my opinion as chair),=
 since both MPRTP and SRTP are within its remit.

Group, please have a look and comment.


Begin forwarded message:

From: "Kaustubh Inamdar (kinamdar)" >
Subject: [Ice] FW: New Version Notification for draft-kaustubh-mprtp-dtls-s=
rtp-01.txt
Date: July 3, 2017 at 10:55:52 PM EDT
To: "ice@ietf.org" >
Cc: "Ram Mohan R (rmohanr)" >, =
Varun Singh >
Resent-From: Jonathan Lennox >
Resent-To: >

Hi WG,
We have submitted a draft that talks about the different considerations of
using MPRTP with DTLS-SRTP.
Please have a look and provide your inputs.

Thanks,
Kaustubh






On 6/30/17, 8:48 AM, "internet-drafts@ietf.org" >
wrote:


A new version of I-D, draft-kaustubh-mprtp-dtls-srtp-01.txt
has been successfully submitted by Kaustubh Inamdar and posted to the
IETF repository.

Name: draft-kaustubh-mprtp-dtls-srtp
Revision: 01
Title: Multipath RTP (MPRTP) with Secure Real-Time Transport (SRTP)
Document date: 2017-06-29
Group: Individual Submission
Pages: 9
URL:
https://www.ietf.org/internet-drafts/draft-kaustubh-mprtp-dtls-srtp-01.txt
Status:
https://datatracker.ietf.org/doc/draft-kaustubh-mprtp-dtls-srtp/
Htmlized:
https://tools.ietf.org/html/draft-kaustubh-mprtp-dtls-srtp-01
Htmlized:
https://datatracker.ietf.org/doc/html/draft-kaustubh-mprtp-dtls-srtp-01
Diff:
https://www.ietf.org/rfcdiff?url2=3Ddraft-kaustubh-mprtp-dtls-srtp-01

Abstract:
 This document describes the considerations when using Multipath RTP
 (MPRTP) with Secure Real-time Transport (SRTP) security context set
 up with the Datagram Transport Layer Security (DTLS) protocol.





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


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



--_000_92081436669A4CB1964E7211DEF951EFvidyocom_
Content-Type: text/html; charset="us-ascii"
Content-ID: <50C0F12120402843AE2FB5E476A04F44@vidyo.com>
Content-Transfer-Encoding: quoted-printable







This is in the scope of the AVTCORE working group (in my op=
inion as chair), since both MPRTP and SRTP are within its remit.







Group, please have a look and comment.












Begin forwarded message:





From:
"Kaustubh Inamdar (kinamdar)"=
 <kinamdar@cisco.com>





Subject:
[Ice] FW: New Version Not=
ification for draft-kaustubh-mprtp-dtls-srtp-01.txt





Date:
July 3, 2017 at 10:55:52 PM EDT





To:
"ice@ietf.org" <ice@ietf.org>





Cc:
"Ram Mohan R (rmohanr)" <<=
a href=3D"mailto:rmohanr@cisco.com" class=3D"">rmohanr@cisco.com>, V=
arun Singh <varun@calls=
tats.io>





Resent-Fro=
m:
Jonathan Lennox <lennox@cs.columbia.edu>





Resent-To:
<jonathan@vidyo.com>








Hi WG,

We have submitted a draft that talks about the different considerations of<=
br class=3D"">
using MPRTP with DTLS-SRTP.

Please have a look and provide your inputs.



Thanks,

Kaustubh













On 6/30/17, 8:48 AM, "internet-drafts@ietf.org" <internet-drafts@ietf.org>

wrote:






A new version of I-D, draft-kaustubh-mprtp-dtls-srtp-01.txt

has been successfully submitted by Kaustubh Inamdar and posted to the

IETF repository.



Name: draft-kaustubh-m=
prtp-dtls-srtp

Revision: 0=
1

Title: Multipath RTP (=
MPRTP) with Secure Real-Time Transport (SRTP)

Document date: 2017-06-29

Group: Individual Subm=
ission

Pages: 9

URL:            

https://www.ietf.org/internet-drafts/draft-kaustubh-=
mprtp-dtls-srtp-01.txt

Status:         

https://datatracker.ietf.org/doc/draft-kaustubh-mprtp-dtls-srtp/

Htmlized:       

https://tools.ietf.org/html/draft-kaustubh-mprtp-dtls-srtp-01

Htmlized:       

https://datatracker.ietf.org/doc/html/draft-kaustubh-mprtp-dtls-srtp-01

Diff:           

https://www.ietf.org/rfcdiff?url2=3Ddraft-kaustubh-mprtp-dtls-srtp-01



Abstract:

 This document describes the considerations when using Multipath RTP
 (MPRTP) with Secure Real-time Transport (SRTP) security context set
 up with the Datagram Transport Layer Security (DTLS) protocol.











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







_______________________________________________

Ice mailing list

Ice@ietf.org

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
















--_000_92081436669A4CB1964E7211DEF951EFvidyocom_--


From nobody Fri Jul  7 13:32:41 2017
Return-Path: 
X-Original-To: avt@ietf.org
Delivered-To: avt@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B12A912EC12; Fri,  7 Jul 2017 13:32:39 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Ben Campbell 
To: "The IESG" 
Cc: draft-ietf-avtcore-aria-srtp@ietf.org, avtcore-chairs@ietf.org, roni.even@mail01.huawei.com, avt@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.55.2
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <149945955972.15094.6380528023048643623.idtracker@ietfa.amsl.com>
Date: Fri, 07 Jul 2017 13:32:39 -0700
Archived-At: 
Subject: [AVTCORE] Ben Campbell's Yes on draft-ietf-avtcore-aria-srtp-10: (with COMMENT)
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.22
List-Id: Audio/Video Transport Core Maintenance 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 07 Jul 2017 20:32:40 -0000

Ben Campbell has entered the following ballot position for
draft-ietf-avtcore-aria-srtp-10: Yes

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-avtcore-aria-srtp/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I think it would be wise to add a paragraph to the security considerations to
call out the dependency on SHA1. A mention of what would need to happen to
migrate to newer hash functions could also be helpful.



From nobody Fri Jul  7 20:26:07 2017
Return-Path: 
X-Original-To: avt@ietf.org
Delivered-To: avt@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 23A9B13161E for ; Fri,  7 Jul 2017 20:26:06 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
To: 
X-Test-IDTracker: no
X-IETF-IDTracker: 6.55.2
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <149948436614.2886.4522830166700625405.idtracker@ietfa.amsl.com>
Date: Fri, 07 Jul 2017 20:26:06 -0700
From: IETF Secretariat 
Archived-At: 
Subject: [AVTCORE] Milestones changed for avtcore WG
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.22
List-Id: Audio/Video Transport Core Maintenance 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 08 Jul 2017 03:26:06 -0000

Changed milestone "Submit update for A General Mechanism for RTP Header
Extensions (RFC5285) for publication as proposed standard", resolved as
"Done".

Changed milestone "Submit Mechanism for Layer Refresh Request for Proposed
Standard", resolved as "Done".

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


From nobody Fri Jul  7 20:33:10 2017
Return-Path: 
X-Original-To: avt@ietfa.amsl.com
Delivered-To: avt@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B489112EC06 for ; Fri,  7 Jul 2017 20:33:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.7
X-Spam-Level: 
X-Spam-Status: No, score=-0.7 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vqftg2XYmkDs for ; Fri,  7 Jul 2017 20:33:07 -0700 (PDT)
Received: from mx0b-00198e01.pphosted.com (mx0b-00198e01.pphosted.com [67.231.157.197]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 799F9129ADD for ; Fri,  7 Jul 2017 20:33:06 -0700 (PDT)
Received: from pps.filterd (m0073110.ppops.net [127.0.0.1]) by mx0b-00198e01.pphosted.com (8.16.0.20/8.16.0.20) with SMTP id v683TIAA021476 for ; Fri, 7 Jul 2017 23:33:04 -0400
Received: from mail.vidyo.com (mail2.vidyo.com [162.209.16.214]) by mx0b-00198e01.pphosted.com with ESMTP id 2be6g45v4e-1 (version=TLSv1 cipher=AES128-SHA bits=128 verify=NOT) for ; Fri, 07 Jul 2017 23:33:04 -0400
Received: from 492132-EXCH1.vidyo.com ([fe80::50:56ff:fe85:4f77]) by 492133-EXCH2.vidyo.com ([fe80::50:56ff:fe85:6b62%13]) with mapi id 14.03.0195.001; Fri, 7 Jul 2017 22:33:03 -0500
From: Jonathan Lennox 
To: IETF AVTCore WG 
Thread-Topic: Agenda for AVTCore at IETF 99
Thread-Index: AQHS95rnRHm/p5XkkEOhaEm22boZ7Q==
Date: Sat, 8 Jul 2017 03:33:03 +0000
Message-ID: <9E18CC41-93CF-4D84-B060-7D0FC40F6D60@vidyo.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [100.35.229.243]
Content-Type: multipart/alternative; boundary="_000_9E18CC4193CF4D84B0607D0FC40F6D60vidyocom_"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-08_02:, , signatures=0
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1707080060
Archived-At: 
Subject: [AVTCORE] Agenda for AVTCore at IETF 99
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Audio/Video Transport Core Maintenance 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 08 Jul 2017 03:33:09 -0000

--_000_9E18CC4193CF4D84B0607D0FC40F6D60vidyocom_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

AVTCore will meet in Prague on Friday, July 21.

The draft agenda for the group is at https://datatracker.ietf.org/doc/agend=
a-99-avtcore/ .

So far we have only one item on the agenda; if you have other items you wis=
h to discuss, please let the chairs know.

Thanks!

--_000_9E18CC4193CF4D84B0607D0FC40F6D60vidyocom_
Content-Type: text/html; charset="us-ascii"
Content-ID: <2A6942E01991DF41BDE6DCBF4BF8DAE6@vidyo.com>
Content-Transfer-Encoding: quoted-printable







AVTCore will meet in Prague on Friday, July 21.







The draft agenda for the group is at 
https://datatracker.ietf.org/doc/agenda-99-avtcore/ .







So far we have only one item on the agenda; if you have oth=
er items you wish to discuss, please let the chairs know.







Thanks!




--_000_9E18CC4193CF4D84B0607D0FC40F6D60vidyocom_--


From nobody Sun Jul  9 20:23:02 2017
Return-Path: 
X-Original-To: avt@ietfa.amsl.com
Delivered-To: avt@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4F77129562 for ; Sun,  9 Jul 2017 20:22:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.221
X-Spam-Level: 
X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KSaWlTC0qw3y for ; Sun,  9 Jul 2017 20:22:58 -0700 (PDT)
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 6B8731272E1 for ; Sun,  9 Jul 2017 20:22:57 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml702-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DKB19813; Mon, 10 Jul 2017 03:22:35 +0000 (GMT)
Received: from NKGEML414-HUB.china.huawei.com (10.98.56.75) by lhreml702-cah.china.huawei.com (10.201.108.43) with Microsoft SMTP Server (TLS) id 14.3.301.0; Mon, 10 Jul 2017 04:22:35 +0100
Received: from NKGEML513-MBX.china.huawei.com ([169.254.1.25]) by nkgeml414-hub.china.huawei.com ([10.98.56.75]) with mapi id 14.03.0235.001; Mon, 10 Jul 2017 11:22:32 +0800
From: "Huangyihong (Rachel)" 
To: IETF AVTCore WG 
CC: Jonathan Lennox 
Thread-Topic: Agenda for AVTCore at IETF 99
Thread-Index: AQHS95rnRHm/p5XkkEOhaEm22boZ7aJMZKhQ
Date: Mon, 10 Jul 2017 03:22:31 +0000
Message-ID: <51E6A56BD6A85142B9D172C87FC3ABBB9C4D056C@nkgeml513-mbx.china.huawei.com>
References: <9E18CC41-93CF-4D84-B060-7D0FC40F6D60@vidyo.com>
In-Reply-To: <9E18CC41-93CF-4D84-B060-7D0FC40F6D60@vidyo.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.134.153.152]
Content-Type: multipart/alternative; boundary="_000_51E6A56BD6A85142B9D172C87FC3ABBB9C4D056Cnkgeml513mbxchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020206.5962F310.0028, ss=1, re=0.000, recu=0.000, reip=0.000,  cl=1, cld=1, fgs=0, ip=169.254.1.25, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: d785c55fc7a8ae7895455cad18dfc9f3
Archived-At: 
Subject: Re: [AVTCORE] Agenda for AVTCore at IETF 99
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Audio/Video Transport Core Maintenance 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 10 Jul 2017 03:23:00 -0000

--_000_51E6A56BD6A85142B9D172C87FC3ABBB9C4D056Cnkgeml513mbxchi_
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: base64

VGhlIGFnZW5kYSBpcyBub3cgdXBkYXRlZCB0byBpbmNsdWRlIHRoZSBSTUNBVCBmZWVkYmFjayBt
ZXNzYWdlIHRvcGljLg0KDQpodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9hZ2VuZGEt
OTktYXZ0Y29yZS8NCg0KDQq3orz+yMs6IGF2dCBbbWFpbHRvOmF2dC1ib3VuY2VzQGlldGYub3Jn
XSC0+rHtIEpvbmF0aGFuIExlbm5veA0Kt6LLzcqxvOQ6IDIwMTfE6jfUwjjI1SAxMTozMw0KytW8
/sjLOiBJRVRGIEFWVENvcmUgV0cNCtb3zOI6IFtBVlRDT1JFXSBBZ2VuZGEgZm9yIEFWVENvcmUg
YXQgSUVURiA5OQ0KDQpBVlRDb3JlIHdpbGwgbWVldCBpbiBQcmFndWUgb24gRnJpZGF5LCBKdWx5
IDIxLg0KDQpUaGUgZHJhZnQgYWdlbmRhIGZvciB0aGUgZ3JvdXAgaXMgYXQgaHR0cHM6Ly9kYXRh
dHJhY2tlci5pZXRmLm9yZy9kb2MvYWdlbmRhLTk5LWF2dGNvcmUvIC4NCg0KU28gZmFyIHdlIGhh
dmUgb25seSBvbmUgaXRlbSBvbiB0aGUgYWdlbmRhOyBpZiB5b3UgaGF2ZSBvdGhlciBpdGVtcyB5
b3Ugd2lzaCB0byBkaXNjdXNzLCBwbGVhc2UgbGV0IHRoZSBjaGFpcnMga25vdy4NCg0KVGhhbmtz
IQ0K

--_000_51E6A56BD6A85142B9D172C87FC3ABBB9C4D056Cnkgeml513mbxchi_
Content-Type: text/html; charset="gb2312"
Content-Transfer-Encoding: quoted-printable











The agenda=
 is now updated to include the RMCAT feedback message topic.


 =
;


https://datatracker.i=
etf.org/doc/agenda-99-avtcore/


 =
;


 =
;






=B7=A2=BC=FE=C8=CB: avt [ma=
ilto:avt-bounces@ietf.org]
=B4=FA=
=B1=ED Jonathan Lennox

=B7=A2=
=CB=CD=CA=B1=BC=E4: 2017=C4=EA7=D4=C28=C8=D5
 11:33

=CA=D5=BC=FE=C8=CB: IETF AVTCore WG

=D6=F7=CC=E2: [AVTCORE] Agenda for AVTCore at IETF 99






 




AVTCore will meet in Prague on =
Friday, July 21.






 






The draft agenda for the group =
is at 
https://datatracker.ietf.org/doc/agenda-99-avtcore/ .






 






So far we have only one item on=
 the agenda; if you have other items you wish to discuss, please let the ch=
airs know.






 






Thanks!








--_000_51E6A56BD6A85142B9D172C87FC3ABBB9C4D056Cnkgeml513mbxchi_--


From nobody Mon Jul 10 02:37:33 2017
Return-Path: 
X-Original-To: avt@ietfa.amsl.com
Delivered-To: avt@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75FC8127342 for ; Mon, 10 Jul 2017 02:37:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.391
X-Spam-Level: 
X-Spam-Status: No, score=0.391 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FSL_HELO_BARE_IP_2=1.499, RDNS_NONE=0.793, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5frPjMJBGYa4 for ; Mon, 10 Jul 2017 02:37:30 -0700 (PDT)
Received: from spam.nsr.re.kr (unknown [210.104.33.65]) by ietfa.amsl.com (Postfix) with ESMTP id 0DC54129B35 for ; Mon, 10 Jul 2017 02:37:29 -0700 (PDT)
Received: from unknown (HELO nsr.re.kr) (210.104.33.70) by 210.104.33.65 with ESMTP; 10 Jul 2017 18:29:29 +0900
X-Original-SENDERIP: 210.104.33.70
X-Original-MAILFROM: whkim5@nsr.re.kr
Received: from 192.168.155.183 ([192.168.155.183]) by mail.nsr.re.kr (Crinity Message Backbone-7.0.1) with SMTP ID 844; Mon, 10 Jul 2017 18:30:11 +0900 (KST)
From: Woo-Hwan Kim 
To: 'Ben Campbell' , 'The IESG' 
Cc: draft-ietf-avtcore-aria-srtp@ietf.org, avtcore-chairs@ietf.org,  roni.even@mail01.huawei.com, avt@ietf.org
References: <149945955972.15094.6380528023048643623.idtracker@ietfa.amsl.com>
In-Reply-To: <149945955972.15094.6380528023048643623.idtracker@ietfa.amsl.com>
Date: Mon, 10 Jul 2017 18:30:22 +0900
Message-ID: <006101d2f95f$274e2dd0$75ea8970$@nsr.re.kr>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 15.0
Thread-Index: AQHWXmjqkO4H0kzTEvFy79Z90ySotKJF/L2g
Content-Language: ko
Archived-At: 
Subject: Re: [AVTCORE] Ben Campbell's Yes on draft-ietf-avtcore-aria-srtp-10: (with COMMENT)
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Audio/Video Transport Core Maintenance 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 10 Jul 2017 09:37:31 -0000

Let me reply to the comment of Ben Campbell.
We would like to add the below to security considerations of the =
previous draft(-10).

--------------------------------------------------------------------
As a note, at the time of publication of this document, SRTP
recommends HMAC-SHA1 as the default and mandatory-to-implement MAC
algorithm. So all of SRTP crypto suites except GCM based ones use
HMAC-SHA1 as their MAC algorithm to provide message authentication/
integrity. Due to security concerns with SHA-1 [RFC6194], the IETF
is gradually moving away from SHA-1 and towards stronger hash
algorithms such as SHA-2 or SHA-3 families. For SRTP, however, SHA-1
is only used in the calculation of an HMAC, and no security issue is
known in this case. To use a secure hash algorithm such as SHA-256
in SRTP, the values of directly related SRTP parameters
auth_key_length and auth_tag_length should be determined considering
the overall security and efficiency when the crypto suite is applied.

[RFC6194] Polk, T., Chen, L., Turner, S., and P. Hoffman, "Security
Considerations for the SHA-0 and SHA-1 Message-Digest
Algorithms", RFC 6194, DOI 10.17487/RFC6194, March 2011,
.
--------------------------------------------------------------------

Sincerely, Woo-Hwan Kim

-----Original Message-----
From: Ben Campbell [mailto:ben@nostrum.com]=20
Sent: Saturday, July 08, 2017 5:33 AM
To: The IESG 
Cc: draft-ietf-avtcore-aria-srtp@ietf.org; avtcore-chairs@ietf.org; =
roni.even@mail01.huawei.com; avt@ietf.org
Subject: Ben Campbell's Yes on draft-ietf-avtcore-aria-srtp-10: (with =
COMMENT)

Ben Campbell has entered the following ballot position for
draft-ietf-avtcore-aria-srtp-10: Yes

When responding, please keep the subject line intact and reply to all =
email addresses included in the To and CC lines. (Feel free to cut this =
introductory paragraph, however.)


Please refer to =
https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-avtcore-aria-srtp/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I think it would be wise to add a paragraph to the security =
considerations to call out the dependency on SHA1. A mention of what =
would need to happen to migrate to newer hash functions could also be =
helpful.



From nobody Mon Jul 10 05:41:33 2017
Return-Path: 
X-Original-To: avt@ietfa.amsl.com
Delivered-To: avt@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22E9013173B for ; Mon, 10 Jul 2017 05:41:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nAUx0GlvemGe for ; Mon, 10 Jul 2017 05:41:23 -0700 (PDT)
Received: from mail-yw0-x229.google.com (mail-yw0-x229.google.com [IPv6:2607:f8b0:4002:c05::229]) (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 AC91B131743 for ; Mon, 10 Jul 2017 05:41:20 -0700 (PDT)
Received: by mail-yw0-x229.google.com with SMTP id v193so34897281ywg.2 for ; Mon, 10 Jul 2017 05:41:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=iM5XYNnrdQTj0ODnAPppGio2oOF2lFUwcnlpmCd5Q8o=; b=f4wCiE8XVQW9PoSWlSy905L3Oo/c1cBuFa8hNvbn675BCTIzB7EyQnseokmbbMdHsG iXnoZpHvR/c7UITMiQodMJTVUq/FrZ4jl3niWbf7a+DNLBcV7aQAEKARxQ3qxRGOMaCv oAlgEoOrPCqi/yFWe/zFbL1N19/C7V0q106QZ9JqIoLCfNo5Pdy0RlcP1eAt6d5mADfI fdYz9ckVDwmZVz9QUEQ+b2g9FtIazfwD8+NgOftzEDOwqF/fXmQ9p8srxlnS7yVEImld /tlgWwJ5jzNtuZkzqPUe8T2AZyBrhmKjtqb7fl2R2bFqnp0fMH5gNcwUrI4E4mP5Woi5 XS5A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=iM5XYNnrdQTj0ODnAPppGio2oOF2lFUwcnlpmCd5Q8o=; b=sP48RDaZs8BI3SFD+3NeV4KwRWNsyebOO0tV71sd+hsjc6QZEO4lWeIa3lAEA/YINQ nrOkUKaJLTzQ5IthauzUDUbHYeUjbEl7k/FtRgZcIU0ppuC2A7H52YNOkzzcvLXtALHa oyqKvtQWuqcm+W7KRgVc1jB2/pPQI73XGcJWl0utXXW6cvpi1QD9SX8MrxKe+wnPkbXQ 4enZmHQQhpfuW+31yPsEDgfoK+PUafAmk7Zdni5iz4wbWK/M108snjrlredcaUhxGEvF li5eVaQvzc3JjFvV/yx+N160qtqHjgdnqKjqI0aun29TiO9x7NOJy3pRgskr4aRPjS/i oJfw==
X-Gm-Message-State: AIVw113wbo5c9STdAakxoJy1QZi3wc32bDo7NuJ+wj4DHyqON0icMsjV Hk6RwpoEIvJF88gKRJfRdf65qlQZrSJx
X-Received: by 10.13.235.20 with SMTP id u20mr491570ywe.45.1499690479872; Mon, 10 Jul 2017 05:41:19 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.13.215.9 with HTTP; Mon, 10 Jul 2017 05:40:39 -0700 (PDT)
In-Reply-To: <006101d2f95f$274e2dd0$75ea8970$@nsr.re.kr>
References: <149945955972.15094.6380528023048643623.idtracker@ietfa.amsl.com> <006101d2f95f$274e2dd0$75ea8970$@nsr.re.kr>
From: Eric Rescorla 
Date: Mon, 10 Jul 2017 05:40:39 -0700
Message-ID: 
To: Woo-Hwan Kim 
Cc: Ben Campbell , The IESG , avtcore-chairs@ietf.org,  roni.even@mail01.huawei.com, draft-ietf-avtcore-aria-srtp@ietf.org,  "avt@ietf.org" 
Content-Type: multipart/alternative; boundary="94eb2c08863c5392220553f5e6bc"
Archived-At: 
Subject: Re: [AVTCORE] Ben Campbell's Yes on draft-ietf-avtcore-aria-srtp-10: (with COMMENT)
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Audio/Video Transport Core Maintenance 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 10 Jul 2017 12:41:25 -0000

--94eb2c08863c5392220553f5e6bc
Content-Type: text/plain; charset="UTF-8"

On Mon, Jul 10, 2017 at 2:30 AM, Woo-Hwan Kim  wrote:

> Let me reply to the comment of Ben Campbell.
> We would like to add the below to security considerations of the previous
> draft(-10).
>
> --------------------------------------------------------------------
> As a note, at the time of publication of this document, SRTP
> recommends HMAC-SHA1 as the default and mandatory-to-implement MAC
> algorithm. So all of SRTP crypto suites except GCM based ones use
> HMAC-SHA1 as their MAC algorithm to provide message authentication/
> integrity. Due to security concerns with SHA-1 [RFC6194], the IETF
> is gradually moving away from SHA-1 and towards stronger hash
> algorithms such as SHA-2 or SHA-3 families. For SRTP, however, SHA-1
> is only used in the calculation of an HMAC, and no security issue is
> known in this case. To use a secure hash algorithm such as SHA-256
> in SRTP, the values of directly related SRTP parameters
> auth_key_length and auth_tag_length should be determined considering
> the overall security and efficiency when the crypto suite is applied.
>

I don't think this last sentence makes sense. We are moving towards AEAD
algorithms, so I doubt we would ever want to publish -HMAC-SHA256.
I would simply remove the sentence.

-Ekr


>
> [RFC6194] Polk, T., Chen, L., Turner, S., and P. Hoffman, "Security
> Considerations for the SHA-0 and SHA-1 Message-Digest
> Algorithms", RFC 6194, DOI 10.17487/RFC6194, March 2011,
> .
> --------------------------------------------------------------------
>
> Sincerely, Woo-Hwan Kim
>
> -----Original Message-----
> From: Ben Campbell [mailto:ben@nostrum.com]
> Sent: Saturday, July 08, 2017 5:33 AM
> To: The IESG 
> Cc: draft-ietf-avtcore-aria-srtp@ietf.org; avtcore-chairs@ietf.org;
> roni.even@mail01.huawei.com; avt@ietf.org
> Subject: Ben Campbell's Yes on draft-ietf-avtcore-aria-srtp-10: (with
> COMMENT)
>
> Ben Campbell has entered the following ballot position for
> draft-ietf-avtcore-aria-srtp-10: Yes
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-avtcore-aria-srtp/
>
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> I think it would be wise to add a paragraph to the security considerations
> to call out the dependency on SHA1. A mention of what would need to happen
> to migrate to newer hash functions could also be helpful.
>
>
>

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




On Mon, Jul 10, 2017 at 2:30 AM, Woo-Hwan Kim <whkim5@nsr.re.kr>=
 wrote:
Let me reply to the commen=
t of Ben Campbell.

We would like to add the below to security considerations of the previous d=
raft(-10).



-----------------------------------------------------------------=
---

As a note, at the time of publication of this document, SRTP

recommends HMAC-SHA1 as the default and mandatory-to-implement MAC

algorithm. So all of SRTP crypto suites except GCM based ones use

HMAC-SHA1 as their MAC algorithm to provide message authentication/

integrity. Due to security concerns with SHA-1 [RFC6194], the IETF

is gradually moving away from SHA-1 and towards stronger hash

algorithms such as SHA-2 or SHA-3 families. For SRTP, however, SHA-1

is only used in the calculation of an HMAC, and no security issue is

known in this case. To use a secure hash algorithm such as SHA-256

in SRTP, the values of directly related SRTP parameters

auth_key_length and auth_tag_length should be determined considering

the overall security and efficiency when the crypto suite is applied.

I don't think this last sentence makes s=
ense. We are moving towards AEAD algorithms, so I doubt we would ever want =
to publish <Cipher>-HMAC-SHA256. I would simply remove the sentence.<=
/div>

-Ekr
=C2=A0



[RFC6194] Polk, T., Chen, L., Turner, S., and P. Hoffman, "Security
Considerations for the SHA-0 and SHA-1 Message-Digest

Algorithms", RFC 6194, DOI 10.17487/RFC6194, March 2011,

<http://www.rfc-editor.org/info/rfc6194>.

-----------------------------------------------------------------=
---



Sincerely, Woo-Hwan Kim




-----Original Message-----

From: Ben Campbell [mailto:ben@nostrum.c=
om]

Sent: Saturday, July 08, 2017 5:33 AM

To: The IESG <iesg@ietf.org>

Cc: draft-ietf-avt=
core-aria-srtp@ietf.org; avtcore-chairs@ietf.org; roni.even@mail01.huawei.com; avt@iet=
f.org

Subject: Ben Campbell's Yes on draft-ietf-avtcore-aria-srtp-10: (w=
ith COMMENT)



Ben Campbell has entered the following ballot position for

draft-ietf-avtcore-aria-srtp-10: Yes



When responding, please keep the subject line intact and reply to all email=
 addresses included in the To and CC lines. (Feel free to cut this introduc=
tory paragraph, however.)





Please refer to https://www.ietf.org/iesg/<=
wbr>statement/discuss-criteria.html

for more information about IESG DISCUSS and COMMENT positions.





The document, along with other ballot positions, can be found here:

https://datatracker.ietf.org/doc/=
draft-ietf-avtcore-aria-srtp/







-----------------------------------------------------------------=
-----

COMMENT:

-----------------------------------------------------------------=
-----



I think it would be wise to add a paragraph to the security considerations =
to call out the dependency on SHA1. A mention of what would need to happen =
to migrate to newer hash functions could also be helpful.









--94eb2c08863c5392220553f5e6bc--


From nobody Mon Jul 10 07:45:32 2017
Return-Path: 
X-Original-To: avt@ietfa.amsl.com
Delivered-To: avt@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 652C213145A; Mon, 10 Jul 2017 07:45:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.881
X-Spam-Level: 
X-Spam-Status: No, score=-1.881 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L047oJl2wR1t; Mon, 10 Jul 2017 07:45:28 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9EE70124B0A; Mon, 10 Jul 2017 07:45:28 -0700 (PDT)
Received: from [10.0.1.63] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v6AEjMdU034136 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 10 Jul 2017 09:45:23 -0500 (CDT) (envelope-from ben@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.63]
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
From: Ben Campbell 
In-Reply-To: 
Date: Mon, 10 Jul 2017 09:45:23 -0500
Cc: Woo-Hwan Kim , The IESG , avtcore-chairs@ietf.org, roni.even@mail01.huawei.com, draft-ietf-avtcore-aria-srtp@ietf.org, "avt@ietf.org" 
Content-Transfer-Encoding: quoted-printable
Message-Id: <41AF9813-C3AB-4F5B-95C0-693780ECE80C@nostrum.com>
References: <149945955972.15094.6380528023048643623.idtracker@ietfa.amsl.com> <006101d2f95f$274e2dd0$75ea8970$@nsr.re.kr> 
To: Eric Rescorla 
X-Mailer: Apple Mail (2.3273)
Archived-At: 
Subject: Re: [AVTCORE] Ben Campbell's Yes on draft-ietf-avtcore-aria-srtp-10: (with COMMENT)
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Audio/Video Transport Core Maintenance 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 10 Jul 2017 14:45:30 -0000

> On Jul 10, 2017, at 7:40 AM, Eric Rescorla  wrote:
>=20
>=20
>=20
> On Mon, Jul 10, 2017 at 2:30 AM, Woo-Hwan Kim  =
wrote:
> Let me reply to the comment of Ben Campbell.
> We would like to add the below to security considerations of the =
previous draft(-10).
>=20
> --------------------------------------------------------------------
> As a note, at the time of publication of this document, SRTP
> recommends HMAC-SHA1 as the default and mandatory-to-implement MAC
> algorithm. So all of SRTP crypto suites except GCM based ones use
> HMAC-SHA1 as their MAC algorithm to provide message authentication/
> integrity. Due to security concerns with SHA-1 [RFC6194], the IETF
> is gradually moving away from SHA-1 and towards stronger hash
> algorithms such as SHA-2 or SHA-3 families. For SRTP, however, SHA-1
> is only used in the calculation of an HMAC, and no security issue is
> known in this case. To use a secure hash algorithm such as SHA-256
> in SRTP, the values of directly related SRTP parameters
> auth_key_length and auth_tag_length should be determined considering
> the overall security and efficiency when the crypto suite is applied.
>=20
> I don't think this last sentence makes sense. We are moving towards =
AEAD algorithms, so I doubt we would ever want to publish =
-HMAC-SHA256. I would simply remove the sentence.

I agree.=20

When I suggested text to say what would need to be done to move to newer =
hashes, I was thinking of something more general from a procedural =
perspective. Maybe something more to the effect of =E2=80=9CChanging =
away from SHA1 for this purpose is out of scope for this document, and =
would require updates to SRTP [REF]=E2=80=9D

On the other hand, I would also be okay with simply removing that =
sentence.


>=20
> -Ekr
> =20
>=20
> [RFC6194] Polk, T., Chen, L., Turner, S., and P. Hoffman, "Security
> Considerations for the SHA-0 and SHA-1 Message-Digest
> Algorithms", RFC 6194, DOI 10.17487/RFC6194, March 2011,
> .
> --------------------------------------------------------------------
>=20
> Sincerely, Woo-Hwan Kim
>=20
> -----Original Message-----
> From: Ben Campbell [mailto:ben@nostrum.com]
> Sent: Saturday, July 08, 2017 5:33 AM
> To: The IESG 
> Cc: draft-ietf-avtcore-aria-srtp@ietf.org; avtcore-chairs@ietf.org; =
roni.even@mail01.huawei.com; avt@ietf.org
> Subject: Ben Campbell's Yes on draft-ietf-avtcore-aria-srtp-10: (with =
COMMENT)
>=20
> Ben Campbell has entered the following ballot position for
> draft-ietf-avtcore-aria-srtp-10: Yes
>=20
> When responding, please keep the subject line intact and reply to all =
email addresses included in the To and CC lines. (Feel free to cut this =
introductory paragraph, however.)
>=20
>=20
> Please refer to =
https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>=20
>=20
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-avtcore-aria-srtp/
>=20
>=20
>=20
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>=20
> I think it would be wise to add a paragraph to the security =
considerations to call out the dependency on SHA1. A mention of what =
would need to happen to migrate to newer hash functions could also be =
helpful.


From nobody Tue Jul 11 22:54:06 2017
Return-Path: 
X-Original-To: avt@ietfa.amsl.com
Delivered-To: avt@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC7AE12EC19 for ; Tue, 11 Jul 2017 22:54:05 -0700 (PDT)
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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pLRSsWMsATrx for ; Tue, 11 Jul 2017 22:54:03 -0700 (PDT)
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 6DE8C129B4D for ; Tue, 11 Jul 2017 22:54:02 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml704-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DKF02077; Wed, 12 Jul 2017 05:53:59 +0000 (GMT)
Received: from DGGEMM406-HUB.china.huawei.com (10.3.20.214) by lhreml704-cah.china.huawei.com (10.201.108.45) with Microsoft SMTP Server (TLS) id 14.3.301.0; Wed, 12 Jul 2017 06:53:58 +0100
Received: from DGGEMM506-MBX.china.huawei.com ([169.254.3.18]) by DGGEMM406-HUB.china.huawei.com ([10.3.20.214]) with mapi id 14.03.0301.000; Wed, 12 Jul 2017 13:53:44 +0800
From: Roni Even 
To: Magnus Westerlund , "Huangyihong (Rachel)" , "avt@ietf.org" 
Thread-Topic: [AVTCORE] [avtcore] WGLC for mux-category issue of draft-ietf-avtcore-rfc5282-bis-12
Thread-Index: AdLwnZp7sXeUq3WWT9e1QMHWLU8W7wD6jg4AAZKG8DA=
Date: Wed, 12 Jul 2017 05:53:43 +0000
Message-ID: <6E58094ECC8D8344914996DAD28F1CCD7DF552@DGGEMM506-MBX.china.huawei.com>
References: <51E6A56BD6A85142B9D172C87FC3ABBB9C4CBF80@nkgeml513-mbx.china.huawei.com> <71a9b15b-dd7e-f736-5be2-dd2bb88cad63@ericsson.com>
In-Reply-To: <71a9b15b-dd7e-f736-5be2-dd2bb88cad63@ericsson.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.200.202.245]
Content-Type: multipart/alternative; boundary="_000_6E58094ECC8D8344914996DAD28F1CCD7DF552DGGEMM506MBXchina_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020203.5965B978.00B4, ss=1, re=0.000, recu=0.000, reip=0.000,  cl=1, cld=1, fgs=0, ip=169.254.3.18, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: e992641bdbc8b445521c07d55d1a9fe8
Archived-At: 
Subject: Re: [AVTCORE] [avtcore] WGLC for mux-category issue of draft-ietf-avtcore-rfc5282-bis-12
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Audio/Video Transport Core Maintenance 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 12 Jul 2017 05:54:06 -0000

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

SGksDQpNeSByZWFzb24gZm9yIHN1Z2dlc3RpbmcgTm9ybWFsIGlzIHRoYXQgaXQgcHJvdmlkZXMg
bW9yZSBmbGV4aWJpbGl0eSBmb3IgaW1wbGVtZW50YXRpb25zLiBJIHVuZGVyc3RhbmQgTWFnbnVz
IHBvaW50IGFib3V0IHRoZSBhZGRlZCBjb21wbGV4aXR5IG9mIHN1cHBvcnRpbmcgYSBtaXhlZCBt
b2RlIHdoZXJlIHNvbWUgbS1saW5lcyBhbGxvdy1taXggd2hpbGUgb3RoZXIgbm90LiBZZXQgc2lu
Y2UgdGhpcyBpcyBhIG5lZ290aWF0ZWQgYXR0cmlidXRlIHRoYW4gaXQgbGVhdmVzIGl0IHRvIHRo
ZSBpbXBsZW1lbnRhdGlvbnMgaWYgdGhleSB3YW50IHRvIG9mZmVyIGFsbG93IG1peCBpbiBhbGwg
bS1saW5lcyBvciBhdCB0aGUgc2Vzc2lvbiBsZXZlbCBvciBub3QuIEkgYW0gbm90IHN1cmUgd2h5
IHdlIHNob3VsZCBsaW1pdCBvdXJzZWx2ZXMgdG8gbWFuZGF0aW5nIGlkZW50aWNhbCBzaW5jZSBh
cyBEYXZlIFNpbmdlciBwb2ludGVkIG91dCB0aGVyZSBtYXkgYmUgY2FzZXMgd2hlcmUgd2Ugd2Fu
dCB0aGUgbm9ybWFsIGNhc2UuICBJZiB3ZSBkZWZpbmUgaXQgYXMgaWRlbnRpY2FsIGl0IG1lYW5z
IHRoYXQgYWxsb3ctbWl4IE1VU1QgYmUgc3VwcG9ydGVkIHdoaWNoIGlzIG5vdCB3aGF0IHRoZSBk
cmFmdCBzYXlzIGZvciB0aGlzIGF0dHJpYnV0ZSBpbiB0aGUgIGdlbmVyYWwgY2FzZS4gSSBhbHNv
IHRoaW5rIHRoYXQgdGhlcmUgaXMgYWx3YXlzIHRoZSBvcHRpb24gdG8gdXNlIG9ubHkgdHdvLWJ5
dGVzIFJUUCBoZWFkZXIgZXh0ZW5zaW9ucyB3aGVuIGluIGRvdWJ0IGFzIHRoZSBkcmFmdCBzYXlz
Lg0KUm9uaQ0KDQpGcm9tOiBhdnQgW21haWx0bzphdnQtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVo
YWxmIE9mIE1hZ251cyBXZXN0ZXJsdW5kDQpTZW50OiDXmdeV150g15IgMDQg15nXldec15kgMjAx
NyAxNjozOQ0KVG86IEh1YW5neWlob25nIChSYWNoZWwpOyBhdnRAaWV0Zi5vcmcNClN1YmplY3Q6
IFJlOiBbQVZUQ09SRV0gW2F2dGNvcmVdIFdHTEMgZm9yIG11eC1jYXRlZ29yeSBpc3N1ZSBvZiBk
cmFmdC1pZXRmLWF2dGNvcmUtcmZjNTI4Mi1iaXMtMTINCg0KSGksDQoNCkFzIG9uZSBvZiB0aGUg
cGVvcGxlIHdobyByYWlzZWQgdGhpcyBiZWZvcmUgSSB3YW50IHRvIGV4cGxhaW4gd2h5IEkgdGhp
bmsgaXQgc2hvdWxkIGlkZW50aWNhbCBtYWtlcyBtb3JlIHNlbnNlIGluIHRoaXMgY2FzZS4NCg0K
U28gZmlyc3QgdGhlIGFzc3VtcHRpb25zLiBXZSBhcmUgdGFsa2luZyBhYm91dCBvZmZlcnMgaW4g
dGhlIGNvbnRleHQgb2YgQlVORExFLCBpLmUuIG11bHRpcGxlIG09IGJsb2NrcyBhcmUgcGFydCBv
ZiB0aGUgc2FtZSBSVFAgc2Vzc2lvbi4gVGh1cywgdGhlc2UgUlRQIHN0cmVhbXMgZ2VuZXJhdGVk
IHdpbGwgYmUgcmVjZWl2ZWQgYW5kIHNlbnQgYnkgYSBwYXJ0aWN1bGFyIGVuZHBvaW50IG9uIHRo
ZSBzYW1lIHRyYW5zcG9ydCBwb3J0LiBUaHVzLCB0aGUgUlRQIHN0YWNrIHByb2Nlc3Npbmcgd2ls
bCBiZSBkb25lIGJ5IGEgc2luZ2xlIGltcGxlbWVudGF0aW9uLg0KDQpUaGUgc2luZ2xlIFJUUCBz
dGFjayBpbXBsZW1lbnRhdGlvbiBpbiBhIEJVTkRMRSBjb250ZXh0IGlzIHRoZSBiYXNpcyBmb3Ig
bXkgYXJndW1lbnQgd2h5IGl0IG1ha2VzIHNlbnNlIHRvIHVzZSBpZGVudGljYWwgZm9yIGV4dG1h
cC1hbGxvdy1taXhlZC4gVGhlIHJlYXNvbiBpcyB0aGF0IHRoZSBlbnRpdHkgb24gdGhlIHNwZWNp
ZmllZCBJUCBhZGRyZXNzICsgcG9ydCB3aWxsIGJlIGEgc2luZ2xlIGltcGxlbWVudGF0aW9uLiBU
aHVzLCBJIGFzc3VtZSBpdCBpcyBjYXBhYmxlIG9mIGhhbmRsaW5nIHRoZSBzd2l0Y2hpbmcgYmV0
d2VlbiBvbmUgYW5kIHR3by1ieXRlIGV4dGVuc2lvbiBoZWFkZXIgZm9ybWF0cyB3aXRob3V0IGlz
c3Vlcy4gRnJvbSB0aGlzIHBlcnNwZWN0aXZlIGlkZW50aWNhbCBhcHBlYXJzIHZlcnkgcmVhc29u
YWJsZS4NCg0KVGhlIGFyZ3VtZW50IHRoYXQgRGF2aWQgU2luZ2VyIGJyb3VnaHQgdG8gdGhlIHRh
YmxlIGlzIHRoYXQgb25lIG1heSBoYXZlIGRpZmZlcmVudCBjYXBhYmlsaXRpZXMgZm9yIGF1ZGlv
IGFuZCB2aWRlbyBpbiBhbiBlbmRwb2ludC4gU28gZnJvbSBteSBwZXJzcGVjdGl2ZSwgdGhpcyBj
YW4gb25seSByZWFsbHkgd29yayBpZiB0aGUgUlRQIHBheWxvYWQgY29udGVudCBpcyBmb3J3YXJk
ZWQgZnJvbSB0aGUgbWVkaWEgcHJvZHVjaW5nIGVudGl0eSBhbmQgcHJvY2Vzc2VkIGJ5IHRoZSBS
VFAgc3RhY2sgaW4gc3VjaCBhIHdheSB0aGF0IHRoZXkgZnVsZmlsbCB0aGUgUlRQIHByb3RvY29s
IHNwZWNpZmljYXRpb24uIElmIG5lY2Vzc2FyeSwgdGhlbiByZXdyaXRpbmcgY291bGQgaGFwcGVu
IGluIHRoYXQgZm9yd2FyZGluZy4gQnV0LCB0aGF0IHNob3VsZCByZWFsbHkgbm90IGJlIG5lZWRl
ZC4gRmlyc3QgdGhlIHNpZ25hbGluZyB0aGF0IGVuYWJsZSBSVFAgaGVhZGVyIGV4dGVuc2lvbiB1
c2FnZSBjYW4gY29udHJvbCBpdHMgc2lkZSBvZiB0aGUgbmVnb3RpYXRpb24gYW5kIHdoYXQgSURz
IGFyZSB1c2VkLiBSZW1lbWJlciB0aGF0IHRoZSBJRCBzcGFjZSBiZWNvbWVzIGpvaW50IG92ZXIg
YWxsIGV4dGVuc2lvbnMgaW4gdGhlIFJUUCBzZXNzaW9uLCBidXQgZGlmZmVyZW50IFJUUCBzdHJl
YW1zIGFuZCBtZWRpYSBibG9ja3MgbWF5IGhhdmUgb25seSBhIHN1YnNldCBvZiBhbGwgaGVhZGVy
IGV4dGVuc2lvbnMgY29uZmlndXJlZC4gVGh1cywgaWYgYXVkaW8gc3RyZWFtIGdlbmVyYXRvciBo
YXZlIHRoaXMgbGltaXRhdGlvbiB0aGF0IGl0IG9ubHkgY2FuIHByb2Nlc3Mgb25lLWJ5dGUgaGVh
ZGVyIGV4dGVuc2lvbnMsIG9ubHkgSURzIHRoYXQgZml0cyB0aGUgc2hvcnQgY2FuIGJlIGFzc2ln
bmVkLCBpZiBhdCBhbGwgcG9zc2libGUuIFRodXMsIHRoZSBvbmx5IHRocmVhdCB3b3VsZCBiZSBh
IHNlbmRlciB0aGF0IHVzZXMgdHdvLWJ5dGUgaGVhZGVycyB3aGVuIGl0IGlzIG5vdCBuZWVkZWQu
DQoNClNvIHRoZSBiZW5lZml0cyBhcyBJIHNlZSB3aXRoIGlkZW50aWNhbCBpcyB0aGUgZm9sbG93
aW5nLiBGb3IgYW4gQlVORExFIGNhcGFibGUgaW1wbGVtZW50YXRpb24gd2hlcmUgdGhlIGltcGxl
bWVudGF0aW9uIHRoYXQgYWRkcyBoZWFkZXIgZXh0ZW5zaW9ucyB0byB0aGUgUlRQIHBhY2tldHMg
aXMgY29tbW9uLCB0aGVyZSBpcyBjb25zaXN0ZW50IGNvbmZpZ3VyYXRpb24gZm9yIHRoZSBSVFAg
c2Vzc2lvbiwgYW5kIHRoZSBwb3NzaWJpbGl0eSB0byBzd2l0Y2ggYXQgYW55IHBvaW50IHJlZHVj
ZXMgdGhlIGNvbXBsZXhpdHkgb2YgdGhlIGNvZGUtYmFzZSBhcyBubyBhdHRlbXB0IHRvIHByZWRp
Y3Qgb3IgZGV0ZXJtaW5lIGZ1dHVyZSBuZWVkcyBhcmUgbmVlZGVkLiBVc2Ugd2hhdCBpcyBjdXJy
ZW50bHkgbmVlZGVkLiBObyBleHRyYSBjb21wbGV4aXR5IGZvciB0aGlzIG1vZGVybiBpbXBsZW1l
bnRhdGlvbnMgdG8gZGVhbCB3aXRoIGxlZ2FjeSBpbXBsZW1lbnRhdGlvbnMgaW50byBidW5kbGUg
c2NlbmFyaW8uDQoNClRoYXQgY29tcGxleGl0eSBvZiBlbnN1cmluZyB3aGljaCBJRHMgYXJlIHVz
ZWQsIGFuZCBkZWFsaW5nIHdpdGggYWRvcHRpbmcgYSBsZWdhY3kgaW1wbGVtZW50YXRpb24gdG8g
QlVORExFIGVuZHMgdXAgd2l0aCB0aGUgb25lcyBkb2luZyB0aGF0IGNob2ljZSwgbm90IGV2ZXJ5
b25lIGVsc2UuIEFuZCB0aGlzIGlzIGZvciBhIGNhc2UgSSBhdCBsZWFzdCBzZWUgYXMgc3RyYW5n
ZSBhcyBhbGwgUlRQIHN0cmVhbXMgd2lsbCBmbG93IG92ZXIgdGhlIHNhbWUgNS10dXBsZSBmb3Ig
dGhlIGRpZmZlcmVudCBtZWRpYSB0eXBlcy4gVGh1cywgb25seSBpbXBsZW1lbnRhdGlvbiB0aGF0
IGF0dGVtcHRzIHRvIGZvcndhcmQgUlRQIHBhY2tldHMgd2l0aG91dCByZXdyaXRpbmcgd2lsbCBo
YXZlIHRoaXMgaXNzdWUuDQoNCklmIG9uZSBhbGxvd3MgTm9ybWFsLCB0aGVuIG9uZSBwdXNoZXMg
dGhlIGNvbXBsZXhpdGllcyBvZiBoYXZpbmcgdG8gYmUgYWJsZSB0byByZXN0cmljdCBzb21lIFJU
UCBzdHJlYW1zIGluIGFuIFJUUCBzZXNzaW9uIHRvIG5vdCBzd2l0Y2ggYmV0d2VlbiBvbmUgYW5k
IHR3by1ieXRlIGhlYWRlcnMuIFRoaXMgd2lsbCByZXF1aXJlIGNvZGUsIGFuZCBhbHNvIG1vcmUg
c2lnbmFsaW5nIGxvZ2ljIHRvIGRlYWwgd2l0aCBjYXNlcyB3aGVyZSB0aGlzIGlzIG9mZmVyZWQu
IFRodXMsIEkgdGhpbmsgdXNpbmcgaWRlbnRpY2FsIHdvdWxkIHNpbXBsaWZ5IHRoZSBzeXN0ZW0g
aW4gZ2VuZXJhbC4gQW5kIGFsbG93IG1vZGVybiBCVU5ETEUgY2FwYWJsZSBpbXBsZW1lbnRhdGlv
bnMgdG8gYmVjb21lcyBzaW1wbGVyLCBmb3IgYSBsaXR0bGUgY29zdCBmb3IgdGhlIGltcGxlbWVu
dGVycyB0aGF0IGF0dGVtcHQgdG8gaW50ZWdyYXRlIGxlZ2FjeSBwYWNrZXQgZ2VuZXJhdG9ycyBp
bnRvIGEgc2luZ2xlIFJUUCBzZXNzaW9uIHdpdGhvdXQgYSB0cmFuc2xhdGlvbiBsYXllciwgb3Ig
YmFjayB0byBiYWNrIFJUUCBzZXNzaW9ucy4NCg0KQ2hlZXJzDQoNCk1hZ251cw0KDQpEZW4gMjAx
Ny0wNi0yOSBrbC4gMDg6MDUsIHNrcmV2IEh1YW5neWlob25nIChSYWNoZWwpOg0KSGkgRm9sa3Ms
DQoNCkFzIHlvdSBtYXkgbm90aWNlIHRoYXQgdGhlcmUgd2FzIGEgZGlzY3Vzc2lvbiBmb3IgdGhl
IG11eCBjYXRlZ29yeSBzZWxlY3Rpb24gZm9yIGE9ZXh0bWFwLWFsbG93LW1peGVkIGluIGRyYWZ0
LWlldGYtYXZ0Y29yZS1yZmM1MjgyLWJpcy0xMi4gVGhpcyBpc3N1ZSB3YXMgcmFpc2VkIGJ5IE1h
Z251cyB3aGVuIGhlIHdhcyBkb2luZyB0aGUgc2hlcGhlcmQgd29yay4gU2VlIGh0dHBzOi8vbWFp
bGFyY2hpdmUuaWV0Zi5vcmcvYXJjaC9tc2cvYXZ0L0JhRWxKbURsbUR0T2FBY1hLVl9SazVmQVJn
ay4gVGhpcyBkaXNjdXNzaW9uIGhhcHBlbmVkIGFmdGVyIHRoZSBXR0xDIGFuZCBubyBmb3JtYWwg
Y29uY2x1c2lvbiB3YXMgbWFkZSB0aGVuLg0KDQpBbmQgbm93IHRoZSBkaXNjdXNzaW9uIGlzIHJl
c3RhcnRlZCBpbiBJRVNHIHJldmlldyBvZiB0aGlzIGRyYWZ0LiBUaGUgYXV0aG9yIHRoaW5rcyBp
dCBzaG91bGQgYmUgTm9ybWFsIHRvIGNvdmVyIG11bHRpcGxlIGNhc2VzLCB3aGlsZSBzb21lIHBl
b3BsZSB0aGluayBpdOKAmXMgYmV0dGVyIHRvIGJlIElkZW50aWNhbCB0byBtYWtlIHRoaW5ncyBz
aW1wbGUuDQoNClNvIHRoaXMgZW1haWwgaXMgdG8gaGF2ZSBhIG9uZS13ZWVrIFdHTEMgZm9yIHRo
aXMgaXNzdWUgYW5kIGRlbGl2ZXIgYSBmb3JtYWwgY29uY2x1c2lvbiB0byBJRVNHOg0KDQpJZiB5
b3UgZG8gbm90IGFncmVlIHRoYXQg4oCcTm9ybWFs4oCdIG11eCBjYXRlZ29yeSBzaG91bGQgYmUg
dXNlZCBmb3IgYT1leHRtYXAtYWxsb3ctbWl4ZWQsIHBsZWFzZSBleHByZXNzIGl0IGluIHRoZSBt
YWlsaW5nIGxpc3QgYmVmb3JlIDh0aCBKdWx5Lg0KDQpUaGFua3MuDQoNCkJSLA0KUmFjaGVsIChh
cyB0aGUgY28tY2hhaXIpDQoNCg0KDQotLQ0KDQoNCg0KTWFnbnVzIFdlc3Rlcmx1bmQNCg0KDQoN
Ci0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0NCg0KTWVkaWEgVGVjaG5vbG9naWVzLCBFcmljc3NvbiBSZXNlYXJjaA0K
DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tDQoNCkVyaWNzc29uIEFCICAgICAgICAgICAgICAgICB8IFBob25lICAr
NDYgMTAgNzE0ODI4Nw0KDQpUb3JzaGFtbnNnYXRhbiAyMyAgICAgICAgICAgfCBNb2JpbGUgKzQ2
IDczIDA5NDkwNzkNCg0KU0UtMTY0IDgwIFN0b2NraG9sbSwgU3dlZGVuIHwgbWFpbHRvOiBtYWdu
dXMud2VzdGVybHVuZEBlcmljc3Nvbi5jb208bWFpbHRvOm1hZ251cy53ZXN0ZXJsdW5kQGVyaWNz
c29uLmNvbT4NCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0K

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

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ
e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpA
Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDIg
MiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNv
Tm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAw
MXB0Ow0KCXRleHQtYWxpZ246anVzdGlmeTsNCglmb250LXNpemU6MTAuNXB0Ow0KCWZvbnQtZmFt
aWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6YmxhY2s7fQ0KYTpsaW5rLCBzcGFu
Lk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0
ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtG
b2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQt
ZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNv
LW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBjbTsNCgltc28tbWFyZ2luLWJv
dHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowY207DQoJZm9udC1zaXplOjEyLjBwdDsNCglm
b250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiOw0KCWNvbG9yOmJsYWNrO30NCnBy
ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9y
bWF0dGVkIENoYXIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZv
bnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCgljb2xvcjpibGFj
azt9DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250
LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bh
bi5IVE1MUHJlZm9ybWF0dGVkQ2hhcg0KCXttc28tc3R5bGUtbmFtZToiSFRNTCBQcmVmb3JtYXR0
ZWQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1M
IFByZWZvcm1hdHRlZCI7DQoJZm9udC1mYW1pbHk6Q29uc29sYXM7DQoJY29sb3I6YmxhY2s7fQ0K
c3Bhbi5FbWFpbFN0eWxlMjENCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9u
dC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29D
aHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4w
cHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdp
bjo3Mi4wcHQgOTAuMHB0IDcyLjBwdCA5MC4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdl
OldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86
c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2Vu
ZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVk
aXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+
PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBiZ2NvbG9yPSJ3aGl0ZSIgbGFuZz0i
RU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rp
b24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0
O2NvbG9yOiMxRjQ5N0QiPkhpLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOiMxRjQ5N0QiPk15IHJl
YXNvbiBmb3Igc3VnZ2VzdGluZyBOb3JtYWwgaXMgdGhhdCBpdCBwcm92aWRlcyBtb3JlIGZsZXhp
YmlsaXR5IGZvciBpbXBsZW1lbnRhdGlvbnMuIEkgdW5kZXJzdGFuZCBNYWdudXMgcG9pbnQgYWJv
dXQgdGhlIGFkZGVkIGNvbXBsZXhpdHkgb2Ygc3VwcG9ydGluZyBhIG1peGVkIG1vZGUgd2hlcmUg
c29tZSBtLWxpbmVzIGFsbG93LW1peA0KIHdoaWxlIG90aGVyIG5vdC4gWWV0IHNpbmNlIHRoaXMg
aXMgYSBuZWdvdGlhdGVkIGF0dHJpYnV0ZSB0aGFuIGl0IGxlYXZlcyBpdCB0byB0aGUgaW1wbGVt
ZW50YXRpb25zIGlmIHRoZXkgd2FudCB0byBvZmZlciBhbGxvdyBtaXggaW4gYWxsIG0tbGluZXMg
b3IgYXQgdGhlIHNlc3Npb24gbGV2ZWwgb3Igbm90LiBJIGFtIG5vdCBzdXJlIHdoeSB3ZSBzaG91
bGQgbGltaXQgb3Vyc2VsdmVzIHRvIG1hbmRhdGluZyBpZGVudGljYWwgc2luY2UgYXMgRGF2ZQ0K
IFNpbmdlciBwb2ludGVkIG91dCB0aGVyZSBtYXkgYmUgY2FzZXMgd2hlcmUgd2Ugd2FudCB0aGUg
bm9ybWFsIGNhc2UuJm5ic3A7IElmIHdlIGRlZmluZSBpdCBhcyBpZGVudGljYWwgaXQgbWVhbnMg
dGhhdCBhbGxvdy1taXggTVVTVCBiZSBzdXBwb3J0ZWQgd2hpY2ggaXMgbm90IHdoYXQgdGhlIGRy
YWZ0IHNheXMgZm9yIHRoaXMgYXR0cmlidXRlIGluIHRoZSAmbmJzcDtnZW5lcmFsIGNhc2UuIEkg
YWxzbyB0aGluayB0aGF0IHRoZXJlIGlzIGFsd2F5cyB0aGUgb3B0aW9uDQogdG8gdXNlIG9ubHkg
dHdvLWJ5dGVzIFJUUCBoZWFkZXIgZXh0ZW5zaW9ucyB3aGVuIGluIGRvdWJ0IGFzIHRoZSBkcmFm
dCBzYXlzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu
IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOiMxRjQ5N0QiPlJvbmk8bzpwPjwvbzpwPjwv
c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx
LjBwdDtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0
eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGNt
IDBjbSAwY20gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10
b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiIGFsaWduPSJsZWZ0IiBzdHlsZT0idGV4dC1hbGlnbjpsZWZ0Ij48Yj48
c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVv
dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjp3aW5kb3d0ZXh0Ij5Gcm9tOjwvc3Bhbj48
L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21h
JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6d2luZG93dGV4dCI+IGF2dCBbbWFp
bHRvOmF2dC1ib3VuY2VzQGlldGYub3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5NYWdudXMgV2Vz
dGVybHVuZDxicj4NCjxiPlNlbnQ6PC9iPiA8c3BhbiBsYW5nPSJIRSIgZGlyPSJSVEwiPteZ15XX
nSZuYnNwO9eSIDA0INeZ15XXnNeZIDIwMTcgMTY6Mzk8L3NwYW4+PGJyPg0KPGI+VG86PC9iPiBI
dWFuZ3lpaG9uZyAoUmFjaGVsKTsgYXZ0QGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJl
OiBbQVZUQ09SRV0gW2F2dGNvcmVdIFdHTEMgZm9yIG11eC1jYXRlZ29yeSBpc3N1ZSBvZiBkcmFm
dC1pZXRmLWF2dGNvcmUtcmZjNTI4Mi1iaXMtMTI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp
dj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImxlZnQiIHN0eWxlPSJ0ZXh0
LWFsaWduOmxlZnQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPkhpLDxicj4NCjxicj4NCkFzIG9uZSBvZiB0aGUgcGVvcGxlIHdobyByYWlzZWQgdGhp
cyBiZWZvcmUgSSB3YW50IHRvIGV4cGxhaW4gd2h5IEkgdGhpbmsgaXQgc2hvdWxkIGlkZW50aWNh
bCBtYWtlcyBtb3JlIHNlbnNlIGluIHRoaXMgY2FzZS4NCjxicj4NCjxicj4NClNvIGZpcnN0IHRo
ZSBhc3N1bXB0aW9ucy4gV2UgYXJlIHRhbGtpbmcgYWJvdXQgb2ZmZXJzIGluIHRoZSBjb250ZXh0
IG9mIEJVTkRMRSwgaS5lLiBtdWx0aXBsZSBtPSBibG9ja3MgYXJlIHBhcnQgb2YgdGhlIHNhbWUg
UlRQIHNlc3Npb24uIFRodXMsIHRoZXNlIFJUUCBzdHJlYW1zIGdlbmVyYXRlZCB3aWxsIGJlIHJl
Y2VpdmVkIGFuZCBzZW50IGJ5IGEgcGFydGljdWxhciBlbmRwb2ludCBvbiB0aGUgc2FtZSB0cmFu
c3BvcnQgcG9ydC4gVGh1cywNCiB0aGUgUlRQIHN0YWNrIHByb2Nlc3Npbmcgd2lsbCBiZSBkb25l
IGJ5IGEgc2luZ2xlIGltcGxlbWVudGF0aW9uLiA8YnI+DQo8YnI+DQpUaGUgc2luZ2xlIFJUUCBz
dGFjayBpbXBsZW1lbnRhdGlvbiBpbiBhIEJVTkRMRSBjb250ZXh0IGlzIHRoZSBiYXNpcyBmb3Ig
bXkgYXJndW1lbnQgd2h5IGl0IG1ha2VzIHNlbnNlIHRvIHVzZSBpZGVudGljYWwgZm9yIGV4dG1h
cC1hbGxvdy1taXhlZC4gVGhlIHJlYXNvbiBpcyB0aGF0IHRoZSBlbnRpdHkgb24gdGhlIHNwZWNp
ZmllZCBJUCBhZGRyZXNzICYjNDM7IHBvcnQgd2lsbCBiZSBhIHNpbmdsZSBpbXBsZW1lbnRhdGlv
bi4gVGh1cywgSSBhc3N1bWUNCiBpdCBpcyBjYXBhYmxlIG9mIGhhbmRsaW5nIHRoZSBzd2l0Y2hp
bmcgYmV0d2VlbiBvbmUgYW5kIHR3by1ieXRlIGV4dGVuc2lvbiBoZWFkZXIgZm9ybWF0cyB3aXRo
b3V0IGlzc3Vlcy4gRnJvbSB0aGlzIHBlcnNwZWN0aXZlIGlkZW50aWNhbCBhcHBlYXJzIHZlcnkg
cmVhc29uYWJsZS4NCjxicj4NCjxicj4NClRoZSBhcmd1bWVudCB0aGF0IERhdmlkIFNpbmdlciBi
cm91Z2h0IHRvIHRoZSB0YWJsZSBpcyB0aGF0IG9uZSBtYXkgaGF2ZSBkaWZmZXJlbnQgY2FwYWJp
bGl0aWVzIGZvciBhdWRpbyBhbmQgdmlkZW8gaW4gYW4gZW5kcG9pbnQuIFNvIGZyb20gbXkgcGVy
c3BlY3RpdmUsIHRoaXMgY2FuIG9ubHkgcmVhbGx5IHdvcmsgaWYgdGhlIFJUUCBwYXlsb2FkIGNv
bnRlbnQgaXMgZm9yd2FyZGVkIGZyb20gdGhlIG1lZGlhIHByb2R1Y2luZyBlbnRpdHkgYW5kDQog
cHJvY2Vzc2VkIGJ5IHRoZSBSVFAgc3RhY2sgaW4gc3VjaCBhIHdheSB0aGF0IHRoZXkgZnVsZmls
bCB0aGUgUlRQIHByb3RvY29sIHNwZWNpZmljYXRpb24uIElmIG5lY2Vzc2FyeSwgdGhlbiByZXdy
aXRpbmcgY291bGQgaGFwcGVuIGluIHRoYXQgZm9yd2FyZGluZy4gQnV0LCB0aGF0IHNob3VsZCBy
ZWFsbHkgbm90IGJlIG5lZWRlZC4gRmlyc3QgdGhlIHNpZ25hbGluZyB0aGF0IGVuYWJsZSBSVFAg
aGVhZGVyIGV4dGVuc2lvbiB1c2FnZSBjYW4gY29udHJvbA0KIGl0cyBzaWRlIG9mIHRoZSBuZWdv
dGlhdGlvbiBhbmQgd2hhdCBJRHMgYXJlIHVzZWQuIFJlbWVtYmVyIHRoYXQgdGhlIElEIHNwYWNl
IGJlY29tZXMgam9pbnQgb3ZlciBhbGwgZXh0ZW5zaW9ucyBpbiB0aGUgUlRQIHNlc3Npb24sIGJ1
dCBkaWZmZXJlbnQgUlRQIHN0cmVhbXMgYW5kIG1lZGlhIGJsb2NrcyBtYXkgaGF2ZSBvbmx5IGEg
c3Vic2V0IG9mIGFsbCBoZWFkZXIgZXh0ZW5zaW9ucyBjb25maWd1cmVkLiBUaHVzLCBpZiBhdWRp
byBzdHJlYW0NCiBnZW5lcmF0b3IgaGF2ZSB0aGlzIGxpbWl0YXRpb24gdGhhdCBpdCBvbmx5IGNh
biBwcm9jZXNzIG9uZS1ieXRlIGhlYWRlciBleHRlbnNpb25zLCBvbmx5IElEcyB0aGF0IGZpdHMg
dGhlIHNob3J0IGNhbiBiZSBhc3NpZ25lZCwgaWYgYXQgYWxsIHBvc3NpYmxlLiBUaHVzLCB0aGUg
b25seSB0aHJlYXQgd291bGQgYmUgYSBzZW5kZXIgdGhhdCB1c2VzIHR3by1ieXRlIGhlYWRlcnMg
d2hlbiBpdCBpcyBub3QgbmVlZGVkLg0KPGJyPg0KPGJyPg0KU28gdGhlIGJlbmVmaXRzIGFzIEkg
c2VlIHdpdGggaWRlbnRpY2FsIGlzIHRoZSBmb2xsb3dpbmcuIEZvciBhbiBCVU5ETEUgY2FwYWJs
ZSBpbXBsZW1lbnRhdGlvbiB3aGVyZSB0aGUgaW1wbGVtZW50YXRpb24gdGhhdCBhZGRzIGhlYWRl
ciBleHRlbnNpb25zIHRvIHRoZSBSVFAgcGFja2V0cyBpcyBjb21tb24sIHRoZXJlIGlzIGNvbnNp
c3RlbnQgY29uZmlndXJhdGlvbiBmb3IgdGhlIFJUUCBzZXNzaW9uLCBhbmQgdGhlIHBvc3NpYmls
aXR5IHRvIHN3aXRjaA0KIGF0IGFueSBwb2ludCByZWR1Y2VzIHRoZSBjb21wbGV4aXR5IG9mIHRo
ZSBjb2RlLWJhc2UgYXMgbm8gYXR0ZW1wdCB0byBwcmVkaWN0IG9yIGRldGVybWluZSBmdXR1cmUg
bmVlZHMgYXJlIG5lZWRlZC4gVXNlIHdoYXQgaXMgY3VycmVudGx5IG5lZWRlZC4gTm8gZXh0cmEg
Y29tcGxleGl0eSBmb3IgdGhpcyBtb2Rlcm4gaW1wbGVtZW50YXRpb25zIHRvIGRlYWwgd2l0aCBs
ZWdhY3kgaW1wbGVtZW50YXRpb25zIGludG8gYnVuZGxlIHNjZW5hcmlvLg0KPGJyPg0KPGJyPg0K
VGhhdCBjb21wbGV4aXR5IG9mIGVuc3VyaW5nIHdoaWNoIElEcyBhcmUgdXNlZCwgYW5kIGRlYWxp
bmcgd2l0aCBhZG9wdGluZyBhIGxlZ2FjeSBpbXBsZW1lbnRhdGlvbiB0byBCVU5ETEUgZW5kcyB1
cCB3aXRoIHRoZSBvbmVzIGRvaW5nIHRoYXQgY2hvaWNlLCBub3QgZXZlcnlvbmUgZWxzZS4gQW5k
IHRoaXMgaXMgZm9yIGEgY2FzZSBJIGF0IGxlYXN0IHNlZSBhcyBzdHJhbmdlIGFzIGFsbCBSVFAg
c3RyZWFtcyB3aWxsIGZsb3cgb3ZlciB0aGUgc2FtZQ0KIDUtdHVwbGUgZm9yIHRoZSBkaWZmZXJl
bnQgbWVkaWEgdHlwZXMuIFRodXMsIG9ubHkgaW1wbGVtZW50YXRpb24gdGhhdCBhdHRlbXB0cyB0
byBmb3J3YXJkIFJUUCBwYWNrZXRzIHdpdGhvdXQgcmV3cml0aW5nIHdpbGwgaGF2ZSB0aGlzIGlz
c3VlLg0KPGJyPg0KPGJyPg0KSWYgb25lIGFsbG93cyBOb3JtYWwsIHRoZW4gb25lIHB1c2hlcyB0
aGUgY29tcGxleGl0aWVzIG9mIGhhdmluZyB0byBiZSBhYmxlIHRvIHJlc3RyaWN0IHNvbWUgUlRQ
IHN0cmVhbXMgaW4gYW4gUlRQIHNlc3Npb24gdG8gbm90IHN3aXRjaCBiZXR3ZWVuIG9uZSBhbmQg
dHdvLWJ5dGUgaGVhZGVycy4gVGhpcyB3aWxsIHJlcXVpcmUgY29kZSwgYW5kIGFsc28gbW9yZSBz
aWduYWxpbmcgbG9naWMgdG8gZGVhbCB3aXRoIGNhc2VzIHdoZXJlIHRoaXMgaXMNCiBvZmZlcmVk
LiBUaHVzLCBJIHRoaW5rIHVzaW5nIGlkZW50aWNhbCB3b3VsZCBzaW1wbGlmeSB0aGUgc3lzdGVt
IGluIGdlbmVyYWwuIEFuZCBhbGxvdyBtb2Rlcm4gQlVORExFIGNhcGFibGUgaW1wbGVtZW50YXRp
b25zIHRvIGJlY29tZXMgc2ltcGxlciwgZm9yIGEgbGl0dGxlIGNvc3QgZm9yIHRoZSBpbXBsZW1l
bnRlcnMgdGhhdCBhdHRlbXB0IHRvIGludGVncmF0ZSBsZWdhY3kgcGFja2V0IGdlbmVyYXRvcnMg
aW50byBhIHNpbmdsZSBSVFAgc2Vzc2lvbg0KIHdpdGhvdXQgYSB0cmFuc2xhdGlvbiBsYXllciwg
b3IgYmFjayB0byBiYWNrIFJUUCBzZXNzaW9ucy4gPGJyPg0KPGJyPg0KQ2hlZXJzPGJyPg0KPGJy
Pg0KTWFnbnVzPGJyPg0KPGJyPg0KRGVuIDIwMTctMDYtMjkga2wuIDA4OjA1LCBza3JldiBIdWFu
Z3lpaG9uZyAoUmFjaGVsKTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5
bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj5IaSBGb2xrcyw8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZu
YnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QXMgeW91IG1heSBub3Rp
Y2UgdGhhdCB0aGVyZSB3YXMgYSBkaXNjdXNzaW9uIGZvciB0aGUgbXV4IGNhdGVnb3J5IHNlbGVj
dGlvbiBmb3IgYT1leHRtYXAtYWxsb3ctbWl4ZWQgaW4gZHJhZnQtaWV0Zi1hdnRjb3JlLXJmYzUy
ODItYmlzLTEyLiBUaGlzIGlzc3VlIHdhcyByYWlzZWQgYnkgTWFnbnVzIHdoZW4gaGUgd2FzIGRv
aW5nIHRoZSBzaGVwaGVyZCB3b3JrLiBTZWUNCjxhIGhyZWY9Imh0dHBzOi8vbWFpbGFyY2hpdmUu
aWV0Zi5vcmcvYXJjaC9tc2cvYXZ0L0JhRWxKbURsbUR0T2FBY1hLVl9SazVmQVJnayI+aHR0cHM6
Ly9tYWlsYXJjaGl2ZS5pZXRmLm9yZy9hcmNoL21zZy9hdnQvQmFFbEptRGxtRHRPYUFjWEtWX1Jr
NWZBUmdrPC9hPi4gVGhpcyBkaXNjdXNzaW9uIGhhcHBlbmVkIGFmdGVyIHRoZSBXR0xDIGFuZCBu
byBmb3JtYWwgY29uY2x1c2lvbiB3YXMgbWFkZSB0aGVuLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij5BbmQgbm93IHRoZSBkaXNjdXNzaW9uIGlzIHJlc3RhcnRlZCBpbiBJRVNHIHJldmlldyBvZiB0
aGlzIGRyYWZ0LiBUaGUgYXV0aG9yIHRoaW5rcyBpdCBzaG91bGQgYmUgTm9ybWFsIHRvIGNvdmVy
IG11bHRpcGxlIGNhc2VzLCB3aGlsZSBzb21lIHBlb3BsZSB0aGluayBpdOKAmXMgYmV0dGVyIHRv
IGJlIElkZW50aWNhbCB0byBtYWtlIHRoaW5ncyBzaW1wbGUuDQo8bzpwPjwvbzpwPjwvcD4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+U28gdGhpcyBlbWFpbCBpcyB0byBoYXZlIGEgb25lLXdlZWsgV0dMQyBmb3IgdGhpcyBp
c3N1ZSBhbmQgZGVsaXZlciBhIGZvcm1hbCBjb25jbHVzaW9uIHRvIElFU0c6PG86cD48L286cD48
L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPklmIHlvdSBkbyBub3QgYWdyZWUgdGhhdCDigJxOb3JtYWzigJ0gbXV4IGNh
dGVnb3J5IHNob3VsZCBiZSB1c2VkIGZvciBhPWV4dG1hcC1hbGxvdy1taXhlZCwgcGxlYXNlIGV4
cHJlc3MgaXQgaW4gdGhlIG1haWxpbmcgbGlzdCBiZWZvcmUgODxzdXA+dGg8L3N1cD4gSnVseS4N
CjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48
L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGFua3MuPG86cD48L286cD48L3A+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PkJSLDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UmFjaGVsIChhcyB0aGUg
Y28tY2hhaXIpPG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8cD48bzpwPiZuYnNwOzwv
bzpwPjwvcD4NCjxwcmU+LS0gPG86cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286
cD48L3ByZT4NCjxwcmU+TWFnbnVzIFdlc3Rlcmx1bmQgPG86cD48L286cD48L3ByZT4NCjxwcmU+
PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxvOnA+PC9vOnA+PC9w
cmU+DQo8cHJlPk1lZGlhIFRlY2hub2xvZ2llcywgRXJpY3Nzb24gUmVzZWFyY2g8bzpwPjwvbzpw
PjwvcHJlPg0KPHByZT4tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPG86cD48L286cD48L3ByZT4NCjxwcmU+RXJpY3Nz
b24gQUImbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCBQaG9uZSZuYnNw
OyAmIzQzOzQ2IDEwIDcxNDgyODc8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5Ub3JzaGFtbnNnYXRh
biAyMyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyB8IE1vYmlsZSAmIzQzOzQ2IDczIDA5NDkwNzk8bzpwPjwvbzpwPjwvcHJlPg0KPHBy
ZT5TRS0xNjQgODAgU3RvY2tob2xtLCBTd2VkZW4gfCBtYWlsdG86IDxhIGhyZWY9Im1haWx0bzpt
YWdudXMud2VzdGVybHVuZEBlcmljc3Nvbi5jb20iPm1hZ251cy53ZXN0ZXJsdW5kQGVyaWNzc29u
LmNvbTwvYT48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPG86cD48L286cD48
L3ByZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo=

--_000_6E58094ECC8D8344914996DAD28F1CCD7DF552DGGEMM506MBXchina_--


From nobody Tue Jul 11 23:29:08 2017
Return-Path: 
X-Original-To: avt@ietfa.amsl.com
Delivered-To: avt@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04CB312F28B for ; Tue, 11 Jul 2017 23:29:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.21
X-Spam-Level: 
X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Mlse79ajn2b for ; Tue, 11 Jul 2017 23:29:02 -0700 (PDT)
Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 530C612F280 for ; Tue, 11 Jul 2017 23:29:02 -0700 (PDT)
X-AuditID: c1b4fb2d-bcf0a9c000005faa-25-5965c1ac95bc
Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.183.69]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id F5.A6.24490.CA1C5695; Wed, 12 Jul 2017 08:29:00 +0200 (CEST)
Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.71) with Microsoft SMTP Server id 14.3.352.0; Wed, 12 Jul 2017 08:28:50 +0200
To: Roni Even , "Huangyihong (Rachel)" , "avt@ietf.org" 
References: <51E6A56BD6A85142B9D172C87FC3ABBB9C4CBF80@nkgeml513-mbx.china.huawei.com> <71a9b15b-dd7e-f736-5be2-dd2bb88cad63@ericsson.com> <6E58094ECC8D8344914996DAD28F1CCD7DF552@DGGEMM506-MBX.china.huawei.com>
From: Magnus Westerlund 
Message-ID: 
Date: Wed, 12 Jul 2017 08:28:50 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1
MIME-Version: 1.0
In-Reply-To: <6E58094ECC8D8344914996DAD28F1CCD7DF552@DGGEMM506-MBX.china.huawei.com>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms090808020602030909060000"
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprDIsWRmVeSWpSXmKPExsUyM2K7q+6ag6mRBocfaVi87FnJbrG08xS7 xadj51kcmD1ajrxl9Viy5CdTAFMUl01Kak5mWWqRvl0CV0bHgS1MBZNfM1ZMXXeNpYHx7S7G LkZODgkBE4nJDQvZuxi5OIQEjjBKbLndwQqSEBJYzijR/lAUxBYWSJbYeOo8WFxEoFzix/NT jBANVxkl9p//wQySYBOwkLj5o5Gti5GDg1fAXuL9Eh+QMIuAqsSr1h8sILaoQIzEtZl3wObw CghKnJz5BCzOKRAise3zTjaQmcwC3YwSbY/7WSCO0JZoaOpgncDINwtJzyxkdSAJZoEwiRsr fzFB2OISt57Mh7LNJOZtfsgMYWtLLFv4GsjmALLVJJa1KqEKg9jWEjN+HWSDsBUlpnQ/ZIew TSVeH/3ICGEbSbzb08i+gJFnFaNocWpxcW66kbFealFmcnFxfp5eXmrJJkZgPB3c8lt3B+Pq 146HGAU4GJV4eMX3p0YKsSaWFVfmHmJUAZrzaMPqC4xSLHn5ealKIrxH9gGleVMSK6tSi/Lj i0pzUosPMUpzsCiJ8zrsuxAhJJCeWJKanZpakFoEk2Xi4JRqYFxmYhd+4NYytayv55PkPAsv PazffMT/sPOWau+3Oe+1Fr5sOPrbv/K/WMIH4frIFe07c2yW5m57WPM37nPv5ILz71OjZt2z W8aiI7ecu+3IUsOe5kVSybEzvHdymEosO8byaScX70tL55RLJft/ZKtlytduenoqaWqz9sHH Tss/8GR/7U18MEmJpTgj0VCLuag4EQDY/la4rwIAAA==
Archived-At: 
Subject: Re: [AVTCORE] [avtcore] WGLC for mux-category issue of draft-ietf-avtcore-rfc5282-bis-12
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Audio/Video Transport Core Maintenance 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 12 Jul 2017 06:29:06 -0000

--------------ms090808020602030909060000
Content-Type: multipart/alternative;
 boundary="------------8E93E2333E6168AAD105E4F4"
Content-Language: en-US

This is a multi-part message in MIME format.
--------------8E93E2333E6168AAD105E4F4
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: quoted-printable

Hi Roni,

Den 2017-07-12 kl. 07:54, skrev Roni Even:
>
> Hi,
>
> My reason for suggesting Normal is that it provides more flexibility=20
> for implementations. I understand Magnus point about the added=20
> complexity of supporting a mixed mode where some m-lines allow-mix=20
> while other not. Yet since this is a negotiated attribute than it=20
> leaves it to the implementations if they want to offer allow mix in=20
> all m-lines or at the session level or not. I am not sure why we=20
> should limit ourselves to mandating identical since as Dave Singer=20
> pointed out there may be cases where we want the normal case.
>

And my point in relation to Dave Singer's use case is that the endpoint=20
wanting to have one media type being produced according to not=20
supporting mixed, and having the rest of the session allow mixed still=20
have to have a RTP receiver front-end capable of dealing with that, and=20
a signaling implementation. Thus, that endpoint can take the cost for=20
handling that use case, rather than putting it on everyone else to deal=20
with that case.

> If we define it as identical it means that allow-mix MUST be supported =

> which is not what the draft says for this attribute in the  general=20
> case. I also think that there is always the option to use only=20
> two-bytes RTP header extensions when in doubt as the draft says.
>

I need to comment on the last part. I don't think it requires it to be=20
supported. Identical only requires one to have the same value for all m=3D=
=20
lines part of the same RTP session, i.e. all RTP m=3D lines in the same=20
bundle group. Thus, not having a=3Dextmap-allow-mixed on any m=3D line in=
=20
the bundle group is a valid use.

Cheers

Magnus

> Roni
>
> *From:*avt [mailto:avt-bounces@ietf.org] *On Behalf Of *Magnus Westerlu=
nd
> *Sent:* =D7=99=D7=95=D7=9D =D7=92 04 =D7=99=D7=95=D7=9C=D7=99 2017 16:3=
9
> *To:* Huangyihong (Rachel); avt@ietf.org
> *Subject:* Re: [AVTCORE] [avtcore] WGLC for mux-category issue of=20
> draft-ietf-avtcore-rfc5282-bis-12
>
> Hi,
>
> As one of the people who raised this before I want to explain why I=20
> think it should identical makes more sense in this case.
>
> So first the assumptions. We are talking about offers in the context=20
> of BUNDLE, i.e. multiple m=3D blocks are part of the same RTP session. =

> Thus, these RTP streams generated will be received and sent by a=20
> particular endpoint on the same transport port. Thus, the RTP stack=20
> processing will be done by a single implementation.
>
> The single RTP stack implementation in a BUNDLE context is the basis=20
> for my argument why it makes sense to use identical for=20
> extmap-allow-mixed. The reason is that the entity on the specified IP=20
> address + port will be a single implementation. Thus, I assume it is=20
> capable of handling the switching between one and two-byte extension=20
> header formats without issues. From this perspective identical appears =

> very reasonable.
>
> The argument that David Singer brought to the table is that one may=20
> have different capabilities for audio and video in an endpoint. So=20
> from my perspective, this can only really work if the RTP payload=20
> content is forwarded from the media producing entity and processed by=20
> the RTP stack in such a way that they fulfill the RTP protocol=20
> specification. If necessary, then rewriting could happen in that=20
> forwarding. But, that should really not be needed. First the signaling =

> that enable RTP header extension usage can control its side of the=20
> negotiation and what IDs are used. Remember that the ID space becomes=20
> joint over all extensions in the RTP session, but different RTP=20
> streams and media blocks may have only a subset of all header=20
> extensions configured. Thus, if audio stream generator have this=20
> limitation that it only can process one-byte header extensions, only=20
> IDs that fits the short can be assigned, if at all possible. Thus, the =

> only threat would be a sender that uses two-byte headers when it is=20
> not needed.
>
> So the benefits as I see with identical is the following. For an 
> BUNDLE capable implementation where the implementation that adds=20
> header extensions to the RTP packets is common, there is consistent=20
> configuration for the RTP session, and the possibility to switch at=20
> any point reduces the complexity of the code-base as no attempt to=20
> predict or determine future needs are needed. Use what is currently=20
> needed. No extra complexity for this modern implementations to deal=20
> with legacy implementations into bundle scenario.
>
> That complexity of ensuring which IDs are used, and dealing with=20
> adopting a legacy implementation to BUNDLE ends up with the ones doing =

> that choice, not everyone else. And this is for a case I at least see=20
> as strange as all RTP streams will flow over the same 5-tuple for the=20
> different media types. Thus, only implementation that attempts to=20
> forward RTP packets without rewriting will have this issue.
>
> If one allows Normal, then one pushes the complexities of having to be =

> able to restrict some RTP streams in an RTP session to not switch=20
> between one and two-byte headers. This will require code, and also=20
> more signaling logic to deal with cases where this is offered. Thus, I =

> think using identical would simplify the system in general. And allow=20
> modern BUNDLE capable implementations to becomes simpler, for a little =

> cost for the implementers that attempt to integrate legacy packet=20
> generators into a single RTP session without a translation layer, or=20
> back to back RTP sessions.
>
> Cheers
>
> Magnus
>
> Den 2017-06-29 kl. 08:05, skrev Huangyihong (Rachel):
>
>     Hi Folks,
>
>     As you may notice that there was a discussion for the mux category
>     selection for a=3Dextmap-allow-mixed in
>     draft-ietf-avtcore-rfc5282-bis-12. This issue was raised by Magnus
>     when he was doing the shepherd work. See
>     https://mailarchive.ietf.org/arch/msg/avt/BaElJmDlmDtOaAcXKV_Rk5fAR=
gk.
>     This discussion happened after the WGLC and no formal conclusion
>     was made then.
>
>     And now the discussion is restarted in IESG review of this draft.
>     The author thinks it should be Normal to cover multiple cases,
>     while some people think it=E2=80=99s better to be Identical to make=
 things
>     simple.
>
>     So this email is to have a one-week WGLC for this issue and
>     deliver a formal conclusion to IESG:
>
>     If you do not agree that =E2=80=9CNormal=E2=80=9D mux category shou=
ld be used for
>     a=3Dextmap-allow-mixed, please express it in the mailing list befor=
e
>     8^th July.
>
>     Thanks.
>
>     BR,
>
>     Rachel (as the co-chair)
>
> --=20
> Magnus Westerlund
> ----------------------------------------------------------------------
> Media Technologies, Ericsson Research
> ----------------------------------------------------------------------
> Ericsson AB                 | Phone  +46 10 7148287
> Torshamnsgatan 23           | Mobile +46 73 0949079
> SE-164 80 Stockholm, Sweden | mailto:magnus.westerlund@ericsson.com 
> ----------------------------------------------------------------------


--=20

Magnus Westerlund

----------------------------------------------------------------------
Media Technologies, Ericsson Research
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Torshamnsgatan 23           | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com
----------------------------------------------------------------------


--------------8E93E2333E6168AAD105E4F4
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable


  
    
  
  
    
Hi Roni,

      

      Den 2017-07-12 kl. 07:54, skrev Roni Even:

    

    

      
      
      
      

        
Hi,

        
My reason for
            suggesting Normal is that it provides more flexibility for
            implementations. I understand Magnus point about the added
            complexity of supporting a mixed mode where some m-lines
            allow-mix while other not. Yet since this is a negotiated
            attribute than it leaves it to the implementations if they
            want to offer allow mix in all m-lines or at the session
            level or not. I am not sure why we should limit ourselves to
            mandating identical since as Dave Singer pointed out there
            may be cases where we want the normal case.=C2=A0 
=

      

    

    

    And my point in relation to Dave Singer's use case is that the
    endpoint wanting to have one media type being produced according to
    not supporting mixed, and having the rest of the session allow mixed
    still have to have a RTP receiver front-end capable of dealing with
    that, and a signaling implementation. Thus, that endpoint can take
    the cost for handling that use case, rather than putting it on
    everyone else to deal with that case.=C2=A0 

    

    

      

        
If we define it as
            identical it means that allow-mix MUST be supported which is
            not what the draft says for this attribute in the =C2=A0gener=
al
            case. I also think that there is always the option to use
            only two-bytes RTP header extensions when in doubt as the
            draft says.

      

    

    

    I need to comment on the last part. I don't think it requires it to
    be supported. Identical only requires one to have the same value for
    all m=3D lines part of the same RTP session, i.e. all RTP m=3D lines =
in
    the same bundle group. Thus, not having a=3Dextmap-allow-mixed on any=

    m=3D line in the bundle group is a valid use. 

    

    Cheers

    

    Magnus

    

    

      

        

        
Roni

        
=C2=A0

        

          

            

              
From:
                  avt [mailto:avt-bounces@ietf.org]
                  On Behalf Of Magnus Westerlund

                  Sent: =D7=99=D7=95=
=D7=9D=C2=A0=D7=92 04 =D7=99=D7=95=D7=9C=D7=99
                    2017 16:39

                  To: Huangyihong (Rachel); avt@ietf.org

                  Subject: Re: [AVTCORE] [avtcore] WGLC for
                  mux-category issue of
                  draft-ietf-avtcore-rfc5282-bis-12
=

            

          

          
=C2=A0

          

            
Hi,

              

              As one of the people who raised this before I want to
              explain why I think it should identical makes more sense
              in this case.
              

              

              So first the assumptions. We are talking about offers in
              the context of BUNDLE, i.e. multiple m=3D blocks are part o=
f
              the same RTP session. Thus, these RTP streams generated
              will be received and sent by a particular endpoint on the
              same transport port. Thus, the RTP stack processing will
              be done by a single implementation. 

              

              The single RTP stack implementation in a BUNDLE context is
              the basis for my argument why it makes sense to use
              identical for extmap-allow-mixed. The reason is that the
              entity on the specified IP address + port will be a single
              implementation. Thus, I assume it is capable of handling
              the switching between one and two-byte extension header
              formats without issues. From this perspective identical
              appears very reasonable.
              

              

              The argument that David Singer brought to the table is
              that one may have different capabilities for audio and
              video in an endpoint. So from my perspective, this can
              only really work if the RTP payload content is forwarded
              from the media producing entity and processed by the RTP
              stack in such a way that they fulfill the RTP protocol
              specification. If necessary, then rewriting could happen
              in that forwarding. But, that should really not be needed.
              First the signaling that enable RTP header extension usage
              can control its side of the negotiation and what IDs are
              used. Remember that the ID space becomes joint over all
              extensions in the RTP session, but different RTP streams
              and media blocks may have only a subset of all header
              extensions configured. Thus, if audio stream generator
              have this limitation that it only can process one-byte
              header extensions, only IDs that fits the short can be
              assigned, if at all possible. Thus, the only threat would
              be a sender that uses two-byte headers when it is not
              needed.
              

              

              So the benefits as I see with identical is the following.
              For an BUNDLE capable implementation where the
              implementation that adds header extensions to the RTP
              packets is common, there is consistent configuration for
              the RTP session, and the possibility to switch at any
              point reduces the complexity of the code-base as no
              attempt to predict or determine future needs are needed.
              Use what is currently needed. No extra complexity for this
              modern implementations to deal with legacy implementations
              into bundle scenario.
              

              

              That complexity of ensuring which IDs are used, and
              dealing with adopting a legacy implementation to BUNDLE
              ends up with the ones doing that choice, not everyone
              else. And this is for a case I at least see as strange as
              all RTP streams will flow over the same 5-tuple for the
              different media types. Thus, only implementation that
              attempts to forward RTP packets without rewriting will
              have this issue.
              

              

              If one allows Normal, then one pushes the complexities of
              having to be able to restrict some RTP streams in an RTP
              session to not switch between one and two-byte headers.
              This will require code, and also more signaling logic to
              deal with cases where this is offered. Thus, I think using
              identical would simplify the system in general. And allow
              modern BUNDLE capable implementations to becomes simpler,
              for a little cost for the implementers that attempt to
              integrate legacy packet generators into a single RTP
              session without a translation layer, or back to back RTP
              sessions. 

              

              Cheers

              

              Magnus

              

              Den 2017-06-29 kl. 08:05, skrev Huangyihong (Rachel):<=
/o:p>

          

          

            
Hi Folks,

            
=C2=A0

            
As you may notice that there was a
              discussion for the mux category selection for
              a=3Dextmap-allow-mixed in draft-ietf-avtcore-rfc5282-bis-12=
=2E
              This issue was raised by Magnus when he was doing the
              shepherd work. See
              https://mailarchive.ietf.org/arc=
h/msg/avt/BaElJmDlmDtOaAcXKV_Rk5fARgk.
              This discussion happened after the WGLC and no formal
              conclusion was made then.

            
=C2=A0

            
And now the discussion is restarted in=

              IESG review of this draft. The author thinks it should be
              Normal to cover multiple cases, while some people think
              it=E2=80=99s better to be Identical to make things simple.
              

            
=C2=A0

            
So this email is to have a one-week
              WGLC for this issue and deliver a formal conclusion to
              IESG:

            
=C2=A0

            
If you do not agree that =E2=80=9CNorm=
al=E2=80=9D mux
              category should be used for a=3Dextmap-allow-mixed, please
              express it in the mailing list before 8th July.
              

            
=C2=A0

            
Thanks.

            
=C2=A0

            
BR,

            
Rachel (as the co-chair)
          

          
=C2=A0

          
-- 

          
=C2=A0

          
Magnus Westerlund 

          
=C2=A0

          
----------------------------------------------------------=
------------

          
Media Technologies, Ericsson Research

          
----------------------------------------------------------=
------------

          
Ericsson AB=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 | Phone=C2=A0 +46 10 714=
8287

          
Torshamnsgatan 23=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0 | Mobile +46 73 0949079

          
SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@=
ericsson.com

          
----------------------------------------------------------=
------------

        

      

    

    


    

    
--=20

Magnus Westerlund=20

----------------------------------------------------------------------
Media Technologies, Ericsson Research
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Torshamnsgatan 23           | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@erics=
son.com
----------------------------------------------------------------------
  


--------------8E93E2333E6168AAD105E4F4--

--------------ms090808020602030909060000
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME-kryptografisk signatur

MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC
DLkwggX7MIID46ADAgECAhEA75oIXW3eBHJH2u7brn5gnDANBgkqhkiG9w0BAQUFADA6MREw
DwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2
MjAeFw0xNTAxMjMwODUwNTdaFw0xODAxMjMwODUwNTdaMHAxETAPBgNVBAoMCEVyaWNzc29u
MRowGAYDVQQDDBFNYWdudXMgV2VzdGVybHVuZDEtMCsGCSqGSIb3DQEJARYebWFnbnVzLndl
c3Rlcmx1bmRAZXJpY3Nzb24uY29tMRAwDgYDVQQFEwdlcmFtc3dkMIIBIjANBgkqhkiG9w0B
AQEFAAOCAQ8AMIIBCgKCAQEAkULrp/ViIWFfDbY2Ycew0bXJc2In2WNQbPORLyFXNpRhjhmg
ot5P/0w90T4HY0H6QayjIPK6qIGt1DBXwkq/QHoRsFZiDK9JDnk2WUDcqbJaHqMXvkhj4Jl4
KvonZ31T3NF/8OlcEjumVc8AUA6iccOeUva3TvL/EOqY3f4bsem4ER3KAcY/lTPWivSY+/Aw
vS64JjaANOHVhZ0LUj10JTe9CpdXB+1nMpqLFYkjse/2ahQuKyaBKhKJs35pSYijh3Ln+vMv
YUNEna2LjHvkCPVo5Oihylxjmd1OSDXND7125tgo/kB08RtaJ9u6PNw0CoUgA+d23UzVzlYg
aSJbhwIDAQABo4IBxDCCAcAwSAYDVR0fBEEwPzA9oDugOYY3aHR0cDovL2NybC50cnVzdC50
ZWxpYS5jb20vZXJpY3Nzb25ubGluZGl2aWR1YWxjYXYyLmNybDCBggYIKwYBBQUHAQEEdjB0
MCgGCCsGAQUFBzABhhxodHRwOi8vb2NzcDIudHJ1c3QudGVsaWEuY29tMEgGCCsGAQUFBzAC
hjxodHRwOi8vY2EudHJ1c3QudGVsaWFzb25lcmEuY29tL2VyaWNzc29ubmxpbmRpdmlkdWFs
Y2F2Mi5jZXIwKQYDVR0RBCIwIIEebWFnbnVzLndlc3Rlcmx1bmRAZXJpY3Nzb24uY29tMFUG
A1UdIAROMEwwSgYMKwYBBAGCDwIDAQESMDowOAYIKwYBBQUHAgEWLGh0dHBzOi8vcmVwb3Np
dG9yeS50cnVzdC50ZWxpYXNvbmVyYS5jb20vQ1BTMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggr
BgEFBQcDAjAdBgNVHQ4EFgQUwff+Y5pMEPJX7xortCv8deSKeQEwHwYDVR0jBBgwFoAUsQ3K
1Ea3r4YCwy9vBsoOdnF/SzcwDgYDVR0PAQH/BAQDAgWgMA0GCSqGSIb3DQEBBQUAA4ICAQBy
rk0JhGgu9Fd/0Fg1cMhSa882HMQZWQLT1V4PFQpU6t2an8xaqT5JsxOpuxb+WxwpKG+UDbzQ
cWgcb/DPW3Mc0AvhTFII1qAYf6Smkq6SOD/8TACjH+dy7JrbcNYJcTlVNBlC/V/C+waICkER
wuMC/8QjXs0ExJekAD3i/3GUok9WnvEHsohIL04qk1lbvJN4WGHCHFercX11Ch+UjStHwtyw
zyFWi64CqD48kKqPwEne3Lj7ozxzuwCCaJI9fmCQgLfSL+UcDgEb7cQucMAnB/Zxlz6U6ohd
PRlQHaLevAYD2UK+BlhZKLAv/DNUz0nk6fx4CiJF5DIRteUdzGoeGcnWMWO9hv5PkEJC1WkZ
gYXZ/91HMUjsYUuy5/EsmkqvkCalRudoqe6Pex3A34iFGNvDhI3fCrbvmRS4FARPse5D8BLu
e/PIvAPNUC7xl8UcfnTNVgy5ITzWNiY9hIrbAzfPbTXyZSIdMD+HTNg33ziMbu2Iry/2eS1X
/whXkApnQNpHplvzf1xMEeNPlDKtL8OOg+9y4ESdn27EKxeeaaFXsrhb3z1woIjQxXINft5W
EPXWnks/YBCvrLTH8kRCLZgH17zDxb+MLqKj1XUQtBKgDhb+VswJM6GF+dDeBJoEYjvLR1Sx
l5yfaRj0F7HYkjRUwyehwSHgTVqtgnT9QjCCBrYwggSeoAMCAQICEQCgDMvMm5mY7OI6cPR8
wcBZMA0GCSqGSIb3DQEBBQUAMDcxFDASBgNVBAoMC1RlbGlhU29uZXJhMR8wHQYDVQQDDBZU
ZWxpYVNvbmVyYSBSb290IENBIHYxMB4XDTE0MDUyNzA3NDYyMVoXDTI0MDUyNzA3NDYyMVow
OjERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIEluZGl2aWR1YWwg
Q0EgdjIwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQDaulPrX0iWU5+JOOqjddx4
Gnl17DJhklkoXOgOSBMhW6FzGVt5RR7KPv+rjt2YpbwdoqWSYa4VPkS/72vuQoWsvz2avWWX
hPTdNzrB3zs5cJO7sKIyd+LRy4l/8kKK4iPm+Q18XyGF0xTuc5WS3WiMScJSxEKdIOP8xehB
raHZabrGh9OxQHC4iBHkzD0YF3J/vBqBTr7blRzYf1h3j5a7qVIHCPfz+eCE175mResXDQRI
7LvMiZtVaqitBl0oAJiJyeBmvEujBNsIEgUQ6JcQFG5ny0EazLywv7clwb7izvLgoXc6SFrd
0D7TGJtkdldVJtMwDYXpyFMGAijT6uf8h2kuPIwrDgQFNEyIQZ4q52ZpRGwugC6sMxgHEDGj
A/CxX9aC5Vi1EMRJiOGF6gV3T+V5yHDHSBBeQbVAXm8wSTDBfXQwdro/AXqET0mG6Rpe4q2F
GBaauE8qHEO6qR3WAEgvjVfFU2k6xZx1qmvwhkXadxh6ZIMXzgb6WpjivLnR0GEKNrgN2DXd
vo+6eAt45Bhvmeka2TrJDxMLWiBy8QYgNeNXYQsuREnDsjWo6wF0LqbA5769om9nn/uJzmzx
b3nT1iHue5co9J93ta06kxiASHvcIzZwAOjKnmk0vR3IT7Qbzq2of3E1s18xo8DM9D91Cak0
Nq+RALtdv1uZKQIDAQABo4IBuDCCAbQwgYoGCCsGAQUFBwEBBH4wfDAtBggrBgEFBQcwAYYh
aHR0cDovL29jc3AudHJ1c3QudGVsaWFzb25lcmEuY29tMEsGCCsGAQUFBzAChj9odHRwOi8v
cmVwb3NpdG9yeS50cnVzdC50ZWxpYXNvbmVyYS5jb20vdGVsaWFzb25lcmFyb290Y2F2MS5j
ZXIwEgYDVR0TAQH/BAgwBgEB/wIBADBVBgNVHSAETjBMMEoGDCsGAQQBgg8CAwEBAjA6MDgG
CCsGAQUFBwIBFixodHRwczovL3JlcG9zaXRvcnkudHJ1c3QudGVsaWFzb25lcmEuY29tL0NQ
UzBLBgNVHR8ERDBCMECgPqA8hjpodHRwOi8vY3JsLTMudHJ1c3QudGVsaWFzb25lcmEuY29t
L3RlbGlhc29uZXJhcm9vdGNhdjEuY3JsMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcD
BDAOBgNVHQ8BAf8EBAMCAQYwHQYDVR0OBBYEFLENytRGt6+GAsMvbwbKDnZxf0s3MB8GA1Ud
IwQYMBaAFPCPWTgAs/WPmpYM1ev6e6oX6BMSMA0GCSqGSIb3DQEBBQUAA4ICAQBuByBsr6x3
PZBCsmGbcSZ/XL+0tnVMblInoJgL1Bh3PiRicgdo8l+6cvWp/ArBwMYNwSNyrvY9IewyaV8n
65c5oN+l2JDUuzrdANVKnYxha7ZyCEiPmY98sB2bnZgxfJLXQYoRwI7pOOwfyoP2fCYVCd+x
hsfysYiIl4ORzE3TpeppQ2yWkyBBmoHUXJh97ue6+bJ2fqnVUoOVMVnYYEtvsz67v7w2z3fv
dcy04/RnoylxSenxADi1tY9iIydHMgyOu3dfzsxU8AivMGG4aKStsCfUEyg0LlkbhqMrdnes
s3e1qAEueSRNASLfpFwyRmzmiuNh9onzuhER2yYhK/6IeCs4HQHrPhkY8JUmhtmdL2uErOZW
Os38FQhGWHWXI0g6SgdDObU0GEHju0MkDziOhm+BVwPZKN7B7wD7OPj6vlLVo6d8vLGK9byw
hEfXjxLIC3Qhtu5lJPTgIo5Bup+aBBjiJ/u9BfqryqZpudnWfG+wxC327rpNAq2OKdFsR92w
behSZD3mSSAemDVwGB2Yu0XHQYyyYfpWsGyGEyRSHKFhRwJdINPzWLI89wy4Wc+PgqyekkEm
Jqe6g4XSQFj4mqtwvqhP4dg2QCcKM/bh62RwfM7GeSS/LFGe84KmJjTDfvT8c2rK8nEyZ/em
OtwCGXQ6tZCByMNLxeDwU1TGbTGCAxcwggMTAgEBME8wOjERMA8GA1UECgwIRXJpY3Nzb24x
JTAjBgNVBAMMHEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjICEQDvmghdbd4Eckfa7tuu
fmCcMA0GCWCGSAFlAwQCAQUAoIIBmTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG
SIb3DQEJBTEPFw0xNzA3MTIwNjI4NTBaMC8GCSqGSIb3DQEJBDEiBCBJAMSmJ/dplBT/+F2n
hHfOD8h4QAdF0gdVFZDzBWC4njBeBgkrBgEEAYI3EAQxUTBPMDoxETAPBgNVBAoMCEVyaWNz
c29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYyAhEA75oIXW3eBHJH
2u7brn5gnDBgBgsqhkiG9w0BCRACCzFRoE8wOjERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNV
BAMMHEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjICEQDvmghdbd4Eckfa7tuufmCcMGwG
CSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAO
BggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgw
DQYJKoZIhvcNAQEBBQAEggEAZogguKE2tObgTz81Jm6ZySE3AMNXVKnsO50aRNJ43l6FRi6t
IcsVjyuNoQRKoDCNwpiotXiACfF4BRbYGwUKTjM2nTLjgBkdxHLtnomkKEGrWADGyZztdj2q
gz+7po1QewY060tpcuId/sZa2tIgpk/hIiq1HXrDX35fdZlSBdd7IM4NURuJhfqAdEwrQ28I
U0fYq6iywjnrAZukIEKtbhvIhciUS7qFYdtPOzYLX2ThgN9YbolwWKtpNcMpsm/ZYWhS2Ay+
f/zdBw0JYuHMVDa21YUwDsIyqhp213caduyWxQqrGqfoGX0wR0y/pakewXTGFtgReQPIlzpP
VO+kfAAAAAAAAA==
--------------ms090808020602030909060000--


From nobody Mon Jul 17 06:10:46 2017
Return-Path: 
X-Original-To: avt@ietfa.amsl.com
Delivered-To: avt@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 976A2131B6F for ; Mon, 17 Jul 2017 06:10:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.698
X-Spam-Level: 
X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MMDu6fvlTfom for ; Mon, 17 Jul 2017 06:10:43 -0700 (PDT)
Received: from mail-yw0-x22e.google.com (mail-yw0-x22e.google.com [IPv6:2607:f8b0:4002:c05::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 093AC131B67 for ; Mon, 17 Jul 2017 06:10:43 -0700 (PDT)
Received: by mail-yw0-x22e.google.com with SMTP id l21so47013107ywb.1 for ; Mon, 17 Jul 2017 06:10:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=vKsdbQV4tsOfIpz7Rxicjc2eABBGK0JdGeZt2wFo1UE=; b=H1Nt0/Kqb4qaxSlA3+eMySlt5RoLSnAB2M13byY+n/TbWEbyHDsDajfUcgfh6oF8CK Srzla0HC343pcJKvZNR3pf2fSNdGTUeqSNDQpnzKrRwRVow9qDoH34nL9UMriYgjY0GD SZRvbuwfbf4nrtskIruPBBPeQbyP1Jwz3w5lzfyvJc6WEl3xGq7Ju/aC1MtJ9RUTIqbx mooXR9nj/UYCi+YZTeeyO1g7MRUPP3bsz4k2Or7pXoYfZNJuOWbyFeIysx6NNWuMHT5y DR/GmUlaKRLk5HYfgiQfjBKu2BiofU0VY/72YVBvC5RDTQzwV/yWk+CRrcI5eipO5BDc nC5Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=vKsdbQV4tsOfIpz7Rxicjc2eABBGK0JdGeZt2wFo1UE=; b=RLc8mXHHLxwb4zwoyjWfJo0k6sZiEjFBNTX5s4eo3yUbfED9zrmscstZiUvT7cHJqN oxmk0/CLezhA1yIhbbNZF83xd1sjcoIifx82IBHd7YuIHVgDsYMoZArOUrHKQUFjFJr6 0m7WBCz0fBsoZ2qD5EuUP51be/K2FyNPw1aYoDRi41Q817BPpnvsyUr2uMFb+WCNk+FO piKEO++A84aSISJlDdhnp6yF0wrS8/ja0KEqtsT12i/xUFqnkyTgOKVuVG96dOc1Vgj2 Mps0kx95WwiTzByvJiOFtikV1KochFdOvFrqKk6fMmFsjakCI8+hfJxcNJTpBYStbPXv 8WJA==
X-Gm-Message-State: AIVw111RKo5syRpOJAW3a3mTSaE1H0oulitkgG5C12PJNw8qINziQSMO en63z3NBwNDv3KUQhgzg1LxbF1CI0g==
X-Received: by 10.129.90.131 with SMTP id o125mr16041236ywb.61.1500297042137;  Mon, 17 Jul 2017 06:10:42 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.129.90.136 with HTTP; Mon, 17 Jul 2017 06:10:21 -0700 (PDT)
In-Reply-To: 
References: 
From: Varun Singh 
Date: Mon, 17 Jul 2017 16:10:21 +0300
Message-ID: 
To: Ted Hardie 
Cc: "avt@ietf.org" , jonathan , Varun Singh 
Content-Type: multipart/alternative; boundary="001a11491bbc4122a40554832048"
Archived-At: 
Subject: Re: [AVTCORE] draft-ietf-avtcore-mprtp-03
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Audio/Video Transport Core Maintenance 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 17 Jul 2017 13:10:46 -0000

--001a11491bbc4122a40554832048
Content-Type: text/plain; charset="UTF-8"

Hi Ted,

Thanks for reviewing the document, I am just getting to the review
comments, see inline.

On Sat, Apr 8, 2017 at 12:49 AM, Ted Hardie  wrote:

> Howdy,
>
> I was asked to review this draft in Chicago; sorry for not getting to it
> sooner.
>
> First, the security considerations seem to be TBD entirely, which seems
> surprising.  I was particularly interested to see how this draft would
> tackle linkability, since it is an ongoing discussion in other groups (e.g.
> QUIC).  I think that the security considerations, when written, need to
> tackle both linkability (the ability of an observer to cross-correlate
> traffic on two different paths as belonging to the same endpoint) and
> consent freshness.
>
>
This is indeed correct, I have not gotten around to this, especially since
RTP has several mechanisms including SRTP not mandatory. That being said,
webrtc-capable endpoints might prefer doing DTLS/SRTP. And here I
envisioned that the DTLS context would be reused for all the subflows.



> Second, I believe this requirement:
>
>    Multipath RTP (MPRTP) MUST be backwards compatible; an MPRTP Stream
>    needs to fall back to be compatible with legacy RTP stacks if MPRTP
>    support is not successfully negotiated.
>
> may need re-wording. I initially misread this team that MPRTP would appear
> to be non-multipath RTP if the MPRTP support were not available (following
> what was said about NAT bindings); it seems you mean instead that an MPRTP
> stack must fall back to non-multipath RTP.  Clarifying this would be useful.
>

The requirement section was written when we were designing the MPRTP
packets. The meaning that we were trying to get across was: consider a
MPRTP endpoint communicating with a RTP endpoint, the MPRTP endpoint should
be use multiple subflows and the RTP subflow should be able to receive
them. The fact that the subflows  are marked inside the RTP header
extensions and not in the RTP header, so that non-MPRTP capable endpoint
would still be able to parse the data even though it does not support MPRTP
and ignore the subflow header extensions. Ofcourse the non-MPRTP capable
endpoint may not do a great job because the path skew (latency across the
distinct paths) may be too high and it may end up arbitrarily start
dropping packets.

In the 2013 paper: MPRTP: Multipath Considerations for Real-time Media,
evaluated MPRTP in various network test scenarios.
http://www.netlab.tkk.fi/~varun/2013_MMSYS_Singh_MPRTP.pdf




>
> On the use cases,  the use case for fault tolerance has some very simple
> applications that I have seen proposed in the past.  In one case, ambulance
> telemetry was sent over multiple cellular networks--there, full duplication
> was appropriate and the receiver simply threw away any information already
> received from a different interface.  Load balancing applications are
> harder, and I believe the draft may want to explicitly consider how
> differential packet traversal times across different paths will impact the
> number of applications that can use this.  If I understand this correctly,
> a system with a playout buffer would be able to interleave RTP packets from
> different subflows successfully.  A system without such a buffer or with
> one too small for late arrivals will end up losing information.  There are
> ways to get around this, but the document does not go into them in detail.
> Will they be covered by later documents?
>


Your observation on the potential issues are correct. This comes down to
defining a couple of algorithms: scheduling algorithm on how to send
packets on particular paths, and how the playout buffer, handles the
varying packet skew of those paths to play packets out. Again pointing to
the above paper considered this for streaming video. We are currently
working on adding congestion control to the mix (i.e., webrtc applications
using MPRTP).


>
> Also, the document says:
>
> In contrast to RTCP, SDP offers a reliable
> communication channel so that no separate retransmissions logic is
> necessary.  In SDP, especially when combined with ICE, connectivity
> check mechanisms including sophisticated rules are readily available.
>
> While SDP is not inherently protected, suitable security may need to
> be applied anyway to the basic session setup.
>
> It's not clear what the draft means when it is saying "SDP offers a
> reliable
> communication channel"; does this man to say SIP?
>

The problem that we wanted to solve, is what does an endpoint do when it
discovers new interfaces (because it may be continuously gathering ICE
candidates). The solution we were discussing was should the availability of
new interfaces be announced to the remote endpoint: in-band (i.e., in RTP)
or out-of-band (i.e., in SDP or SIP).  The draft currently allows MPRTP
endpoints to announce the newly discovered interfaces in-band. With the
formation of the ICE working group and discussion around passive-aggressive
nomination or continuous nomination or similar techniques, we might be
leaning on the output of the ICE working group.


Thanks for the review again,
Varun


> I am not currently subscribed to this list, so if there are comments in
> response, please cc me.
>
> thanks,
>
> Ted
>
> _______________________________________________
> Audio/Video Transport Core Maintenance
> avt@ietf.org
> https://www.ietf.org/mailman/listinfo/avt
>
>


-- 
http://www.callstats.io

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


Hi Ted,

Thanks for reviewing the docume=
nt, I am just getting to the review comments, see inline.

On Sat, Apr 8, 2017 at 12:4=
9 AM, Ted Hardie <ted.ietf@gmail.com> wrote:
Howd=
y,

I was asked to review this draft in Chicago; sorry for not =
getting to it sooner.

First, the security considerations seem =
to be TBD entirely, which seems surprising.=C2=A0 I was particularly intere=
sted to see how this draft would tackle linkability, since it is an ongoing=
 discussion in other groups (e.g. QUIC).=C2=A0 I think that the security co=
nsiderations, when written, need to tackle both linkability (the ability of=
 an observer to cross-correlate traffic on two different paths as belonging=
 to the same endpoint) and consent freshness.=C2=A0 


This is indeed correct, I have not gotten aro=
und to this, especially since RTP has several mechanisms including SRTP not=
 mandatory. That being said, webrtc-capable endpoints might prefer doing DT=
LS/SRTP. And here I envisioned that the DTLS context would be reused for al=
l the subflows.

=C2=A0
Second, I beli=
eve this requirement:
   Multipath R=
TP (MPRTP) MUST be backwards compatible; an MPRTP Stream
   needs to fall back to be compatible with legacy RTP stacks if MPRTP
   support is not successfully negotiated.
may need =
re-wording. I initially misread this team that MPRTP would appear to be non=
-multipath RTP if the MPRTP support were not available (following what was =
said about NAT bindings); it seems you mean instead that an MPRTP stack mus=
t fall back to non-multipath RTP.=C2=A0 Clarifying this would be useful.

The requirement section was w=
ritten when we were designing the MPRTP packets. The meaning that we were t=
rying to get across was: consider a MPRTP endpoint communicating with a RTP=
 endpoint, the MPRTP endpoint should be use multiple subflows and the RTP s=
ubflow should be able to receive them. The fact that the subflows=C2=A0 are=
 marked inside the RTP header extensions and not in the RTP header, so that=
 non-MPRTP capable endpoint would still be able to parse the data even thou=
gh it does not support MPRTP and ignore the subflow header extensions. Ofco=
urse the non-MPRTP capable endpoint may not do a great job because the path=
 skew (latency across the distinct paths) may be too high and it may end up=
 arbitrarily start dropping packets.

In the 2013 p=
aper:=C2=A0MPRTP: Multipath Considerations for Real-time Media, evaluated M=
PRTP in various network test scenarios.=C2=A0


=

=C2=A0

On the use cases,=C2=A0 the use case for fault=
 tolerance has some very simple applications that I have seen proposed in t=
he past.=C2=A0 In one case, ambulance telemetry was sent over multiple cell=
ular networks--there, full duplication was appropriate and the receiver sim=
ply threw away any information already received from a different interface.=
=C2=A0 Load balancing applications are harder, and I believe the draft may =
want to explicitly consider how differential packet traversal times across =
different paths will impact the number of applications that can use this.=
=C2=A0 If I understand this correctly, a system with a playout buffer would=
 be able to interleave RTP packets from different subflows successfully.=C2=
=A0 A system without such a buffer or with one too small for late arrivals =
will end up losing information.=C2=A0 There are ways to get around this, bu=
t the document does not go into them in detail.=C2=A0 Will they be covered =
by later documents?


Your observation on the potential issues are correct. This comes do=
wn to defining a couple of algorithms: scheduling algorithm on how to send =
packets on particular paths, and how the playout buffer, handles the varyin=
g packet skew of those paths to play packets out. Again pointing to the abo=
ve paper considered this for streaming video. We are currently working on a=
dding congestion control to the mix (i.e., webrtc applications using MPRTP)=
.
=C2=A0
<=
div dir=3D"ltr">

Also, the document says:
In contrast to RT=
CP, SDP offers a reliable
communication channel so that no separate retr=
ansmissions logic is
necessary.  In SDP, especially when combined with ICE, connectivity
check mechanisms including sophisticated rules are readily available.

While SDP is not inherently protected, suitable security may need to
be applied anyway to the basic session setup.
It=
's not clear what the draft means when it is saying "SDP offers a =
reliable
communication channel"; does this man to say SI=
P?

The problem =
that we wanted to solve, is what does an endpoint do when it discovers new =
interfaces (because it may be continuously gathering ICE candidates). The s=
olution we were discussing was should the availability of new interfaces be=
 announced to the remote endpoint: in-band (i.e., in RTP) or out-of-band (i=
.e., in SDP or SIP).=C2=A0 The draft currently allows MPRTP endpoints to an=
nounce the newly discovered interfaces in-band. With the formation of the I=
CE working group and discussion around passive-aggressive nomination or con=
tinuous nomination or similar techniques, we might be leaning on the output=
 of the ICE working group.
=C2=A0

Thanks=
 for the review again,
Varun


I am not currently subscribed to this list, so if there are comments =
in response, please cc me.

thanks,

Ted<=
br>


_______________________________________________

Audio/Video Transport Core Maintenance

avt@ietf.org

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





-- 




--001a11491bbc4122a40554832048--


From nobody Sat Jul 22 23:22:50 2017
Return-Path: 
X-Original-To: avt@ietf.org
Delivered-To: avt@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D914131C3C; Sat, 22 Jul 2017 23:22:42 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: 
Cc: avt@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.57.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <150079096200.31280.14992655395951009107@ietfa.amsl.com>
Date: Sat, 22 Jul 2017 23:22:42 -0700
Archived-At: 
Subject: [AVTCORE] I-D Action: draft-ietf-avtcore-rfc5285-bis-13.txt
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.22
List-Id: Audio/Video Transport Core Maintenance 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 23 Jul 2017 06:22:42 -0000

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Audio/Video Transport Core Maintenance WG of the IETF.

        Title           : A General Mechanism for RTP Header Extensions
        Authors         : David Singer
                          Harikishan Desineni
                          Roni Even
	Filename        : draft-ietf-avtcore-rfc5285-bis-13.txt
	Pages           : 24
	Date            : 2017-07-22

Abstract:
   This document provides a general mechanism to use the header
   extension feature of RTP (the Real-Time Transport Protocol).  It
   provides the option to use a small number of small extensions in each
   RTP packet, where the universe of possible extensions is large and
   registration is de-centralized.  The actual extensions in use in a
   session are signaled in the setup information for that session.  This
   document obsoletes RFC5285.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-avtcore-rfc5285-bis/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-avtcore-rfc5285-bis-13
https://datatracker.ietf.org/doc/html/draft-ietf-avtcore-rfc5285-bis-13

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-avtcore-rfc5285-bis-13


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

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


From nobody Sat Jul 22 23:27:03 2017
Return-Path: 
X-Original-To: avt@ietfa.amsl.com
Delivered-To: avt@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B595131892; Sat, 22 Jul 2017 23:27:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.221
X-Spam-Level: 
X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Z2PUDJ20q7f; Sat, 22 Jul 2017 23:27:00 -0700 (PDT)
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 3B411124D37; Sat, 22 Jul 2017 23:26:59 -0700 (PDT)
Received: from 172.18.7.190 (EHLO LHREML712-CAH.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DRU17388; Sun, 23 Jul 2017 06:26:57 +0000 (GMT)
Received: from DGGEMM403-HUB.china.huawei.com (10.3.20.211) by LHREML712-CAH.china.huawei.com (10.201.108.35) with Microsoft SMTP Server (TLS) id 14.3.301.0; Sun, 23 Jul 2017 07:26:56 +0100
Received: from DGGEMM506-MBX.china.huawei.com ([169.254.3.170]) by DGGEMM403-HUB.china.huawei.com ([10.3.20.211]) with mapi id 14.03.0301.000; Sun, 23 Jul 2017 14:26:52 +0800
From: Roni Even 
To: "avt@ietf.org" , Magnus Westerlund , Ben Campbell 
CC: The IESG 
Thread-Topic: New Version Notification for draft-ietf-avtcore-rfc5285-bis-13.txt
Thread-Index: AQHTA3wazYOxZ6o2tki2nlu6oFLtJqJg8V3A
Date: Sun, 23 Jul 2017 06:26:52 +0000
Message-ID: <6E58094ECC8D8344914996DAD28F1CCD7EE876@DGGEMM506-MBX.china.huawei.com>
References: <150079096276.31280.12592363692999578408.idtracker@ietfa.amsl.com>
In-Reply-To: <150079096276.31280.12592363692999578408.idtracker@ietfa.amsl.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.200.202.51]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020204.597441B1.0071, ss=1, re=0.000, recu=0.000, reip=0.000,  cl=1, cld=1, fgs=0, ip=169.254.3.170, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: ec44457eec7057f5c890a8bd8dafe3e3
Archived-At: 
Subject: [AVTCORE] FW: New Version Notification for draft-ietf-avtcore-rfc5285-bis-13.txt
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Audio/Video Transport Core Maintenance 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 23 Jul 2017 06:27:02 -0000

SGksDQpJIHN1Ym1pdHRlZCBhIHZlcnNpb24gdGhhdCBJIGhvcGUgYWRkcmVzc2VzIGFsbCB0aGUg
Y29tbWVudHMgZnJvbSB0aGUgSUVTRyByZXZpZXcuDQpUaGUgbWFqb3Igb3BlbiBpc3N1ZSB3YXMg
dGhlIGNhdGVnb3J5IG9mIGFsbG93ZWQtbWl4IGluIGJ1bmRsZSBhbmQgYmFzZWQgb24gdGhlIFdH
IHByZWZlcmVuY2UgaXQgaXMgbm93IElkZW50aWNhbC4NCg0KVGhhbmtzDQpSb25pIEV2ZW4NCg0K
LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IGludGVybmV0LWRyYWZ0c0BpZXRmLm9y
ZyBbbWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZ10gDQpTZW50OiDXmdeV153CoNeQIDIz
INeZ15XXnNeZIDIwMTcgMDk6MjMNClRvOiBIYXJpa2lzaGFuIERlc2luZW5pOyBIYXJpS2lzaGFu
IERlc2luZW5pOyBSb25pIEV2ZW47IGF2dGNvcmUtY2hhaXJzQGlldGYub3JnOyBEYXZpZCBTaW5n
ZXI7IFJvbmkgRXZlbg0KU3ViamVjdDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFm
dC1pZXRmLWF2dGNvcmUtcmZjNTI4NS1iaXMtMTMudHh0DQoNCg0KQSBuZXcgdmVyc2lvbiBvZiBJ
LUQsIGRyYWZ0LWlldGYtYXZ0Y29yZS1yZmM1Mjg1LWJpcy0xMy50eHQNCmhhcyBiZWVuIHN1Y2Nl
c3NmdWxseSBzdWJtaXR0ZWQgYnkgUm9uaSBFdmVuIGFuZCBwb3N0ZWQgdG8gdGhlIElFVEYgcmVw
b3NpdG9yeS4NCg0KTmFtZToJCWRyYWZ0LWlldGYtYXZ0Y29yZS1yZmM1Mjg1LWJpcw0KUmV2aXNp
b246CTEzDQpUaXRsZToJCUEgR2VuZXJhbCBNZWNoYW5pc20gZm9yIFJUUCBIZWFkZXIgRXh0ZW5z
aW9ucw0KRG9jdW1lbnQgZGF0ZToJMjAxNy0wNy0yMg0KR3JvdXA6CQlhdnRjb3JlDQpQYWdlczoJ
CTI0DQpVUkw6ICAgICAgICAgICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRz
L2RyYWZ0LWlldGYtYXZ0Y29yZS1yZmM1Mjg1LWJpcy0xMy50eHQNClN0YXR1czogICAgICAgICBo
dHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLWF2dGNvcmUtcmZjNTI4
NS1iaXMvDQpIdG1saXplZDogICAgICAgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0
LWlldGYtYXZ0Y29yZS1yZmM1Mjg1LWJpcy0xMw0KSHRtbGl6ZWQ6ICAgICAgIGh0dHBzOi8vZGF0
YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQtaWV0Zi1hdnRjb3JlLXJmYzUyODUtYmlz
LTEzDQpEaWZmOiAgICAgICAgICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRy
YWZ0LWlldGYtYXZ0Y29yZS1yZmM1Mjg1LWJpcy0xMw0KDQpBYnN0cmFjdDoNCiAgIFRoaXMgZG9j
dW1lbnQgcHJvdmlkZXMgYSBnZW5lcmFsIG1lY2hhbmlzbSB0byB1c2UgdGhlIGhlYWRlcg0KICAg
ZXh0ZW5zaW9uIGZlYXR1cmUgb2YgUlRQICh0aGUgUmVhbC1UaW1lIFRyYW5zcG9ydCBQcm90b2Nv
bCkuICBJdA0KICAgcHJvdmlkZXMgdGhlIG9wdGlvbiB0byB1c2UgYSBzbWFsbCBudW1iZXIgb2Yg
c21hbGwgZXh0ZW5zaW9ucyBpbiBlYWNoDQogICBSVFAgcGFja2V0LCB3aGVyZSB0aGUgdW5pdmVy
c2Ugb2YgcG9zc2libGUgZXh0ZW5zaW9ucyBpcyBsYXJnZSBhbmQNCiAgIHJlZ2lzdHJhdGlvbiBp
cyBkZS1jZW50cmFsaXplZC4gIFRoZSBhY3R1YWwgZXh0ZW5zaW9ucyBpbiB1c2UgaW4gYQ0KICAg
c2Vzc2lvbiBhcmUgc2lnbmFsZWQgaW4gdGhlIHNldHVwIGluZm9ybWF0aW9uIGZvciB0aGF0IHNl
c3Npb24uICBUaGlzDQogICBkb2N1bWVudCBvYnNvbGV0ZXMgUkZDNTI4NS4NCg0KICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgIA0KDQoNClBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3Vw
bGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24gdW50aWwgdGhlIGh0bWxp
emVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy4NCg0K
VGhlIElFVEYgU2VjcmV0YXJpYXQNCg0K


From nobody Mon Jul 24 14:52:44 2017
Return-Path: 
X-Original-To: avt@ietfa.amsl.com
Delivered-To: avt@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26A34129B5E; Mon, 24 Jul 2017 14:52:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.871
X-Spam-Level: 
X-Spam-Status: No, score=-1.871 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, T_FILL_THIS_FORM_SHORT=0.01, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o9DXaB2xoCAI; Mon, 24 Jul 2017 14:52:40 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EDB691204DA; Mon, 24 Jul 2017 14:52:39 -0700 (PDT)
Received: from [10.0.1.63] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v6OLqUDV033023 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 24 Jul 2017 16:52:31 -0500 (CDT) (envelope-from ben@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.63]
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
From: Ben Campbell 
In-Reply-To: <6E58094ECC8D8344914996DAD28F1CCD7EE876@DGGEMM506-MBX.china.huawei.com>
Date: Mon, 24 Jul 2017 16:52:29 -0500
Cc: "avt@ietf.org" , Magnus Westerlund , The IESG 
Content-Transfer-Encoding: quoted-printable
Message-Id: <4868C682-0915-4AD0-868A-AB3E14E999DA@nostrum.com>
References: <150079096276.31280.12592363692999578408.idtracker@ietfa.amsl.com> <6E58094ECC8D8344914996DAD28F1CCD7EE876@DGGEMM506-MBX.china.huawei.com>
To: Roni Even 
X-Mailer: Apple Mail (2.3273)
Archived-At: 
Subject: Re: [AVTCORE] New Version Notification for draft-ietf-avtcore-rfc5285-bis-13.txt
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Audio/Video Transport Core Maintenance 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 24 Jul 2017 21:52:42 -0000

Hi Roni,

I agree this covers the IESG comments. However, I am confused about some =
of the new text in section 7 about an answerer marking an extension as =
=E2=80=9Cinactive=E2=80=9D. I assume these are here in response to =
Alexey=E2=80=99s questions about why the SHOULDs are only SHOULDs.

In the first instance:

   "If an extension is marked as "sendonly" and the answerer desires to
   receive it, the extension MUST be marked as "recvonly" in the SDP
   answer.  An answerer that has no desire to receive the extension or
   does not understand the extension SHOULD remove it from the SDP
   answer.  An answerer MAY want to respond that he supports the
   extension and may use it in the future will mark the extension as
   =E2=80=9Cinactive=E2=80=9D=E2=80=9D

What does =E2=80=9Cwilling to use it in the future=E2=80=9D mean that is =
different than just being willing to receive it, which is already =
covered by marking it as =E2=80=9Crecvonly=E2=80=9D? Do we contemplate =
that the offerer may at some point in the future send an updated offer =
or answer that changes this to =E2=80=9Crecvonly=E2=80=9D?

Similarly in the second instance:

  If an extension is marked as "recvonly" and the answerer desires to
   send it, the extension MUST be marked as "sendonly" in the SDP
   answer.  An answerer that has no desire to, or is unable to, send the
   extension SHOULD remove it from the SDP answer.  An answerer MAY want
   to respond that he support this extension and may send in the future
   or will be able to receive by marking the extension as "inactive"

=E2=80=A6 is the answer expected to mark the extension as =E2=80=9Csendonl=
y=E2=80=9D at some point in the future?


 =20
If it turns out that the added text is roughly correct, the text is =
still confusing from a pure sentence structure perspective. I would =
suggest text, but we probably need to resolve the above questions first.

Thanks!

Ben.


> On Jul 23, 2017, at 1:26 AM, Roni Even  wrote:
>=20
> Hi,
> I submitted a version that I hope addresses all the comments from the =
IESG review.
> The major open issue was the category of allowed-mix in bundle and =
based on the WG preference it is now Identical.
>=20
> Thanks
> Roni Even
>=20
> -----Original Message-----
> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]=20
> Sent: =D7=99=D7=95=D7=9D =D7=90 23 =D7=99=D7=95=D7=9C=D7=99 2017 09:23
> To: Harikishan Desineni; HariKishan Desineni; Roni Even; =
avtcore-chairs@ietf.org; David Singer; Roni Even
> Subject: New Version Notification for =
draft-ietf-avtcore-rfc5285-bis-13.txt
>=20
>=20
> A new version of I-D, draft-ietf-avtcore-rfc5285-bis-13.txt
> has been successfully submitted by Roni Even and posted to the IETF =
repository.
>=20
> Name:		draft-ietf-avtcore-rfc5285-bis
> Revision:	13
> Title:		A General Mechanism for RTP Header Extensions
> Document date:	2017-07-22
> Group:		avtcore
> Pages:		24
> URL:            =
https://www.ietf.org/internet-drafts/draft-ietf-avtcore-rfc5285-bis-13.txt=

> Status:         =
https://datatracker.ietf.org/doc/draft-ietf-avtcore-rfc5285-bis/
> Htmlized:       =
https://tools.ietf.org/html/draft-ietf-avtcore-rfc5285-bis-13
> Htmlized:       =
https://datatracker.ietf.org/doc/html/draft-ietf-avtcore-rfc5285-bis-13
> Diff:           =
https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-avtcore-rfc5285-bis-13
>=20
> Abstract:
>   This document provides a general mechanism to use the header
>   extension feature of RTP (the Real-Time Transport Protocol).  It
>   provides the option to use a small number of small extensions in =
each
>   RTP packet, where the universe of possible extensions is large and
>   registration is de-centralized.  The actual extensions in use in a
>   session are signaled in the setup information for that session.  =
This
>   document obsoletes RFC5285.
>=20
>=20
>=20
>=20
> 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.
>=20
> The IETF Secretariat
>=20


From nobody Mon Jul 24 15:13:39 2017
Return-Path: 
X-Original-To: avt@ietfa.amsl.com
Delivered-To: avt@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E33B91267BB; Mon, 24 Jul 2017 15:13:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.881
X-Spam-Level: 
X-Spam-Status: No, score=-1.881 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=unavailable autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mxTd6qstMF2R; Mon, 24 Jul 2017 15:13:29 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1EEFC127180; Mon, 24 Jul 2017 15:13:26 -0700 (PDT)
Received: from [10.0.1.63] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v6OMCPJw036394 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 24 Jul 2017 17:13:17 -0500 (CDT) (envelope-from ben@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.63]
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
From: Ben Campbell 
In-Reply-To: 
Date: Mon, 24 Jul 2017 17:13:17 -0500
Cc: Roni Even , "avtcore-chairs@ietf.org" , "magnus.westerlund@ericsson.com" , The IESG , "avt@ietf.org" , "draft-ietf-avtcore-rfc5285-bis@ietf.org" 
Content-Transfer-Encoding: quoted-printable
Message-Id: <69F7C4DE-AE22-411F-BCC6-A4F32E90BBF8@nostrum.com>
References: <149791884335.23828.13769788810069405479.idtracker@ietfa.amsl.com> <6E58094ECC8D8344914996DAD28F1CCD7DBAE6@DGGEMM506-MBX.china.huawei.com>  <6E58094ECC8D8344914996DAD28F1CCD7DBC1F@DGGEMM506-MBX.china.huawei.com> 
To: Eric Rescorla 
X-Mailer: Apple Mail (2.3273)
Archived-At: 
Subject: Re: [AVTCORE] Eric Rescorla's Discuss on draft-ietf-avtcore-rfc5285-bis-12: (with DISCUSS and COMMENT)
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Audio/Video Transport Core Maintenance 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 24 Jul 2017 22:13:31 -0000

To close the loop on this: AVTCORE discussed this issue in Prague, with =
a consensus to change the mux-category to =E2=80=9Cidentical=E2=80=9D.

Ben.

> On Jun 22, 2017, at 8:20 AM, Eric Rescorla  wrote:
>=20
>=20
>=20
> On Thu, Jun 22, 2017 at 6:15 AM, Roni Even  =
wrote:
> Want to use only one byte header extensions for the audio for routing =
audio on low bandwidth link.
>=20
>=20
> But mixed mode allows this.
>=20
> =20
> Anyhow many of the RTP header extensions will be different between the =
audio and video
>=20
>=20
> I don't see how this is relevant.
>=20
> -Ekr
> =20
>=20
> Roni
>=20
> =20
>=20
> From: Eric Rescorla [mailto:ekr@rtfm.com]=20
> Sent: =D7=99=D7=95=D7=9D =D7=94 22 =D7=99=D7=95=D7=A0=D7=99 2017 15:54
> To: Roni Even
> Cc: The IESG; avtcore-chairs@ietf.org; magnus.westerlund@ericsson.com; =
draft-ietf-avtcore-rfc5285-bis@ietf.org; avt@ietf.org
> Subject: Re: Eric Rescorla's Discuss on =
draft-ietf-avtcore-rfc5285-bis-12: (with DISCUSS and COMMENT)
>=20
> =20
>=20
> Yes, I understand that, but why would you not want to mix? I assume =
merely because your implementation can't handle it, right? Is there some =
other reason?
>=20
> =20
>=20
> -Ekr
>=20
> =20
>=20
> =20
>=20
> On Thu, Jun 22, 2017 at 4:32 AM, Roni Even  =
wrote:
>=20
> inline
>=20
> > -----Original Message-----
> > From: Eric Rescorla [mailto:ekr@rtfm.com]
> > Sent: =D7=99=D7=95=D7=9D =D7=92 20 =D7=99=D7=95=D7=A0=D7=99 2017 =
03:34
> > To: The IESG
> > Cc: draft-ietf-avtcore-rfc5285-bis@ietf.org; Magnus Westerlund; =
avtcore-
> > chairs@ietf.org; magnus.westerlund@ericsson.com; avt@ietf.org
> > Subject: Eric Rescorla's Discuss on =
draft-ietf-avtcore-rfc5285-bis-12: (with
> > DISCUSS and COMMENT)
> >
> > Eric Rescorla has entered the following ballot position for
> > draft-ietf-avtcore-rfc5285-bis-12: Discuss
> >
> > When responding, please keep the subject line intact and reply to =
all email
> > addresses included in the To and CC lines. (Feel free to cut this =
introductory
> > paragraph, however.)
> >
> >
> > Please refer to =
https://www.ietf.org/iesg/statement/discuss-criteria.html
> > for more information about IESG DISCUSS and COMMENT positions.
> >
> >
> > The document, along with other ballot positions, can be found here:
> > https://datatracker.ietf.org/doc/draft-ietf-avtcore-rfc5285-bis/
> >
> >
> >
> > =
----------------------------------------------------------------------
> > DISCUSS:
> > =
----------------------------------------------------------------------
> >
> > Why are you allowing this extension to be "normal" in BUNDLE?
> > If you're bundling, you should be modern enough to handle mixed, no? =
Why
> > not make life simple?
> >
> >
> [Roni Even] It is not a question about handing mixing if you bundle =
but if there is a use case where you do not want to mix for one of the =
m-lines. This is the discussion since even if you use normal you can =
still do identical (for example by having the allow mixing at the =
session level) but not the opposite.
>=20
>=20
> =20
>=20
>=20
> _______________________________________________
> Audio/Video Transport Core Maintenance
> avt@ietf.org
> https://www.ietf.org/mailman/listinfo/avt


From nobody Tue Jul 25 13:40:23 2017
Return-Path: 
X-Original-To: avt@ietfa.amsl.com
Delivered-To: avt@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5747D131EF1 for ; Tue, 25 Jul 2017 13:40:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.101
X-Spam-Level: 
X-Spam-Status: No, score=-1.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_WEB=1.5, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id joQe7sJTAhGv for ; Tue, 25 Jul 2017 13:40:21 -0700 (PDT)
Received: from mx0b-00198e01.pphosted.com (mx0b-00198e01.pphosted.com [67.231.157.197]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 17D9A131EE7 for ; Tue, 25 Jul 2017 13:40:20 -0700 (PDT)
Received: from pps.filterd (m0073110.ppops.net [127.0.0.1]) by mx0b-00198e01.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id v6PKcZ0P001341 for ; Tue, 25 Jul 2017 16:40:18 -0400
Received: from mail.vidyo.com (mail2.vidyo.com [162.209.16.214]) by mx0b-00198e01.pphosted.com with ESMTP id 2bv1f4hwyk-1 (version=TLSv1 cipher=AES128-SHA bits=128 verify=NOT) for ; Tue, 25 Jul 2017 16:40:17 -0400
Received: from 492132-EXCH1.vidyo.com ([fe80::50:56ff:fe85:4f77]) by 492133-EXCH2.vidyo.com ([fe80::50:56ff:fe85:6b62%13]) with mapi id 14.03.0195.001; Tue, 25 Jul 2017 15:40:17 -0500
From: Jonathan Lennox 
To: IETF AVTCore WG 
Thread-Topic: Confirmation of Consensus: Adoption of Congestion Control Feedback Message
Thread-Index: AQHTBYY5DIwSscAW4UGI4qMKGwK2yQ==
Date: Tue, 25 Jul 2017 20:40:17 +0000
Message-ID: <1157B98E-6F05-40B0-A287-94CBC1E2035C@vidyo.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [160.79.219.114]
Content-Type: text/plain; charset="utf-8"
Content-ID: <6C80033C5937104C915CEB7A847AE02B@vidyo.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-25_09:, , signatures=0
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1706020000 definitions=main-1707250320
Archived-At: 
Subject: [AVTCORE] Confirmation of Consensus: Adoption of Congestion Control Feedback Message
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Audio/Video Transport Core Maintenance 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 25 Jul 2017 20:40:22 -0000

SGksIGFsbCDigJQNCg0KQXQgdGhlIEFWVENPUkUgbWVldGluZyBpbiBQcmFndWUsIHdlIGhhZCBj
b25zZW5zdXMgaW4gdGhlIHJvb20gdG8gdGFrZSBvbiBhIENvbmdlc3Rpb24gQ29udHJvbCBGZWVk
YmFjayBNZXNzYWdlIGFzIGFuIEFWVENPUkUgd29ya2luZyBncm91cCBpdGVtLCBhbmQgYWRvcHQg
ZHJhZnQtZHQtcm1jYXQtZmVlZGJhY2stbWVzc2FnZSBhcyB0aGUgYmFzaXMgZm9yIHRoZSB3b3Jr
aW5nIGdyb3VwIGRvY3VtZW50Lg0KDQpJZiB5b3Ugd2VyZSBub3QgYXQgdGhlIG1lZXRpbmcgKG9y
IGlmIHlvdSBoYXZlIGNoYW5nZWQgeW91ciBtaW5kIHNpbmNlIHRoZSBtZWV0aW5nKSBhbmQgaGF2
ZSBvcGluaW9ucyBvbiB0aGlzIHRvcGljLCBwbGVhc2UgbGV0IHRoZSB3b3JraW5nIGdyb3VwIGtu
b3cgaW4gdGhlIG5leHQgd2VlayAoYnkgQXVndXN0IDFzdCkuDQoNClRoYW5rIHlvdSENCg0KSm9u
YXRoYW4gTGVubm94DQpBVlRDT1JFIGNvLWNoYWlyDQoNCg==


From nobody Tue Jul 25 13:51:10 2017
Return-Path: 
X-Original-To: avt@ietfa.amsl.com
Delivered-To: avt@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BCE0131EF8 for ; Tue, 25 Jul 2017 13:51:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.698
X-Spam-Level: 
X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UriHj8PiWBOo for ; Tue, 25 Jul 2017 13:51:06 -0700 (PDT)
Received: from mail-vk0-x230.google.com (mail-vk0-x230.google.com [IPv6:2607:f8b0:400c:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB325131EEE for ; Tue, 25 Jul 2017 13:51:06 -0700 (PDT)
Received: by mail-vk0-x230.google.com with SMTP id n125so11453638vke.1 for ; Tue, 25 Jul 2017 13:51:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=KNo8OiBDajnLzHYFcUpUctFy5JU1T7tIg11+cOlqVmM=; b=ZeKG/bYVr1B3jgwbpQlHCBwUNs1GAtELUFxdDoudqtHrsKvlg/RMqPTlh52CD/bGII EjVw1rjZQMKUaoKOD1GIrPdu+wcuEbmK4qA7bwS47ZBFD6GmltQRBbWwnBJFYKCMbH6h zDlUXPgEli3mrgxV5wt4APH4fzLoZt/j9qVPJZ+8njF9kiLL27Y9SyDrUpLYj3LxVdQD yS26yiTg7XLKvxwVTahPGYgNzHQYF7Smw+cWFthQU+ZkMUgBjkRZHyBLFt8P+NVGJQu1 L0yjLeJkoTqiXOpWElcau9GH9qmVyHQ6O7wBaa+ErE3sQCtMR6KVRW4UAeW6zcF64oDi dtbQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=KNo8OiBDajnLzHYFcUpUctFy5JU1T7tIg11+cOlqVmM=; b=bm0lv35arUqWQDv7XyvIByXGUF6KbH1gyiMhcUlJBrE8KAckRyodJpeflxVe6bZ8EO qiTD69UEzJn68uxJ6MWTFxOZU5zDThc0VCsB8xbyPvlV5pvUwKIs1AShhDOxHURC7Amm MbFk7+tJF0IKnUEUiOf3u7cvQJkbqYInQRu/zqWyYhrTcOtS+dp/zImefpzi5SR+Wot5 hgJc7CGE/162/nTVetSYfy9yEWRg0juvm7T+Wf+U0IejhTvor7aZzkCtWHVr6+TOg6pJ dUHKZ5cGWnsfYRdBKVHKhmy56bC+jkNtvWt+4sAC3tR9opOTSY2ETdtGD2naKXFQ/YvB kywg==
X-Gm-Message-State: AIVw112Q5wOnihuxEpjuoiHbLaf7dAlpK57N3J/MCf1Uv5C5yYQ57KEr a3mgRu6zMtO71bBchTHXZpLThucaWA==
X-Received: by 10.31.77.67 with SMTP id a64mr12114845vkb.186.1501015865550; Tue, 25 Jul 2017 13:51:05 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.159.36.111 with HTTP; Tue, 25 Jul 2017 13:50:45 -0700 (PDT)
In-Reply-To: <1157B98E-6F05-40B0-A287-94CBC1E2035C@vidyo.com>
References: <1157B98E-6F05-40B0-A287-94CBC1E2035C@vidyo.com>
From: Bernard Aboba 
Date: Tue, 25 Jul 2017 13:50:45 -0700
Message-ID: 
To: Jonathan Lennox 
Cc: IETF AVTCore WG 
Content-Type: multipart/alternative; boundary="001a114edc2877ecf005552a7dce"
Archived-At: 
Subject: Re: [AVTCORE] Confirmation of Consensus: Adoption of Congestion Control Feedback Message
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Audio/Video Transport Core Maintenance 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 25 Jul 2017 20:51:09 -0000

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

I believe that the consensus of the meeting was to utilize feedback message
205.  This change would increase efficiency as well as to improve the
chances that the draft will be implemented and deployed.  With those
changes, I support adoption.

I do have some concerns about potential deployment, though. The proposal
was found to be only marginally more efficient than the feedback message
defined in
https://tools.ietf.org/html/draft-holmer-rmcat-transport-wide-cc-extensions
which is available in open source and is in widespread usage.  In one of
his first acts as Apple CEO, Steve Jobs killed a number of projects that
were "different but not better".  This makes me wonder whether the IETF
would not benefit from that level of realism.

On Tue, Jul 25, 2017 at 1:40 PM, Jonathan Lennox  wrote=
:

> Hi, all =E2=80=94
>
> At the AVTCORE meeting in Prague, we had consensus in the room to take on
> a Congestion Control Feedback Message as an AVTCORE working group item, a=
nd
> adopt draft-dt-rmcat-feedback-message as the basis for the working group
> document.
>
> If you were not at the meeting (or if you have changed your mind since th=
e
> meeting) and have opinions on this topic, please let the working group kn=
ow
> in the next week (by August 1st).
>
> Thank you!
>
> Jonathan Lennox
> AVTCORE co-chair
>
> _______________________________________________
> Audio/Video Transport Core Maintenance
> avt@ietf.org
> https://www.ietf.org/mailman/listinfo/avt
>

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


I believe that the consensus of the meeting was to ut=
ilize feedback message 205.=C2=A0 This change would increase efficiency as =
well as to improve the chances that the draft will be implemented and deplo=
yed.=C2=A0 With those changes, I support adoption.

I do have some concerns about potential deployment, though. The proposal w=
as found to be only marginally more efficient than the feedback message def=
ined in=C2=A0https://tools.ietf.org/html/draft-holmer-rmcat-tr=
ansport-wide-cc-extensions which is available in open source and is in =
widespread usage.=C2=A0 In one of his first acts as Apple CEO, Steve Jobs k=
illed a number of projects that were "different but not better".=
=C2=A0 This makes me wonder whether the IETF would not benefit from that le=
vel of realism.=C2=A0

On Tue, Jul 25, 2017 at 1:40 PM, Jonathan Lennox <jonath=
an@vidyo.com> wrote:
Hi, al=
l =E2=80=94



At the AVTCORE meeting in Prague, we had consensus in the room to take on a=
 Congestion Control Feedback Message as an AVTCORE working group item, and =
adopt draft-dt-rmcat-feedback-message as the basis for the working gro=
up document.



If you were not at the meeting (or if you have changed your mind since the =
meeting) and have opinions on this topic, please let the working group know=
 in the next week (by August 1st).



Thank you!



Jonathan Lennox

AVTCORE co-chair



_______________________________________________

Audio/Video Transport Core Maintenance

avt@ietf.org

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





--001a114edc2877ecf005552a7dce--


From nobody Tue Jul 25 14:43:51 2017
Return-Path: 
X-Original-To: avt@ietfa.amsl.com
Delivered-To: avt@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DFBB131F1E for ; Tue, 25 Jul 2017 14:43:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level: 
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id arjfN9ZZuBiF for ; Tue, 25 Jul 2017 14:43:47 -0700 (PDT)
Received: from haggis.mythic-beasts.com (haggis.mythic-beasts.com [IPv6:2a00:1098:0:86:1000:0:2: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 E8D821252BA for ; Tue, 25 Jul 2017 14:43:46 -0700 (PDT)
Received: from [81.187.2.149] (port=43292 helo=[192.168.0.71]) by haggis.mythic-beasts.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89) (envelope-from ) id 1da7cB-0001A1-UM; Tue, 25 Jul 2017 22:43:45 +0100
From: Colin Perkins 
Message-Id: <3C2E8387-ACC6-49B9-88DB-76F008A9AD02@csperkins.org>
Content-Type: multipart/alternative; boundary="Apple-Mail=_ED13883C-31C8-4A47-8800-718E1C091A1A"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Date: Tue, 25 Jul 2017 22:43:35 +0100
In-Reply-To: 
Cc: Jonathan Lennox , IETF AVTCore WG 
To: Bernard Aboba 
References: <1157B98E-6F05-40B0-A287-94CBC1E2035C@vidyo.com> 
X-Mailer: Apple Mail (2.3273)
X-BlackCat-Spam-Score: 14
Archived-At: 
Subject: Re: [AVTCORE] Confirmation of Consensus: Adoption of Congestion Control Feedback Message
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Audio/Video Transport Core Maintenance 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 25 Jul 2017 21:43:49 -0000

--Apple-Mail=_ED13883C-31C8-4A47-8800-718E1C091A1A
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

> On 25 Jul 2017, at 21:50, Bernard Aboba  =
wrote:
>=20
> I believe that the consensus of the meeting was to utilize feedback =
message 205.  This change would increase efficiency as well as to =
improve the chances that the draft will be implemented and deployed.  =
With those changes, I support adoption.

The plan is that authors will submit a -04 individual draft making that =
change, and will confirm with the AVTCORE chairs to adopt that version/

> I do have some concerns about potential deployment, though. The =
proposal was found to be only marginally more efficient than the =
feedback message defined in =
https://tools.ietf.org/html/draft-holmer-rmcat-transport-wide-cc-extension=
s =
 which is available in open source and is in widespread usage.  In =
one of his first acts as Apple CEO, Steve Jobs killed a number of =
projects that were "different but not better".  This makes me wonder =
whether the IETF would not benefit from that level of realism.=20

As an individual, I find the approach taken in the =
transport-wide-cc-extensions a very poor fit with RTP. It also doesn=E2=80=
=99t convey ECN feedback information, which is needed by several of the =
candidate congestion control algorithms being proposed in RMCAT.=20

Colin




> On Tue, Jul 25, 2017 at 1:40 PM, Jonathan Lennox > wrote:
> Hi, all =E2=80=94
>=20
> At the AVTCORE meeting in Prague, we had consensus in the room to take =
on a Congestion Control Feedback Message as an AVTCORE working group =
item, and adopt draft-dt-rmcat-feedback-message as the basis for the =
working group document.
>=20
> If you were not at the meeting (or if you have changed your mind since =
the meeting) and have opinions on this topic, please let the working =
group know in the next week (by August 1st).
>=20
> Thank you!
>=20
> Jonathan Lennox
> AVTCORE co-chair
>=20
> _______________________________________________
> Audio/Video Transport Core Maintenance
> avt@ietf.org 
> https://www.ietf.org/mailman/listinfo/avt =

>=20
> _______________________________________________
> Audio/Video Transport Core Maintenance
> avt@ietf.org
> https://www.ietf.org/mailman/listinfo/avt



--=20
Colin Perkins
https://csperkins.org/





--Apple-Mail=_ED13883C-31C8-4A47-8800-718E1C091A1A
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8


On =
25 Jul 2017, at 21:50, Bernard Aboba <bernard.aboba@gmail.com> wrote:

I believe that the consensus of the meeting =
was to utilize feedback message 205.  This change would increase =
efficiency as well as to improve the chances that the draft will be =
implemented and deployed.  With those changes, I support =
adoption.

The=
 plan is that authors will submit a -04 individual draft making that =
change, and will confirm with the AVTCORE chairs to adopt that =
version/

I do have some =
concerns about potential deployment, though. The proposal was found to =
be only marginally more efficient than the feedback message defined =
in https://tools.ietf.org/html/draft-holmer-rmcat-transport-wide-c=
c-extensions which is available in open source and is in widespread =
usage.  In one of his first acts as Apple CEO, Steve Jobs killed a =
number of projects that were "different but not better".  This =
makes me wonder whether the IETF would not benefit from that level of =
realism. 

As an individual, I find the approach taken in the =
transport-wide-cc-extensions a very poor fit with RTP. It also doesn=E2=80=
=99t convey ECN feedback information, which is needed by several of the =
candidate congestion control algorithms being proposed in =
RMCAT. 

Colin




On Tue, Jul 25, 2017 at =
1:40 PM, Jonathan Lennox <jonathan@vidyo.com> wrote:
Hi, all =E2=80=94



At the AVTCORE meeting in Prague, we had consensus in the room to take =
on a Congestion Control Feedback Message as an AVTCORE working group =
item, and adopt draft-dt-rmcat-feedback-message as the =
basis for the working group document.



If you were not at the meeting (or if you have changed your mind since =
the meeting) and have opinions on this topic, please let the working =
group know in the next week (by August 1st).



Thank you!



Jonathan Lennox

AVTCORE co-chair



_______________________________________________

Audio/Video Transport Core Maintenance

avt@ietf.org
=

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




_______________________________________________
Audio/Video =
Transport Core Maintenance
avt@ietf.org
https://www.ietf.org/mailman/listinfo/avt




-- 
Colin Perkins
https://csperkins.org/








=

--Apple-Mail=_ED13883C-31C8-4A47-8800-718E1C091A1A--


From nobody Tue Jul 25 22:04:01 2017
Return-Path: 
X-Original-To: avt@ietfa.amsl.com
Delivered-To: avt@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A80FC1243F3; Tue, 25 Jul 2017 22:03:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.222
X-Spam-Level: 
X-Spam-Status: No, score=-4.222 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AZEsXW7dUbEU; Tue, 25 Jul 2017 22:03:57 -0700 (PDT)
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 83FB3131F07; Tue, 25 Jul 2017 22:03:56 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml703-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DLH75858; Wed, 26 Jul 2017 05:03:54 +0000 (GMT)
Received: from DGGEMM404-HUB.china.huawei.com (10.3.20.212) by lhreml703-cah.china.huawei.com (10.201.108.44) with Microsoft SMTP Server (TLS) id 14.3.301.0; Wed, 26 Jul 2017 06:03:53 +0100
Received: from DGGEMM506-MBX.china.huawei.com ([169.254.3.170]) by DGGEMM404-HUB.china.huawei.com ([10.3.20.212]) with mapi id 14.03.0301.000; Wed, 26 Jul 2017 13:03:48 +0800
From: Roni Even 
To: Ben Campbell 
CC: "avt@ietf.org" , Magnus Westerlund , The IESG 
Thread-Topic: New Version Notification for draft-ietf-avtcore-rfc5285-bis-13.txt
Thread-Index: AQHTBMcsg1Dvytnmv0CQB+rqRL/Q/qJljRUw
Date: Wed, 26 Jul 2017 05:03:48 +0000
Message-ID: <6E58094ECC8D8344914996DAD28F1CCD7EED0F@DGGEMM506-MBX.china.huawei.com>
References: <150079096276.31280.12592363692999578408.idtracker@ietfa.amsl.com> <6E58094ECC8D8344914996DAD28F1CCD7EE876@DGGEMM506-MBX.china.huawei.com> <4868C682-0915-4AD0-868A-AB3E14E999DA@nostrum.com>
In-Reply-To: <4868C682-0915-4AD0-868A-AB3E14E999DA@nostrum.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.200.202.51]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090201.597822BA.0085, ss=1, re=0.000, recu=0.000, reip=0.000,  cl=1, cld=1, fgs=0, ip=169.254.3.170, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: 0739a7d6dd42f71a758f7b587312c91d
Archived-At: 
Subject: Re: [AVTCORE] New Version Notification for draft-ietf-avtcore-rfc5285-bis-13.txt
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Audio/Video Transport Core Maintenance 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 26 Jul 2017 05:03:59 -0000

SEkgQmVuLA0KSW5hY3RpdmUgbWVhbnMgSSBzdXBwb3J0IHRoZSBleHRlbnNpb24gYnV0IHdvdWxk
IG5vdCBsaWtlIHRvIHNlbmQgb3IgcmVjZWl2ZSBhdCB0aGUgbW9tZW50LiBNYXkgZG8gaXQgaW4g
YSBmdXR1cmUgb2ZmZXIvYW5zd2VyLiBUaGlzIGlzIHdoZW4gdGhlIGFuc3dlcmVyIHVuZGVyc3Rh
bmRzIHRoZSBvZmZlcmVkIGV4dGVuc2lvbi4NClJvbmkNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3Nh
Z2UtLS0tLQ0KPiBGcm9tOiBCZW4gQ2FtcGJlbGwgW21haWx0bzpiZW5Abm9zdHJ1bS5jb21dDQo+
IFNlbnQ6INeZ15XXncKg15IgMjUg15nXldec15kgMjAxNyAwMDo1Mg0KPiBUbzogUm9uaSBFdmVu
DQo+IENjOiBhdnRAaWV0Zi5vcmc7IE1hZ251cyBXZXN0ZXJsdW5kOyBUaGUgSUVTRw0KPiBTdWJq
ZWN0OiBSZTogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1pZXRmLWF2dGNvcmUt
cmZjNTI4NS1iaXMtDQo+IDEzLnR4dA0KPiANCj4gSGkgUm9uaSwNCj4gDQo+IEkgYWdyZWUgdGhp
cyBjb3ZlcnMgdGhlIElFU0cgY29tbWVudHMuIEhvd2V2ZXIsIEkgYW0gY29uZnVzZWQgYWJvdXQg
c29tZQ0KPiBvZiB0aGUgbmV3IHRleHQgaW4gc2VjdGlvbiA3IGFib3V0IGFuIGFuc3dlcmVyIG1h
cmtpbmcgYW4gZXh0ZW5zaW9uIGFzDQo+IOKAnGluYWN0aXZl4oCdLiBJIGFzc3VtZSB0aGVzZSBh
cmUgaGVyZSBpbiByZXNwb25zZSB0byBBbGV4ZXnigJlzIHF1ZXN0aW9ucyBhYm91dA0KPiB3aHkg
dGhlIFNIT1VMRHMgYXJlIG9ubHkgU0hPVUxEcy4NCj4gDQo+IEluIHRoZSBmaXJzdCBpbnN0YW5j
ZToNCj4gDQo+ICAgICJJZiBhbiBleHRlbnNpb24gaXMgbWFya2VkIGFzICJzZW5kb25seSIgYW5k
IHRoZSBhbnN3ZXJlciBkZXNpcmVzIHRvDQo+ICAgIHJlY2VpdmUgaXQsIHRoZSBleHRlbnNpb24g
TVVTVCBiZSBtYXJrZWQgYXMgInJlY3Zvbmx5IiBpbiB0aGUgU0RQDQo+ICAgIGFuc3dlci4gIEFu
IGFuc3dlcmVyIHRoYXQgaGFzIG5vIGRlc2lyZSB0byByZWNlaXZlIHRoZSBleHRlbnNpb24gb3IN
Cj4gICAgZG9lcyBub3QgdW5kZXJzdGFuZCB0aGUgZXh0ZW5zaW9uIFNIT1VMRCByZW1vdmUgaXQg
ZnJvbSB0aGUgU0RQDQo+ICAgIGFuc3dlci4gIEFuIGFuc3dlcmVyIE1BWSB3YW50IHRvIHJlc3Bv
bmQgdGhhdCBoZSBzdXBwb3J0cyB0aGUNCj4gICAgZXh0ZW5zaW9uIGFuZCBtYXkgdXNlIGl0IGlu
IHRoZSBmdXR1cmUgd2lsbCBtYXJrIHRoZSBleHRlbnNpb24gYXMNCj4gICAg4oCcaW5hY3RpdmXi
gJ3igJ0NCj4gDQo+IFdoYXQgZG9lcyDigJx3aWxsaW5nIHRvIHVzZSBpdCBpbiB0aGUgZnV0dXJl
4oCdIG1lYW4gdGhhdCBpcyBkaWZmZXJlbnQgdGhhbiBqdXN0DQo+IGJlaW5nIHdpbGxpbmcgdG8g
cmVjZWl2ZSBpdCwgd2hpY2ggaXMgYWxyZWFkeSBjb3ZlcmVkIGJ5IG1hcmtpbmcgaXQgYXMNCj4g
4oCccmVjdm9ubHnigJ0/IERvIHdlIGNvbnRlbXBsYXRlIHRoYXQgdGhlIG9mZmVyZXIgbWF5IGF0
IHNvbWUgcG9pbnQgaW4gdGhlDQo+IGZ1dHVyZSBzZW5kIGFuIHVwZGF0ZWQgb2ZmZXIgb3IgYW5z
d2VyIHRoYXQgY2hhbmdlcyB0aGlzIHRvIOKAnHJlY3Zvbmx54oCdPw0KPiANCj4gU2ltaWxhcmx5
IGluIHRoZSBzZWNvbmQgaW5zdGFuY2U6DQo+IA0KPiAgIElmIGFuIGV4dGVuc2lvbiBpcyBtYXJr
ZWQgYXMgInJlY3Zvbmx5IiBhbmQgdGhlIGFuc3dlcmVyIGRlc2lyZXMgdG8NCj4gICAgc2VuZCBp
dCwgdGhlIGV4dGVuc2lvbiBNVVNUIGJlIG1hcmtlZCBhcyAic2VuZG9ubHkiIGluIHRoZSBTRFAN
Cj4gICAgYW5zd2VyLiAgQW4gYW5zd2VyZXIgdGhhdCBoYXMgbm8gZGVzaXJlIHRvLCBvciBpcyB1
bmFibGUgdG8sIHNlbmQgdGhlDQo+ICAgIGV4dGVuc2lvbiBTSE9VTEQgcmVtb3ZlIGl0IGZyb20g
dGhlIFNEUCBhbnN3ZXIuICBBbiBhbnN3ZXJlciBNQVkNCj4gd2FudA0KPiAgICB0byByZXNwb25k
IHRoYXQgaGUgc3VwcG9ydCB0aGlzIGV4dGVuc2lvbiBhbmQgbWF5IHNlbmQgaW4gdGhlIGZ1dHVy
ZQ0KPiAgICBvciB3aWxsIGJlIGFibGUgdG8gcmVjZWl2ZSBieSBtYXJraW5nIHRoZSBleHRlbnNp
b24gYXMgImluYWN0aXZlIg0KPiANCj4g4oCmIGlzIHRoZSBhbnN3ZXIgZXhwZWN0ZWQgdG8gbWFy
ayB0aGUgZXh0ZW5zaW9uIGFzIOKAnHNlbmRvbmx54oCdIGF0IHNvbWUgcG9pbnQNCj4gaW4gdGhl
IGZ1dHVyZT8NCj4gDQo+IA0KPiANCj4gSWYgaXQgdHVybnMgb3V0IHRoYXQgdGhlIGFkZGVkIHRl
eHQgaXMgcm91Z2hseSBjb3JyZWN0LCB0aGUgdGV4dCBpcyBzdGlsbCBjb25mdXNpbmcNCj4gZnJv
bSBhIHB1cmUgc2VudGVuY2Ugc3RydWN0dXJlIHBlcnNwZWN0aXZlLiBJIHdvdWxkIHN1Z2dlc3Qg
dGV4dCwgYnV0IHdlDQo+IHByb2JhYmx5IG5lZWQgdG8gcmVzb2x2ZSB0aGUgYWJvdmUgcXVlc3Rp
b25zIGZpcnN0Lg0KPiANCj4gVGhhbmtzIQ0KPiANCj4gQmVuLg0KPiANCj4gDQo+ID4gT24gSnVs
IDIzLCAyMDE3LCBhdCAxOjI2IEFNLCBSb25pIEV2ZW4gPHJvbmkuZXZlbkBodWF3ZWkuY29tPiB3
cm90ZToNCj4gPg0KPiA+IEhpLA0KPiA+IEkgc3VibWl0dGVkIGEgdmVyc2lvbiB0aGF0IEkgaG9w
ZSBhZGRyZXNzZXMgYWxsIHRoZSBjb21tZW50cyBmcm9tIHRoZSBJRVNHDQo+IHJldmlldy4NCj4g
PiBUaGUgbWFqb3Igb3BlbiBpc3N1ZSB3YXMgdGhlIGNhdGVnb3J5IG9mIGFsbG93ZWQtbWl4IGlu
IGJ1bmRsZSBhbmQgYmFzZWQNCj4gb24gdGhlIFdHIHByZWZlcmVuY2UgaXQgaXMgbm93IElkZW50
aWNhbC4NCj4gPg0KPiA+IFRoYW5rcw0KPiA+IFJvbmkgRXZlbg0KPiA+DQo+ID4gLS0tLS1Pcmln
aW5hbCBNZXNzYWdlLS0tLS0NCj4gPiBGcm9tOiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcgW21h
aWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmddDQo+ID4gU2VudDog15nXldedINeQIDIzINeZ
15XXnNeZIDIwMTcgMDk6MjMNCj4gPiBUbzogSGFyaWtpc2hhbiBEZXNpbmVuaTsgSGFyaUtpc2hh
biBEZXNpbmVuaTsgUm9uaSBFdmVuOyBhdnRjb3JlLQ0KPiBjaGFpcnNAaWV0Zi5vcmc7IERhdmlk
IFNpbmdlcjsgUm9uaSBFdmVuDQo+ID4gU3ViamVjdDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9u
IGZvciBkcmFmdC1pZXRmLWF2dGNvcmUtcmZjNTI4NS1iaXMtMTMudHh0DQo+ID4NCj4gPg0KPiA+
IEEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1pZXRmLWF2dGNvcmUtcmZjNTI4NS1iaXMtMTMu
dHh0DQo+ID4gaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBSb25pIEV2ZW4gYW5k
IHBvc3RlZCB0byB0aGUgSUVURg0KPiByZXBvc2l0b3J5Lg0KPiA+DQo+ID4gTmFtZToJCWRyYWZ0
LWlldGYtYXZ0Y29yZS1yZmM1Mjg1LWJpcw0KPiA+IFJldmlzaW9uOgkxMw0KPiA+IFRpdGxlOgkJ
QSBHZW5lcmFsIE1lY2hhbmlzbSBmb3IgUlRQIEhlYWRlciBFeHRlbnNpb25zDQo+ID4gRG9jdW1l
bnQgZGF0ZToJMjAxNy0wNy0yMg0KPiA+IEdyb3VwOgkJYXZ0Y29yZQ0KPiA+IFBhZ2VzOgkJMjQN
Cj4gPiBVUkw6ICAgICAgICAgICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRz
L2RyYWZ0LWlldGYtYXZ0Y29yZS1yZmM1Mjg1LQ0KPiBiaXMtMTMudHh0DQo+ID4gU3RhdHVzOiAg
ICAgICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtYXZ0Y29y
ZS1yZmM1Mjg1LWJpcy8NCj4gPiBIdG1saXplZDogICAgICAgaHR0cHM6Ly90b29scy5pZXRmLm9y
Zy9odG1sL2RyYWZ0LWlldGYtYXZ0Y29yZS1yZmM1Mjg1LWJpcy0xMw0KPiA+IEh0bWxpemVkOiAg
ICAgICBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LWlldGYtYXZ0
Y29yZS0NCj4gcmZjNTI4NS1iaXMtMTMNCj4gPiBEaWZmOiAgICAgICAgICAgaHR0cHM6Ly93d3cu
aWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWlldGYtYXZ0Y29yZS1yZmM1Mjg1LWJpcy0NCj4g
MTMNCj4gPg0KPiA+IEFic3RyYWN0Og0KPiA+ICAgVGhpcyBkb2N1bWVudCBwcm92aWRlcyBhIGdl
bmVyYWwgbWVjaGFuaXNtIHRvIHVzZSB0aGUgaGVhZGVyDQo+ID4gICBleHRlbnNpb24gZmVhdHVy
ZSBvZiBSVFAgKHRoZSBSZWFsLVRpbWUgVHJhbnNwb3J0IFByb3RvY29sKS4gIEl0DQo+ID4gICBw
cm92aWRlcyB0aGUgb3B0aW9uIHRvIHVzZSBhIHNtYWxsIG51bWJlciBvZiBzbWFsbCBleHRlbnNp
b25zIGluIGVhY2gNCj4gPiAgIFJUUCBwYWNrZXQsIHdoZXJlIHRoZSB1bml2ZXJzZSBvZiBwb3Nz
aWJsZSBleHRlbnNpb25zIGlzIGxhcmdlIGFuZA0KPiA+ICAgcmVnaXN0cmF0aW9uIGlzIGRlLWNl
bnRyYWxpemVkLiAgVGhlIGFjdHVhbCBleHRlbnNpb25zIGluIHVzZSBpbiBhDQo+ID4gICBzZXNz
aW9uIGFyZSBzaWduYWxlZCBpbiB0aGUgc2V0dXAgaW5mb3JtYXRpb24gZm9yIHRoYXQgc2Vzc2lv
bi4gIFRoaXMNCj4gPiAgIGRvY3VtZW50IG9ic29sZXRlcyBSRkM1Mjg1Lg0KPiA+DQo+ID4NCj4g
Pg0KPiA+DQo+ID4gUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51
dGVzIGZyb20gdGhlIHRpbWUgb2YNCj4gc3VibWlzc2lvbiB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVy
c2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnLg0KPiA+DQo+ID4g
VGhlIElFVEYgU2VjcmV0YXJpYXQNCj4gPg0KDQo=


From nobody Wed Jul 26 13:25:04 2017
Return-Path: 
X-Original-To: avt@ietfa.amsl.com
Delivered-To: avt@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E470913146C; Wed, 26 Jul 2017 13:24:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.881
X-Spam-Level: 
X-Spam-Status: No, score=-1.881 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YDNnda6DixpS; Wed, 26 Jul 2017 13:24:52 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D625D12EC46; Wed, 26 Jul 2017 13:24:52 -0700 (PDT)
Received: from [10.0.1.63] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v6QKOiCh066110 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 26 Jul 2017 15:24:45 -0500 (CDT) (envelope-from ben@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.63]
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
From: Ben Campbell 
In-Reply-To: <6E58094ECC8D8344914996DAD28F1CCD7EED0F@DGGEMM506-MBX.china.huawei.com>
Date: Wed, 26 Jul 2017 15:24:44 -0500
Cc: "avt@ietf.org" , Magnus Westerlund , The IESG 
Content-Transfer-Encoding: quoted-printable
Message-Id: <7D454855-6211-484D-AA7E-37AF86CF7386@nostrum.com>
References: <150079096276.31280.12592363692999578408.idtracker@ietfa.amsl.com> <6E58094ECC8D8344914996DAD28F1CCD7EE876@DGGEMM506-MBX.china.huawei.com> <4868C682-0915-4AD0-868A-AB3E14E999DA@nostrum.com> <6E58094ECC8D8344914996DAD28F1CCD7EED0F@DGGEMM506-MBX.china.huawei.com>
To: Roni Even 
X-Mailer: Apple Mail (2.3273)
Archived-At: 
Subject: Re: [AVTCORE] New Version Notification for draft-ietf-avtcore-rfc5285-bis-13.txt
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Audio/Video Transport Core Maintenance 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 26 Jul 2017 20:24:55 -0000

> On Jul 26, 2017, at 12:03 AM, Roni Even  wrote:
>=20
> HI Ben,
> Inactive means I support the extension but would not like to send or =
receive at the moment. May do it in a future offer/answer. This is when =
the answerer understands the offered extension.

Hi Roni,

I think it would be helpful to add a sentence to that effect for each =
instance.

Thanks!

Ben.


> Roni
>=20
>> -----Original Message-----
>> From: Ben Campbell [mailto:ben@nostrum.com]
>> Sent: =D7=99=D7=95=D7=9D =D7=92 25 =D7=99=D7=95=D7=9C=D7=99 2017 =
00:52
>> To: Roni Even
>> Cc: avt@ietf.org; Magnus Westerlund; The IESG
>> Subject: Re: New Version Notification for =
draft-ietf-avtcore-rfc5285-bis-
>> 13.txt
>>=20
>> Hi Roni,
>>=20
>> I agree this covers the IESG comments. However, I am confused about =
some
>> of the new text in section 7 about an answerer marking an extension =
as
>> =E2=80=9Cinactive=E2=80=9D. I assume these are here in response to =
Alexey=E2=80=99s questions about
>> why the SHOULDs are only SHOULDs.
>>=20
>> In the first instance:
>>=20
>>   "If an extension is marked as "sendonly" and the answerer desires =
to
>>   receive it, the extension MUST be marked as "recvonly" in the SDP
>>   answer.  An answerer that has no desire to receive the extension or
>>   does not understand the extension SHOULD remove it from the SDP
>>   answer.  An answerer MAY want to respond that he supports the
>>   extension and may use it in the future will mark the extension as
>>   =E2=80=9Cinactive=E2=80=9D=E2=80=9D
>>=20
>> What does =E2=80=9Cwilling to use it in the future=E2=80=9D mean that =
is different than just
>> being willing to receive it, which is already covered by marking it =
as
>> =E2=80=9Crecvonly=E2=80=9D? Do we contemplate that the offerer may at =
some point in the
>> future send an updated offer or answer that changes this to =
=E2=80=9Crecvonly=E2=80=9D?
>>=20
>> Similarly in the second instance:
>>=20
>>  If an extension is marked as "recvonly" and the answerer desires to
>>   send it, the extension MUST be marked as "sendonly" in the SDP
>>   answer.  An answerer that has no desire to, or is unable to, send =
the
>>   extension SHOULD remove it from the SDP answer.  An answerer MAY
>> want
>>   to respond that he support this extension and may send in the =
future
>>   or will be able to receive by marking the extension as "inactive"
>>=20
>> =E2=80=A6 is the answer expected to mark the extension as =
=E2=80=9Csendonly=E2=80=9D at some point
>> in the future?
>>=20
>>=20
>>=20
>> If it turns out that the added text is roughly correct, the text is =
still confusing
>> from a pure sentence structure perspective. I would suggest text, but =
we
>> probably need to resolve the above questions first.
>>=20
>> Thanks!
>>=20
>> Ben.
>>=20
>>=20
>>> On Jul 23, 2017, at 1:26 AM, Roni Even  wrote:
>>>=20
>>> Hi,
>>> I submitted a version that I hope addresses all the comments from =
the IESG
>> review.
>>> The major open issue was the category of allowed-mix in bundle and =
based
>> on the WG preference it is now Identical.
>>>=20
>>> Thanks
>>> Roni Even
>>>=20
>>> -----Original Message-----
>>> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]
>>> Sent: =D7=99=D7=95=D7=9D =D7=90 23 =D7=99=D7=95=D7=9C=D7=99 2017 =
09:23
>>> To: Harikishan Desineni; HariKishan Desineni; Roni Even; avtcore-
>> chairs@ietf.org; David Singer; Roni Even
>>> Subject: New Version Notification for =
draft-ietf-avtcore-rfc5285-bis-13.txt
>>>=20
>>>=20
>>> A new version of I-D, draft-ietf-avtcore-rfc5285-bis-13.txt
>>> has been successfully submitted by Roni Even and posted to the IETF
>> repository.
>>>=20
>>> Name:		draft-ietf-avtcore-rfc5285-bis
>>> Revision:	13
>>> Title:		A General Mechanism for RTP Header Extensions
>>> Document date:	2017-07-22
>>> Group:		avtcore
>>> Pages:		24
>>> URL:            =
https://www.ietf.org/internet-drafts/draft-ietf-avtcore-rfc5285-
>> bis-13.txt
>>> Status:         =
https://datatracker.ietf.org/doc/draft-ietf-avtcore-rfc5285-bis/
>>> Htmlized:       =
https://tools.ietf.org/html/draft-ietf-avtcore-rfc5285-bis-13
>>> Htmlized:       =
https://datatracker.ietf.org/doc/html/draft-ietf-avtcore-
>> rfc5285-bis-13
>>> Diff:           =
https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-avtcore-rfc5285-bis-
>> 13
>>>=20
>>> Abstract:
>>>  This document provides a general mechanism to use the header
>>>  extension feature of RTP (the Real-Time Transport Protocol).  It
>>>  provides the option to use a small number of small extensions in =
each
>>>  RTP packet, where the universe of possible extensions is large and
>>>  registration is de-centralized.  The actual extensions in use in a
>>>  session are signaled in the setup information for that session.  =
This
>>>  document obsoletes RFC5285.
>>>=20
>>>=20
>>>=20
>>>=20
>>> 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.
>>>=20
>>> The IETF Secretariat
>>>=20
>=20


From nobody Wed Jul 26 18:18:38 2017
Return-Path: 
X-Original-To: avt@ietfa.amsl.com
Delivered-To: avt@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1883126C23 for ; Wed, 26 Jul 2017 18:18:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.22
X-Spam-Level: 
X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hfgBo7xrqZrL for ; Wed, 26 Jul 2017 18:18:36 -0700 (PDT)
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 AC981124C27 for ; Wed, 26 Jul 2017 18:18:35 -0700 (PDT)
Received: from 172.18.7.190 (EHLO LHREML712-CAH.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DSC72887; Thu, 27 Jul 2017 01:18:33 +0000 (GMT)
Received: from NKGEML412-HUB.china.huawei.com (10.98.56.73) by LHREML712-CAH.china.huawei.com (10.201.108.35) with Microsoft SMTP Server (TLS) id 14.3.301.0; Thu, 27 Jul 2017 02:18:32 +0100
Received: from NKGEML513-MBX.china.huawei.com ([169.254.1.9]) by nkgeml412-hub.china.huawei.com ([10.98.56.73]) with mapi id 14.03.0235.001; Thu, 27 Jul 2017 09:18:29 +0800
From: "Huangyihong (Rachel)" 
To: IETF AVTCore WG 
Thread-Topic: AVTCORE minutes for IETF99
Thread-Index: AdMGdi/0LV4o4qZUTL+TfrLPifGnWQ==
Date: Thu, 27 Jul 2017 01:18:29 +0000
Message-ID: <51E6A56BD6A85142B9D172C87FC3ABBB9C512AB8@nkgeml513-mbx.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.134.153.152]
Content-Type: multipart/alternative; boundary="_000_51E6A56BD6A85142B9D172C87FC3ABBB9C512AB8nkgeml513mbxchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A0B0204.59793F6A.0023, ss=1, re=0.000, recu=0.000, reip=0.000,  cl=1, cld=1, fgs=0, ip=169.254.1.9, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: bff0bde0728d36d16c4a0a8140103506
Archived-At: 
Subject: [AVTCORE] AVTCORE minutes for IETF99
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Audio/Video Transport Core Maintenance 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 27 Jul 2017 01:18:38 -0000

--_000_51E6A56BD6A85142B9D172C87FC3ABBB9C512AB8nkgeml513mbxchi_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi folks,

Thanks to Varun for taking notes.

https://www.ietf.org/proceedings/99/minutes/minutes-99-avtcore-00.txt

Please check to see if any corrections are needed.

BR,
Rachel and Jonathan

--_000_51E6A56BD6A85142B9D172C87FC3ABBB9C512AB8nkgeml513mbxchi_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











Hi folks,


 


Thanks to Varun for taking note=
s. 


 


https://www.ietf.org/pro=
ceedings/99/minutes/minutes-99-avtcore-00.txt


 


Please check to see if any corr=
ections are needed.


 


BR,


Rachel and Jonathan<=
/span>






--_000_51E6A56BD6A85142B9D172C87FC3ABBB9C512AB8nkgeml513mbxchi_--


From nobody Fri Jul 28 06:31:02 2017
Return-Path: 
X-Original-To: avt@ietfa.amsl.com
Delivered-To: avt@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14D8E126E3A for ; Fri, 28 Jul 2017 06:31:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.701
X-Spam-Level: 
X-Spam-Status: No, score=-3.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lobi6DIh2c26 for ; Fri, 28 Jul 2017 06:30:57 -0700 (PDT)
Received: from smtps.ntu.edu.tw (smtps.ntu.edu.tw [140.112.2.142]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 73BC9131D09 for ; Fri, 28 Jul 2017 06:30:57 -0700 (PDT)
Received: from mail-ua0-f178.google.com (mail-ua0-f178.google.com [209.85.217.178]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtps.ntu.edu.tw (Postfix) with ESMTP id 3DF19106B2D for ; Fri, 28 Jul 2017 21:30:54 +0800 (CST)
Received: by mail-ua0-f178.google.com with SMTP id d29so154164657uai.2 for ; Fri, 28 Jul 2017 06:30:54 -0700 (PDT)
X-Gm-Message-State: AIVw11266wSvhl9E9Cna4EDSDsxukugawKM74tuNOsuiBdhLslXJ64NU 2ozosdf0X7d0ANoSJRUbwvaOJLDwnw==
X-Received: by 10.31.214.2 with SMTP id n2mr3995058vkg.198.1501248652464; Fri, 28 Jul 2017 06:30:52 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.31.178.16 with HTTP; Fri, 28 Jul 2017 06:30:51 -0700 (PDT)
From: Polly Huang 
Date: Fri, 28 Jul 2017 21:30:51 +0800
X-Gmail-Original-Message-ID: 
Message-ID: 
To: avt@ietf.org
Content-Type: multipart/alternative; boundary="94eb2c07d7bca670f8055560b0c0"
Archived-At: 
Subject: [AVTCORE] ACM SenSys 2017 2nd Call for Poster/Demo
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Audio/Video Transport Core Maintenance 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 28 Jul 2017 13:31:01 -0000

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

-- Our sincere apologies if you receive multiple copies of the call --

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
                                      Call for Posters and Demos
                                           ACM Sensys 2017
                                   http://sensys.acm.org/2017/
                                       Delft, The Netherlands
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

SenSys 2017 solicits submissions of poster and demo abstracts reflecting
on-going
research progress and/or demonstrating working prototypes. We welcome
submissions
in broadly defined areas of interests (but not limited to): systems of
smart sensors
and actuators, brand-new applications of sensory devices, smart things, and
smart
infrastructure, and the underlying research challenges in communication,
networking,
energy and resources, data management, algorithms and machine intelligence,
hardware designs, and deployment on real environments.

Student participants will greatly benefit from the Posters and Demos
session; it will
be a lively forum to present their work and receive early feedback from
international
leading experts attending the conference. We explicitly encourage
submissions of
revolutionary concepts, path breaking ideas, and ongoing research
prototypes.

Major IT industry as well as emerging technology startups are also highly
encouraged
to participate. SenSys is an ideal venue to present brand-new products,
early prototypes,
new development platforms, or even ongoing crowdfunding projects of smart
platforms
and solutions that might catalyse future applications and/or disrupt
today=E2=80=99s sensing
and networking technologies.

Submitted abstracts will be evaluated based on technical merit and
innovation as well
as their potential to stimulate interesting discussions and exchange of
ideas. Authors
of accepted abstracts will be given a one-minute slot in a =E2=80=9Cmadness
session=E2=80=9D during
the conference to present their work in front of the conference audience.
As with
previous editions of SenSys, the best poster and demo will receive an award=
.

All abstracts shall be formatted according to the main conference paper
layout. Accepted
abstracts will appear in the conference proceedings and the ACM Digital
Library.

## Submission Guidelines

* Posters and Demos must be submitted as a single PDF containing no more
than 2 pages.
The submission should be self-contained ready for publication, including
the title, authors,
institutional affiliations and contact information, abstract, main body,
and references.
Please DO NOT anonymize your submission. Upon acceptance, instructions for
the
final camera-ready abstract will be provided.
* You may include links to additional online material such as videos. Links
to videos showing
the demonstration are especially encouraged. Videos of accepted
posters/demos will be
linked from the SenSys web pages and permanently included in the ACM
Digital Library.
* To submit a demo abstract, please add =E2=80=9CDemo Abstract:=E2=80=9D at=
 the beginning
of the
manuscript=E2=80=99s title.
* To submit a poster abstract, please add =E2=80=9CPoster Abstract:=E2=80=
=9D at the
beginning of the
manuscript=E2=80=99s title.
* Template link for MS Word and LaTeX. (If LaTeX is used, please use
=E2=80=98Option 2=E2=80=99)
* Submissions for posters and demos can be done separately at the following
URL:
   https://sensys17.hotcrp.com/

## Important dates

* Submission: August 16, 2017
* Notification of acceptance: August 25, 2017
* Camera-ready abstract: September 9, 2017

## Co-chairs

* Andrew Markham, University of Oxford
* Marco Zuniga, Delft University of Technology

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


<=
div class=3D"gmail_quote">
-- Ou=
r sincere apologies if you receive multiple copies of the call --



=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Call for Poster=
s and Demos

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0ACM Sensys 2017

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0http://sensys.acm.org=
/2017/

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Delft, Th=
e Netherlands

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D



SenSys 2017 solicits submissions of poster and demo abstracts reflecting on=
-going

research progress and/or demonstrating working prototypes. We welcome submi=
ssions

in broadly defined areas of interests (but not limited to): systems of smar=
t sensors

and actuators, brand-new applications of sensory devices, smart things, and=
 smart

infrastructure, and the underlying research challenges in communication, ne=
tworking,

energy and resources, data management, algorithms and machine intelligence,=


hardware designs, and deployment on real environments.



Student participants will greatly benefit from the Posters and Demos sessio=
n; it will

be a lively forum to present their work and receive early feedback from int=
ernational

leading experts attending the conference. We explicitly encourage submissio=
ns of

revolutionary concepts, path breaking ideas, and ongoing research prototype=
s.



Major IT industry as well as emerging technology startups are also highly e=
ncouraged

to participate. SenSys is an ideal venue to present brand-new products, ear=
ly prototypes,

new development platforms, or even ongoing crowdfunding projects of smart p=
latforms

and solutions that might catalyse future applications and/or disrupt today=
=E2=80=99s sensing

and networking technologies.



Submitted abstracts will be evaluated based on technical merit and innovati=
on as well

as their potential to stimulate interesting discussions and exchange of ide=
as. Authors

of accepted abstracts will be given a one-minute slot in a =E2=80=9Cmadness=
 session=E2=80=9D during

the conference to present their work in front of the conference audience. A=
s with

previous editions of SenSys, the best poster and demo will receive an award=
.



All abstracts shall be formatted according to the main conference paper lay=
out. Accepted

abstracts will appear in the conference proceedings and the ACM Digital Lib=
rary.



## Submission Guidelines



* Posters and Demos must be submitted as a single PDF containing no more th=
an 2 pages.

The submission should be self-contained ready for publication, including th=
e title, authors,

institutional affiliations and contact information, abstract, main body, an=
d references.

Please DO NOT anonymize your submission. Upon acceptance, instructions for =
the

final camera-ready abstract will be provided.=E2=80=A8

* You may include links to additional online material such as videos. Links=
 to videos showing

the demonstration are especially encouraged. Videos of accepted posters/dem=
os will be

linked from the SenSys web pages and permanently included in the ACM Digita=
l Library.=E2=80=A8

* To submit a demo abstract, please add =E2=80=9CDemo Abstract:=E2=80=9D at=
 the beginning of the

manuscript=E2=80=99s title.=E2=80=A8

* To submit a poster abstract, please add =E2=80=9CPoster Abstract:=E2=80=
=9D at the beginning of the

manuscript=E2=80=99s title.=E2=80=A8

* Template link for MS Word and LaTeX. (If LaTeX is used, please use =E2=80=
=98Option 2=E2=80=99)=E2=80=A8

* Submissions for posters and demos can be done separately at the following=
 URL:

=C2=A0 =C2=A0https://sensys17.hotcrp.com/=E2=80=A8



## Important dates



* Submission: August 16, 2017

* Notification of acceptance: August 25, 2017

* Camera-ready abstract: September 9, 2017



## Co-chairs



* Andrew Markham, University of Oxford

* Marco Zuniga, Delft University of Technology




--94eb2c07d7bca670f8055560b0c0--


From nobody Sat Jul 29 11:56:42 2017
Return-Path: 
X-Original-To: avt@ietf.org
Delivered-To: avt@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 84131129B5B; Sat, 29 Jul 2017 11:56:40 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Warren Kumari 
To: "The IESG" 
Cc: draft-ietf-avtcore-aria-srtp@ietf.org, Roni Even , avtcore-chairs@ietf.org, roni.even@huawei.com, avt@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.57.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <150135460053.2956.16815637133782131171.idtracker@ietfa.amsl.com>
Date: Sat, 29 Jul 2017 11:56:40 -0700
Archived-At: 
Subject: [AVTCORE] Warren Kumari's No Objection on draft-ietf-avtcore-aria-srtp-10: (with COMMENT)
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.22
List-Id: Audio/Video Transport Core Maintenance 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 29 Jul 2017 18:56:41 -0000

Warren Kumari has entered the following ballot position for
draft-ietf-avtcore-aria-srtp-10: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-avtcore-aria-srtp/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I agree with most of Ben Laurie's SecDir comments, and Ben's questions on
SHA-1, but will leave it to the Sec ADs to evaluate.



From nobody Mon Jul 31 09:30:22 2017
Return-Path: 
X-Original-To: avt@ietf.org
Delivered-To: avt@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AC8CF132668; Mon, 31 Jul 2017 09:30:13 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: =?utf-8?q?Mirja_K=C3=BChlewind?= 
To: "The IESG" 
Cc: draft-ietf-avtcore-aria-srtp@ietf.org, Roni Even , avtcore-chairs@ietf.org, roni.even@huawei.com, avt@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.58.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <150151861369.6298.12051161492632423089.idtracker@ietfa.amsl.com>
Date: Mon, 31 Jul 2017 09:30:13 -0700
Archived-At: 
Subject: [AVTCORE] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draf?= =?utf-8?q?t-ietf-avtcore-aria-srtp-10=3A_=28with_COMMENT=29?=
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.22
List-Id: Audio/Video Transport Core Maintenance 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 31 Jul 2017 16:30:14 -0000

Mirja Kühlewind has entered the following ballot position for
draft-ietf-avtcore-aria-srtp-10: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-avtcore-aria-srtp/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

This actually looks more like a document that we would rather typically publish
by the ISE (as it is describing a method employed by one specific entity only).
I do not object to it publication as informational and I do understand that
this mostly due to the registration the in the MIKEY registry, however, i would
like to note that IESG Approval would have been another option for this
registration.