From nobody Sun Feb 2 08:08:33 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B31712004D; Sun, 2 Feb 2020 08:08:24 -0800 (PST) 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, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=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 jRJcBaVFb2wi; Sun, 2 Feb 2020 08:08:22 -0800 (PST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 D8335120125; Sun, 2 Feb 2020 08:08:21 -0800 (PST) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 012G8HNY019565 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 2 Feb 2020 11:08:19 -0500 Date: Sun, 2 Feb 2020 08:08:16 -0800 From: Benjamin Kaduk To: Vincent Roca Cc: secdir@ietf.org, last-call@ietf.org, draft-ietf-pim-msdp-yang.all@ietf.org, pim@ietf.org Message-ID: <20200202160816.GK91553@kduck.mit.edu> References: <158028589133.2819.6239221909447380902@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <158028589133.2819.6239221909447380902@ietfa.amsl.com> User-Agent: Mutt/1.12.1 (2019-06-15) Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-pim-msdp-yang-12 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Feb 2020 16:08:24 -0000 Hi Vincent, Thanks for doing the review! On Wed, Jan 29, 2020 at 12:18:11AM -0800, Vincent Roca via Datatracker wrote: > Reviewer: Vincent Roca > Review result: Has Nits > > Hello, > > I have reviewed this document as part of the security directorate’s ongoing > effort to review all IETF documents being processed by the IESG. These > comments were written primarily for the benefit of the security area > directors. Document editors and WG chairs should treat these comments just > like any other last call comments. > > Summary: Ready with nits > > The security considerations section is globally well writen and addresses > important topics. I don't have major comments. > > Details: > - it is said that "(i.e., config true, which is the default)". > I've searched in the YANG model and only found "config false" entries which > seems to contradict what is said in section 5. I think the idea is that you never actually say "config true", and rather just omit any 'config' statement to get the default (writeable) behavior. So I think there are still writeable leaves in this module. -Ben > - Section 2.1 says: "This model can be used to configure and manage MSDP > protocols." (with a final "s") which suggests there could be several MSDP > protocols. I think it's a mistake. > > Cheers, Vincent > > _______________________________________________ > secdir mailing list > secdir@ietf.org > https://www.ietf.org/mailman/listinfo/secdir > wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview From nobody Sun Feb 2 10:56:09 2020 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AB37A12012D; Sun, 2 Feb 2020 10:55:58 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Derrell Piper via Datatracker To: Cc: draft-ietf-6lo-minimal-fragment.all@ietf.org, last-call@ietf.org, 6lo@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.116.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Derrell Piper Message-ID: <158066975850.11281.14961061251951485181@ietfa.amsl.com> Date: Sun, 02 Feb 2020 10:55:58 -0800 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-6lo-minimal-fragment-10 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Feb 2020 18:55:59 -0000 Reviewer: Derrell Piper Review result: Ready I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. The summary of the review is Ready. Minor revision, no substantive changes. From nobody Sun Feb 2 16:34:23 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8738912013A; Sun, 2 Feb 2020 16:34:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.198 X-Spam-Level: X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 Uswc6pA646Tg; Sun, 2 Feb 2020 16:34:13 -0800 (PST) Received: from mxhk.zte.com.cn (mxhk.zte.com.cn [63.217.80.70]) (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 D61E312004A; Sun, 2 Feb 2020 16:34:12 -0800 (PST) Received: from mse-fl2.zte.com.cn (unknown [10.30.14.239]) by Forcepoint Email with ESMTPS id 249BAF8714B92B2A7C79; Mon, 3 Feb 2020 08:34:10 +0800 (CST) Received: from njxapp04.zte.com.cn ([10.41.132.203]) by mse-fl2.zte.com.cn with SMTP id 0130XuiQ092620; Mon, 3 Feb 2020 08:33:56 +0800 (GMT-8) (envelope-from zhang.zheng@zte.com.cn) Received: from mapi (njxapp04[null]) by mapi (Zmail) with MAPI id mid203; Mon, 3 Feb 2020 08:33:55 +0800 (CST) Date: Mon, 3 Feb 2020 08:33:55 +0800 (CST) X-Zmail-TransId: 2afc5e376a739618c902 X-Mailer: Zmail v1.0 Message-ID: <202002030833550333378@zte.com.cn> In-Reply-To: <20200202160816.GK91553@kduck.mit.edu> References: 158028589133.2819.6239221909447380902@ietfa.amsl.com, 20200202160816.GK91553@kduck.mit.edu Mime-Version: 1.0 From: To: , Cc: , , , Content-Type: multipart/mixed; boundary="=====_001_next=====" X-MAIL: mse-fl2.zte.com.cn 0130XuiQ092620 Archived-At: Subject: Re: [secdir] =?utf-8?q?=5Bpim=5D__Secdir_last_call_review_ofdraft-ie?= =?utf-8?q?tf-pim-msdp-yang-12?= X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Feb 2020 00:34:17 -0000 --=====_001_next===== Content-Type: multipart/related; boundary="=====_002_next=====" --=====_002_next===== Content-Type: multipart/alternative; boundary="=====_003_next=====" --=====_003_next===== Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 SGkgQmVuLCBWaW5jZW50LA0KDQoNCg0KDQoNCg0KVGhhbmsgeW91IHZlcnkgbXVjaCBmb3IgeW91 ciByZXZpZXchDQoNCg0KWWVzLiBUaGlzIHNlbnRlbmNlIG1lYW5zIHRoYXQgYWxsIHRoZSBjb25m aWd1cmFibGUgbGVhdmVzIGluIHRoZSBtb2RlbC4NCg0KDQoNClNob3VsZCBJIGRlbGV0ZSB0aGlz IHNlbnRlbmNlIHRvIGF2b2lkIG1pc3VuZGVyc3RhbmRpbmc/DQoNCg0KDQoNCg0KDQpCZXN0IHJl Z2FyZHMsDQoNCg0KU2FuZHkNCg0KDQoNCg0KDQoNCg0KDQoNCuWOn+Wni+mCruS7tg0KDQoNCg0K 5Y+R5Lu25Lq677yaQmVuamFtaW5LYWR1ayA8a2FkdWtAbWl0LmVkdT4NCuaUtuS7tuS6uu+8mlZp bmNlbnQgUm9jYSA8dmluY2VudC5yb2NhQGlucmlhLmZyPjsNCuaKhOmAgeS6uu+8mmxhc3QtY2Fs bEBpZXRmLm9yZyA8bGFzdC1jYWxsQGlldGYub3JnPjtkcmFmdC1pZXRmLXBpbS1tc2RwLXlhbmcu YWxsQGlldGYub3JnIDxkcmFmdC1pZXRmLXBpbS1tc2RwLXlhbmcuYWxsQGlldGYub3JnPjtwaW1A aWV0Zi5vcmcgPHBpbUBpZXRmLm9yZz47c2VjZGlyQGlldGYub3JnIDxzZWNkaXJAaWV0Zi5vcmc+ Ow0K5pelIOacnyDvvJoyMDIw5bm0MDLmnIgwM+aXpSAwMDowOA0K5Li7IOmimCDvvJpSZTogW3Bp bV0gW3NlY2Rpcl0gU2VjZGlyIGxhc3QgY2FsbCByZXZpZXcgb2ZkcmFmdC1pZXRmLXBpbS1tc2Rw LXlhbmctMTINCg0KDQoNCg0KSGkgVmluY2VudCwNCg0KVGhhbmtzIGZvciBkb2luZyB0aGUgcmV2 aWV3IQ0KDQpPbiBXZWQsIEphbiAyOSwgMjAyMCBhdCAxMjoxODoxMUFNIC0wODAwLCBWaW5jZW50 IFJvY2EgdmlhIERhdGF0cmFja2VyIHdyb3RlOg0KPiBSZXZpZXdlcjogVmluY2VudCBSb2NhDQo+ IFJldmlldyByZXN1bHQ6IEhhcyBOaXRzDQo+IA0KPiBIZWxsbywNCj4gDQo+IEkgaGF2ZSByZXZp ZXdlZCB0aGlzIGRvY3VtZW50IGFzIHBhcnQgb2YgdGhlIHNlY3VyaXR5IGRpcmVjdG9yYXRl4oCZ cyBvbmdvaW5nDQo+IGVmZm9ydCB0byByZXZpZXcgYWxsIElFVEYgZG9jdW1lbnRzIGJlaW5nIHBy b2Nlc3NlZCBieSB0aGUgSUVTRy4gVGhlc2UNCj4gY29tbWVudHMgd2VyZSB3cml0dGVuIHByaW1h cmlseSBmb3IgdGhlIGJlbmVmaXQgb2YgdGhlIHNlY3VyaXR5IGFyZWENCj4gZGlyZWN0b3JzLiAg RG9jdW1lbnQgZWRpdG9ycyBhbmQgV0cgY2hhaXJzIHNob3VsZCB0cmVhdCB0aGVzZSBjb21tZW50 cyBqdXN0DQo+IGxpa2UgYW55IG90aGVyIGxhc3QgY2FsbCBjb21tZW50cy4NCj4gDQo+IFN1bW1h cnk6IFJlYWR5IHdpdGggbml0cw0KPiANCj4gVGhlIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIHNl Y3Rpb24gaXMgZ2xvYmFsbHkgd2VsbCB3cml0ZW4gYW5kIGFkZHJlc3Nlcw0KPiBpbXBvcnRhbnQg dG9waWNzLiBJIGRvbid0IGhhdmUgbWFqb3IgY29tbWVudHMuDQo+IA0KPiBEZXRhaWxzOg0KPiAt IGl0IGlzIHNhaWQgdGhhdCAiKGkuZS4sIGNvbmZpZyB0cnVlLCB3aGljaCBpcyB0aGUgZGVmYXVs dCkiLg0KPiAgIEkndmUgc2VhcmNoZWQgaW4gdGhlIFlBTkcgbW9kZWwgYW5kIG9ubHkgZm91bmQg ImNvbmZpZyBmYWxzZSIgZW50cmllcyB3aGljaA0KPiAgIHNlZW1zIHRvIGNvbnRyYWRpY3Qgd2hh dCBpcyBzYWlkIGluIHNlY3Rpb24gNS4NCg0KSSB0aGluayB0aGUgaWRlYSBpcyB0aGF0IHlvdSBu ZXZlciBhY3R1YWxseSBzYXkgImNvbmZpZyB0cnVlIiwgYW5kIHJhdGhlcg0KanVzdCBvbWl0IGFu eSAnY29uZmlnJyBzdGF0ZW1lbnQgdG8gZ2V0IHRoZSBkZWZhdWx0ICh3cml0ZWFibGUpIGJlaGF2 aW9yLg0KU28gSSB0aGluayB0aGVyZSBhcmUgc3RpbGwgd3JpdGVhYmxlIGxlYXZlcyBpbiB0aGlz IG1vZHVsZS4NCg0KLUJlbg0KDQo+IC0gU2VjdGlvbiAyLjEgc2F5czogIlRoaXMgbW9kZWwgY2Fu IGJlIHVzZWQgdG8gY29uZmlndXJlIGFuZCBtYW5hZ2UgTVNEUA0KPiBwcm90b2NvbHMuIiAod2l0 aCBhIGZpbmFsICJzIikgd2hpY2ggc3VnZ2VzdHMgdGhlcmUgY291bGQgYmUgc2V2ZXJhbCBNU0RQ DQo+IHByb3RvY29scy4gSSB0aGluayBpdCdzIGEgbWlzdGFrZS4NCj4gDQo+IENoZWVycywgICAg VmluY2VudA0KPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCj4gc2VjZGlyIG1haWxpbmcgbGlzdA0KPiBzZWNkaXJAaWV0Zi5vcmcNCj4gaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZWNkaXINCj4gd2lraTogaHR0cDovL3Rv b2xzLmlldGYub3JnL2FyZWEvc2VjL3RyYWMvd2lraS9TZWNEaXJSZXZpZXcNCg0KX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnBpbSBtYWlsaW5nIGxpc3QN CnBpbUBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9waW0= --=====_003_next===== Content-Type: text/html ; charset="UTF-8" Content-Transfer-Encoding: base64 PGRpdiBjbGFzcz0iemNvbnRlbnRSb3ciPjxwIHN0eWxlPSJmb250LXNpemU6MTRweDtmb250LWZh bWlseTphcmlhbDsiPkhpIEJlbiwgVmluY2VudCw8L3A+PHAgc3R5bGU9ImZvbnQtc2l6ZToxNHB4 O2ZvbnQtZmFtaWx5OmFyaWFsOyI+PGJyPjwvcD48cCBzdHlsZT0iZm9udC1zaXplOjE0cHg7Zm9u dC1mYW1pbHk6YXJpYWw7Ij5UaGFuayB5b3UgdmVyeSBtdWNoIGZvciB5b3VyIHJldmlldyE8L3A+ PHAgc3R5bGU9ImZvbnQtc2l6ZToxNHB4O2ZvbnQtZmFtaWx5OmFyaWFsOyI+WWVzLiBUaGlzIHNl bnRlbmNlIG1lYW5zIHRoYXQgYWxsIHRoZSBjb25maWd1cmFibGUgbGVhdmVzIGluIHRoZSBtb2Rl bC48YnI+PC9wPjxwIHN0eWxlPSJmb250LXNpemU6MTRweDtmb250LWZhbWlseTphcmlhbDsiPlNo b3VsZCBJIGRlbGV0ZSB0aGlzIHNlbnRlbmNlIHRvIGF2b2lkIG1pc3VuZGVyc3RhbmRpbmc/PC9w PjxwIHN0eWxlPSJmb250LXNpemU6MTRweDtmb250LWZhbWlseTphcmlhbDsiPjxicj48L3A+PHAg c3R5bGU9ImZvbnQtc2l6ZToxNHB4O2ZvbnQtZmFtaWx5OmFyaWFsOyI+QmVzdCByZWdhcmRzLDwv cD48cCBzdHlsZT0iZm9udC1zaXplOjE0cHg7Zm9udC1mYW1pbHk6YXJpYWw7Ij5TYW5keTwvcD48 cCBzdHlsZT0iZm9udC1zaXplOjE0cHg7Zm9udC1mYW1pbHk6YXJpYWw7Ij48YnI+PC9wPjxkaXYg Y2xhc3M9InpNYWlsRnJvbSI+PC9kaXY+PGRpdj48ZGl2IGNsYXNzPSJ6aGlzdG9yeVJvdyIgc3R5 bGU9ImRpc3BsYXk6YmxvY2siPjxkaXYgY2xhc3M9InpoaXN0b3J5RGVzIiBzdHlsZT0id2lkdGg6 IDEwMCU7IGhlaWdodDogMjhweDsgbGluZS1oZWlnaHQ6IDI4cHg7IGJhY2tncm91bmQtY29sb3I6 ICNFMEU1RTk7IGNvbG9yOiAjMTM4OEZGOyB0ZXh0LWFsaWduOiBjZW50ZXI7IiBsYW5ndWFnZS1k YXRhPSJIaXN0b3J5T3JnVHh0Ij7ljp/lp4vpgq7ku7Y8L2Rpdj48ZGl2IGlkPSJ6d3JpdGVIaXN0 b3J5Q29udGFpbmVyIj48ZGl2IGNsYXNzPSJjb250cm9sLWdyb3VwIHpoaXN0b3J5UGFuZWwiPjxk aXYgY2xhc3M9InpoaXN0b3J5SGVhZGVyIiBzdHlsZT0icGFkZGluZzogOHB4OyBiYWNrZ3JvdW5k LWNvbG9yOiAjRjVGNkY4OyI+PGRpdj48c3Ryb25nIGxhbmd1YWdlLWRhdGE9Ikhpc3RvcnlTZW5k ZXJUeHQiPuWPkeS7tuS6uu+8mjwvc3Ryb25nPjxzcGFuIGNsYXNzPSJ6cmVhZFVzZXJOYW1lIj5C ZW5qYW1pbkthZHVrICZsdDtrYWR1a0BtaXQuZWR1Jmd0Ozwvc3Bhbj48L2Rpdj48ZGl2PjxzdHJv bmcgbGFuZ3VhZ2UtZGF0YT0iSGlzdG9yeVRPVHh0Ij7mlLbku7bkurrvvJo8L3N0cm9uZz48c3Bh biBjbGFzcz0ienJlYWRVc2VyTmFtZSIgc3R5bGU9ImRpc3BsYXk6IGlubGluZTsiPlZpbmNlbnQg Um9jYSAmbHQ7dmluY2VudC5yb2NhQGlucmlhLmZyJmd0Ozs8L3NwYW4+PC9kaXY+PGRpdj48c3Ry b25nIGxhbmd1YWdlLWRhdGE9Ikhpc3RvcnlDQ1R4dCI+5oqE6YCB5Lq677yaPC9zdHJvbmc+PHNw YW4gY2xhc3M9InpyZWFkVXNlck5hbWUiIHN0eWxlPSJkaXNwbGF5OiBpbmxpbmU7Ij5sYXN0LWNh bGxAaWV0Zi5vcmcgJmx0O2xhc3QtY2FsbEBpZXRmLm9yZyZndDs7PC9zcGFuPjxzcGFuIGNsYXNz PSJ6cmVhZFVzZXJOYW1lIiBzdHlsZT0iZGlzcGxheTogaW5saW5lOyI+ZHJhZnQtaWV0Zi1waW0t bXNkcC15YW5nLmFsbEBpZXRmLm9yZyAmbHQ7ZHJhZnQtaWV0Zi1waW0tbXNkcC15YW5nLmFsbEBp ZXRmLm9yZyZndDs7PC9zcGFuPjxzcGFuIGNsYXNzPSJ6cmVhZFVzZXJOYW1lIiBzdHlsZT0iZGlz cGxheTogaW5saW5lOyI+cGltQGlldGYub3JnICZsdDtwaW1AaWV0Zi5vcmcmZ3Q7Ozwvc3Bhbj48 c3BhbiBjbGFzcz0ienJlYWRVc2VyTmFtZSIgc3R5bGU9ImRpc3BsYXk6IGlubGluZTsiPnNlY2Rp ckBpZXRmLm9yZyAmbHQ7c2VjZGlyQGlldGYub3JnJmd0Ozs8L3NwYW4+PC9kaXY+PGRpdj48c3Ry b25nIGxhbmd1YWdlLWRhdGE9Ikhpc3RvcnlEYXRlVHh0Ij7ml6Ug5pyfIO+8mjwvc3Ryb25nPjxz cGFuIGNsYXNzPSIiPjIwMjDlubQwMuaciDAz5pelIDAwOjA4PC9zcGFuPjwvZGl2PjxkaXY+PHN0 cm9uZyBsYW5ndWFnZS1kYXRhPSJIaXN0b3J5U3ViamVjdFR4dCI+5Li7IOmimCDvvJo8L3N0cm9u Zz48c3BhbiBjbGFzcz0ienJlYWRUaXRsZSI+PHN0cm9uZz5SZTogW3BpbV0gW3NlY2Rpcl0gU2Vj ZGlyIGxhc3QgY2FsbCByZXZpZXcgb2ZkcmFmdC1pZXRmLXBpbS1tc2RwLXlhbmctMTI8L3N0cm9u Zz48L3NwYW4+PC9kaXY+PC9kaXY+PGRpdiB6bWFpbGJ1c2luZXNzPSJidXNpbmVzc0V4dGVybmFs Ij48L2Rpdj48ZGl2IGNsYXNzPSJ6aGlzdG9yeUNvbnRlbnQiPjxkaXY+SGkmbmJzcDtWaW5jZW50 LDxicj48YnI+VGhhbmtzJm5ic3A7Zm9yJm5ic3A7ZG9pbmcmbmJzcDt0aGUmbmJzcDtyZXZpZXch PGJyPjxicj5PbiZuYnNwO1dlZCwmbmJzcDtKYW4mbmJzcDsyOSwmbmJzcDsyMDIwJm5ic3A7YXQm bmJzcDsxMjoxODoxMUFNJm5ic3A7LTA4MDAsJm5ic3A7VmluY2VudCZuYnNwO1JvY2EmbmJzcDt2 aWEmbmJzcDtEYXRhdHJhY2tlciZuYnNwO3dyb3RlOjxicj4mZ3Q7Jm5ic3A7UmV2aWV3ZXI6Jm5i c3A7VmluY2VudCZuYnNwO1JvY2E8YnI+Jmd0OyZuYnNwO1JldmlldyZuYnNwO3Jlc3VsdDombmJz cDtIYXMmbmJzcDtOaXRzPGJyPiZndDsmbmJzcDs8YnI+Jmd0OyZuYnNwO0hlbGxvLDxicj4mZ3Q7 Jm5ic3A7PGJyPiZndDsmbmJzcDtJJm5ic3A7aGF2ZSZuYnNwO3Jldmlld2VkJm5ic3A7dGhpcyZu YnNwO2RvY3VtZW50Jm5ic3A7YXMmbmJzcDtwYXJ0Jm5ic3A7b2YmbmJzcDt0aGUmbmJzcDtzZWN1 cml0eSZuYnNwO2RpcmVjdG9yYXRl4oCZcyZuYnNwO29uZ29pbmc8YnI+Jmd0OyZuYnNwO2VmZm9y dCZuYnNwO3RvJm5ic3A7cmV2aWV3Jm5ic3A7YWxsJm5ic3A7SUVURiZuYnNwO2RvY3VtZW50cyZu YnNwO2JlaW5nJm5ic3A7cHJvY2Vzc2VkJm5ic3A7YnkmbmJzcDt0aGUmbmJzcDtJRVNHLiZuYnNw O1RoZXNlPGJyPiZndDsmbmJzcDtjb21tZW50cyZuYnNwO3dlcmUmbmJzcDt3cml0dGVuJm5ic3A7 cHJpbWFyaWx5Jm5ic3A7Zm9yJm5ic3A7dGhlJm5ic3A7YmVuZWZpdCZuYnNwO29mJm5ic3A7dGhl Jm5ic3A7c2VjdXJpdHkmbmJzcDthcmVhPGJyPiZndDsmbmJzcDtkaXJlY3RvcnMuJm5ic3A7Jm5i c3A7RG9jdW1lbnQmbmJzcDtlZGl0b3JzJm5ic3A7YW5kJm5ic3A7V0cmbmJzcDtjaGFpcnMmbmJz cDtzaG91bGQmbmJzcDt0cmVhdCZuYnNwO3RoZXNlJm5ic3A7Y29tbWVudHMmbmJzcDtqdXN0PGJy PiZndDsmbmJzcDtsaWtlJm5ic3A7YW55Jm5ic3A7b3RoZXImbmJzcDtsYXN0Jm5ic3A7Y2FsbCZu YnNwO2NvbW1lbnRzLjxicj4mZ3Q7Jm5ic3A7PGJyPiZndDsmbmJzcDtTdW1tYXJ5OiZuYnNwO1Jl YWR5Jm5ic3A7d2l0aCZuYnNwO25pdHM8YnI+Jmd0OyZuYnNwOzxicj4mZ3Q7Jm5ic3A7VGhlJm5i c3A7c2VjdXJpdHkmbmJzcDtjb25zaWRlcmF0aW9ucyZuYnNwO3NlY3Rpb24mbmJzcDtpcyZuYnNw O2dsb2JhbGx5Jm5ic3A7d2VsbCZuYnNwO3dyaXRlbiZuYnNwO2FuZCZuYnNwO2FkZHJlc3Nlczxi cj4mZ3Q7Jm5ic3A7aW1wb3J0YW50Jm5ic3A7dG9waWNzLiZuYnNwO0kmbmJzcDtkb24ndCZuYnNw O2hhdmUmbmJzcDttYWpvciZuYnNwO2NvbW1lbnRzLjxicj4mZ3Q7Jm5ic3A7PGJyPiZndDsmbmJz cDtEZXRhaWxzOjxicj4mZ3Q7Jm5ic3A7LSZuYnNwO2l0Jm5ic3A7aXMmbmJzcDtzYWlkJm5ic3A7 dGhhdCZuYnNwOyIoaS5lLiwmbmJzcDtjb25maWcmbmJzcDt0cnVlLCZuYnNwO3doaWNoJm5ic3A7 aXMmbmJzcDt0aGUmbmJzcDtkZWZhdWx0KSIuPGJyPiZndDsmbmJzcDsmbmJzcDsmbmJzcDtJJ3Zl Jm5ic3A7c2VhcmNoZWQmbmJzcDtpbiZuYnNwO3RoZSZuYnNwO1lBTkcmbmJzcDttb2RlbCZuYnNw O2FuZCZuYnNwO29ubHkmbmJzcDtmb3VuZCZuYnNwOyJjb25maWcmbmJzcDtmYWxzZSImbmJzcDtl bnRyaWVzJm5ic3A7d2hpY2g8YnI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwO3NlZW1zJm5ic3A7dG8m bmJzcDtjb250cmFkaWN0Jm5ic3A7d2hhdCZuYnNwO2lzJm5ic3A7c2FpZCZuYnNwO2luJm5ic3A7 c2VjdGlvbiZuYnNwOzUuPGJyPjxicj5JJm5ic3A7dGhpbmsmbmJzcDt0aGUmbmJzcDtpZGVhJm5i c3A7aXMmbmJzcDt0aGF0Jm5ic3A7eW91Jm5ic3A7bmV2ZXImbmJzcDthY3R1YWxseSZuYnNwO3Nh eSZuYnNwOyJjb25maWcmbmJzcDt0cnVlIiwmbmJzcDthbmQmbmJzcDtyYXRoZXI8YnI+anVzdCZu YnNwO29taXQmbmJzcDthbnkmbmJzcDsnY29uZmlnJyZuYnNwO3N0YXRlbWVudCZuYnNwO3RvJm5i c3A7Z2V0Jm5ic3A7dGhlJm5ic3A7ZGVmYXVsdCZuYnNwOyh3cml0ZWFibGUpJm5ic3A7YmVoYXZp b3IuPGJyPlNvJm5ic3A7SSZuYnNwO3RoaW5rJm5ic3A7dGhlcmUmbmJzcDthcmUmbmJzcDtzdGls bCZuYnNwO3dyaXRlYWJsZSZuYnNwO2xlYXZlcyZuYnNwO2luJm5ic3A7dGhpcyZuYnNwO21vZHVs ZS48YnI+PGJyPi1CZW48YnI+PGJyPiZndDsmbmJzcDstJm5ic3A7U2VjdGlvbiZuYnNwOzIuMSZu YnNwO3NheXM6Jm5ic3A7IlRoaXMmbmJzcDttb2RlbCZuYnNwO2NhbiZuYnNwO2JlJm5ic3A7dXNl ZCZuYnNwO3RvJm5ic3A7Y29uZmlndXJlJm5ic3A7YW5kJm5ic3A7bWFuYWdlJm5ic3A7TVNEUDxi cj4mZ3Q7Jm5ic3A7cHJvdG9jb2xzLiImbmJzcDsod2l0aCZuYnNwO2EmbmJzcDtmaW5hbCZuYnNw OyJzIikmbmJzcDt3aGljaCZuYnNwO3N1Z2dlc3RzJm5ic3A7dGhlcmUmbmJzcDtjb3VsZCZuYnNw O2JlJm5ic3A7c2V2ZXJhbCZuYnNwO01TRFA8YnI+Jmd0OyZuYnNwO3Byb3RvY29scy4mbmJzcDtJ Jm5ic3A7dGhpbmsmbmJzcDtpdCdzJm5ic3A7YSZuYnNwO21pc3Rha2UuPGJyPiZndDsmbmJzcDs8 YnI+Jmd0OyZuYnNwO0NoZWVycywmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtWaW5jZW50PGJyPiZn dDsmbmJzcDs8YnI+Jmd0OyZuYnNwO19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fPGJyPiZndDsmbmJzcDtzZWNkaXImbmJzcDttYWlsaW5nJm5ic3A7bGlzdDxi cj4mZ3Q7Jm5ic3A7c2VjZGlyQGlldGYub3JnPGJyPiZndDsmbmJzcDtodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NlY2Rpcjxicj4mZ3Q7Jm5ic3A7d2lraTombmJzcDtodHRw Oi8vdG9vbHMuaWV0Zi5vcmcvYXJlYS9zZWMvdHJhYy93aWtpL1NlY0RpclJldmlldzxicj48YnI+ X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+cGltJm5i c3A7bWFpbGluZyZuYnNwO2xpc3Q8YnI+cGltQGlldGYub3JnPGJyPmh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vcGltPGJyPjwvZGl2PjwvZGl2PjwvZGl2PjwvZGl2PjwvZGl2 PjwvZGl2PjxwPjxicj48L3A+PC9kaXY+ --=====_003_next=====-- --=====_002_next=====-- --=====_001_next=====-- From nobody Sun Feb 2 20:24:34 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBFE012089D; Sun, 2 Feb 2020 20:24:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=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 PLSZh3NVLt91; Sun, 2 Feb 2020 20:24:28 -0800 (PST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 2A4BE120890; Sun, 2 Feb 2020 20:24:28 -0800 (PST) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 0134ONgR000370 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 2 Feb 2020 23:24:25 -0500 Date: Sun, 2 Feb 2020 20:24:22 -0800 From: Benjamin Kaduk To: zhang.zheng@zte.com.cn Cc: vincent.roca@inria.fr, last-call@ietf.org, draft-ietf-pim-msdp-yang.all@ietf.org, pim@ietf.org, secdir@ietf.org Message-ID: <20200203042422.GN91553@kduck.mit.edu> References: <20200202160816.GK91553@kduck.mit.edu> <202002030833550333378@zte.com.cn> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <202002030833550333378@zte.com.cn> User-Agent: Mutt/1.12.1 (2019-06-15) Archived-At: Subject: Re: [secdir] [pim] Secdir last call review ofdraft-ietf-pim-msdp-yang-12 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Feb 2020 04:24:30 -0000 Hi Sandy, No, you should not delete the sentence. We should keep the standard template as-is. -Ben On Mon, Feb 03, 2020 at 08:33:55AM +0800, zhang.zheng@zte.com.cn wrote: > Hi Ben, Vincent, > > > > > > > Thank you very much for your review! > > > Yes. This sentence means that all the configurable leaves in the model. > > > > Should I delete this sentence to avoid misunderstanding? > > > > > > > Best regards, > > > Sandy > > > > > > > > > > 原始邮件 > > > > 发件人：BenjaminKaduk > 收件人：Vincent Roca ; > 抄送人：last-call@ietf.org ;draft-ietf-pim-msdp-yang.all@ietf.org ;pim@ietf.org ;secdir@ietf.org ; > 日 期 ：2020年02月03日 00:08 > 主 题 ：Re: [pim] [secdir] Secdir last call review ofdraft-ietf-pim-msdp-yang-12 > > > > > Hi Vincent, > > Thanks for doing the review! > > On Wed, Jan 29, 2020 at 12:18:11AM -0800, Vincent Roca via Datatracker wrote: > > Reviewer: Vincent Roca > > Review result: Has Nits > > > > Hello, > > > > I have reviewed this document as part of the security directorate’s ongoing > > effort to review all IETF documents being processed by the IESG. These > > comments were written primarily for the benefit of the security area > > directors. Document editors and WG chairs should treat these comments just > > like any other last call comments. > > > > Summary: Ready with nits > > > > The security considerations section is globally well writen and addresses > > important topics. I don't have major comments. > > > > Details: > > - it is said that "(i.e., config true, which is the default)". > > I've searched in the YANG model and only found "config false" entries which > > seems to contradict what is said in section 5. > > I think the idea is that you never actually say "config true", and rather > just omit any 'config' statement to get the default (writeable) behavior. > So I think there are still writeable leaves in this module. > > -Ben > > > - Section 2.1 says: "This model can be used to configure and manage MSDP > > protocols." (with a final "s") which suggests there could be several MSDP > > protocols. I think it's a mistake. > > > > Cheers, Vincent > > > > _______________________________________________ > > secdir mailing list > > secdir@ietf.org > > https://www.ietf.org/mailman/listinfo/secdir > > wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview > > _______________________________________________ > pim mailing list > pim@ietf.org > https://www.ietf.org/mailman/listinfo/pim From nobody Sun Feb 2 21:12:57 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA3F51208CE; Sun, 2 Feb 2020 21:12:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=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 fSfd8poAFCmQ; Sun, 2 Feb 2020 21:12:44 -0800 (PST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 2D9BF1208C6; Sun, 2 Feb 2020 21:12:44 -0800 (PST) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 0135CaEG011271 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 3 Feb 2020 00:12:39 -0500 Date: Sun, 2 Feb 2020 21:12:36 -0800 From: Benjamin Kaduk To: "Pascal Thubert (pthubert)" Cc: "Eric Vyncke (evyncke)" , The IESG , "secdir@ietf.org" , "draft-ietf-6lo-ap-nd@ietf.org" , "6lo-chairs@ietf.org" <6lo-chairs@ietf.org>, "Shwetha Bhandari (shwethab)" , "6lo@ietf.org" <6lo@ietf.org> Message-ID: <20200203051214.GP91553@kduck.mit.edu> References: <158030752268.2728.2544838912831012540.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.12.1 (2019-06-15) Archived-At: Subject: Re: [secdir] =?iso-8859-1?q?=C9ric_Vyncke=27s_Discuss_on_draft-ietf-?= =?iso-8859-1?q?6lo-ap-nd-13=3A_=28with_DISCUSS_and_COMMENT=29?= X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Feb 2020 05:12:47 -0000 On Wed, Jan 29, 2020 at 03:38:26PM +0000, Pascal Thubert (pthubert) wrote: > Hello Eric : ) > > Many thanks for your review! I cc'ed SEC-DIR because we could really use their recommendation to solve some of your questions, more below. > > Please see below: > > > == DISCUSS == > > > > -- Section 4.4 -- > > The length of the reserved field is not specified. Or am I missing something > > obvious ? > > I concatenated the reserved fields in the picture and declared it as 40 bits. > Also added the number of bits in the reserved fields of other structures. > > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > > == COMMENTS == > > > > -- Section 4.2 -- > > While status is set to 0 when sending a NS, what is the expected behavior of a > > receiver ? > > Changed to > " > In NS messages it MUST be set to 0 by the sender and ignored by the receiver. > " > > > -- Section 4.3 and 4.4 -- > > Why is the Pad Length field a 8-bit field while the actual padding will always be > > less than 8 bytes. Suggest to make it a 3 or 4 bits field and extend the reserved > > field. > > Actually I thought that if we want to extend the option in the future, it is better to indicate the length of the public key as follows: > > | Type | Length | Reserved| Public Key Length | > > Where: > > Public Key Length: 13-bit unsigned integer. The length of the Public Key field in bytes. > Public Key: A variable-length field, size indicated in the Public Key Length field. > JWK-Encoded Public Key [RFC7517] > >Padding: A variable-length field completing the Public Key field to align to the next 8-bytes boundary. > > > Works? > > > > > > > -- Section 6.1 -- > > About "Nonce option MUST contain a random Nonce value that was never used > > with this device", how can it be done? Keeping a local history? Giving some > > operational hints would bee welcome. Especially, when there are multiple 6LR in > > the LLN: how can they synchronize the nonce? > > The nonce is used once, so there's no synchronization. A new pair is formed and exchanged at each validation. > > The nonce game used here appear to be common practice. Yes, there's usually a need of local history, and the fact that we get a nonce from both side, apart from guaranteeing that the result is effectively unique to both parties, also makes the chances for history to repeat very low. > > CC'ing SEC-DIR: Please help: if there is a reference for that practice, what it takes to maintain a nonce, and why we have a nonce from both sides? Trying to reinvent that text does not look like a good idea for this draft. It's pretty standard, so I'm not sure that there's a perfect reference for it. A key phrase is that it provides "contributory behavior", so that a party (either one) that knows it has a good RNG knows that the protocol will be secure. > > > > > > -- References -- > > Is there a reason why the crypto algorithms RFC 7748 and 8032 are not > > normative? > > Interestingly they are informational. So that would be a downref. > > CC'ing SEC-DIR: Please help: should we make these refs normative? Generally yes; they're listed at https://datatracker.ietf.org/doc/downref/ so no need to re-run the IETF LC. -Ben > > > > > == NITS == > > > > -- Section 2.2 -- > > To be honest, I am not a big fan of simply announcing concepts and referring to > > many other RFCs. Suggest to mention which terms and concepts are defined in > > each document. Else, the current section 2.2 mostly forces the readers to read > > all the references. > > Yes and they are really there as additional reading, not normative. > I changed the text to > " The reader may get additional context for this specification from the following references" > I also moved classical ND and SEND references to informational references. > > Works? > > > -- Section 6 -- > > s/may use a same Crypto-ID/may use the same Crypto-ID/ ? > > Done > > Many thanks again Eric! > > Let's see what SEC-DIR thinks > > And a very happy new year (in France we have till Jan 31st to send wishes 😉) > > Pascal > > > From nobody Sun Feb 2 23:33:14 2020 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FCA3120020; Sun, 2 Feb 2020 23:33:12 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Valery Smyslov via Datatracker To: Cc: last-call@ietf.org, draft-halpern-gendispatch-consensusinformational.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.116.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Valery Smyslov Message-ID: <158071519216.11324.2230466035276788626@ietfa.amsl.com> Date: Sun, 02 Feb 2020 23:33:12 -0800 Archived-At: Subject: [secdir] Secdir last call review of draft-halpern-gendispatch-consensusinformational-02 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Feb 2020 07:33:12 -0000 Reviewer: Valery Smyslov Review result: Ready Reviewer: Valery Smyslov Review result: Ready I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. The document doesn't describe any protocol, it only concerns with IETF process. For this reason the document has no direct impact on the security of IETF protocols. From nobody Mon Feb 3 02:02:38 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06BD6120077; Mon, 3 Feb 2020 02:02:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=E9BlOtbu; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=Xd42nmrJ 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 I42ISbqDngQ6; Mon, 3 Feb 2020 02:02:30 -0800 (PST) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 955D4120108; Mon, 3 Feb 2020 02:02:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1708; q=dns/txt; s=iport; t=1580724150; x=1581933750; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=+Thv9PktyKg5TCyM7dTcgmHk7xJ2TOp58IInI37fvPY=; b=E9BlOtbuW2OmWxWcKKFNqjakgSEDtXVQ+jrBqdqMVGFfw1BkmRhp4qtN 7bRMF9Bk3RE9uS3VOhHgRJsYkBBPDgH9+wB3AhEMh4+8IxhdfJ9nwi2UM tstrmhNSo88G5obBDpuMAuE5wfBYYcoPMvsVF8V/xp9CmC7iJ3nEPZPts Y=; IronPort-PHdr: =?us-ascii?q?9a23=3ALfi0uRNxFhdjcNNlUKsl6mtXPHoupqn0MwgJ65?= =?us-ascii?q?Eul7NJdOG58o//OFDEu6w/l0fHCIPc7f8My/HbtaztQyQh2d6AqzhDFf4ETB?= =?us-ascii?q?oZkYMTlg0kDtSCDBjjMP73ZSEgAOxJVURu+DewNk0GUMs=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CiCQBA7zde/4QNJK1lDhABCxyDT1A?= =?us-ascii?q?FgUQgBAsqhBSDRgOKdYJfmA+CUgNUCQEBAQwBAS0CAQGEQAIXghwkOBMCAw0?= =?us-ascii?q?BAQQBAQECAQUEbYU3DIVmAQEBAQIBEhERDAEBNwEPAgEIGgImAgICMBUFCwI?= =?us-ascii?q?EDg0ahU8DDiABAqBFAoE5iGJ1gTKCfwEBBYUTGIIMCYEOKoUehT+BQxqBQT+?= =?us-ascii?q?BEUeBTn4+hE2DDjKCLJAcO49ZjzYKgjuWW4JIiA6QMoNJpjICBAIEBQIOAQE?= =?us-ascii?q?FgWkigVhwFYMnUBgNjh04gzuKGDt0gSmNYAEB?= X-IronPort-AV: E=Sophos;i="5.70,397,1574121600"; d="scan'208";a="433834622" Received: from alln-core-10.cisco.com ([173.36.13.132]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 03 Feb 2020 10:02:27 +0000 Received: from XCH-ALN-002.cisco.com (xch-aln-002.cisco.com [173.36.7.12]) by alln-core-10.cisco.com (8.15.2/8.15.2) with ESMTPS id 013A2Q5f007328 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 3 Feb 2020 10:02:26 GMT Received: from xhs-rcd-002.cisco.com (173.37.227.247) by XCH-ALN-002.cisco.com (173.36.7.12) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 3 Feb 2020 04:02:26 -0600 Received: from xhs-rtp-002.cisco.com (64.101.210.229) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 3 Feb 2020 04:02:25 -0600 Received: from NAM02-CY1-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Mon, 3 Feb 2020 05:02:25 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=CD1YTEsq7EIDdFF+tEHxy3nCCDLnhO00MVXtgPCUHu/2BjwGfovASwR+Iv9PN333sNme5Fk6Zs86y161AuzhYIrbdG71zvdIKedgFgByd+5JVvzoNQl52er2hdE4R7g5alP9OlKjli7penrsblBSoxoeh0cTpEevIMwpgYma4EGZbOgNCx3zCqZzDRzqmr/V3XwSWfDF9TjO4sI20zC5kWrwrie1255o/8+1MxV084SsMIMusy8XW88dwDpTxtNuwN0+xfITuYl0CUFg17NY76EdoVJQAgAA8oeQN7IyStZwSAoiMZo0FRuSHNzwQzkfA13ng2BsIG58U2INJyLeww== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=+Thv9PktyKg5TCyM7dTcgmHk7xJ2TOp58IInI37fvPY=; b=jXasQCR5wmDEy4NqOuOy0ELoxYC/i2RvNOUT/qJgkeS91OZAWqeySdP33GWmDJdm99zXiqqPWJ1ZxaHMLYHWt/Ub2MKVgFJn9bcZUrVsstDq1f574V8E/FHRAOCqD4ozrr8daMTdkMw58+/JWh5/Ak4sb9X1zmBgq2BnvhvprnDGNBdpXvQe+UVOREKqa6uhbA91at61AzCYkxeUQUy3iJlSRrj/fxAm00Q1ef2blYMR1oapxrRgHYR9yHOB1fU1bxsww+2CuUaDN3EkB+QCkkses11YDVRU5fFRon9RbURhQnW/qrjPfBCF8H5XZgsSMtbSlxQQTklEatCmPrhjcw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=+Thv9PktyKg5TCyM7dTcgmHk7xJ2TOp58IInI37fvPY=; b=Xd42nmrJpnBXw8seWl9hhR9DcSE0dN/aedXHpJ7qWBu3PTTbcTC6NO0Fw9ZsgwczARpJSuVZE8nGKlr9O3LnB51Z+eW+/XjXFLRrwV1lQTojjS5uAFS6tSoiRj5XUKwEVpqmT8saLk1/QxtxgEeRWjpb3x0J7sv/CeDFDKNYAwc= Received: from MN2PR11MB3565.namprd11.prod.outlook.com (20.178.250.159) by MN2PR11MB4366.namprd11.prod.outlook.com (52.135.38.209) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2686.27; Mon, 3 Feb 2020 10:02:24 +0000 Received: from MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::fd76:1534:4f9a:452a]) by MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::fd76:1534:4f9a:452a%3]) with mapi id 15.20.2686.031; Mon, 3 Feb 2020 10:02:24 +0000 From: "Pascal Thubert (pthubert)" To: Benjamin Kaduk CC: "Eric Vyncke (evyncke)" , The IESG , "secdir@ietf.org" , "draft-ietf-6lo-ap-nd@ietf.org" , "6lo-chairs@ietf.org" <6lo-chairs@ietf.org>, "Shwetha Bhandari (shwethab)" , "6lo@ietf.org" <6lo@ietf.org> Thread-Topic: =?utf-8?B?w4lyaWMgVnluY2tlJ3MgRGlzY3VzcyBvbiBkcmFmdC1pZXRmLTZsby1hcC1u?= =?utf-8?Q?d-13:_(with_DISCUSS_and_COMMENT)?= Thread-Index: AQHV1q8ObZjsSNLsNE+ME5HgTzGBvKgBtsSwgAc89gCAAE9OEA== Date: Mon, 3 Feb 2020 10:02:04 +0000 Deferred-Delivery: Mon, 3 Feb 2020 10:01:07 +0000 Message-ID: References: <158030752268.2728.2544838912831012540.idtracker@ietfa.amsl.com> <20200203051214.GP91553@kduck.mit.edu> In-Reply-To: <20200203051214.GP91553@kduck.mit.edu> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=pthubert@cisco.com; x-originating-ip: [2a01:cb1d:4ec:2200:bc37:b7fd:22bd:a988] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 7ef21f8f-04f1-4cf6-c58d-08d7a8902acf x-ms-traffictypediagnostic: MN2PR11MB4366: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0302D4F392 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(39860400002)(366004)(346002)(396003)(376002)(136003)(199004)(189003)(66556008)(64756008)(66446008)(76116006)(7696005)(5660300002)(71200400001)(9686003)(2906002)(52536014)(66476007)(66946007)(81156014)(186003)(55016002)(224303003)(81166006)(8936002)(6916009)(86362001)(6666004)(478600001)(4326008)(33656002)(6506007)(316002)(54906003); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB4366; H:MN2PR11MB3565.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 911K3W6xKqQJX6+dNmPl7aUI8o3v/8TgFm94vcLBiM1b6NsWpRmSR2muZRDV+67vZ2dpP7QjWSggL6yZNkCgXTg6v54Zo2N1RJCtHDywHnNOt5uWCd3EJBpIeqQPFe0ergSAJ3U5rQLO0moqnLhK36/GxZQtLpYfieByD/xEQneWIJ4OY+ZOn/e+6G/XIgA0siKLZXTQa4p7/3Nh2U2n5Oxp9Ds/+F1kKR0zwB+B4vKNEsDyQ4hju6Mu/k3MyWjK9T3bsWkApNln7cv+bigQ5lt6EnEjpCauxsXbgLt3SiH1/3ecAOnWTt46lc+pUNgb9Qx/rw9GvxjSX+RI5QfORRM5WAj+MjXq2l4/urta4a7ogSOiKe3uz1hrXMvmVYFPwCZ1adE6VZvs90DrSB4R5NMUoCQHhjAd52ImZqzVVsyL1583iEe0kyp5BMs/GJ5b x-ms-exchange-antispam-messagedata: Xw7D8R68emv2Sa5JrbNo0OPumoL29T93NpN4SImTi/T01xhQhHrczD+wlh5c1IGAcQlZtAA/75+IG4qkERJ9hgaVkbf3FjAcwC7Ht3B/jcq5rr0vzCE5wZcUTva6HB4Pkd4f42bGut8doCD12fV+CxilS3xgPE1nSSdRJ7jKHLDB941NTsuoJVQxCDVsQMTFSu4XBWBcm4IfZ2di8AgJJw== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 7ef21f8f-04f1-4cf6-c58d-08d7a8902acf X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Feb 2020 10:02:24.1292 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: wvk6wpLHCqfmKiO/26vnM7boXfU7aTtUeSPYMt1HkPEo2OEHa55evGCMEWqC27LTxjEuQWksssP/3qnrpeF0dw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB4366 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.12, xch-aln-002.cisco.com X-Outbound-Node: alln-core-10.cisco.com Archived-At: Subject: Re: [secdir] =?utf-8?q?=C3=89ric_Vyncke=27s_Discuss_on_draft-ietf-6l?= =?utf-8?q?o-ap-nd-13=3A_=28with_DISCUSS_and_COMMENT=29?= X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Feb 2020 10:02:33 -0000 SGVsbG8gQmVuamFtaW4NCg0KPiA+IENDJ2luZyBTRUMtRElSOiBQbGVhc2UgaGVscDogaWYgdGhl cmUgaXMgYSByZWZlcmVuY2UgZm9yIHRoYXQgcHJhY3RpY2UsIHdoYXQgaXQNCj4gPiB0YWtlcyB0 byBtYWludGFpbiBhIG5vbmNlLCBhbmQgd2h5IHdlIGhhdmUgYSBub25jZSBmcm9tIGJvdGggc2lk ZXM/IFRyeWluZw0KPiA+IHRvIHJlaW52ZW50IHRoYXQgdGV4dCBkb2VzIG5vdCBsb29rIGxpa2Ug YSBnb29kIGlkZWEgZm9yIHRoaXMgZHJhZnQuDQo+IA0KPiBJdCdzIHByZXR0eSBzdGFuZGFyZCwg c28gSSdtIG5vdCBzdXJlIHRoYXQgdGhlcmUncyBhIHBlcmZlY3QgcmVmZXJlbmNlIGZvciBpdC4g IEENCj4ga2V5IHBocmFzZSBpcyB0aGF0IGl0IHByb3ZpZGVzICJjb250cmlidXRvcnkgYmVoYXZp b3IiLCBzbyB0aGF0IGEgcGFydHkgKGVpdGhlcg0KPiBvbmUpIHRoYXQga25vd3MgaXQgaGFzIGEg Z29vZCBSTkcga25vd3MgdGhhdCB0aGUgcHJvdG9jb2wgd2lsbCBiZSBzZWN1cmUuDQoNCkdyZWF0 OiBJIG1vZGlmaWVkIHNlY3Rpb24gNi4xIHRvIGluY2x1ZGUgdGhpcyBpbmRpY2F0aW9uIGFzIGZv bGxvd3M6DQoNCiINCg0KICAgVGhlIDZMTiByZXBsaWVzIHRvIHRoZSBjaGFsbGVuZ2Ugd2l0aCBh biBOUyhFQVJPKSB0aGF0IGluY2x1ZGVzIGEgbmV3DQogICBOb25jZSBvcHRpb24gKHNob3duIGFz IE5vbmNlTE4gaW4gRmlndXJlIDUpLCB0aGUgQ0lQTyAoU2VjdGlvbiA0LjMpLA0KICAgYW5kIHRo ZSBORFBTTyBjb250YWluaW5nIHRoZSBzaWduYXR1cmUuICBCb3RoIE5vbmNlcyBhcmUgaW5jbHVk ZWQgaW4NCiAgIHRoZSBzaWduZWQgbWF0ZXJpYWwuICBUaGlzIHByb3ZpZGVzIGEgImNvbnRyaWJ1 dG9yeSBiZWhhdmlvciIsIHNvDQogICB0aGF0IGVpdGhlciBwYXJ0eSB0aGF0IGtub3dzIGl0IGdl bmVyYXRlcyBhIGdvb2QgcXVhbGl0eSBOb25jZSBrbm93cw0KICAgdGhhdCB0aGUgcHJvdG9jb2wg d2lsbCBiZSBzZWN1cmUuICBUaGUgaW5mb3JtYXRpb24gYXNzb2NpYXRlZCB0byBhDQogICBDcnlw dG8tSUQgc3RvcmVkIGJ5IHRoZSA2TFIgb24gdGhlIGZpcnN0IE5TIGV4Y2hhbmdlIHdoZXJlIGl0 DQogICBhcHBlYXJzLiAgVGhlIDZMUiBNVVNUIHN0b3JlIHRoZSBDSVBPIHBhcmFtZXRlcnMgYXNz b2NpYXRlZCB3aXRoIHRoZQ0KICAgQ3J5cHRvLUlEIHNvIGl0IGNhbiBiZSB1c2VkIGZvciBtb3Jl IHRoYW4gb25lIGFkZHJlc3MuDQoiDQoNCk1hbnkgdGhhbmtzIQ0KDQpQYXNjYWwNCg== From nobody Mon Feb 3 04:31:35 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57B2E1200B2; Mon, 3 Feb 2020 04:31:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.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 ph3f5Kn40S-I; Mon, 3 Feb 2020 04:31:32 -0800 (PST) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (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 1A229120098; Mon, 3 Feb 2020 04:31:32 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 48B6dJ0GXQz6GFdR; Mon, 3 Feb 2020 04:31:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1580733092; bh=caIxlNh9D9cAVpH/mgyJE4kkdnCpdwcMguOrlZgH/E0=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=F/EjjX2S3MQBhY3r9L43QB3ISHQDbgsyksTgR7rOlqaI6HkqdKWpY6ixEP/Cf1pbI VnSsKXLbB6knfGZg/1p5QQPZurdYzFI1inYWaxI/cRazdtzoPHpt0PQAOGT3fYP9Gh UqhOQSfyhx9f9kKmn8eo8eHdW2UFuVBvK/+UCR9c= X-Virus-Scanned: Debian amavisd-new at a2.tigertech.net Received: from [192.168.128.43] (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 48B6dG6YHZz6GDWq; Mon, 3 Feb 2020 04:31:30 -0800 (PST) To: Valery Smyslov , secdir@ietf.org Cc: last-call@ietf.org, draft-halpern-gendispatch-consensusinformational.all@ietf.org References: <158071519216.11324.2230466035276788626@ietfa.amsl.com> From: "Joel M. Halpern" Message-ID: <0b6d11ec-4631-574e-972f-866a6627c33c@joelhalpern.com> Date: Mon, 3 Feb 2020 07:31:27 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.4.2 MIME-Version: 1.0 In-Reply-To: <158071519216.11324.2230466035276788626@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [secdir] [Last-Call] Secdir last call review of draft-halpern-gendispatch-consensusinformational-02 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Feb 2020 12:31:33 -0000 Thank you Valery. Yours, Joel On 2/3/2020 2:33 AM, Valery Smyslov via Datatracker wrote: > Reviewer: Valery Smyslov > Review result: Ready > > Reviewer: Valery Smyslov > Review result: Ready > > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the > IESG. These comments were written primarily for the benefit of the > security area directors. Document editors and WG chairs should treat > these comments just like any other last call comments. > > The document doesn't describe any protocol, it only concerns with > IETF process. For this reason the document has no direct impact > on the security of IETF protocols. > > > From nobody Mon Feb 3 05:53:52 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08C9912009E for ; Mon, 3 Feb 2020 05:53:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mcafee.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 kuMcT4BVZ7PH for ; Mon, 3 Feb 2020 05:53:49 -0800 (PST) Received: from us-smtp-delivery-140.mimecast.com (us-smtp-delivery-140.mimecast.com [216.205.24.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 22C99120026 for ; Mon, 3 Feb 2020 05:53:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mcafee.com; s=mimecast20190606; t=1580738027; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type; bh=hklV6a/Mr2asYsU/LWPgYOgl39gLO1Fc/H1rhk0FxDg=; b=hC4uLrAsM5E0zu+f4fhkoHwgzV0pxcZK2uVmzAAZULSmrhi+6qr38x4v5PBve0rK01oxGe mCiXO3xUoOOdXRp5YFiLeIewwbiTrA/RUYt85x26/5+sV8h4S4AENdWDPxkJHjmOLlnLN4 9kKN6M3oVR+VP/cPl/rbx9a050rkaMM= Received: from NAM10-MW2-obe.outbound.protection.outlook.com (mail-mw2nam10lp2107.outbound.protection.outlook.com [104.47.55.107]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-11-HT0TbvKyNdewHyTFAcVHkA-1; Mon, 03 Feb 2020 08:53:41 -0500 Received: from CY4PR1601MB1254.namprd16.prod.outlook.com (10.172.118.12) by CY4PR1601MB1317.namprd16.prod.outlook.com (10.172.116.13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2686.32; Mon, 3 Feb 2020 13:53:38 +0000 Received: from CY4PR1601MB1254.namprd16.prod.outlook.com ([fe80::e851:20e8:57bd:fedd]) by CY4PR1601MB1254.namprd16.prod.outlook.com ([fe80::e851:20e8:57bd:fedd%12]) with mapi id 15.20.2686.028; Mon, 3 Feb 2020 13:53:38 +0000 From: "Konda, Tirumaleswar Reddy" To: "secdir@ietf.org" , "draft-ietf-6lo-fragment-recovery.all@ietf.org" Thread-Topic: Secdir last call review of draft-ietf-6lo-fragment-recovery-08 Thread-Index: AdXalCLFRlrAAOY/RCW/KaF9W1FCvA== Date: Mon, 3 Feb 2020 13:53:38 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.4.0.45 dlp-reaction: no-action x-originating-ip: [49.37.206.28] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 2c63dbfa-5b7c-4e99-4648-08d7a8b0788d x-ms-traffictypediagnostic: CY4PR1601MB1317: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-forefront-prvs: 0302D4F392 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(136003)(366004)(39860400002)(346002)(376002)(396003)(189003)(32952001)(199004)(66476007)(64756008)(66556008)(66446008)(52536014)(33656002)(66946007)(76116006)(5660300002)(9686003)(110136005)(450100002)(7696005)(55016002)(316002)(186003)(26005)(8936002)(81156014)(81166006)(86362001)(6506007)(478600001)(966005)(71200400001)(2906002)(8676002)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:CY4PR1601MB1317; H:CY4PR1601MB1254.namprd16.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: tytbOTPfUQWMaAySq25PDNFllp+iuQRPFYKVmHBgqgIb6Y8660JBwvd6/imZ78l8yt2dxXc2XKXvxvKMMlzAwwmn4P1t1if96NUyljdq4tGoLxaVH996jRad7RA7O39zdqleuglpxeSwWXvowWUlxuBbR3vX+UF6+TwNOjankrdhMrJV2PeFIDBRd8ZrTsX832kECt7q/TGiJdvrPykkPdNzZT+WezLHlFdOubJ0eAkoIE/72VX91blqmamRaEwrJpBuT+ny8DrYCrPl9Xkg+a0H0+nxoIfZU5mE76+ULoPP+gzF1XFf+u0eATP7euqPmGCtdvwpCq6UlJEvzQeouISnVAqtUFvS6L7JR8LkiBFZy4ORZqmrRlR5V+TSwqhrPJytsdRl33bGFv9sX7eQ2JuDDDWq2X5rNWvJLserdtIGvylqGeZPXZqcSeh52Pk0RBBvf2Jq5jpIWdfHTELJwixv1DLYVBx0wI6KtBxP2OX0Yw8mIAQeQO2OxoWpmPL4UnGyWVk4wG2dLrd9zNn7RoojEre+B71Mj0HtDO9G/CVWTc9lLehRRonsB9fFA45nRRSkH3aEB3sfIUASRhcOa11ts5OTzVwR+zejYE46TrE= x-ms-exchange-antispam-messagedata: +aYebAJZD2CknkCrouczuVcyWdI+KI3T7I5RqgS+rEV2ItvhIE+vPjtF6/YU+RTFtbOVOU/8gBluNKe1yAfcF0F+Pc/lj+MMGgq2nnzAqaQLEjwTom+N1ZH6MY7NxKyD99B1GFApltziRhcWtpPAdA== x-ms-exchange-transport-forked: True MIME-Version: 1.0 X-OriginatorOrg: mcafee.com X-MS-Exchange-CrossTenant-Network-Message-Id: 2c63dbfa-5b7c-4e99-4648-08d7a8b0788d X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Feb 2020 13:53:38.4510 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: y4VQ7dwujudICLVQmQ+TnN1GOXCgnbEV4E9DcwNnbRHeXbl//azkKiLdaW2nB4jnlL59xJ8VjL3upnL/v8JFUXO//7PuZFqcEJQZ03lv1bTO/xOrbkQTLs7vp/JxDNJ1 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR1601MB1317 X-MC-Unique: HT0TbvKyNdewHyTFAcVHkA-1 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: mcafee.com Content-Type: multipart/alternative; boundary="_000_CY4PR1601MB1254AAB128CD71BB283BDA72EA000CY4PR1601MB1254_" Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-6lo-fragment-recovery-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Feb 2020 13:53:51 -0000 --_000_CY4PR1601MB1254AAB128CD71BB283BDA72EA000CY4PR1601MB1254_ Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Reviewer: Tirumaleswar Reddy Review result: Ready with nits I have reviewed this document as part of the security directorate's ongoing= effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area = directors. Document editors and WG chairs should treat these comments just= like any other last call comments. Summary: Ready with nits [1] It is not clear to me how the Security sections of I-D.ietf-core-cocoa = apply to this specification ? [2] The security considerations section discusses I-D.ietf-lwig-6lowpan-vir= tual-reassembly but that document does not discuss any security considerati= ons yet. [3] It is not clear how the DoS attack of bogus first fragments is handled = and other attacks discussed in https://tools.ietf.org/html/draft-ietf-intar= ea-frag-fragile-17#section-3.7 are tackled ? [4] How does the document align with the recommendations given in https://t= ools.ietf.org/html/draft-ietf-intarea-frag-fragile-17#section-6 ? Cheers, -Tiru --_000_CY4PR1601MB1254AAB128CD71BB283BDA72EA000CY4PR1601MB1254_ Content-Type: text/html; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable

Reviewer: Tirumaleswar Reddy

Review result: Ready with nits

 

I have reviewed this document as part of the securit= y directorate's ongoing effort to review all IETF documents being processed= by the IESG.

These comments were written primarily for the benefi= t of the security area directors.  Document editors and WG chairs shou= ld treat these comments just like any other last call comments.<= /p>

 

Summary: Ready with nits

 

[1] It is not clear to me how the Security sections = of I-D.ietf-core-cocoa apply to this specification ?

[2] The security considerations section discusses I-= D.ietf-lwig-6lowpan-virtual-reassembly but that document does not discuss a= ny security considerations yet.

[3] It is not clear how the DoS attack of bogus firs= t fragments is handled and other attacks discussed in https://tools.ietf.org/html/draft-ietf-intarea-frag-fragile-17#section-3.7<= /a> are tackled ?

[4] How does the document align with the recommendat= ions given in https://tools.ietf.org/html/draft-ietf-intarea-frag-fragile-17#section-6 ?

 

Cheers,

-Tiru

--_000_CY4PR1601MB1254AAB128CD71BB283BDA72EA000CY4PR1601MB1254_-- From nobody Thu Feb 6 02:34:40 2020 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CF0C12001A for ; Thu, 6 Feb 2020 02:34:38 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Tero Kivinen via Datatracker To: X-Test-IDTracker: no X-IETF-IDTracker: 6.117.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: secdir-secretary@mit.edu, Tero Kivinen Message-ID: <158098527830.12180.15278715553775288272.idtracker@ietfa.amsl.com> Date: Thu, 06 Feb 2020 02:34:38 -0800 Archived-At: Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Feb 2020 10:34:38 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview For telechat 2020-02-06 Reviewer LC end Draft Roman Danyliw 2019-11-12 draft-ietf-dtn-bpbis-22 Russ Mundy 2020-01-02 draft-ietf-dprive-bcp-op-08 Stefan Santesson 2020-01-27 draft-ietf-dots-architecture-16 Last calls: Reviewer LC end Draft Shaun Cooley 2019-11-12 draft-ietf-regext-login-security-08 Roman Danyliw 2019-11-12 draft-ietf-dtn-bpbis-22 Alan DeKok 2019-06-04 draft-ietf-netvc-testing-09 Russ Mundy 2020-01-02 draft-ietf-dprive-bcp-op-08 Sandra Murphy 2019-10-04 draft-ietf-mpls-ldp-yang-06 Magnus Nystrom 2019-04-10 draft-ietf-avtcore-multiplex-guidelines-09 Kyle Rose 2020-01-29 draft-ietf-emu-rfc5448bis-06 Stefan Santesson 2020-01-27 draft-ietf-dots-architecture-16 Robert Sparks 2020-02-12 draft-ietf-dnssd-prireq-04 Takeshi Takahashi 2020-02-06 draft-ietf-mmusic-t140-usage-data-channel-11 Tina Tsou 2020-02-06 draft-ietf-6lo-backbone-router-13 Sean Turner None draft-ietf-opsawg-sdi-02 Dacheng Zhang 2019-11-05 draft-ietf-mpls-ri-rsvp-frr-07 Next in the reviewer rotation: Mališa Vučinić Carl Wallace David Waltermire Samuel Weiler Brian Weis Klaas Wierenga Christopher Wood Paul Wouters Liang Xia Dacheng Zhang From nobody Thu Feb 6 21:30:02 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E37412001B; Thu, 6 Feb 2020 21:29:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.748 X-Spam-Level: X-Spam-Status: No, score=-1.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no 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 UzQ5gdTXXWtT; Thu, 6 Feb 2020 21:29:55 -0800 (PST) Received: from mail-il1-x130.google.com (mail-il1-x130.google.com [IPv6:2607:f8b0:4864:20::130]) (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 E93D8120058; Thu, 6 Feb 2020 21:29:54 -0800 (PST) Received: by mail-il1-x130.google.com with SMTP id f10so672145ils.8; Thu, 06 Feb 2020 21:29:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=yADnkR/ou0fhxAvh9doASDpI+WHLBDlt91fN5ZrqqNQ=; b=aP+3KgVkHYrMc9Mdft2ljeBLe6uPJzl83cadkUF7ku5SkTKllzvNTiW17IU5c6gBuq +isOQvhuaJ9LUq5v6BeNWCl8JwaiBkYYS0y8EFjOXk2zKa1zlVrskYb8ob1taQZJi1E9 QI/X5kabJP6SqGI3fHF5M0cAxhrLJhm3cgByQ4I3NE4lsZ43jOPsCVdlZv8xQQb16kkX ZFFl8qiQfEtTD5Jg/VIkFsTRnMYN0u8v9qNIB7T4QBMhQj0FN4XriqqM+C7J9MWT3/3B uor9p0k2Roqe3V14Z0ood55Ac528FAORaRsCELx6cT6OmpAu8K0BywQmNYWG/66peqBE OUew== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=yADnkR/ou0fhxAvh9doASDpI+WHLBDlt91fN5ZrqqNQ=; b=IX6HwCtjt8KsWD7NHuOPzvW2s1tZ218H2jT2RuUSOSvo7XfpGNr9E/BQxICuALSShl 4v3/4N6eU2w00VCydm9JOeUcpWFVidFgvYXwcQaTEqrZVwyDZHn6PMqtGhoRyzwAbyRE WE8ZfHYD9e1X/4UmxBCcXeNuxZhflta5Rzhbese85bZa86hdnkHKSOtSV1TuRuLed4w9 Ez1iJs8DJdnU17nFOIf33Mb/uB8JAtIZhrRr8mURTvabyDVFYQNdaaRcLMtp+YKVBRCN TW0b7lzu8ITvjKwkjpVN7X6pchHCM4d2xa/J1y4qSBPsyf+BRsWGWMyGIaFzgwIiqpqV tmxw== X-Gm-Message-State: APjAAAWB7KmeaIvFQZysSyFgY/eC1Pfaw1CQiEoEAdm7Z+l0NogQw943 njLFRnnZkiACrgUORr0FGEivJKJgLoPI/T4ocwlHu/kj X-Google-Smtp-Source: APXvYqxwgQ/4IivCnxH1AST2b+yc7kmtvebpFzXOyiICbwZ0mDVzxkfsyGB7cr9chVrTvVqOC79eBlOTDE1Ig0KBrF0= X-Received: by 2002:a92:4e:: with SMTP id 75mr7454190ila.276.1581053394250; Thu, 06 Feb 2020 21:29:54 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Donald Eastlake Date: Fri, 7 Feb 2020 00:29:43 -0500 Message-ID: To: Robert Moskowitz Cc: draft-ietf-hip-dex.all@ietf.org, "iesg@ietf.org" , secdir , Miika Komu Content-Type: multipart/alternative; boundary="000000000000ef7346059df5add6" Archived-At: Subject: Re: [secdir] SECDIR Reveiw of draft-ietf-hip-dex-11 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Feb 2020 05:29:57 -0000 --000000000000ef7346059df5add6 Content-Type: text/plain; charset="UTF-8" Hi Bob, Sorry to delay in response... Changes look good to me with one little exception: On page 52, after the line beginning "Section 6", the next three lines are nicely indented but I believe the fourth line of text is sort of a continuation of the line beginning "Section 6" and so should not be specially indented but should be left justified lining up with the words "Section 6". Thanks, Donald =============================== Donald E. Eastlake 3rd +1-508-333-2270 (cell) 2386 Panoramic Circle, Apopka, FL 32703 USA d3e3e3@gmail.com On Mon, Jan 27, 2020 at 11:25 AM Robert Moskowitz wrote: > Donald, > > This is a partial update which I believe addresses your comments plus a > strong request to justify no PFS. > > Please check that I have indeed addressed your comments. > > More edits for other comments next. > > Bob > > On 1/20/20 11:18 PM, Donald Eastlake wrote: > > I have reviewed this document as (a very late) part of the security > directorate's ongoing effort to review all IETF documents being > processed by the IESG. > > The summary of the review is Ready with Nits. > > Sorry to get this review in so late but, while approved by the IESG, > the draft is still in revised draft needed state so this may do some > good. On the security front, although the draft is pretty complex and > I am not that familiar with HIP, I did not see any significant > security issues that were not already called out in the draft. So I > concentrated on possible editorial issues. > > Editorial: > > Section 1.1, 3rd paragraph, page 5. Delete "However," a the beginning > of the 2nd sentence. It doesn't make sense. > > Section 2.3, Definitions should be in alphabetic order. > > Section 2.3: It seems to me that people who are puzzled about what > something means are most likely to be puzzled by the acronym. So I > would put the acronym first, where there is an acronym or acronym-like > term to use, then the expansion in parenthesis or in the body of the > definition. This done for a couple of entries like CMAC and CKDF but > most are the other way. > > Section 3 last paragraph and Section 12.10 5th bullet: "to use" -> "use of" > > I think OGA and KEYMAT should be in the Definitions list and KEYMAT, > which I assume just is short for "keying material", should be expanded > on first use in Section 6.3. Alternatively, you could just replace all > occurrences of KEYMAT with "Keying Material". > > Section 5.3.2, page 23. The first sentence of the first paragraph > starting on that page has problems. Maybe "chose" should be "choses" > but I'm not sure: > "The DH_GROUP_LIST parameter contains the Responder's order of > preference based on which the Responder chose the ECDH key contained > in the HOST_ID parameter (see below)." > > Appendix A, first sentence, "allows to identify" -> "allows identifying" > > Appendix B, "IEDG" -> "IESG" > > Appendix B, around the middle of page 51, right after the line > beginning with "Section 6," there are three line with a blank line > before and after. I found this confusing at first. I suggest those > three line also be indented. > > Appendix B, page 52, "SHOUDS" -> "SHOUDs" > > Thanks, > Donald > =============================== > Donald E. Eastlake 3rd +1-508-333-2270 (cell) > 2386 Panoramic Circle, Apopka, FL 32703 USA > d3e3e3@gmail.com > > > -- > Robert Moskowitz > Owner > HTT Consulting > C: 248-219-2059 > F: 248-968-2824 > E: rgm@labs.htt-consult.com > > There's no limit to what can be accomplished if it doesn't matter who gets > the credit > --000000000000ef7346059df5add6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Bob,


On Mon, Jan 27, 2020 at 11:25 AM Robert Mos= kowitz <rgm@labs.htt-consult= .com> wrote:
=20 =20 =20
Donald,

This is a partial update which I believe addresses your comments plus a strong request to justify no PFS.

Please check that I have indeed addressed your comments.

More edits for other comments next.

Bob

On 1/20/20 11:18 PM, Donald Eastlake wrote:
I have reviewed this document as (a very late) part of the secur=
ity
directorate's ongoing effort to review all IETF documents being
processed by the IESG.

The summary of the review is Ready with Nits.

Sorry to get this review in so late but, while approved by the IESG,
the draft is still in revised draft needed state so this may do some
good. On the security front, although the draft is pretty complex and
I am not that familiar with HIP, I did not see any significant
security issues that were not already called out in the draft. So I
concentrated on possible editorial issues.

Editorial:

Section 1.1, 3rd paragraph, page 5. Delete "However," a the begin=
ning
of the 2nd sentence. It doesn't make sense.

Section 2.3, Definitions should be in alphabetic order.

Section 2.3: It seems to me that people who are puzzled about what
something means are most likely to be puzzled by the acronym. So I
would put the acronym first, where there is an acronym or acronym-like
term to use, then the expansion in parenthesis or in the body of the
definition. This done for a couple of entries like CMAC and CKDF but
most are the other way.

Section 3 last paragraph and Section 12.10 5th bullet: "to use" -=
> "use of"

I think OGA  and KEYMAT should be in the Definitions list and KEYMAT,
which I assume just is short for "keying material", should be exp=
anded
on first use in Section 6.3. Alternatively, you could just replace all
occurrences of KEYMAT with "Keying Material".

Section 5.3.2, page 23. The first sentence of the first paragraph
starting on that page has problems. Maybe "chose" should be "=
;choses"
but I'm not sure:
  "The DH_GROUP_LIST parameter contains the Responder's order of
   preference based on which the Responder chose the ECDH key contained
   in the HOST_ID parameter (see below)."

Appendix A, first sentence, "allows to identify" -> "allo=
ws identifying"

Appendix B, "IEDG" -> "IESG"

Appendix B, around the middle of page 51, right after the line
beginning with "Section 6," there are three line with a blank lin=
e
before and after. I found this confusing at first. I suggest those
three line also be indented.

Appendix B, page 52, "SHOUDS" -> "SHOUDs"

Thanks,
Donald
=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
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 2386 Panoramic Circle, Apopka, FL 32703 USA
 d3e3e3@gmail.com

--
=20 =20 Robert Moskowitz
Owner
HTT Consulting
C:=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0248-219-2059
F:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0248-968-2824
E:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0rgm@labs.htt-consult.com

There's no limit to what can be accomplished if it doesn't matter who gets the credit
--000000000000ef7346059df5add6-- From nobody Fri Feb 7 07:51:27 2020 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CDA9120907; Fri, 7 Feb 2020 07:51:19 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Robert Sparks via Datatracker To: Cc: draft-ietf-dnssd-prireq.all@ietf.org, last-call@ietf.org, dnssd@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.117.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Robert Sparks Message-ID: <158109067912.11622.15617540846660389050@ietfa.amsl.com> Date: Fri, 07 Feb 2020 07:51:19 -0800 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-dnssd-prireq-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Feb 2020 15:51:19 -0000 Reviewer: Robert Sparks Review result: Ready This is a combined genart and secdir last-call review. Please treat these comments just like any other last call comments. Document: draft-ietf-dnssd-prireq-04 Reviewer: Robert Sparks Review Date: 2020-02-07 IETF LC End Date: 2020-02-12 IESG Telechat date: Not scheduled for a telechat Summary: Ready (but with nits) for publication as an Informational RFC This document provides a set of high-level requirements for a DNS-SD privacy exptension, and discussion motivating those requirements. Comment: It might be good to call out in the discussion that while it is intended to be thorough, it's not possible to be exhaustive. Nits (editorial, in document order): The last sentence of the first paragraph of the introduction is complex. Consider breaking it apart. In the introduction at "When analyzing these scenarios in Section 3.2", did you mean Section 3.1? In the first sentence of 3.2 at "the scenarios in Section 2", did you mean Section 3.1? At the first sentence in 3.4.4, at "online" did you mean "on-link"? The statement in the second paragraph of section 4 is perhaps too strong. Consider changing "will lead" to "are intended to lead". The item numbering in sections 4.1 and 4.2 are messsed up. The intent of the next to last paragraph in 4.1 and the last paragraph in 4.2 could be made more clear. I suggest something like: "When listing and resolving services in current DNS-SD deployments". From nobody Fri Feb 7 09:56:28 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6421F1208BD; Fri, 7 Feb 2020 09:16:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1581095762; bh=bkFgbw0pPvWiHKKEuISg1XpUBO5K/c9Op/Us0AxjVzM=; h=From:To:Date:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe; b=FnREXcoVLfnz7b4SfzOShwhCLBR1j1fNiF36dbPsKPU/8jCT1/NdFdpBFxf0+sBhY a9GvDJvdwGeXBkJm5P2djAI+NPL86ZFaiIihPv/A65pt6PH4zmRagYNZHMLNnPs9dI 8e5TuumPS22oO5i2eHXf/Qs8Da1R3xSpZ9ZaFwhE= X-Mailbox-Line: From new-work-bounces@ietf.org Fri Feb 7 09:16:01 2020 Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AC9361200CC; Fri, 7 Feb 2020 09:16:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1581095761; bh=bkFgbw0pPvWiHKKEuISg1XpUBO5K/c9Op/Us0AxjVzM=; h=From:To:Date:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe; b=zVuUePWJzv/Txu5CrBrsmS8da0l08oErGM5su1Zy8TJCiVDp6zhrIzh8NMGs4FdOQ oGZD03DJp3RGrh5ErOpRZS1+WINzUnf4e6CvaVdFGmA35K8ElQm8cBywFJy5Cr1BsU dm2jefdhOvtytGDEBVv+wS9o8PBcbnSmiCutDeSM= X-Original-To: new-work@ietf.org Delivered-To: new-work@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 035861208A7 for ; Fri, 7 Feb 2020 09:15:59 -0800 (PST) MIME-Version: 1.0 From: The IESG To: X-Test-IDTracker: no X-IETF-IDTracker: 6.117.0 Auto-Submitted: auto-generated Precedence: bulk Reply_to: MIME-Version: 1.0 Message-ID: <158109575901.11589.12081546313734621765.idtracker@ietfa.amsl.com> Date: Fri, 07 Feb 2020 09:15:59 -0800 Archived-At: X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.29 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Errors-To: new-work-bounces@ietf.org Sender: "new-work" Archived-At: X-Mailman-Approved-At: Fri, 07 Feb 2020 09:56:26 -0800 Subject: [secdir] [new-work] WG Review: QUIC (quic) X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Feb 2020 17:16:05 -0000 VGhlIFFVSUMgKHF1aWMpIFdHIGluIHRoZSBUcmFuc3BvcnQgQXJlYSBvZiB0aGUgSUVURiBpcyB1 bmRlcmdvaW5nCnJlY2hhcnRlcmluZy4gVGhlIElFU0cgaGFzIG5vdCBtYWRlIGFueSBkZXRlcm1p bmF0aW9uIHlldC4gVGhlIGZvbGxvd2luZwpkcmFmdCBjaGFydGVyIHdhcyBzdWJtaXR0ZWQsIGFu ZCBpcyBwcm92aWRlZCBmb3IgaW5mb3JtYXRpb25hbCBwdXJwb3NlcyBvbmx5LgpQbGVhc2Ugc2Vu ZCB5b3VyIGNvbW1lbnRzIHRvIHRoZSBJRVNHIG1haWxpbmcgbGlzdCAoaWVzZ0BpZXRmLm9yZykg YnkKMjAyMC0wMi0xNy4KClFVSUMgKHF1aWMpCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCkN1cnJlbnQgc3RhdHVz OiBBY3RpdmUgV0cKCkNoYWlyczoKICBNYXJrIE5vdHRpbmdoYW0gPG1ub3RAbW5vdC5uZXQ+CiAg TGFycyBFZ2dlcnQgPGxhcnNAZWdnZXJ0Lm9yZz4KICBMdWNhcyBQYXJkdWUgPGx1Y2FzcGFyZHVl LjI0LjdAZ21haWwuY29tPgoKQXNzaWduZWQgQXJlYSBEaXJlY3RvcjoKICBNYWdudXMgV2VzdGVy bHVuZCA8bWFnbnVzLndlc3Rlcmx1bmRAZXJpY3Nzb24uY29tPgoKVHJhbnNwb3J0IEFyZWEgRGly ZWN0b3JzOgogIE1pcmphIEvDvGhsZXdpbmQgPGlldGZAa3VlaGxld2luZC5uZXQ+CiAgTWFnbnVz IFdlc3Rlcmx1bmQgPG1hZ251cy53ZXN0ZXJsdW5kQGVyaWNzc29uLmNvbT4KCk1haWxpbmcgbGlz dDoKICBBZGRyZXNzOiBxdWljQGlldGYub3JnCiAgVG8gc3Vic2NyaWJlOiBodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3F1aWMKICBBcmNoaXZlOiBodHRwczovL21haWxhcmNo aXZlLmlldGYub3JnL2FyY2gvYnJvd3NlL3F1aWMvCgpHcm91cCBwYWdlOiBodHRwczovL2RhdGF0 cmFja2VyLmlldGYub3JnL2dyb3VwL3F1aWMvCgpDaGFydGVyOiBodHRwczovL2RhdGF0cmFja2Vy LmlldGYub3JnL2RvYy9jaGFydGVyLWlldGYtcXVpYy8KClRoZSBRVUlDIHdvcmtpbmcgZ3JvdXAg d2lsbCBwcm92aWRlIHN0YW5kYXJkcy10cmFjayBzcGVjaWZpY2F0aW9ucyBmb3IgYQpVRFAtYmFz ZWQsIHN0cmVhbS1tdWx0aXBsZXhpbmcsIGVuY3J5cHRlZCB0cmFuc3BvcnQgcHJvdG9jb2wsIGJh c2VkIG9uCnByZS1zdGFuZGFyZGl6YXRpb24gaW1wbGVtZW50YXRpb24gYW5kIGRlcGxveW1lbnQg ZXhwZXJpZW5jZS4KCktleSBnb2FscyBmb3IgUVVJQyBhcmU6CgogLSBNaW5pbWl6aW5nIGNvbm5l Y3Rpb24gZXN0YWJsaXNobWVudCBhbmQgb3ZlcmFsbCB0cmFuc3BvcnQgbGF0ZW5jeSBmb3IKIGFw cGxpY2F0aW9ucywgc3RhcnRpbmcgd2l0aCBIVFRQOwoKIC0gUHJvdmlkaW5nIG11bHRpcGxleGlu ZyB3aXRob3V0IGhlYWQtb2YtbGluZSBibG9ja2luZzsKCiAtIFJlcXVpcmluZyBvbmx5IGNoYW5n ZXMgdG8gcGF0aCBlbmRwb2ludHMgdG8gZW5hYmxlIGRlcGxveW1lbnQ7CgogLSBFbmFibGluZyBt dWx0aXBhdGggYW5kIGZvcndhcmQgZXJyb3IgY29ycmVjdGlvbiBleHRlbnNpb25zOyBhbmQKCiAt IFByb3ZpZGluZyBhbHdheXMtc2VjdXJlIHRyYW5zcG9ydCwgdXNpbmcgVExTIDEuMyBieSBkZWZh dWx0LgoKVGhlIHdvcmsgb2YgdGhlIGdyb3VwIHdpbGwgaGF2ZSBmaXZlIG1haW4gZm9jdXMgYXJl YXMsIGNvcnJlc3BvbmRpbmcgdG8gZml2ZQpjb3JlIGRlbGl2ZXJhYmxlcy4KClRoZSBmaXJzdCBv ZiB0aGVzZSBpcyB0aGUgY29yZSB0cmFuc3BvcnQgd29yaywgd2hpY2ggd2lsbCBkZXNjcmliZSB0 aGUgd2lyZQpmb3JtYXQsIGFsb25nIHdpdGggdGhlIG1lY2hhbmlzbXMgZm9yIGNvbm5lY3Rpb24g ZXN0YWJsaXNobWVudCwgc3RyZWFtCm11bHRpcGxleGluZywgZGF0YSByZWxpYWJpbGl0eSwgbG9z cyBkZXRlY3Rpb24gYW5kIHJlY292ZXJ5LCBjb25nZXN0aW9uCmNvbnRyb2wsIGFuZCBvcHRpb25z IG5lZ290aWF0aW9uLiBXb3JrIG9uIGNvbmdlc3Rpb24gY29udHJvbCB3aWxsIGRlc2NyaWJlCnVz ZSBvZiBhIHN0YW5kYXJkaXplZCBjb25nZXN0aW9uIGNvbnRyb2xsZXIgYXMgYSBkZWZhdWx0IHNj aGVtZSBmb3IgUVVJQy4KRGVmaW5pbmcgbmV3IGNvbmdlc3Rpb24gY29udHJvbCBzY2hlbWVzIGlz IGV4cGxpY2l0bHkgb3V0IG9mIHNjb3BlIGZvciB0aGlzCmdyb3VwLiBRVUlDIGlzIGV4cGVjdGVk IHRvIHN1cHBvcnQgcmFwaWQsIGRpc3RyaWJ1dGVkIGRldmVsb3BtZW50IGFuZCB0ZXN0aW5nCm9m IGZlYXR1cmVzLgoKVGhlIHNlY29uZCBvZiB0aGVzZSBmb2N1cyBhcmVhcyBpcyBzZWN1cml0eS4g VGhpcyB3b3JrIHdpbGwgZGVzY3JpYmUgaG93IHRoZQpwcm90b2NvbCB1c2VzIFRMUyAxLjMgZm9y IGtleSBuZWdvdGlhdGlvbiBhbmQgd2lsbCBhbHNvIGRlc2NyaWJlIGhvdyB0aG9zZQprZXlzIGFy ZSB1c2VkIHRvIHByb3ZpZGUgY29uZmlkZW50aWFsaXR5IGFuZCBpbnRlZ3JpdHkgcHJvdGVjdGlv biBvZiBib3RoCmFwcGxpY2F0aW9uIGRhdGEgYW5kIFFVSUMgaGVhZGVycy4gVGhpcyB3b3JrIHdp bGwgZW5zdXJlIHRoYXQgUVVJQyBoYXMKc2VjdXJpdHkgYW5kIHByaXZhY3kgcHJvcGVydGllcyB0 aGF0IGFyZSBhdCBsZWFzdCBhcyBnb29kIGFzIGEgc3RhY2sgY29tcG9zZWQKb2YgVExTIDEuMyB1 c2luZyBUQ1AgKG9yIE1QVENQIHdoZW4gdXNpbmcgbXVsdGlwYXRoKS4KClRoZSB0aGlyZCBmb2N1 cyBhcmVhIGRlc2NyaWJlcyB0aGUgbWFwcGluZyBiZXR3ZWVuIHRoZSBIVFRQIGFwcGxpY2F0aW9u CnByb3RvY29sIGFuZCB0aGUgdHJhbnNwb3J0IGZhY2lsaXRpZXMgb2YgUVVJQy4gVGhpcyBtYXBw aW5nIHdpbGwgaGF2ZQpwZXJmb3JtYW5jZSBjaGFyYWN0ZXJpc3RpY3MgY29tcGFyYWJsZSB3aXRo IEhUVFAvMiwgYW5kIHByb3ZpZGUgZXh0ZW5zaW9uCm1lY2hhbmlzbXMgc2ltaWxhciB0byBIVFRQ LzIuIFVwb24gY29tcGxldGlvbiBvZiB0aGlzIG1hcHBpbmcsIHdvcmsgdG8gZGVmaW5lCmFkZGl0 aW9uYWwgbWFwcGluZ3MgbWF5IGJlIGluY2x1ZGVkIGJ5IHVwZGF0ZXMgdG8gdGhpcyBjaGFydGVy LCBvciBtYXkgYmUKd29ya2VkIG9uIGJ5IG90aGVyIHdvcmtpbmcgZ3JvdXBzLgoKVGhlIGZvdXJ0 aCBmb2N1cyBhcmVhIHdpbGwgYmUgb24gZXh0ZW5zaW9ucyB0byBjb3JlIHByb3RvY29sIGZhY2ls aXRpZXMsIHRvCmVuYWJsZSBkYXRhZ3JhbSBkZWxpdmVyeSwgdmVyc2lvbiBuZWdvdGlhdGlvbiwg YW5kIG11bHRpcGF0aCBjYXBhYmlsaXRpZXMuCk90aGVyIGV4dGVuc2lvbnMgYXJlIG91dCBvZiB0 aGUgc2NvcGUgb2YgdGhpcyBjaGFydGVyLgoKVGhlIGZpZnRoIGZvY3VzIGFyZWEgd2lsbCBwcm92 aWRlIGFuIEFwcGxpY2FiaWxpdHkgYW5kIE1hbmFnZWFiaWxpdHkKU3RhdGVtZW50LCBkZXNjcmli aW5nIGhvdywgYW5kIHVuZGVyIHdoYXQgY2lyY3Vtc3RhbmNlcywgUVVJQyBtYXkgYmUgc2FmZWx5 CnVzZWQsIGFuZCBkZXNjcmliaW5nIGRlcGxveW1lbnQgYW5kIG1hbmFnZWFiaWxpdHkgaW1wbGlj YXRpb25zIG9mIHRoZQpwcm90b2NvbC4gQWRkaXRpb25hbGx5LCB0aGUgV29ya2luZyBHcm91cCB3 aWxsIHByb3ZpZGUgZ3VpZGFuY2Ugb24gaG93IHRvCmhhbmRsZSBRVUlDIHRyYWZmaWMgaW4gbG9h ZCBiYWxhbmNlcnMuCgpDdXJyZW50IHByYWN0aWNlcyBmb3IgbmV0d29yayBtYW5hZ2VtZW50IG9m IHRyYW5zcG9ydCBwcm90b2NvbHMgaW5jbHVkZSB0aGUKYWJpbGl0eSB0byBhcHBseSBhY2Nlc3Mg Y29udHJvbCBsaXN0cyAoQUNMcyksIGhhc2hpbmcgb2YgZmxvd3MgZm9yIGVxdWFsLWNvc3QKbXVs dGlwYXRoIHJvdXRpbmcgKEVDTVApLCBkaXJlY3Rpb25hbCBzaWduYWxpbmcgb2YgZmxvd3MsIHNp Z25hbGluZyBvZiBmbG93CnNldHVwIGFuZCB0ZWFyZG93biwgYW5kIHRoZSBhYmlsaXR5IHRvIGV4 cG9ydCBpbmZvcm1hdGlvbiBhYm91dCBmbG93cyBmb3IKYWNjb3VudGluZyBwdXJwb3Nlcy4gVGhl IFFVSUMgcHJvdG9jb2wgbmVlZCBub3QgYmUgZGVmaW5lZCB0byBlbmFibGUgZWFjaCBvZgp0aGVz ZSBhYmlsaXRpZXMsIG9yIGVuYWJsZSB0aGVtIGluIHRoZSBzYW1lIHdheSBhcyB0aGV5IGFyZSBl bmFibGVkIGJ5IFRDUAp3aGVuIHVzZWQgd2l0aCBUTFMgMS4zLCBidXQgdGhlIHdvcmtpbmcgZ3Jv dXAgbXVzdCBjb25zaWRlciB0aGUgaW1wYWN0IG9mIHRoZQpwcm90b2NvbCBvbiBuZXR3b3JrIG1h bmFnZW1lbnQgcHJhY3RpY2VzLCByZWZsZWN0aW5nIHRoZSB0ZW5zaW9ucyBkZXNjcmliZWQKaW4g UkZDIDcyNTguCgpOb3RlIHRoYXQgY29uc2Vuc3VzIGlzIHJlcXVpcmVkIGJvdGggZm9yIGNoYW5n ZXMgdG8gdGhlIGN1cnJlbnQgcHJvdG9jb2wKbWVjaGFuaXNtcyBhbmQgcmV0ZW50aW9uIG9mIGN1 cnJlbnQgbWVjaGFuaXNtcy4gSW4gcGFydGljdWxhciwgYmVjYXVzZQpzb21ldGhpbmcgaXMgaW4g dGhlIGluaXRpYWwgZG9jdW1lbnQgc2V0IGRvZXMgbm90IGltcGx5IHRoYXQgdGhlcmUgaXMKY29u c2Vuc3VzIGFyb3VuZCB0aGUgZmVhdHVyZSBvciBhcm91bmQgaG93IGl0IGlzIHNwZWNpZmllZC4K ClRoZSBRVUlDIHdvcmtpbmcgZ3JvdXAgd2lsbCB3b3JrIGNsb3NlbHkgd2l0aCB0aGUgSFRUUGJp cyB3b3JraW5nIGdyb3VwLAplc3BlY2lhbGx5IG9uIHRoZSBRVUlDIG1hcHBpbmcgZm9yIEhUVFAu CgpNaWxlc3RvbmVzOgoKICBKdWwgMjAyMCAtIENvcmUgUHJvdG9jb2wgZG9jdW1lbnQgdG8gSUVT RwoKICBKdWwgMjAyMCAtIExvc3MgZGV0ZWN0aW9uIGFuZCBDb25nZXN0aW9uIENvbnRyb2wgZG9j dW1lbnQgdG8gSUVTRwoKICBKdWwgMjAyMCAtIFRMUyAxLjMgTWFwcGluZyBkb2N1bWVudCB0byBJ RVNHCgogIEp1bCAyMDIwIC0gSFRUUC8yIG1hcHBpbmcgZG9jdW1lbnQgdG8gSUVTRwoKICBKdWwg MjAyMCAtIFFVSUMgQXBwbGljYWJpbGl0eSBhbmQgTWFuYWdlYWJpbGl0eSBTdGF0ZW1lbnQgdG8g SUVTRwoKICBKdWwgMjAyMCAtIFZlcnNpb24tSW5kZXBlbmRlbnQgUHJvcGVydGllcyBvZiBRVUlD IHRvIElFU0cKCiAgSnVsIDIwMjAgLSBRUEFDSzogSGVhZGVyIENvbXByZXNzaW9uIGZvciBIVFRQ IG92ZXIgUVVJQyB0byBJRVNHCgogIERlYyAyMDIwIC0gV29ya2luZyBncm91cCBhZG9wdGlvbiBv ZiBNdWx0aXBhdGggZXh0ZW5zaW9uIGRvY3VtZW50CgogIE1hciAyMDIxIC0gRGF0YWdyYW0gRXh0 ZW5zaW9uIHRvIElFU0cKCiAgTWFyIDIwMjEgLSBWZXJzaW9uIE5lZ290aWF0aW9uIEV4dGVuc2lv biB0byBJRVNHCgogIERlYyAyMDIxIC0gTXVsdGlwYXRoIGV4dGVuc2lvbiBkb2N1bWVudCB0byBJ RVNHCgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KbmV3 LXdvcmsgbWFpbGluZyBsaXN0Cm5ldy13b3JrQGlldGYub3JnCmh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vbmV3LXdvcmsK From nobody Fri Feb 7 09:56:33 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AC5EC1208A8; Fri, 7 Feb 2020 09:20:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1581096036; bh=kNQyzC/Vr9J9FTvoD3SAL0F6m3aP1WfeATRLjmNIAwo=; h=From:To:Date:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe; b=C8COtWafGUbGTy3BJieaeqWHrKaNGsnWnQyC0FnXk3FTmABOYY5OA7g5EoW0KnWGg V/b2RMMdPDUGnJp8WkRxFe1UG46zVAdLr9YZjxpQjEv6TMh8K4CnpJ2bhtho7YRB5S P+djtT5scbyLHGRTtJk9/twAiflYNgwCBFssfRnw= X-Mailbox-Line: From new-work-bounces@ietf.org Fri Feb 7 09:20:33 2020 Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 168781208AF; Fri, 7 Feb 2020 09:20:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1581096032; bh=kNQyzC/Vr9J9FTvoD3SAL0F6m3aP1WfeATRLjmNIAwo=; h=From:To:Date:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe; b=lAX6Y+JPUgb9xrnhsqGCt3Nl9SbQK82nu6dmchQELTwFDyD5iSVPHBoH2CQuq7pHF X4KAJ1US05CP6RmJ8BObaa9ivvWYdXwzzA270hgUmAdQYjmaS6ynTtPf34vxtghcj8 5quqDK7GpuGuGSkmZfqQw2PHWH+aw2E2UrRNLw/4= X-Original-To: new-work@ietf.org Delivered-To: new-work@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BAD412098C for ; Fri, 7 Feb 2020 09:20:21 -0800 (PST) MIME-Version: 1.0 From: The IESG To: X-Test-IDTracker: no X-IETF-IDTracker: 6.117.0 Auto-Submitted: auto-generated Precedence: bulk Reply_to: MIME-Version: 1.0 Message-ID: <158109602130.11739.2560157846068050808.idtracker@ietfa.amsl.com> Date: Fri, 07 Feb 2020 09:20:21 -0800 Archived-At: X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.29 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: new-work-bounces@ietf.org Sender: "new-work" Archived-At: X-Mailman-Approved-At: Fri, 07 Feb 2020 09:56:26 -0800 Subject: [secdir] [new-work] WG Review: Adaptive DNS Discovery (add) X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Feb 2020 17:20:40 -0000 A new IETF WG has been proposed in the Applications and Real-Time Area. The IESG has not made any determination yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org) by 2020-02-17. Adaptive DNS Discovery (add) ----------------------------------------------------------------------- Current status: Proposed WG Chairs: David Lawrence Glenn Deen Assigned Area Director: Barry Leiba Applications and Real-Time Area Directors: Adam Roach Alexey Melnikov Barry Leiba Mailing list: Address: add@ietf.org To subscribe: https://www.ietf.org/mailman/listinfo/add Archive: https://mailarchive.ietf.org/arch/browse/add/ Group page: https://datatracker.ietf.org/group/add/ Charter: https://datatracker.ietf.org/doc/charter-ietf-add/ Adaptive DNS Discovery (ADD) ==================================== Proposed Working Group Charter Sending DNS messages over encrypted transports, as defined in DNS over TLS (DoT) [RFC 7858] and DNS over HTTPS (DoH) [RFC 8484], provides benefits to the security and privacy of DNS data. Clients, such as applications and host operating systems, have started adopting these protocols to provide these user benefits. This working group will focus on discovery and selection of DNS resolvers by DNS clients in a variety of networking environments, including public networks, private networks, and VPNs, supporting both encrypted and unencrypted resolvers. It is chartered solely to develop technical mechanisms. Making any recommendations about specific policies for clients or servers is out of scope. Clients adopting encrypted DNS protocols need to determine which DNS servers support those protocols, and which server to use for specific queries if multiple servers are available. These decisions can vary based on the network environment, and also based on the content and purpose of the client queries. Network operators that start offering DNS encryption on their servers also need a way to indicate this support to clients. Communicating information about resolver configuration and behavior allows clients to make more informed decisions about which DNS servers to use. For example, a resolver may be able to resolve private or local names as a split DNS server. The Adaptive DNS Discovery (ADD) working group will work on the following deliverables: - Define a mechanism that allows clients to discover DNS resolvers that support encryption and that are available to the client either on the public Internet or on private or local networks. - Define a mechanism that allows communication of DNS resolver information to clients for use in selection decisions. This could be part of the mechanism used for discovery, above. - Develop an informational document that describes mechanisms for clients to detect specific network environments (such as captive portal and split horizon) and to use that information to inform their DNS configuration. This working group will coordinate with dnsop, doh, and dprive for any changes required in DNS protocols and will make sure that those groups are included in major document reviews at appropriate times. It will also work with capport to ensure that solutions are applicable to captive networks. Milestones: TBD _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From nobody Fri Feb 7 11:32:20 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33F771208F8; Fri, 7 Feb 2020 11:32:15 -0800 (PST) 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_HELO_NONE=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 XRPM3ayz5etr; Fri, 7 Feb 2020 11:32:10 -0800 (PST) Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [23.123.122.147]) (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 9DB3A1208F6; Fri, 7 Feb 2020 11:32:10 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id B4419621AA; Fri, 7 Feb 2020 14:32:08 -0500 (EST) X-Virus-Scanned: amavisd-new at htt-consult.com Received: from z9m9z.htt-consult.com ([127.0.0.1]) by localhost (z9m9z.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id Vzmufi8cSafV; Fri, 7 Feb 2020 14:31:59 -0500 (EST) Received: from lx140e.htt-consult.com (unknown [192.168.160.12]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by z9m9z.htt-consult.com (Postfix) with ESMTPSA id 7A51662133; Fri, 7 Feb 2020 14:31:59 -0500 (EST) To: Donald Eastlake Cc: draft-ietf-hip-dex.all@ietf.org, "iesg@ietf.org" , secdir , Miika Komu References: From: Robert Moskowitz Message-ID: <085acebb-e929-4e10-186c-226eb04b10ea@labs.htt-consult.com> Date: Fri, 7 Feb 2020 14:31:52 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------C61E17714C1A9887AEDCF9E9" Content-Language: en-US Archived-At: Subject: Re: [secdir] SECDIR Reveiw of draft-ietf-hip-dex-11 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Feb 2020 19:32:15 -0000 This is a multi-part message in MIME format. --------------C61E17714C1A9887AEDCF9E9 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Donald, Thanks for the catch.  I got a little too rambunctious in my indenting.  :) On 2/7/20 12:29 AM, Donald Eastlake wrote: > Hi Bob, > > Sorry to delay in response... > > Changes look good to me with one little exception: On page 52, after > the line beginning "Section 6", the next three lines are nicely > indented but I believe the fourth line of text is sort of a > continuation of the line beginning "Section 6" and so should not be > specially indented but should be left justified lining up with the > words "Section 6". > > Thanks, > Donald > =============================== >  Donald E. Eastlake 3rd   +1-508-333-2270 (cell) >  2386 Panoramic Circle, Apopka, FL 32703 USA > d3e3e3@gmail.com > > > On Mon, Jan 27, 2020 at 11:25 AM Robert Moskowitz > > wrote: > > Donald, > > This is a partial update which I believe addresses your comments > plus a strong request to justify no PFS. > > Please check that I have indeed addressed your comments. > > More edits for other comments next. > > Bob > > On 1/20/20 11:18 PM, Donald Eastlake wrote: >> I have reviewed this document as (a very late) part of the security >> directorate's ongoing effort to review all IETF documents being >> processed by the IESG. >> >> The summary of the review is Ready with Nits. >> >> Sorry to get this review in so late but, while approved by the IESG, >> the draft is still in revised draft needed state so this may do some >> good. On the security front, although the draft is pretty complex and >> I am not that familiar with HIP, I did not see any significant >> security issues that were not already called out in the draft. So I >> concentrated on possible editorial issues. >> >> Editorial: >> >> Section 1.1, 3rd paragraph, page 5. Delete "However," a the beginning >> of the 2nd sentence. It doesn't make sense. >> >> Section 2.3, Definitions should be in alphabetic order. >> >> Section 2.3: It seems to me that people who are puzzled about what >> something means are most likely to be puzzled by the acronym. So I >> would put the acronym first, where there is an acronym or acronym-like >> term to use, then the expansion in parenthesis or in the body of the >> definition. This done for a couple of entries like CMAC and CKDF but >> most are the other way. >> >> Section 3 last paragraph and Section 12.10 5th bullet: "to use" -> "use of" >> >> I think OGA and KEYMAT should be in the Definitions list and KEYMAT, >> which I assume just is short for "keying material", should be expanded >> on first use in Section 6.3. Alternatively, you could just replace all >> occurrences of KEYMAT with "Keying Material". >> >> Section 5.3.2, page 23. The first sentence of the first paragraph >> starting on that page has problems. Maybe "chose" should be "choses" >> but I'm not sure: >> "The DH_GROUP_LIST parameter contains the Responder's order of >> preference based on which the Responder chose the ECDH key contained >> in the HOST_ID parameter (see below)." >> >> Appendix A, first sentence, "allows to identify" -> "allows identifying" >> >> Appendix B, "IEDG" -> "IESG" >> >> Appendix B, around the middle of page 51, right after the line >> beginning with "Section 6," there are three line with a blank line >> before and after. I found this confusing at first. I suggest those >> three line also be indented. >> >> Appendix B, page 52, "SHOUDS" -> "SHOUDs" >> >> Thanks, >> Donald >> =============================== >> Donald E. Eastlake 3rd +1-508-333-2270 (cell) >> 2386 Panoramic Circle, Apopka, FL 32703 USA >> d3e3e3@gmail.com > > -- > Robert Moskowitz > Owner > HTT Consulting > C: 248-219-2059 > F: 248-968-2824 > E: rgm@labs.htt-consult.com > > There's no limit to what can be accomplished if it doesn't matter > who gets the credit > -- Standard Robert Moskowitz Owner HTT Consulting C:248-219-2059 F:248-968-2824 E:rgm@labs.htt-consult.com There's no limit to what can be accomplished if it doesn't matter who gets the credit --------------C61E17714C1A9887AEDCF9E9 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Donald,

Thanks for the catch.  I got a little too rambunctious in my indenting.  :)

On 2/7/20 12:29 AM, Donald Eastlake wrote:
Hi Bob,

Sorry to delay in response...

Changes look good to me with one little exception: On page 52, after the line beginning "Section 6", the next three lines are nicely indented but I believe the fourth line of text is sort of a continuation of the line beginning "Section 6" and so should not be specially indented but should be left justified lining up with the words "Section 6".

Thanks,
Donald
===============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 2386 Panoramic Circle, Apopka, FL 32703 USA
 d3e3e3@gmail.com


On Mon, Jan 27, 2020 at 11:25 AM Robert Moskowitz <rgm@labs.htt-consult.com> wrote:
Donald,

This is a partial update which I believe addresses your comments plus a strong request to justify no PFS.

Please check that I have indeed addressed your comments.

More edits for other comments next.

Bob

On 1/20/20 11:18 PM, Donald Eastlake wrote:
I have reviewed this document as (a very late) part of the security
directorate's ongoing effort to review all IETF documents being
processed by the IESG.

The summary of the review is Ready with Nits.

Sorry to get this review in so late but, while approved by the IESG,
the draft is still in revised draft needed state so this may do some
good. On the security front, although the draft is pretty complex and
I am not that familiar with HIP, I did not see any significant
security issues that were not already called out in the draft. So I
concentrated on possible editorial issues.

Editorial:

Section 1.1, 3rd paragraph, page 5. Delete "However," a the beginning
of the 2nd sentence. It doesn't make sense.

Section 2.3, Definitions should be in alphabetic order.

Section 2.3: It seems to me that people who are puzzled about what
something means are most likely to be puzzled by the acronym. So I
would put the acronym first, where there is an acronym or acronym-like
term to use, then the expansion in parenthesis or in the body of the
definition. This done for a couple of entries like CMAC and CKDF but
most are the other way.

Section 3 last paragraph and Section 12.10 5th bullet: "to use" -> "use of"

I think OGA  and KEYMAT should be in the Definitions list and KEYMAT,
which I assume just is short for "keying material", should be expanded
on first use in Section 6.3. Alternatively, you could just replace all
occurrences of KEYMAT with "Keying Material".

Section 5.3.2, page 23. The first sentence of the first paragraph
starting on that page has problems. Maybe "chose" should be "choses"
but I'm not sure:
  "The DH_GROUP_LIST parameter contains the Responder's order of
   preference based on which the Responder chose the ECDH key contained
   in the HOST_ID parameter (see below)."

Appendix A, first sentence, "allows to identify" -> "allows identifying"

Appendix B, "IEDG" -> "IESG"

Appendix B, around the middle of page 51, right after the line
beginning with "Section 6," there are three line with a blank line
before and after. I found this confusing at first. I suggest those
three line also be indented.

Appendix B, page 52, "SHOUDS" -> "SHOUDs"

Thanks,
Donald
===============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 2386 Panoramic Circle, Apopka, FL 32703 USA
 d3e3e3@gmail.com

--
Robert Moskowitz
Owner
HTT Consulting
C:      248-219-2059
F:      248-968-2824
E:      rgm@labs.htt-consult.com

There's no limit to what can be accomplished if it doesn't matter who gets the credit

--
Standard Robert Moskowitz
Owner
HTT Consulting
C:      248-219-2059
F:      248-968-2824
E:      rgm@labs.htt-consult.com

There's no limit to what can be accomplished if it doesn't matter who gets the credit
--------------C61E17714C1A9887AEDCF9E9-- From nobody Sat Feb 8 22:29:16 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F8551200D5 for ; Sat, 8 Feb 2020 22:29:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=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 MkBjO_nAEGN2 for ; Sat, 8 Feb 2020 22:29:13 -0800 (PST) Received: from mx43-out1.antispamcloud.com (mx43-out1.antispamcloud.com [138.201.61.189]) (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 39F251200B3 for ; Sat, 8 Feb 2020 22:29:13 -0800 (PST) Received: from xse170.mail2web.com ([66.113.196.170] helo=xse.mail2web.com) by mx120.antispamcloud.com with esmtp (Exim 4.92) (envelope-from ) id 1j0g5e-000xfl-2C for secdir@ietf.org; Sun, 09 Feb 2020 07:29:10 +0100 Received: from xsmtp21.mail2web.com (unknown [10.100.68.60]) by xse.mail2web.com (Postfix) with ESMTPS id 48FfJN5LHVzkYK for ; Sat, 8 Feb 2020 22:29:08 -0800 (PST) Received: from [10.5.2.49] (helo=xmail11.myhosting.com) by xsmtp21.mail2web.com with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.92) (envelope-from ) id 1j0g5c-00013M-KE for secdir@ietf.org; Sat, 08 Feb 2020 22:29:08 -0800 Received: (qmail 16872 invoked from network); 9 Feb 2020 06:29:08 -0000 Received: from unknown (HELO [192.168.1.103]) (Authenticated-user:_huitema@huitema.net@[172.58.43.97]) (envelope-sender ) by xmail11.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 9 Feb 2020 06:29:08 -0000 To: Robert Sparks , secdir@ietf.org Cc: draft-ietf-dnssd-prireq.all@ietf.org, "last-call@ietf.org" , dnssd@ietf.org References: <158109067912.11622.15617540846660389050@ietfa.amsl.com> From: Christian Huitema Autocrypt: addr=huitema@huitema.net; prefer-encrypt=mutual; keydata= mQENBFIRX8gBCAC26usy/Ya38IqaLBSu33vKD6hP5Yw390XsWLaAZTeQR64OJEkoOdXpvcOS HWfMIlD5s5+oHfLe8jjmErFAXYJ8yytPj1fD2OdSKAe1TccUBiOXT8wdVxSr5d0alExVv/LO I/vA2aU1TwOkVHKSapD7j8/HZBrqIWRrXUSj2f5n9tY2nJzG9KRzSG0giaJWBfUFiGb4lvsy IaCaIU0YpfkDDk6PtK5YYzuCeF0B+O7N9LhDu/foUUc4MNq4K3EKDPb2FL1Hrv0XHpkXeMRZ olpH8SUFUJbmi+zYRuUgcXgMZRmZFL1tu6z9h6gY4/KPyF9aYot6zG28Qk/BFQRtj7V1ABEB AAG0J0NocmlzdGlhbiBIdWl0ZW1hIDxodWl0ZW1hQGh1aXRlbWEubmV0PokBOQQTAQIAIwUC UhFfyAIbLwcLCQgHAwIBBhUIAgkKCwQWAgMBAh4BAheAAAoJEJNDCbJVyA1yhbYH/1ud6x6m VqGIp0JcZUfSQO8w+TjugqxCyGNn+w/6Qb5O/xENxNQ4HaMQ5uSRK9n8WKKDDRSzwZ4syKKf wbkfj05vgFxrjCynVbm1zs2X2aGXh+PxPL/WHUaxzEP7KjYbLtCUZDRzOOrm+0LMktngT/k3 6+EZoLEM52hwwpIAzJoscyEz7QfqMOZtFm6xQnlvDQeIrHx0KUvwo/vgDLK3SuruG1CSHcR0 D24kEEUa044AIUKBS3b0b8AR7f6mP2NcnLpdsibtpabi9BzqAidcY/EjTaoea46HXALk/eJd 6OLkLE6UQe1PPzQC4jB7rErX2BxnSkHDw50xMgLRcl5/b1a5AQ0EUhFfyAEIAKp7Cp8lqKTV CC9QiAf6QTIjW+lie5J44Ad++0k8gRgANZVWubQuCQ71gxDWLtxYfFkEXjG4TXV/MUtnOliG 5rc2E+ih6Dg61Y5PQakm9OwPIsOx+2R+iSW325ngln2UQrVPgloO83QiUoi7mBJPbcHlxkhZ bd3+EjFxSLIQogt29sTcg2oSh4oljUpz5niTt69IOfZx21kf29NfDE+Iw56gfrxI2ywZbu5o G+d0ZSp0lsovygpk4jK04fDTq0vxjEU5HjPcsXC4CSZdq5E2DrF4nOh1UHkHzeaXdYR2Bn1Y wTePfaHBFlvQzI+Li/Q6AD/uxbTM0vIcsUxrv3MNHCUAEQEAAYkCPgQYAQIACQUCUhFfyAIb LgEpCRCTQwmyVcgNcsBdIAQZAQIABgUCUhFfyAAKCRC22tOSFDh1UOlBB/94RsCJepNvmi/c YiNmMnm0mKb6vjv43OsHkqrrCqJSfo95KHyl5Up4JEp8tiJMyYT2mp4IsirZHxz/5lqkw9Az tcGAF3GlFsj++xTyD07DXlNeddwTKlqPRi/b8sppjtWur6Pm+wnAHp0mQ7GidhxHccFCl65w uT7S/ocb1MjrTgnAMiz+x87d48n1UJ7yIdI41Wpg2XFZiA9xPBiDuuoPwFj14/nK0elV5Dvq 4/HVgfurb4+fd74PV/CC/dmd7hg0ZRlgnB5rFUcFO7ywb7/TvICIIaLWcI42OJDSZjZ/MAzz BeXm263lHh+kFxkh2LxEHnQGHCHGpTYyi4Z3dv03HtkH/1SI8joQMQq00Bv+RdEbJXfEExrT u4gtdZAihwvy97OPA2nCdTAHm/phkzryMeOaOztI4PS8u2Ce5lUB6P/HcGtK/038KdX5MYST Fn8KUDt4o29bkv0CUXwDzS3oTzPNtGdryBkRMc9b+yn9+AdwFEH4auhiTQXPMnl0+G3nhKr7 jvzVFJCRif3OAhEm4vmBNDE3uuaXFQnbK56GJrnqVN+KX5Z3M7X3fA8UcVCGOEHXRP/aubiw Ngawj0V9x+43kUapFp+nF69R53UI65YtJ95ec4PTO/Edvap8h1UbdEOc4+TiYwY1TBuIKltY 1cnrjgAWUh/Ucvr++/KbD9tD6C8= Message-ID: <1619adeb-50f7-cdc1-c08c-159bbcdd8ec5@huitema.net> Date: Sat, 8 Feb 2020 22:29:08 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 MIME-Version: 1.0 In-Reply-To: <158109067912.11622.15617540846660389050@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US X-Originating-IP: 66.113.196.170 X-Spampanel-Domain: xsmtpout.mail2web.com X-Spampanel-Username: 66.113.196.170/32 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=66.113.196.170/32@xsmtpout.mail2web.com X-Spampanel-Outgoing-Class: unsure X-Spampanel-Outgoing-Evidence: Combined (0.11) X-Recommended-Action: accept X-Filter-ID: Mvzo4OR0dZXEDF/gcnlw0S9sfM/nP8gxoqs1zeWkeM2pSDasLI4SayDByyq9LIhV2Ahkt42yLPuK dJjhmGk4mUTNWdUk1Ol2OGx3IfrIJKywOmJyM1qr8uRnWBrbSAGDcQkv3rfK9nOh84B6FNp+WsRX qYbtEQV1z/L435ZRxFT1CRBShAd7LKR1wL1sWm+t+rYZvu7UEJiU3s27VgKHO7lwS3dBJTnTxDoD vBGGxph9w6EwXICYy0ePXtGEMhqrP7W83ZalCLbuUenLlRfduGU6UgOqKJ9sMwhVoOBGSAIboXtx P9OF0EfNs5TqNq2Yhy7LI0kfFnXdPP6btp4oBeJDeKRq5oPj2hFJhLx+qI3HlR3ootg7OlA3N5WN re/oppAGOX5cHTu1yz4pRT/9FGrxEaaKeSxe0Wrx6M4G5/WoLsdfEoJI0BNUQ4KpaNyNCwGqOUcw rXf55E8Tb8bmXq4yH8StrboPphDtmrtUkwkDMc9xayd+oZJo2heFY+g6kVWClPVvbW5lVyQanRxw 5rdY2rW50fd1ekaDpmIWc1Vmt3mnxMTQMQWbvBqEXskTQn6USYs98Imn+lZXe3dwYfgVB1xo6dCf BaU/iegBU8Y4fWfVu/PU6c7RMIKlIhrz4WC0htBT0eIdZEXiwqm8sZm92nVBGvo1xj9oQ+Q699FX dU571qBU/d2sq9m7FB7HP8MofWJrrx8NNDBu7iiSz2kvZ+pWP1s35neRYWMQUWZErSs0X3oyoTc8 j/o7qulxEwT+7SWZnqfhaUMEF57OQGre/hsBBxzR0ZxLcHZ9dOjg9PQkkqraXKNSC3rAS2gcU5ai J+iXLGX0M6Jn3Qbp3QEH5tktsnhMr4gG+2qXrJ3sKT7Ng4M0hCvu+R6vZlk+9R/2gMGq0KWAzmMf +ibVDpdplkxcBm4XM6d7s4Bx3w1WbaUe4g0kgaInvdEp64qlVpe//bVkg87Xe61e30HXuSERbInM iTBIUBbQ/Dy6Ip4D1rnEhdYtY/lMQX5s39oH5ijcGdSK77ViXbmzTYWgl82XucjoLWQ7++7jcUS/ T5w= X-Report-Abuse-To: spam@quarantine11.antispamcloud.com Archived-At: Subject: Re: [secdir] [Last-Call] Secdir last call review of draft-ietf-dnssd-prireq-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Feb 2020 06:29:16 -0000 Thanks for the review, Robert. We will fix the nits in the next revision. -- Christian Huitema On 2/7/2020 7:51 AM, Robert Sparks via Datatracker wrote: > Reviewer: Robert Sparks > Review result: Ready > > This is a combined genart and secdir last-call review. > Please treat these comments just like any other last call comments. > > Document: draft-ietf-dnssd-prireq-04 > Reviewer: Robert Sparks > Review Date: 2020-02-07 > IETF LC End Date: 2020-02-12 > IESG Telechat date: Not scheduled for a telechat > > Summary: Ready (but with nits) for publication as an Informational RFC > > This document provides a set of high-level requirements for a DNS-SD > privacy exptension, and discussion motivating those requirements. > > Comment: > It might be good to call out in the discussion that while it is intended > to be thorough, it's not possible to be exhaustive. > > Nits (editorial, in document order): > > The last sentence of the first paragraph of the introduction is complex. > Consider breaking it apart. > > In the introduction at "When analyzing these scenarios in Section 3.2", > did you mean Section 3.1? > > In the first sentence of 3.2 at "the scenarios in Section 2", did you > mean Section 3.1? > > At the first sentence in 3.4.4, at "online" did you mean "on-link"? > > The statement in the second paragraph of section 4 is perhaps too strong. > Consider changing "will lead" to "are intended to lead". > > The item numbering in sections 4.1 and 4.2 are messsed up. > > The intent of the next to last paragraph in 4.1 and the last paragraph in 4.2 > could be made more clear. I suggest something like: "When listing and resolving > services in current DNS-SD deployments". > > > From nobody Mon Feb 10 08:03:59 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91ACF12008D; Sun, 9 Feb 2020 23:36:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.499 X-Spam-Level: X-Spam-Status: No, score=-14.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=HiCgev5p; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=Bb6BYoa0 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 Er_8eR8SHeLJ; Sun, 9 Feb 2020 23:36:08 -0800 (PST) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AAD15120077; Sun, 9 Feb 2020 23:36:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10881; q=dns/txt; s=iport; t=1581320168; x=1582529768; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=7owi2CIRJEyythgZZkCUeyh7HsCE7b4ZTzF1IsmBoSQ=; b=HiCgev5pJTCGWR2baMtR7nsEmH+Cezp8gcsaH6IuGDELphz2SCSbc1iZ 6jR2Fw5wgAunUOZ2Kkh7a8Pr2iTqQJNfQ19cjRexax0yAgmg2WgLxZhOu dqIUlWhZoxB50ORKdKU8XP7C31rDJrt6IfhnM7AVignYKNU5hs5gHKA34 I=; IronPort-PHdr: =?us-ascii?q?9a23=3AL77dThRxY+2GaSv1RzOh0FBWbtpsv++ubAcI9p?= =?us-ascii?q?oqja5Pea2//pPkeVbS/uhpkESXBNfA8/wRje3QvuigQmEG7Zub+FE6OJ1XH1?= =?us-ascii?q?5g640NmhA4RsuMCEn1NvnvOjQmHNlIWUV513q6KkNSXs35Yg6arw=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BLEACFB0Fe/4oNJK1mHAEBAQEBBwE?= =?us-ascii?q?BEQEEBAEBgXuBJS9QBWxYIAQLKodbA4p/TpU1DIRigUKBEANUCQEBAQwBASU?= =?us-ascii?q?IAgEBhEACgkQkOBMCAw0BAQQBAQECAQUEbYU3DIVnAgQSGxMBATgPAgEIRjI?= =?us-ascii?q?lAQEEARoagwWBfU0DLgECDKFzAoE5iGKCJ4J/AQEFhTYYggwDBoE4hR+EO4J?= =?us-ascii?q?JGoFBP4FYgkw+gmQBAQIBgSwBARIBIyuDFYIsjUIhiFyJf45IcAqCOodMgiy?= =?us-ascii?q?Mb4JIiBGLb4RHjmSIbJI5AgQCBAUCDgEBBYFpImdxcBWDJ1AYDY4dCRqDUIU?= =?us-ascii?q?UhT90AoEniw2CMgEB?= X-IronPort-AV: E=Sophos;i="5.70,424,1574121600"; d="scan'208,217";a="447625896" Received: from alln-core-5.cisco.com ([173.36.13.138]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 10 Feb 2020 07:36:06 +0000 Received: from XCH-ALN-004.cisco.com (xch-aln-004.cisco.com [173.36.7.14]) by alln-core-5.cisco.com (8.15.2/8.15.2) with ESMTPS id 01A7a5Ej020328 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 10 Feb 2020 07:36:06 GMT Received: from xhs-rtp-002.cisco.com (64.101.210.229) by XCH-ALN-004.cisco.com (173.36.7.14) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 10 Feb 2020 01:36:05 -0600 Received: from xhs-aln-001.cisco.com (173.37.135.118) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 10 Feb 2020 02:36:04 -0500 Received: from NAM12-DM6-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-001.cisco.com (173.37.135.118) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Mon, 10 Feb 2020 01:36:04 -0600 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=NOb4dHzzpwBo2tP3tW5P/+Dj8MSzT0gNDmXLQLS+/wyikKos2uHMIHcDyrsLM6cPw67jZpFzvfpCgq+P4jBGuD5MihZi5mpXz/xDtjYKStzZ2TlK2HHxoIpj47ytuVz43TIDRAyYGeUnQKLVoozHkNa2T0iutWfHqc3HBtlS29QPN/rs9l+rPDA0bPNCWWM+KbdzygVsk9kdYOe2/37FTicx+K1Abka4t99Bm0Vlaq2AL7hiA5zuRXMyyoharH5sQz4Pzz2w1UlYYN6X0uQxq24g4QjTWqOLuRqniRuQp+qj7u15jG4xizAEvM/eUi4Cd0Of8Iyf+Gk4hV1n5EWWnw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Ir5U6AAxB2THXu2qHAuCP/ffQYj60skcSgfSRhRLw+Q=; b=StmAPnOAiNfIv7GZrV1We/5a5xM1Do5KQLLSe13b2eeC/jUq8tivDSLegagktadpue+D5CJhlrjOAum1L/i4PHD2cCAxvrRpc4ah5tJ9tANgBHG89vKAVnKczw2n+G2eMoopax+6w10gzilnCsYZR1AQ3WUPvFr4tW+t5yzhibE27sSmuRHkzvLyWuVjTM/qRsX2YiVkGPlqBR+VCRK6wi6K2fpxZ9PxHV0MrOMBhKRe6NtCaQyEh78YGp8utymTYwWdmV7s0Y7laiqlJ/jBgG/i3kK72589HwOGAD1ZpGbRQExaiE3UedQs53VHmkWX9nKTKlpYmyFJOwNUQbcYkw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Ir5U6AAxB2THXu2qHAuCP/ffQYj60skcSgfSRhRLw+Q=; b=Bb6BYoa0TZNfbspboG6dcSJ9tXRSKu3OOdJf9Up3ehajTpG0oYhTnRfgiEyhwbUYGZNXkgQnbDy6ZDgvtuAFLaCG4PPDqHra8qbwqa1z0yM1qjcjEC98E+yTNdQAhkJIXiglxHHCPpMl2mxKNJqj3ALHW1gd1NTBwVlJ1JJtOxQ= Received: from MN2PR11MB3565.namprd11.prod.outlook.com (20.178.250.159) by MN2PR11MB3551.namprd11.prod.outlook.com (20.178.250.140) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2707.24; Mon, 10 Feb 2020 07:36:03 +0000 Received: from MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::fd76:1534:4f9a:452a]) by MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::fd76:1534:4f9a:452a%3]) with mapi id 15.20.2707.030; Mon, 10 Feb 2020 07:36:03 +0000 From: "Pascal Thubert (pthubert)" To: "Konda, Tirumaleswar Reddy" , "secdir@ietf.org" , "draft-ietf-6lo-fragment-recovery.all@ietf.org" Thread-Topic: Secdir last call review of draft-ietf-6lo-fragment-recovery-08 Thread-Index: AdXalCLFRlrAAOY/RCW/KaF9W1FCvAFSSLMw Date: Mon, 10 Feb 2020 07:35:46 +0000 Deferred-Delivery: Mon, 10 Feb 2020 07:04:24 +0000 Message-ID: References: In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=pthubert@cisco.com; x-originating-ip: [2a01:cb1d:4ec:2200:21c7:b739:ec9c:f622] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: b9ce06a2-9bd0-4c13-f716-08d7adfbe201 x-ms-traffictypediagnostic: MN2PR11MB3551: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 03094A4065 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(136003)(39860400002)(366004)(376002)(396003)(346002)(199004)(189003)(2906002)(478600001)(9686003)(55016002)(7696005)(71200400001)(6666004)(33656002)(86362001)(76116006)(316002)(66476007)(66946007)(64756008)(66446008)(66556008)(5660300002)(81166006)(966005)(52536014)(8936002)(110136005)(6506007)(81156014)(8676002)(186003); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB3551; H:MN2PR11MB3565.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: Pwdw7POhZEY8VVy0GUjglEZfb5yFuo/mg4X2iwd9qitK3Mp/wJnrFZdTFzxzAPDyX5qS61fExy+DURJcwPd6E5hx3xXU4WyHjKy03F3lRDSCbh1BrFuw/+ek+0AaCjVCbduhIQsidHN1JVqD+7RoRo2FMqmd3I2EOOkUBgF566CrVeLzkgaF0dA7UCu7VDUM4bCUsK2IkEXCcxOGUZcKNUCLzXWS844VWXf/carozhxaXEqr/IbDMUWyyrPjjP+MJrprUh5uMwjema/kjhHphT9b+x/PZGmTulfRY6X+5pWQHWu9nKnP5GcwGFF/rAKMnxkm3CTshTXxi0HuWDWslSzgIWBka8rft0EYb7EeaXGEzDlw8fJlIsOngP8jqM4yqe/Sk2tSE2YRcxQBAVCEWwlXkVJty/jkoXETNmn5qBFgEiUJEWTuvIoZDcDyvzRFIfAsUuKE496N5wEaQoq+rVySah9kfdQ8EeWg74i9U3yfJFFaXGJ4Jr1ymb4vLxT/ju4qFKNrZcPK9HttRNYNKA== x-ms-exchange-antispam-messagedata: 4oQY18lPkQA+XROr6PBjo6ZixPwyBq483cyzY6c8vO/a123xWjQpcMwNQRkwKjsFeYvXjCYDQ3R4epleV/7rfDBcGZ7pwTCPLcRsltzLb+ZGcMdSXI42zrC5vfdg0B+SK3E2Azi2+653p/ufaqGGzVykqE7FNYvzvSSGogoJvO4NGR01bje9KqiIkl4C9WSrWVQROYRIF7n4tHz4Gnpr/A== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_MN2PR11MB35652608BABFC6B1EB0B1A9FD8190MN2PR11MB3565namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: b9ce06a2-9bd0-4c13-f716-08d7adfbe201 X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Feb 2020 07:36:03.5671 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: pKFFVkSAmKIzMRbIo4od9xjSuw6oBe7o5ij9aHDd3+uK9v5ERl+fbb0SyaxDRDeQdAwKvW2wsIF7H+/JylKGQQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB3551 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.14, xch-aln-004.cisco.com X-Outbound-Node: alln-core-5.cisco.com Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-6lo-fragment-recovery-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Feb 2020 07:36:10 -0000 --_000_MN2PR11MB35652608BABFC6B1EB0B1A9FD8190MN2PR11MB3565namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello Tiru; Many thanks for your review! Please see below > [1] It is not clear to me how the Security sections of I-D.ietf-core-coco= a apply to this specification ? The specification depends on a Retransmission TimeOut (RTO) estimation that= can be attacked. Adding the reference to cocoa was a earlier review commen= t that we got. Cocoa computes an RTO in a similar type of network. I agreed= that the recommendation made sense but still, I can probably dig that emai= l and start a thread with the reviewer if you think it is irrelevant. > [2] The security considerations section discusses I-D.ietf-lwig-6lowpan-v= irtual-reassembly but that document does not discuss any security considera= tions yet. Correct. When it does I hope it describes the issue that this specification= discusses. In any fashion we use it to explain a difference: "here's a tra= ditional drawback of fragments and here's why it does not hurt us", as oppo= sed to an inheritance. If you think that the text is not helpful, we can open another thread on th= at. > [3] It is not clear how the DoS attack of bogus first fragments is handle= d and other attacks discussed in https://tools.ietf.org/html/draft-ietf-int= area-frag-fragile-17#section-3.7 are tackled ? They are not, apart from whatever protection we get from the requirement in= L2 security (we are talking about an homogeneous mesh). This section is hi= ghly relevant. This is all detailed in section 7 of draft-ietf-6lo-minimal-= fragment that this specification inherits. > [4] How does the document align with the recommendations given in https:/= /tools.ietf.org/html/draft-ietf-intarea-frag-fragile-17#section-6 ? Section 6 says that IP fragmentation should be avoided by new protocols. Th= is Is not IP fragmentation, it is lower layer. We cannot avoid it if we are= to support IPv6 that has a MIN MTU of 1280 bytes and the 6LoWPAN MTU is lo= wer than that, see RFC 4944. Please let me know if you have a recommendation for a change, I saw questio= ns but not real hiunt on how to act on them. Many thanks again! Pascal --_000_MN2PR11MB35652608BABFC6B1EB0B1A9FD8190MN2PR11MB3565namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello Tiru;

 

Many thanks for your review!

 

Please see below

 

> [1] It is not clear to me how the Security sections of I-D.ietf-core= -cocoa apply to this specification ?

 

The specification depends on a Retransmission TimeOut (RTO) = estimation that can be attacked. Adding the reference to cocoa was a earlie= r review comment that we got. Cocoa computes an RTO in a similar type of network. I agreed that the recommendation made= sense but still, I can probably dig that email and start a thread with the= reviewer if you think it is irrelevant.

 

> [2] The security considerations section discusses I-D.ietf-lwig-6low= pan-virtual-reassembly but that document does not discuss any security cons= iderations yet.

 

Correct. When it does I hope it describes the issue that thi= s specification discusses. In any fashion we use it to explain a difference= : “here’s a traditional drawback of fragments and here’s why it does not hurt us”, as opposed to an inherita= nce.

If you think that the text is not helpful, we can open anoth= er thread on that.

 

 

> [3] It is not clear how the DoS attack of bogus first f= ragments is handled and other attacks discussed in https://tools.ietf.org/html/draft-ietf-intarea-frag-fragile-17#section-3.7<= /a> are tackled ?

 

They are not, apart from whatever protection we get from the= requirement in L2 security (we are talking about an homogeneous mesh). Thi= s section is highly relevant. This is all detailed in section 7 of draft-ietf-6lo-minimal-fragment that this specifi= cation inherits.

 

> [4] How does the document align with the recommendations given in https://tools.ietf.org/html/draft-ietf-intarea-frag-fragile-17#section-6 ?

 

Section 6 says that IP fragmentation should be avoided by ne= w protocols. This Is not IP fragmentation, it is lower layer. We cannot avo= id it if we are to support IPv6 that has a MIN MTU of 1280 bytes and the 6LoWPAN MTU is lower than that, see RFC 49= 44.

 

Please let me know if you have a recommendation for a change= , I saw questions but not real hiunt on how to act on them.

 

Many thanks again!

 

Pascal

 

 

--_000_MN2PR11MB35652608BABFC6B1EB0B1A9FD8190MN2PR11MB3565namp_-- From nobody Mon Feb 10 08:04:37 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43B9E1200B2 for ; Mon, 10 Feb 2020 00:38:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mcafee.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 OrdJ6ux9FkFN for ; Mon, 10 Feb 2020 00:38:29 -0800 (PST) Received: from us-smtp-delivery-140.mimecast.com (us-smtp-delivery-140.mimecast.com [216.205.24.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA86312008C for ; Mon, 10 Feb 2020 00:38:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mcafee.com; s=mimecast20190606; t=1581323908; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=Q3FW3vWcwydo1rnw/OAaVHiNc5TZDcOL0fgRMb5bNZM=; b=EIKHgVhhaP+NWCqlJK7maT1CbfXU9iQna8n+pQIts62Cu+CNjAKkyiUn3tNxLSC4zrNOEc X7rn8N623gKQmJCAcIjt9TbjvzsonQ/uooQBaoAeAbEGJ0QAdUQRnJ8bxAhLWiRWHkbkq6 0J0JbmCsfHERS0083UToXVgxJdu0o5Y= Received: from NAM11-DM6-obe.outbound.protection.outlook.com (mail-dm6nam11lp2172.outbound.protection.outlook.com [104.47.57.172]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-171-j7vldyXpO0WhZXN4VsCWQQ-1; Mon, 10 Feb 2020 03:38:25 -0500 Received: from CY4PR1601MB1254.namprd16.prod.outlook.com (10.172.118.12) by CY4PR1601MB1160.namprd16.prod.outlook.com (10.172.115.138) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2707.21; Mon, 10 Feb 2020 08:38:23 +0000 Received: from CY4PR1601MB1254.namprd16.prod.outlook.com ([fe80::e851:20e8:57bd:fedd]) by CY4PR1601MB1254.namprd16.prod.outlook.com ([fe80::e851:20e8:57bd:fedd%12]) with mapi id 15.20.2707.028; Mon, 10 Feb 2020 08:38:23 +0000 From: "Konda, Tirumaleswar Reddy" To: "Pascal Thubert (pthubert)" , "secdir@ietf.org" , "draft-ietf-6lo-fragment-recovery.all@ietf.org" Thread-Topic: Secdir last call review of draft-ietf-6lo-fragment-recovery-08 Thread-Index: AdXalCLFRlrAAOY/RCW/KaF9W1FCvAFSSLMwAAIQbvA= Date: Mon, 10 Feb 2020 08:38:23 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.4.0.45 dlp-reaction: no-action x-originating-ip: [103.245.47.20] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: d5cc5d13-61fc-4de3-6bf0-08d7ae0496f8 x-ms-traffictypediagnostic: CY4PR1601MB1160: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 03094A4065 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(366004)(136003)(346002)(376002)(396003)(39860400002)(32952001)(189003)(199004)(33656002)(316002)(71200400001)(9326002)(52536014)(8936002)(81156014)(26005)(86362001)(81166006)(186003)(478600001)(2906002)(966005)(5660300002)(8676002)(53546011)(6506007)(76116006)(66946007)(55016002)(66476007)(64756008)(66446008)(66556008)(7696005)(110136005)(9686003)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:CY4PR1601MB1160; H:CY4PR1601MB1254.namprd16.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: Q4gSkDZRjdpwFxeXvwZIGyOgA/lgiS1LYvjyuLN6UvPnyNIbA3JSJEun4lTHe977dUj5k1Uwmb/ELFFJ4Bcr0FAzZwt7gnDjYsWdThJvMz++14XgR+XuSclwc4yVhhgafkJzeQ0He7wPYJ2AjOzJUx1ihHR1m2s7g8NUSqxxy88Ks8+/M4cunF1iY73wQpen2L+2DnEcDyWtbs137sFyUOvvRsCLC6rSvxUJxcKyI6DJxDqZdTkuEUrhsbyPDzjeXaT8Bwj1SbIhaQYcA4pO9fP6jio36i8Sb4MgGsYnABqbRqtv2e6ypsD+HlaLHJ6IuOXEdkCsjxfmJ0iMqmRfrnsjpX2Div3F5YfFVC6ZynorUzwjTU2BqH4/VJPQqJHYlMQIqq+VupDndW3DB/QT3pbKcmkC89We4QJ8O+vqPTf+EA9Hbywxa+Eyz4/e+QILtOt+rfGXdgNljcltBaFfQtoTaaHfEAgmCElKEW/G24MEoqBOSgNa1NWTJOiTLp1Uif2J45EsLSHIfYokzq/EbbNgeH9O797Kb/PTU5LfS5YwnozmgRq1W+c5QORGA9pDawKlM4Vpl9AIp8gi1qyP4Qy7bpenckrcMsjIaoT53DQ= x-ms-exchange-antispam-messagedata: yoi9TdRKVP5BtObkcPn3I0OE91M72JLYUuImAHkjHZHqa1oNcsTd3YHtJ9xhU9LnYEPT5IHJ9fIkF2C5SNZSBqgkRA3M8mKmG0kdkY6u7152OzT+uSkGcl6VPmM56zA7yIepUKVXF38gqN54bpcrEA== x-ms-exchange-transport-forked: True MIME-Version: 1.0 X-OriginatorOrg: mcafee.com X-MS-Exchange-CrossTenant-Network-Message-Id: d5cc5d13-61fc-4de3-6bf0-08d7ae0496f8 X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Feb 2020 08:38:23.1170 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: TaAZjotMZRQ4kjVu97ogCuXowOK8hyLCLYnXuk/XoSJA3J9Fji6rcT3oa/7x6Rk3ARK8cZ3/2Gk4c4rdU/VdS1IBbqWZvu4QJ4ZFajMcdhCCYzBBxdHekg6bjUcOA9dY X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR1601MB1160 X-MC-Unique: j7vldyXpO0WhZXN4VsCWQQ-1 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: mcafee.com Content-Type: multipart/alternative; boundary="_000_CY4PR1601MB1254EEDFF6B78FC0BC2BF3D0EA190CY4PR1601MB1254_" Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-6lo-fragment-recovery-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Feb 2020 08:38:32 -0000 --_000_CY4PR1601MB1254EEDFF6B78FC0BC2BF3D0EA190CY4PR1601MB1254_ Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Hi Pascal, Please see inline From: Pascal Thubert (pthubert) Sent: Monday, February 10, 2020 1:06 PM To: Konda, Tirumaleswar Reddy ; secdir@= ietf.org; draft-ietf-6lo-fragment-recovery.all@ietf.org Subject: RE: Secdir last call review of draft-ietf-6lo-fragment-recovery-08 CAUTION: External email. Do not click links or open attachments unless you = recognize the sender and know the content is safe. ________________________________ Hello Tiru; Many thanks for your review! Please see below > [1] It is not clear to me how the Security sections of I-D.ietf-core-coco= a apply to this specification ? The specification depends on a Retransmission TimeOut (RTO) estimation that= can be attacked. Adding the reference to cocoa was a earlier review commen= t that we got. Cocoa computes an RTO in a similar type of network. I agreed= that the recommendation made sense but still, I can probably dig that emai= l and start a thread with the reviewer if you think it is irrelevant. If coca is relevant, please add more details on how it is relevant. The sec= urity considerations in cocao is only discussing network access control to = prevent an attacker from dropping packets to eventually increase the RTO. > [2] The security considerations section discusses I-D.ietf-lwig-6lowpan-v= irtual-reassembly but that document does not discuss any security considera= tions yet. Correct. When it does I hope it describes the issue that this specification= discusses. In any fashion we use it to explain a difference: "here's a tra= ditional drawback of fragments and here's why it does not hurt us", as oppo= sed to an inheritance. If you think that the text is not helpful, we can open another thread on th= at. Thanks for the clarification. > [3] It is not clear how the DoS attack of bogus first fragments is handle= d and other attacks discussed in https://tools.ietf.org/html/draft-ietf-int= area-frag-fragile-17#section-3.7 are tackled ? They are not, apart from whatever protection we get from the requirement in= L2 security (we are talking about an homogeneous mesh). This section is hi= ghly relevant. This is all detailed in section 7 of draft-ietf-6lo-minimal-= fragment that this specification inherits. Okay. > [4] How does the document align with the recommendations given in https:/= /tools.ietf.org/html/draft-ietf-intarea-frag-fragile-17#section-6 ? Section 6 says that IP fragmentation should be avoided by new protocols. Th= is Is not IP fragmentation, it is lower layer. We cannot avoid it if we are= to support IPv6 that has a MIN MTU of 1280 bytes and the 6LoWPAN MTU is lo= wer than that, see RFC 4944. Got it. Cheers, -Tiru Please let me know if you have a recommendation for a change, I saw questio= ns but not real hiunt on how to act on them. Many thanks again! Pascal --_000_CY4PR1601MB1254EEDFF6B78FC0BC2BF3D0EA190CY4PR1601MB1254_ Content-Type: text/html; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable

Hi Pascal,

 

Please see inline

 

From: Pascal Thubert (pthubert) <pthubert@= cisco.com>
Sent: Monday, February 10, 2020 1:06 PM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com= >; secdir@ietf.org; draft-ietf-6lo-fragment-recovery.all@ietf.org
Subject: RE: Secdir last call review of draft-ietf-6lo-fragment-reco= very-08

 

CAUTION: External email. Do not click links or open attachments unless you recognize the sender and know the content is safe.<= /span><= /span>

 

Hello Tiru;

 

Many thanks for your review!

 

Please see below

 

> [1] It is not = clear to me how the Security sections of I-D.ietf-core-cocoa apply to this = specification ?

 

The specification depends on a Retransmission TimeOu= t (RTO) estimation that can be attacked. Adding the reference to cocoa was = a earlier review comment that we got. Cocoa computes an RTO in a similar ty= pe of network. I agreed that the recommendation made sense but still, I can probably dig that email and start a thread wit= h the reviewer if you think it is irrelevant.

 

If coca is relevant, please add more details on how = it is relevant. The security considerations in cocao is only discussing net= work access control to prevent an attacker from dropping packets to eventua= lly increase the RTO.

 

> [2] The securi= ty considerations section discusses I-D.ietf-lwig-6lowpan-virtual-reassembl= y but that document does not discuss any security considerations yet.<= /o:p>

 

Correct. When it does I hope it describes the issue = that this specification discusses. In any fashion we use it to explain a di= fference: “here’s a traditional drawback of fragments and here&= #8217;s why it does not hurt us”, as opposed to an inheritance.

If you think that the text is not helpful, we can op= en another thread on that.

 

Thanks for the clarification.

 

> [3] It is not clear how the DoS attack of bogus= first fragments is handled and other attacks discussed in https://tools.ietf.org/html/draft-ietf-intarea-frag-fragile-17#section-3.7<= /a> are tackled ?

 

They are not, apart from whatever protection we get = from the requirement in L2 security (we are talking about an homogeneous me= sh). This section is highly relevant. This is all detailed in section 7 of = draft-ietf-6lo-minimal-fragment that this specification inherits.

 

Okay.

 

> [4] How does t= he document align with the recommendations given in https://tools.ietf.org/html/draft-ietf-intarea-frag-fragile-17#section-6 ?

 

Section 6 says that IP fragmentation should be avoid= ed by new protocols. This Is not IP fragmentation, it is lower layer. We ca= nnot avoid it if we are to support IPv6 that has a MIN MTU of 1280 bytes an= d the 6LoWPAN MTU is lower than that, see RFC 4944.

 

Got it.

 

Cheers,

-Tiru

 

Please let me know if you have a recommendation for = a change, I saw questions but not real hiunt on how to act on them.

 

 

Many thanks again!

 

Pascal

 

 

--_000_CY4PR1601MB1254EEDFF6B78FC0BC2BF3D0EA190CY4PR1601MB1254_-- From nobody Mon Feb 10 08:06:40 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 172271200E5; Mon, 10 Feb 2020 04:18:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.499 X-Spam-Level: X-Spam-Status: No, score=-14.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=e7Bztd4k; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=erJaCnez 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 2ACpOlb58l6l; Mon, 10 Feb 2020 04:18:38 -0800 (PST) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 75D681200C7; Mon, 10 Feb 2020 04:18:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=29537; q=dns/txt; s=iport; t=1581337118; x=1582546718; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=J2BJ/MyGHGrvtg32qARYc67LNToZHI2bS/TLWSqTP8Q=; b=e7Bztd4kU1TK9J5l6UXOTgdXNLQzhDMgr7IsSsU5YZKPTmhgiBaroQk6 a3oJ98UjAi8DnTCwCMslN7RtJPba4QHFJ6oM8AMllwKVCdi4N79N/1PzX mPHpe9QooTVi+T3A3JdBFAej3ndByRitryIhsuh8FOyfCswv0CHAEnHP4 8=; IronPort-PHdr: =?us-ascii?q?9a23=3ArAn8lRZCkI8J3Bf66QXt/yj/LSx94ef9IxIV55?= =?us-ascii?q?w7irlHbqWk+dH4MVfC4el20gabRp3VvvRDjeee87vtX2AN+96giDgDa9QNMn?= =?us-ascii?q?1NksAKh0olCc+BB1f8KavycywnFslYSHdu/mqwNg5eH8OtL1A=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0B3EABcSUFe/4MNJK1mHAEBAQEBBwE?= =?us-ascii?q?BEQEEBAEBgXuBJS9QBWxYIAQLKodbA4sAToIRkySEboFCgRADVAkBAQEMAQE?= =?us-ascii?q?lCAIBAYRAAoJFJDgTAgMNAQEEAQEBAgEFBG2FNwyFZgEBAQMBEhsTAQE4BAs?= =?us-ascii?q?CAQgRBAEBIQEGBzIUCQgBAQQBEggagwWBfU0DDiABAgydZAKBOYgtNYIngn8?= =?us-ascii?q?BAQWFOxiCDAMGgTiFH4Q7gkkagUE/gRFHgkw+gmQBAQIBgSMJAQESASMMEQ4?= =?us-ascii?q?JgwyCLI09BRIGCYhcgkmHNo5IcAqCOodMgiyMb4JIiBEFi2qER40pgTuIbJI?= =?us-ascii?q?5AgQCBAUCDgEBBYFpImdxcBWDJ1AYDYEajQMJGoNQhRSFP3QCgSeLDYFTXwE?= =?us-ascii?q?B?= X-IronPort-AV: E=Sophos;i="5.70,424,1574121600"; d="scan'208,217";a="447785262" Received: from alln-core-1.cisco.com ([173.36.13.131]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 10 Feb 2020 12:18:36 +0000 Received: from XCH-RCD-002.cisco.com (xch-rcd-002.cisco.com [173.37.102.12]) by alln-core-1.cisco.com (8.15.2/8.15.2) with ESMTPS id 01ACIaFM009276 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 10 Feb 2020 12:18:36 GMT Received: from xhs-rtp-001.cisco.com (64.101.210.228) by XCH-RCD-002.cisco.com (173.37.102.12) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 10 Feb 2020 06:18:36 -0600 Received: from xhs-aln-002.cisco.com (173.37.135.119) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 10 Feb 2020 07:18:35 -0500 Received: from NAM10-MW2-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Mon, 10 Feb 2020 06:18:35 -0600 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=nP/LjBorCIZQkJC+PU/cFG0tsuEgs4d+lzic146/l8g3rXfwpiSfzq7NoXmSiDLOBe5tq6r/DQkKwa8j66+HQBqaAlhSPWOHrIt2HP+YOUiQZuYJLpiJVd8j+2rNC0kFrPYVHf3TWyvthKpYy3bpk4zgy9MWPAdWDw23Uca8wl3Rl/M2vyJgg/K0A+ylpqrg51qtvSYIxLIPCCZOWyuOz3uwGNgjkpy3C3DkINT/wlx9QhtN1tCDclpjpx9eOSaXZ9PA36GwRxlwYPi3jGPOrXJwioSyoibYPPpDtq9ejk9jwvqalurWO7qwpXvzvQwOgjLwlKeNuPjqnqc5BQJ4Ww== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=SbIe6Iuw5fRDqSNl99GI/j33wSeGj+vquTVz93rP60g=; b=aVSiOV2CLIkKUdqfSRJ0Ev5H+uD4MQlw7811lw0Dt7d9FIK+3iZucUitZsKoTqVhB6Z/YSkcNYed3yL3V3x5uHl+612fUO+NwTAhktrTOJmVfnUAC73T3Jh+o3K3CNbCE39LOGbgNnxCuPkikIYQ4Iv+ZFOAzHdIPZplombRebmTmNRf+viZnutRk/T9s5NoZ+PUHfgn7H18bEZOWAaQ5VAhId1r+X+BFcBmW70riFKV7T+UllrnC5Q1TxhCDlJMLUYJHnyVLZ1kG2pgEMXWoPmqvHBt+bfx7ViJgzYez1oeDRbi5pic9BULSZXZO8hxNKYue0ZeQVAQj0Mqb5JeAQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=SbIe6Iuw5fRDqSNl99GI/j33wSeGj+vquTVz93rP60g=; b=erJaCnezCFnu3iEJnPRydu5y8GOkALbvd5Qxn9/IA5M5CdZinqCi58Ghk9BUDSizSunWn99xspHgaiN5NJOzwZeICd2yifGPABMdsHP/Fe+2rQTX6nDh67cxIbQde4s9y4VKVUiZX6UytHpaOfdHEdcMc9MrO16voUQ++LV4UUY= Received: from MN2PR11MB3565.namprd11.prod.outlook.com (20.178.250.159) by MN2PR11MB4416.namprd11.prod.outlook.com (52.135.36.225) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2707.21; Mon, 10 Feb 2020 12:18:33 +0000 Received: from MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::fd76:1534:4f9a:452a]) by MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::fd76:1534:4f9a:452a%3]) with mapi id 15.20.2707.030; Mon, 10 Feb 2020 12:18:33 +0000 From: "Pascal Thubert (pthubert)" To: "Konda, Tirumaleswar Reddy" , "secdir@ietf.org" , "draft-ietf-6lo-fragment-recovery.all@ietf.org" Thread-Topic: Secdir last call review of draft-ietf-6lo-fragment-recovery-08 Thread-Index: AdXalCLFRlrAAOY/RCW/KaF9W1FCvAFSSLMwAAIQbvAABa7EcA== Date: Mon, 10 Feb 2020 12:18:12 +0000 Deferred-Delivery: Mon, 10 Feb 2020 12:17:59 +0000 Message-ID: References: In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=pthubert@cisco.com; x-originating-ip: [2a01:cb1d:4ec:2200:1177:ce8:44a5:7e4b] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: a6440b7f-7d9f-4a0f-21c7-08d7ae235907 x-ms-traffictypediagnostic: MN2PR11MB4416: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 03094A4065 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(136003)(39860400002)(346002)(396003)(366004)(376002)(199004)(189003)(5660300002)(110136005)(52536014)(66476007)(7696005)(2906002)(66446008)(64756008)(66556008)(966005)(478600001)(66946007)(76116006)(186003)(316002)(8676002)(8936002)(81166006)(81156014)(6666004)(86362001)(6506007)(9686003)(33656002)(55016002)(53546011)(71200400001); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB4416; H:MN2PR11MB3565.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: Cavd/Z6AmJs9HIkw9wCVL3aFt/DZAoVGjvPEag+rMmt5GnJ21ijDkL+nhd96RdTRROG0Lmxa6KhAdnAezBk35s8VT7p0d75JErKOi84sb1qtZxuC+Tm3/81iWwxHCGNSBznQUhZV+s85D+GKrJJgpVIKvu/BnK//ozTl7pFsaMQnkeM5jKF/1gqQ04moAJ3CbVKgSo/cfD5srjAduXUGwBCcAvt1XLiISNeirA+jdWgNM982FQjwQUxkImfhszbNv1dNCefATHFQ7Qrzzo955axvssDngCVS3mkueY/UtRTNvgJ2oBPdHEUj2P7FD29sNeeZ2VDnI8BJDzSr21C7e6jYE6WP2tvfmETbpfqAORToIx0vRNTnXaBakqqRwvd+usL5u2GoR0TSERriiFcOUkSDH7e05U804F+2tHQk82ybsV69KKgeWB7E26uUVF1ZnfzsEQCIAi3DzFE3W4vCOY0jIJvYab8jEVMRAqHtWQjTpmtXV3GXfYQ0MrKmNWMEH6OJHm3T27180a8B7w2w6Q== x-ms-exchange-antispam-messagedata: O8m1uYrIA4wQjMOXqAlCZ0iBaR3bPItq0eWcwQHHKNR6e5mLHwTa+YvzDz0jqdgWzCsOWSgxMCdpDpfh5YrBIYOMTYgBbQadRgf60QxmAXMgigaKncLk85rCvM+wqYwhQNB74vneWNrBc4g7etb65sZRT0OkZKNfPE+dF+q2v2LwsJ7CpEa0s4qudhEKEeotZHI57enCPTdJn9xovNL0WQ== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_MN2PR11MB35654B2E68BAE8C6B3BF46BBD8190MN2PR11MB3565namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: a6440b7f-7d9f-4a0f-21c7-08d7ae235907 X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Feb 2020 12:18:33.5303 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: w7mUS+4IlZP9TlzCu9Q6PqM6hKCt975vvR1Iywt+bEbEymkxLAQudeixd0WtHtsv0n5whnQ7AP6gdnkUAg7/QA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB4416 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.12, xch-rcd-002.cisco.com X-Outbound-Node: alln-core-1.cisco.com Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-6lo-fragment-recovery-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Feb 2020 12:18:42 -0000 --_000_MN2PR11MB35654B2E68BAE8C6B3BF46BBD8190MN2PR11MB3565namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello Tiru >>>[1] It is not clear to me how the Security sections of I-D.ietf-core-coc= oa apply to this specification ? >> The specification depends on a Retransmission TimeOut (RTO) estimation t= hat can be attacked. Adding the reference to cocoa was a earlier review com= ment that we got. Cocoa computes an RTO in a similar type of network. I agr= eed that the recommendation made sense but still, I can probably dig that e= mail and start a thread with the reviewer if you think it is irrelevant. > If coca is relevant, please add more details on how it is relevant. The s= ecurity considerations in cocao is only discussing network access control t= o prevent an attacker from dropping packets to eventually increase the RTO. Makes sense. I checked the status of cocoa and it appears stuck( IESG state Expired (IESG: Dead) ). Maybe the safest is to import the idea that we wanted to cover and avoid th= e reference. What about schanging the first 3 paragraphs as follows: " This document specifies an instantiation of a 6LoWPAN Fragment Forwarding technique. "On Forwarding 6LoWPAN Fragments over a Multihop IPv6 Network" [I-D.ietf-6lo-minimal-fragment] provides the generic description of Fragment Forwarding and this specification inherits from it. The generic considerations in the Security sections of [I-D.ietf-6lo-minimal-fragment] apply equally to this document. This specification does not recommend a particular algorithm for the estimation of the duration of the RTO that covers the detection of the loss of a fragment with the 'X' flag set; regardless, an attacker on the path may slow down or discard packets, which in turn can affect the throughput of fragmented packets. Compared to "Transmission of IPv6 Packets over IEEE 802.15.4 Networks" [RFC4944], this specification reduces the datagram_tag to 8 bits and the tag wraps faster than with [RFC4944]. But for a constrained network where a node is expected to be able to hold only one or a few large packets in memory, 256 is still a large number. Also, the acknowledgement mechanism allows cleaning up the state rapidly once the packet is fully transmitted or aborted. " Many thanks again, Tiru. Pascal From: Pascal Thubert (pthubert) > Sent: Monday, February 10, 2020 1:06 PM To: Konda, Tirumaleswar Reddy >; secdir@ietf.org= ; draft-ietf-6lo-fragment-recovery.all@ietf.org Subject: RE: Secdir last call review of draft-ietf-6lo-fragment-recovery-08 CAUTION: External email. Do not click links or open attachments unless you = recognize the sender and know the content is safe. ________________________________ Hello Tiru; Many thanks for your review! Please see below > [1] It is not clear to me how the Security sections of I-D.ietf-core-coco= a apply to this specification ? The specification depends on a Retransmission TimeOut (RTO) estimation that= can be attacked. Adding the reference to cocoa was a earlier review commen= t that we got. Cocoa computes an RTO in a similar type of network. I agreed= that the recommendation made sense but still, I can probably dig that emai= l and start a thread with the reviewer if you think it is irrelevant. If coca is relevant, please add more details on how it is relevant. The sec= urity considerations in cocao is only discussing network access control to = prevent an attacker from dropping packets to eventually increase the RTO. > [2] The security considerations section discusses I-D.ietf-lwig-6lowpan-v= irtual-reassembly but that document does not discuss any security considera= tions yet. Correct. When it does I hope it describes the issue that this specification= discusses. In any fashion we use it to explain a difference: "here's a tra= ditional drawback of fragments and here's why it does not hurt us", as oppo= sed to an inheritance. If you think that the text is not helpful, we can open another thread on th= at. Thanks for the clarification. > [3] It is not clear how the DoS attack of bogus first fragments is handle= d and other attacks discussed in https://tools.ietf.org/html/draft-ietf-int= area-frag-fragile-17#section-3.7 are tackled ? They are not, apart from whatever protection we get from the requirement in= L2 security (we are talking about an homogeneous mesh). This section is hi= ghly relevant. This is all detailed in section 7 of draft-ietf-6lo-minimal-= fragment that this specification inherits. Okay. > [4] How does the document align with the recommendations given in https:/= /tools.ietf.org/html/draft-ietf-intarea-frag-fragile-17#section-6 ? Section 6 says that IP fragmentation should be avoided by new protocols. Th= is Is not IP fragmentation, it is lower layer. We cannot avoid it if we are= to support IPv6 that has a MIN MTU of 1280 bytes and the 6LoWPAN MTU is lo= wer than that, see RFC 4944. Got it. Cheers, -Tiru Please let me know if you have a recommendation for a change, I saw questio= ns but not real hiunt on how to act on them. Many thanks again! Pascal --_000_MN2PR11MB35654B2E68BAE8C6B3BF46BBD8190MN2PR11MB3565namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello Tiru

 

 

>>>[1] It is not clear to me how the Security sections of I-D.= ietf-core-cocoa apply to this specification ?

 

>> The specification depends on a Retransmission TimeO= ut (RTO) estimation that can be attacked. Adding the reference to cocoa was= a earlier review comment that we got. Cocoa computes an RTO in a similar type of network. I agreed that the recommendation made= sense but still, I can probably dig that email and start a thread with the= reviewer if you think it is irrelevant.

 

> If coca is relevant, please add more details on how it = is relevant. The security considerations in cocao is only discussing networ= k access control to prevent an attacker from dropping packets to eventually increase the RTO. =

 

Makes sense. I checked the status of cocoa and it appears st= uck(

IESG st= ate

Expired (IESG: Dead)

).

Maybe the safest is to import the idea that we wanted to cov= er and avoid the reference.

 

What about schanging the first 3 paragraphs as follows:=

“

   This do= cument specifies an instantiation of a 6LoWPAN Fragment

   Forward= ing technique.  "On Forwarding 6LoWPAN Fragments over a

   Multiho= p IPv6 Network" [I-D.ietf-6lo-minimal-fragment] provides the

   generic= description of Fragment Forwarding and this specification

   inherit= s from it.  The generic considerations in the Security

   section= s of [I-D.ietf-6lo-minimal-fragment] apply equally to this

   documen= t.

 

   This sp= ecification does not recommend a particular algorithm for the

   estimat= ion of the duration of the RTO that covers the detection of

   the los= s of a fragment with the 'X' flag set; regardless, an attacker

   on the = path may slow down or discard packets, which in turn can<= /font>

   affect = the throughput of fragmented packets.

 

   Compare= d to "Transmission of IPv6 Packets over IEEE 802.15.4

   Network= s" [RFC4944], this specification reduces the datagram_tag to 8

   bits an= d the tag wraps faster than with [RFC4944].  But for a

   constra= ined network where a node is expected to be able to hold only

   one or = a few large packets in memory, 256 is still a large number.

   Also, t= he acknowledgement mechanism allows cleaning up the state=

   rapidly= once the packet is fully transmitted or aborted.<= /p>

 

 

“

 

Many thanks again, Tiru.

 

Pascal

 

 

 

From: Pascal Thubert (= pthubert) <pthubert@cisco.com&= gt;
Sent: Monday, February 10, 2= 020 1:06 PM
To: Konda, Tirumaleswar Redd= y <TirumaleswarRed= dy_Konda@McAfee.com>; secdir@ietf.org; draft-ietf-6lo-fragment-recovery.all@ietf.org
Subject: RE: Secdir last cal= l review of draft-ietf-6lo-fragment-recovery-08

 

CAUTION= : External email. Do not click links or open attachments unless you recogniz= e the sender and know the content is safe.

 

Hello Tiru;

 

Many thanks for your review!

 

Please see below

 

> [1] It is n= ot clear to me how the Security sections of I-D.ietf-core-cocoa apply to th= is specification ?

 

The specification depends on a Retransmission TimeOut (RTO) = estimation that can be attacked. Adding the reference to cocoa was a earlie= r review comment that we got. Cocoa computes an RTO in a similar type of network. I agreed that the recommendation made= sense but still, I can probably dig that email and start a thread with the= reviewer if you think it is irrelevant.

 

If coca is relevant, please add more details on how it is re= levant. The security considerations in cocao is only discussing network acc= ess control to prevent an attacker from dropping packets to eventually increase the RTO. =

 

> [2] The sec= urity considerations section discusses I-D.ietf-lwig-6lowpan-virtual-reasse= mbly but that document does not discuss any security considerations yet.

 

Correct. When it does I hope it describes the issue that thi= s specification discusses. In any fashion we use it to explain a difference= : “here’s a traditional drawback of fragments and here’s why it does not hurt us”, as opposed to an inherita= nce.

If you think that the text is not helpful, we can open anoth= er thread on that.

 

Thanks for the clarification.

 

> [3] It is not clear how the DoS attack of bogus first f= ragments is handled and other attacks discussed in https://tools.ietf.org/html/draft-ietf-intarea-frag-fragile-17#section-3.7<= /a> are tackled ?

 

They are not, apart from whatever protection we get from the= requirement in L2 security (we are talking about an homogeneous mesh). Thi= s section is highly relevant. This is all detailed in section 7 of draft-ietf-6lo-minimal-fragment that this specifi= cation inherits.

 

Okay.

 

> [4] How doe= s the document align with the recommendations given in https://tools.ietf.org/html/draft-ietf-intarea-frag-fragile-17#section-6 ?

 

Section 6 says that IP fragmentation should be avoided by ne= w protocols. This Is not IP fragmentation, it is lower layer. We cannot avo= id it if we are to support IPv6 that has a MIN MTU of 1280 bytes and the 6LoWPAN MTU is lower than that, see RFC 49= 44.

 

Got it.

 

Cheers,

-Tiru

 

Please let me know if you have a recommendation for a change= , I saw questions but not real hiunt on how to act on them.

 

 

Many thanks again!

 

Pascal

 

 

--_000_MN2PR11MB35654B2E68BAE8C6B3BF46BBD8190MN2PR11MB3565namp_-- From nobody Mon Feb 10 08:06:46 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52C941200C7 for ; Mon, 10 Feb 2020 04:25:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mcafee.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 Yy62MQzPkuS1 for ; Mon, 10 Feb 2020 04:25:35 -0800 (PST) Received: from us-smtp-delivery-140.mimecast.com (us-smtp-delivery-140.mimecast.com [63.128.21.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA7461200E5 for ; Mon, 10 Feb 2020 04:25:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mcafee.com; s=mimecast20190606; t=1581337533; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=KQ8Q8kB3fK41g4SjYpJSBYdy25jzWea+dV4pOb4sB58=; b=Tl83t7drUuRe8JpWdHOpGAC35ceA2gIgS2UPxgthNYCiZTDTI2iDTipu4G1xaaT55hB7gG Rp20ASZ3AqB21LBsaxdrQ1ArYEIvXFmi2is+/heC7Ay2W8MZNtz37Bhk8v6yNtYEvafSuN tg7kcbqVYo92e2d53KbYaJrZgO5swS0= Received: from NAM04-CO1-obe.outbound.protection.outlook.com (mail-co1nam04lp2055.outbound.protection.outlook.com [104.47.45.55]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-418-IzTuDsOrN4u-kGI-A999rw-1; Mon, 10 Feb 2020 07:25:25 -0500 Received: from CY4PR1601MB1254.namprd16.prod.outlook.com (10.172.118.12) by CY4PR1601MB1301.namprd16.prod.outlook.com (10.172.118.135) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2707.27; Mon, 10 Feb 2020 12:25:22 +0000 Received: from CY4PR1601MB1254.namprd16.prod.outlook.com ([fe80::e851:20e8:57bd:fedd]) by CY4PR1601MB1254.namprd16.prod.outlook.com ([fe80::e851:20e8:57bd:fedd%12]) with mapi id 15.20.2707.028; Mon, 10 Feb 2020 12:25:22 +0000 From: "Konda, Tirumaleswar Reddy" To: "Pascal Thubert (pthubert)" , "secdir@ietf.org" , "draft-ietf-6lo-fragment-recovery.all@ietf.org" Thread-Topic: Secdir last call review of draft-ietf-6lo-fragment-recovery-08 Thread-Index: AdXalCLFRlrAAOY/RCW/KaF9W1FCvAFSSLMwAAIQbvAABa7EcAAENPAg Date: Mon, 10 Feb 2020 12:25:21 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.4.0.45 dlp-reaction: no-action x-originating-ip: [49.37.206.28] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 45e53939-137c-4e67-d5e7-08d7ae244c81 x-ms-traffictypediagnostic: CY4PR1601MB1301: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 03094A4065 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(396003)(376002)(346002)(136003)(39860400002)(366004)(199004)(32952001)(189003)(2906002)(26005)(55016002)(8936002)(53546011)(86362001)(8676002)(71200400001)(478600001)(5660300002)(7696005)(52536014)(186003)(9686003)(66446008)(66556008)(81166006)(81156014)(110136005)(64756008)(6506007)(966005)(66946007)(33656002)(76116006)(66476007)(316002)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:CY4PR1601MB1301; H:CY4PR1601MB1254.namprd16.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: pVvrRuUX85LTPbU/0Ckb+WcEpuZpnO29HBxIaUnbjhASSsr8+jhxSzV4IYvIi6TtzxoASyUMJJzX6XL52wFOCmQBB1cOT6I5UBf+icXoQ9LEQp6C516HOTkRaBHvjdJJ+0an1wHPnntNF2UnE7cxgoMuXOQsiwMkwzCmPBo4bjRNM/kdj9644wHj2akZFxogzgki4gPc9vBjLhsX3jYQKm/LeScMPaDRtefOnFIJmb0srxtEO9rQ6OU2+wkNmUCekb98nogwu5X/At9dAEjG8N2nnUoOwpqiFdjL2bHu88LGojEJD0Kn41QcWGUtl6RjRJz8+3U7sGC3m2qW3EDgHDY0C/iBH8qyQZLitSellhf+BNbm2aX0L0dnyLOPpmNH5ili9seYW56D8kP1Kbgsg3ol0hyTRBGCUToY7w+YrRa/XIkTfZqzlvSNXgLJMqY5oJ6NpCUOVTYc4DDYNlXb7flz4f2Ub4GSHeIZ7RMBcl5h0rVKv6XyXED54Ejltq9x4upm2NHsDORHdNMZW9cTYRS/pDJ8KBJZ7vr8KHPRnsAnMNWipsT943ThX/ioOeIN8k/sq+KykedQ3svhh2QNLSGGRYxr6IxKIAvNLATWORo= x-ms-exchange-antispam-messagedata: qFyInyp25tj533NjKiUKQ1hMUYsfdmHfZWI3RuVHeeaKVM35u0RXAOMQYsUCabN53x3YHyJrEowCKYd7fTzLU+MhoDwE0cfcKItOP5Ya5oG985zm281ClkoqYVsZa5ZJGJIizEhleCcpcEORr0OEWw== x-ms-exchange-transport-forked: True MIME-Version: 1.0 X-OriginatorOrg: mcafee.com X-MS-Exchange-CrossTenant-Network-Message-Id: 45e53939-137c-4e67-d5e7-08d7ae244c81 X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Feb 2020 12:25:21.9418 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: a8mvx0U8G4987hb8nmZuCYvHMM13yX0ZvxbaIwTma7Y+SHr/KmKVdOJjLyAxSk9HDdBaWLxFKrWbK2dZI+GmkWjjdvdAMbc7owHxh+nKyCrDUecdKchWiBbAG0mw3OvU X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR1601MB1301 X-MC-Unique: IzTuDsOrN4u-kGI-A999rw-1 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: mcafee.com Content-Type: multipart/alternative; boundary="_000_CY4PR1601MB1254C5AF8FE1543EAAEC55F9EA190CY4PR1601MB1254_" Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-6lo-fragment-recovery-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Feb 2020 12:25:39 -0000 --_000_CY4PR1601MB1254C5AF8FE1543EAAEC55F9EA190CY4PR1601MB1254_ Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Thanks Pascal. Updated text looks good. Cheers, -Tiru From: Pascal Thubert (pthubert) Sent: Monday, February 10, 2020 5:48 PM To: Konda, Tirumaleswar Reddy ; secdir@= ietf.org; draft-ietf-6lo-fragment-recovery.all@ietf.org Subject: RE: Secdir last call review of draft-ietf-6lo-fragment-recovery-08 CAUTION: External email. Do not click links or open attachments unless you = recognize the sender and know the content is safe. ________________________________ Hello Tiru >>>[1] It is not clear to me how the Security sections of I-D.ietf-core-coc= oa apply to this specification ? >> The specification depends on a Retransmission TimeOut (RTO) estimation t= hat can be attacked. Adding the reference to cocoa was a earlier review com= ment that we got. Cocoa computes an RTO in a similar type of network. I agr= eed that the recommendation made sense but still, I can probably dig that e= mail and start a thread with the reviewer if you think it is irrelevant. > If coca is relevant, please add more details on how it is relevant. The s= ecurity considerations in cocao is only discussing network access control t= o prevent an attacker from dropping packets to eventually increase the RTO. Makes sense. I checked the status of cocoa and it appears stuck( IESG state Expired (IESG: Dead) ). Maybe the safest is to import the idea that we wanted to cover and avoid th= e reference. What about schanging the first 3 paragraphs as follows: " This document specifies an instantiation of a 6LoWPAN Fragment Forwarding technique. "On Forwarding 6LoWPAN Fragments over a Multihop IPv6 Network" [I-D.ietf-6lo-minimal-fragment] provides the generic description of Fragment Forwarding and this specification inherits from it. The generic considerations in the Security sections of [I-D.ietf-6lo-minimal-fragment] apply equally to this document. This specification does not recommend a particular algorithm for the estimation of the duration of the RTO that covers the detection of the loss of a fragment with the 'X' flag set; regardless, an attacker on the path may slow down or discard packets, which in turn can affect the throughput of fragmented packets. Compared to "Transmission of IPv6 Packets over IEEE 802.15.4 Networks" [RFC4944], this specification reduces the datagram_tag to 8 bits and the tag wraps faster than with [RFC4944]. But for a constrained network where a node is expected to be able to hold only one or a few large packets in memory, 256 is still a large number. Also, the acknowledgement mechanism allows cleaning up the state rapidly once the packet is fully transmitted or aborted. " Many thanks again, Tiru. Pascal From: Pascal Thubert (pthubert) > Sent: Monday, February 10, 2020 1:06 PM To: Konda, Tirumaleswar Reddy >; secdir@ietf.org= ; draft-ietf-6lo-fragment-recovery.all@ietf.org Subject: RE: Secdir last call review of draft-ietf-6lo-fragment-recovery-08 CAUTION: External email. Do not click links or open attachments unless you = recognize the sender and know the content is safe. ________________________________ Hello Tiru; Many thanks for your review! Please see below > [1] It is not clear to me how the Security sections of I-D.ietf-core-coco= a apply to this specification ? The specification depends on a Retransmission TimeOut (RTO) estimation that= can be attacked. Adding the reference to cocoa was a earlier review commen= t that we got. Cocoa computes an RTO in a similar type of network. I agreed= that the recommendation made sense but still, I can probably dig that emai= l and start a thread with the reviewer if you think it is irrelevant. If coca is relevant, please add more details on how it is relevant. The sec= urity considerations in cocao is only discussing network access control to = prevent an attacker from dropping packets to eventually increase the RTO. > [2] The security considerations section discusses I-D.ietf-lwig-6lowpan-v= irtual-reassembly but that document does not discuss any security considera= tions yet. Correct. When it does I hope it describes the issue that this specification= discusses. In any fashion we use it to explain a difference: "here's a tra= ditional drawback of fragments and here's why it does not hurt us", as oppo= sed to an inheritance. If you think that the text is not helpful, we can open another thread on th= at. Thanks for the clarification. > [3] It is not clear how the DoS attack of bogus first fragments is handle= d and other attacks discussed in https://tools.ietf.org/html/draft-ietf-int= area-frag-fragile-17#section-3.7 are tackled ? They are not, apart from whatever protection we get from the requirement in= L2 security (we are talking about an homogeneous mesh). This section is hi= ghly relevant. This is all detailed in section 7 of draft-ietf-6lo-minimal-= fragment that this specification inherits. Okay. > [4] How does the document align with the recommendations given in https:/= /tools.ietf.org/html/draft-ietf-intarea-frag-fragile-17#section-6 ? Section 6 says that IP fragmentation should be avoided by new protocols. Th= is Is not IP fragmentation, it is lower layer. We cannot avoid it if we are= to support IPv6 that has a MIN MTU of 1280 bytes and the 6LoWPAN MTU is lo= wer than that, see RFC 4944. Got it. Cheers, -Tiru Please let me know if you have a recommendation for a change, I saw questio= ns but not real hiunt on how to act on them. Many thanks again! Pascal --_000_CY4PR1601MB1254C5AF8FE1543EAAEC55F9EA190CY4PR1601MB1254_ Content-Type: text/html; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable

Thanks Pascal. Updated text looks good.

 

Cheers,

-Tiru

 

From: Pascal Thubert (pthubert) <pthubert@= cisco.com>
Sent: Monday, February 10, 2020 5:48 PM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com= >; secdir@ietf.org; draft-ietf-6lo-fragment-recovery.all@ietf.org
Subject: RE: Secdir last call review of draft-ietf-6lo-fragment-reco= very-08

 

CAUTION: External email. Do not click links or open attachments unless you recognize the sender and know the content is safe.<= /span><= /span>

 

Hello Tiru

 

 

>>>[1] It = is not clear to me how the Security sections of I-D.ietf-core-cocoa apply t= o this specification ?

 

>> The specification depends on a Retransmissi= on TimeOut (RTO) estimation that can be attacked. Adding the reference to c= ocoa was a earlier review comment that we got. Cocoa computes an RTO in a s= imilar type of network. I agreed that the recommendation made sense but still, I can probably dig that email and sta= rt a thread with the reviewer if you think it is irrelevant.

 

> If coca is relevant, please add more details on= how it is relevant. The security considerations in cocao is only discussin= g network access control to prevent an attacker from dropping packets to ev= entually increase the RTO.

 

Makes sense. I checked the status of cocoa and it ap= pears stuck(

IESG state

Expired (IESG: Dead)

).

Maybe the safest is to import the idea that we wante= d to cover and avoid the reference.

 

What about schanging the first 3 paragraphs as follo= ws:

“

   This document specifies an instantiation of a= 6LoWPAN Fragment

   Forwarding technique.  "On Forwardi= ng 6LoWPAN Fragments over a

   Multihop IPv6 Network" [I-D.ietf-6lo-min= imal-fragment] provides the

   generic description of Fragment Forwarding an= d this specification

   inherits from it.  The generic considera= tions in the Security

   sections of [I-D.ietf-6lo-minimal-fragment] a= pply equally to this

   document.

 

   This specification does not recommend a parti= cular algorithm for the

   estimation of the duration of the RTO that co= vers the detection of

   the loss of a fragment with the 'X' flag set;= regardless, an attacker

   on the path may slow down or discard packets,= which in turn can

   affect the throughput of fragmented packets.<= o:p>

 

   Compared to "Transmission of IPv6 Packet= s over IEEE 802.15.4

   Networks" [RFC4944], this specification = reduces the datagram_tag to 8

   bits and the tag wraps faster than with [RFC4= 944].  But for a

   constrained network where a node is expected = to be able to hold only

   one or a few large packets in memory, 256 is = still a large number.

   Also, the acknowledgement mechanism allows cl= eaning up the state

   rapidly once the packet is fully transmitted = or aborted.

 

 

“

 

Many thanks again, Tiru.

 

Pascal

 

 

 

From: Pascal Thubert (pthubert) <pthubert@cisco.com>
Sent: Monday, February 10, 2020 1:06 PM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com>; secdir@ietf.org; draft-ietf-6lo-fragment-recovery.all@ietf.org
Subject: RE: Secdir last call review of draft-ietf-6lo-fragment-reco= very-08

 

CAUTION: External email. Do not click links or open attachments unless you recognize the sender and know the content is safe.<= /span><= /span>

 

Hello Tiru;

 

Many thanks for your review!

 

Please see below

 

> [1] It is not = clear to me how the Security sections of I-D.ietf-core-cocoa apply to this = specification ?

 

The specification depends on a Retransmission TimeOu= t (RTO) estimation that can be attacked. Adding the reference to cocoa was = a earlier review comment that we got. Cocoa computes an RTO in a similar ty= pe of network. I agreed that the recommendation made sense but still, I can probably dig that email and start a thread wit= h the reviewer if you think it is irrelevant.

 

If coca is relevant, please add more details on how = it is relevant. The security considerations in cocao is only discussing net= work access control to prevent an attacker from dropping packets to eventua= lly increase the RTO.

 

> [2] The securi= ty considerations section discusses I-D.ietf-lwig-6lowpan-virtual-reassembl= y but that document does not discuss any security considerations yet.<= /o:p>

 

Correct. When it does I hope it describes the issue = that this specification discusses. In any fashion we use it to explain a di= fference: “here’s a traditional drawback of fragments and here&= #8217;s why it does not hurt us”, as opposed to an inheritance.

If you think that the text is not helpful, we can op= en another thread on that.

 

Thanks for the clarification.

 

> [3] It is not clear how the DoS attack of bogus= first fragments is handled and other attacks discussed in https://tools.ietf.org/html/draft-ietf-intarea-frag-fragile-17#section-3.7<= /a> are tackled ?

 

They are not, apart from whatever protection we get = from the requirement in L2 security (we are talking about an homogeneous me= sh). This section is highly relevant. This is all detailed in section 7 of = draft-ietf-6lo-minimal-fragment that this specification inherits.

 

Okay.

 

> [4] How does t= he document align with the recommendations given in https://tools.ietf.org/html/draft-ietf-intarea-frag-fragile-17#section-6 ?

 

Section 6 says that IP fragmentation should be avoid= ed by new protocols. This Is not IP fragmentation, it is lower layer. We ca= nnot avoid it if we are to support IPv6 that has a MIN MTU of 1280 bytes an= d the 6LoWPAN MTU is lower than that, see RFC 4944.

 

Got it.

 

Cheers,

-Tiru

 

Please let me know if you have a recommendation for = a change, I saw questions but not real hiunt on how to act on them.

 

 

Many thanks again!

 

Pascal

 

 

--_000_CY4PR1601MB1254C5AF8FE1543EAAEC55F9EA190CY4PR1601MB1254_-- From nobody Mon Feb 10 08:06:54 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 059DF1201CE; Mon, 10 Feb 2020 04:32:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.499 X-Spam-Level: X-Spam-Status: No, score=-14.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=magsXimD; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=DnCfgKT0 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 s8YTmErCnkBP; Mon, 10 Feb 2020 04:32:08 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0DFCD1201A3; Mon, 10 Feb 2020 04:32:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=36905; q=dns/txt; s=iport; t=1581337927; x=1582547527; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=0kbIOC67t8OS8S1WlUaQ+ay8u3JM4Xjfa6GiXT+/VJQ=; b=magsXimD3HyvxCxbgog9xD97tgvW5WAdiOlgkdJUWkRrFY10p0EWDRkO JSI+j0FM8x2GUX9UjiKBGHCODGy41qE7ZK0sZJCO5fQqpABDqgu99RsVZ uiKsARbCKH9RWC/Ci6U2F8DxRCfhyse4YbfNrR5rHrFkjdmgLlAU3kT/6 s=; IronPort-PHdr: =?us-ascii?q?9a23=3A7lKjAh1T3eRTJbtosmDT+zVfbzU7u7jyIg8e44?= =?us-ascii?q?YmjLQLaKm44pD+JxKGt+51ggrPWoPWo7JfhuzavrqoeFRI4I3J8RVgOIdJSw?= =?us-ascii?q?dDjMwXmwI6B8vQEVH7MfTndTASF8VZX1gj9Ha+YgBY?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BLFwDcS0Fe/4gNJK1mHQEBAQkBEQU?= =?us-ascii?q?FAYF7gSUvUAVsWCAECyqHWwOLAk6CEZMkhG6BQoEQA1QJAQEBDAEBJQgCAQG?= =?us-ascii?q?EQAKCRSQ4EwIDDQEBBAEBAQIBBQRthTcMhWYBAQEDARIbEwEBOAQLAgEIEQQ?= =?us-ascii?q?BASEBBgcyFAkIAQEEARIIGoMFgX1NAw4gAQIMnBkCgTmILTWCJ4J/AQEFgTM?= =?us-ascii?q?ChAYYggwDBoE4hR+EO4JJGoFBP4ERR4JMPoJkAQECARmBCgkBARIBIwwRDgm?= =?us-ascii?q?DDIIsjT0FEgYJiFyBBoFDhzaOSHAKgjqHTIIsjG+CSIgRBYtqhEeNKYE7iGy?= =?us-ascii?q?SOQIEAgQFAg4BAQWBaSJncXAVgydQGA2BGo0DCRqDUIUUhT90AoEniw2BU18?= =?us-ascii?q?BAQ?= X-IronPort-AV: E=Sophos;i="5.70,424,1574121600"; d="scan'208,217";a="718556957" Received: from alln-core-3.cisco.com ([173.36.13.136]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 10 Feb 2020 12:32:06 +0000 Received: from XCH-RCD-004.cisco.com (xch-rcd-004.cisco.com [173.37.102.14]) by alln-core-3.cisco.com (8.15.2/8.15.2) with ESMTPS id 01ACW6vh027033 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 10 Feb 2020 12:32:06 GMT Received: from xhs-aln-002.cisco.com (173.37.135.119) by XCH-RCD-004.cisco.com (173.37.102.14) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 10 Feb 2020 06:32:05 -0600 Received: from xhs-rcd-003.cisco.com (173.37.227.248) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 10 Feb 2020 06:32:05 -0600 Received: from NAM12-MW2-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-003.cisco.com (173.37.227.248) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Mon, 10 Feb 2020 06:32:05 -0600 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=IvsCiu0VKC1ElNxRd2vSeDM6bLYP1PV3Cv9OoLnjn0f6IGcQLhS9tqrdCe4Rzl5mlDA3rmr2n27bdyaUL1smw4+T2E6GF/PQMnRwcJCAfclSUKRUNQaqXzWprajtWOmxa8TINmyW6S9UuV6lzumITbSj91yf+illQfxHeVVCbHls4bs6lKtE2GMlzg2zxjPTDwRrIK8aavWPc3d7Rja/njWl7zjoiPMo8WG0a82RnlqzHQaG/dc+MrWJ49T0lCQs/dixdeQAk5oVKY3RcPbCfGk5pc70+DPcGsK9c9cuxt65PNmYSmBRABJgtA9/Pk0n4tadom3cxjPb4gJg+S7b7Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=G0GPMraIGSZCX8LupVPAKjFdKcrx+ESL92RnATNIYLg=; b=mIMv9l5ZrGtC0ejIOcUHNWOAX7AmQTL3QkH0EsN6aQ/V3lUlS3MijMs9JpxBF9wqMsFCTtOJijXxamRSrsFz69JZwtw6uk0og3vE1YvlWgH8WVZ3jHVKW/lN/RvcRsdz6f0QFiXBAFr/4GTsSwaxMW4SNd5jTqj+6++YQ/JRx6jBtcz0AHEMKom+W3xUm5HDnoLVk4wsfBminRi468QNKbLCJu5yO1T92cqDjIy2nQ4J62+UTbin7cKmSI+gIVYrrJwhqs5dBJ0vRw9V4PFwscv7cyM+/SqEz+boDWv6d4OoXsgW+mjOKRF94MmTT4CLtQqr2MHwOdC+ohhwOz/xnA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=G0GPMraIGSZCX8LupVPAKjFdKcrx+ESL92RnATNIYLg=; b=DnCfgKT0oCmUnkdgbMj4h04HGgDp0PSpA/XxxDBoclXNxJmXdNPxSOPapCpn55j/HL+4W7rS9Z1rKBVyzkx5mR2BD2GX7OwjWN95QSXAx8TlUBRFigtjINIFAQXz5cKgtkcnPJR2PShhzibxGjpyURAbK0aJ1GFQG/gir+jFOVg= Received: from MN2PR11MB3565.namprd11.prod.outlook.com (20.178.250.159) by MN2PR11MB4365.namprd11.prod.outlook.com (52.135.38.32) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2707.24; Mon, 10 Feb 2020 12:32:03 +0000 Received: from MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::fd76:1534:4f9a:452a]) by MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::fd76:1534:4f9a:452a%3]) with mapi id 15.20.2707.030; Mon, 10 Feb 2020 12:32:03 +0000 From: "Pascal Thubert (pthubert)" To: "Konda, Tirumaleswar Reddy" , "secdir@ietf.org" , "draft-ietf-6lo-fragment-recovery.all@ietf.org" Thread-Topic: Secdir last call review of draft-ietf-6lo-fragment-recovery-08 Thread-Index: AdXalCLFRlrAAOY/RCW/KaF9W1FCvAFSSLMwAAIQbvAABa7EcAAENPAgAAAaHwA= Date: Mon, 10 Feb 2020 12:31:59 +0000 Deferred-Delivery: Mon, 10 Feb 2020 12:31:46 +0000 Message-ID: References: In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=pthubert@cisco.com; x-originating-ip: [2a01:cb1d:4ec:2200:1177:ce8:44a5:7e4b] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 919974fb-46f9-444b-ff28-08d7ae253bc9 x-ms-traffictypediagnostic: MN2PR11MB4365: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 03094A4065 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(136003)(346002)(376002)(39860400002)(396003)(366004)(189003)(199004)(6666004)(71200400001)(76116006)(66574012)(5660300002)(52536014)(86362001)(66946007)(66476007)(64756008)(66446008)(6506007)(53546011)(33656002)(9686003)(66556008)(110136005)(7696005)(2906002)(55016002)(478600001)(316002)(81166006)(81156014)(8936002)(8676002)(966005)(186003); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB4365; H:MN2PR11MB3565.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: FyMhGj6TEBpomTZNXn+X/ortWJK3x4wzrM0sLptg8I9Ye4J8lSoBL6TxWEJyjG2Awa6HMEYPh1UbsRA8kpcrPr5sitzsptKsvJh3FRTTC/yO7WZc1GubDo72zJyzZA8uNo5JUC/LDUhSxepP33RanS16AEA8w1hG7MaUL2dNlRttt5pSErVSa1X2ZutP6tuWE/JQrqNRhjltgjEv//S+chOXpvaoQbisbQ1QCR+iBj7H/Vmq5Xmkb5DLIiHAb6TrDmq9G8wetW6yUzxbe7JLroNF7VH49t7CpWroZT7Dih+HOpuRKOjYPv22aiHt2fzPBxnOuCtpheHc+4lbs7mRKxpExTcTE/mTS7VSF2FAAtMc2aGJk9Qi67lfKgrDZmjHSXXTWKAM1+5adY+BU7lPwOM3MwZlbRkY7KERGPg8AUanN1c3lv6e/BhqaU86aHAFcS178pTxFy0mCsp0lbEzds0uMUDTTc+C36kZA19hESIfumyp4K2aR8mTcV3x7yLMmsT9Sz9gPdXmd08qekwm+g== x-ms-exchange-antispam-messagedata: uaQhKTdhEI5q0gOkDIuKZ2sj4sntael5I3Eu/0/nOiup9GszLHNeC2IAhs9v+Uczx/xYOygqamBIds5v6CdhvvmOsvfHRFxr6vSpsMVfEn0c5CdTVuwxsmpzY2qBjoAf7Pp1OzNE9XOP1HRjmIqpfUB1usYJKkCVXxDuituyht7YHj5pxa/FBzoKhLRqHEMQog1REi2CpHYR22BEiqVk1w== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_MN2PR11MB3565C3CF04D7F17F70504449D8190MN2PR11MB3565namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 919974fb-46f9-444b-ff28-08d7ae253bc9 X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Feb 2020 12:32:03.5381 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: Ft+8obbwAC5x4PiTimoFT/BmykSHgnSHeWcd4gFPwmoWk+8qxR+3c7c0F3P4u9+JULsanLZEqgmwXU4bpsZxXg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB4365 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.14, xch-rcd-004.cisco.com X-Outbound-Node: alln-core-3.cisco.com Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-6lo-fragment-recovery-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Feb 2020 12:32:11 -0000 --_000_MN2PR11MB3565C3CF04D7F17F70504449D8190MN2PR11MB3565namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Great! I posted v11. The diffs are visible here https://www.ietf.org/rfcdiff?url2= =3Ddraft-ietf-6lo-fragment-recovery-11. Please let me know if I missed something. Many thanks again, Tiru. Pascal From: Konda, Tirumaleswar Reddy Sent: lundi 10 f=E9vrier 2020 13:25 To: Pascal Thubert (pthubert) ; secdir@ietf.org; draft-= ietf-6lo-fragment-recovery.all@ietf.org Subject: RE: Secdir last call review of draft-ietf-6lo-fragment-recovery-08 Thanks Pascal. Updated text looks good. Cheers, -Tiru From: Pascal Thubert (pthubert) > Sent: Monday, February 10, 2020 5:48 PM To: Konda, Tirumaleswar Reddy >; secdir@ietf.org= ; draft-ietf-6lo-fragment-recovery.all@ietf.org Subject: RE: Secdir last call review of draft-ietf-6lo-fragment-recovery-08 CAUTION: External email. Do not click links or open attachments unless you = recognize the sender and know the content is safe. ________________________________ Hello Tiru >>>[1] It is not clear to me how the Security sections of I-D.ietf-core-coc= oa apply to this specification ? >> The specification depends on a Retransmission TimeOut (RTO) estimation t= hat can be attacked. Adding the reference to cocoa was a earlier review com= ment that we got. Cocoa computes an RTO in a similar type of network. I agr= eed that the recommendation made sense but still, I can probably dig that e= mail and start a thread with the reviewer if you think it is irrelevant. > If coca is relevant, please add more details on how it is relevant. The s= ecurity considerations in cocao is only discussing network access control t= o prevent an attacker from dropping packets to eventually increase the RTO. Makes sense. I checked the status of cocoa and it appears stuck( IESG state Expired (IESG: Dead) ). Maybe the safest is to import the idea that we wanted to cover and avoid th= e reference. What about schanging the first 3 paragraphs as follows: " This document specifies an instantiation of a 6LoWPAN Fragment Forwarding technique. "On Forwarding 6LoWPAN Fragments over a Multihop IPv6 Network" [I-D.ietf-6lo-minimal-fragment] provides the generic description of Fragment Forwarding and this specification inherits from it. The generic considerations in the Security sections of [I-D.ietf-6lo-minimal-fragment] apply equally to this document. This specification does not recommend a particular algorithm for the estimation of the duration of the RTO that covers the detection of the loss of a fragment with the 'X' flag set; regardless, an attacker on the path may slow down or discard packets, which in turn can affect the throughput of fragmented packets. Compared to "Transmission of IPv6 Packets over IEEE 802.15.4 Networks" [RFC4944], this specification reduces the datagram_tag to 8 bits and the tag wraps faster than with [RFC4944]. But for a constrained network where a node is expected to be able to hold only one or a few large packets in memory, 256 is still a large number. Also, the acknowledgement mechanism allows cleaning up the state rapidly once the packet is fully transmitted or aborted. " Many thanks again, Tiru. Pascal From: Pascal Thubert (pthubert) > Sent: Monday, February 10, 2020 1:06 PM To: Konda, Tirumaleswar Reddy >; secdir@ietf.org= ; draft-ietf-6lo-fragment-recovery.all@ietf.org Subject: RE: Secdir last call review of draft-ietf-6lo-fragment-recovery-08 CAUTION: External email. Do not click links or open attachments unless you = recognize the sender and know the content is safe. ________________________________ Hello Tiru; Many thanks for your review! Please see below > [1] It is not clear to me how the Security sections of I-D.ietf-core-coco= a apply to this specification ? The specification depends on a Retransmission TimeOut (RTO) estimation that= can be attacked. Adding the reference to cocoa was a earlier review commen= t that we got. Cocoa computes an RTO in a similar type of network. I agreed= that the recommendation made sense but still, I can probably dig that emai= l and start a thread with the reviewer if you think it is irrelevant. If coca is relevant, please add more details on how it is relevant. The sec= urity considerations in cocao is only discussing network access control to = prevent an attacker from dropping packets to eventually increase the RTO. > [2] The security considerations section discusses I-D.ietf-lwig-6lowpan-v= irtual-reassembly but that document does not discuss any security considera= tions yet. Correct. When it does I hope it describes the issue that this specification= discusses. In any fashion we use it to explain a difference: "here's a tra= ditional drawback of fragments and here's why it does not hurt us", as oppo= sed to an inheritance. If you think that the text is not helpful, we can open another thread on th= at. Thanks for the clarification. > [3] It is not clear how the DoS attack of bogus first fragments is handle= d and other attacks discussed in https://tools.ietf.org/html/draft-ietf-int= area-frag-fragile-17#section-3.7 are tackled ? They are not, apart from whatever protection we get from the requirement in= L2 security (we are talking about an homogeneous mesh). This section is hi= ghly relevant. This is all detailed in section 7 of draft-ietf-6lo-minimal-= fragment that this specification inherits. Okay. > [4] How does the document align with the recommendations given in https:/= /tools.ietf.org/html/draft-ietf-intarea-frag-fragile-17#section-6 ? Section 6 says that IP fragmentation should be avoided by new protocols. Th= is Is not IP fragmentation, it is lower layer. We cannot avoid it if we are= to support IPv6 that has a MIN MTU of 1280 bytes and the 6LoWPAN MTU is lo= wer than that, see RFC 4944. Got it. Cheers, -Tiru Please let me know if you have a recommendation for a change, I saw questio= ns but not real hiunt on how to act on them. Many thanks again! Pascal --_000_MN2PR11MB3565C3CF04D7F17F70504449D8190MN2PR11MB3565namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Great!

 

I posted v11. The diffs are visible here https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-6lo-fragment= -recovery-11.

Please let me know if I missed something.

 

Many thanks again, Tiru.

 

Pascal

 

From: Konda, Tirumales= war Reddy <TirumaleswarReddy_Konda@McAfee.com>
Sent: lundi 10 f=E9vrier 202= 0 13:25
To: Pascal Thubert (pthubert= ) <pthubert@cisco.com>; secdir@ietf.org; draft-ietf-6lo-fragment-reco= very.all@ietf.org
Subject: RE: Secdir last cal= l review of draft-ietf-6lo-fragment-recovery-08

 

Thanks Pascal. Updated text looks good.

 

Cheers,

-Tiru

 

From: Pascal Thubert (= pthubert) <pthubert@cisco.com&= gt;
Sent: Monday, February 10, 2= 020 5:48 PM
To: Konda, Tirumaleswar Redd= y <TirumaleswarRed= dy_Konda@McAfee.com>; secdir@ietf.org; draft-ietf-6lo-fragment-recovery.all@ietf.org
Subject: RE: Secdir last cal= l review of draft-ietf-6lo-fragment-recovery-08

 

CAUTION= : External email. Do not click links or open attachments unless you recogniz= e the sender and know the content is safe.

 

Hello Tiru

 

 

>>>[1] It is not clear to me how the Security sections of I-D.= ietf-core-cocoa apply to this specification ?

 

>> The specification depends on a Retransmission TimeO= ut (RTO) estimation that can be attacked. Adding the reference to cocoa was= a earlier review comment that we got. Cocoa computes an RTO in a similar type of network. I agreed that the recommendation made= sense but still, I can probably dig that email and start a thread with the= reviewer if you think it is irrelevant.

 

> If coca is relevant, please add more details on how it = is relevant. The security considerations in cocao is only discussing networ= k access control to prevent an attacker from dropping packets to eventually increase the RTO. =

 

Makes sense. I checked the status of cocoa and it appears st= uck(

IESG st= ate

Expired (IESG: Dead)

).

Maybe the safest is to import the idea that we wanted to cov= er and avoid the reference.

 

What about schanging the first 3 paragraphs as follows:=

“

   This do= cument specifies an instantiation of a 6LoWPAN Fragment

   Forward= ing technique.  "On Forwarding 6LoWPAN Fragments over a

   Multiho= p IPv6 Network" [I-D.ietf-6lo-minimal-fragment] provides the

   generic= description of Fragment Forwarding and this specification

   inherit= s from it.  The generic considerations in the Security

   section= s of [I-D.ietf-6lo-minimal-fragment] apply equally to this

   documen= t.

 

   This sp= ecification does not recommend a particular algorithm for the

   estimat= ion of the duration of the RTO that covers the detection of

   the los= s of a fragment with the 'X' flag set; regardless, an attacker

   on the = path may slow down or discard packets, which in turn can<= /font>

   affect = the throughput of fragmented packets.

 

   Compare= d to "Transmission of IPv6 Packets over IEEE 802.15.4

   Network= s" [RFC4944], this specification reduces the datagram_tag to 8

   bits an= d the tag wraps faster than with [RFC4944].  But for a

   constra= ined network where a node is expected to be able to hold only

   one or = a few large packets in memory, 256 is still a large number.

   Also, t= he acknowledgement mechanism allows cleaning up the state=

   rapidly= once the packet is fully transmitted or aborted.<= /p>

 

 

“

 

Many thanks again, Tiru.

 

Pascal

 

 

 

From: Pascal Thubert (= pthubert) <pthubert@cisco.com&= gt;
Sent: Monday, February 10, 2= 020 1:06 PM
To: Konda, Tirumaleswar Redd= y <TirumaleswarRed= dy_Konda@McAfee.com>; secdir@ietf.org; draft-ietf-6lo-fragment-recovery.all@ietf.org
Subject: RE: Secdir last cal= l review of draft-ietf-6lo-fragment-recovery-08

 

CAUTION= : External email. Do not click links or open attachments unless you recogniz= e the sender and know the content is safe.

 

Hello Tiru;

 

Many thanks for your review!

 

Please see below

 

> [1] It is n= ot clear to me how the Security sections of I-D.ietf-core-cocoa apply to th= is specification ?

 

The specification depends on a Retransmission TimeOut (RTO) = estimation that can be attacked. Adding the reference to cocoa was a earlie= r review comment that we got. Cocoa computes an RTO in a similar type of network. I agreed that the recommendation made= sense but still, I can probably dig that email and start a thread with the= reviewer if you think it is irrelevant.

 

If coca is relevant, please add more details on how it is re= levant. The security considerations in cocao is only discussing network acc= ess control to prevent an attacker from dropping packets to eventually increase the RTO. =

 

> [2] The sec= urity considerations section discusses I-D.ietf-lwig-6lowpan-virtual-reasse= mbly but that document does not discuss any security considerations yet.

 

Correct. When it does I hope it describes the issue that thi= s specification discusses. In any fashion we use it to explain a difference= : “here’s a traditional drawback of fragments and here’s why it does not hurt us”, as opposed to an inherita= nce.

If you think that the text is not helpful, we can open anoth= er thread on that.

 

Thanks for the clarification.

 

> [3] It is not clear how the DoS attack of bogus first f= ragments is handled and other attacks discussed in https://tools.ietf.org/html/draft-ietf-intarea-frag-fragile-17#section-3.7<= /a> are tackled ?

 

They are not, apart from whatever protection we get from the= requirement in L2 security (we are talking about an homogeneous mesh). Thi= s section is highly relevant. This is all detailed in section 7 of draft-ietf-6lo-minimal-fragment that this specifi= cation inherits.

 

Okay.

 

> [4] How doe= s the document align with the recommendations given in https://tools.ietf.org/html/draft-ietf-intarea-frag-fragile-17#section-6 ?

 

Section 6 says that IP fragmentation should be avoided by ne= w protocols. This Is not IP fragmentation, it is lower layer. We cannot avo= id it if we are to support IPv6 that has a MIN MTU of 1280 bytes and the 6LoWPAN MTU is lower than that, see RFC 49= 44.

 

Got it.

 

Cheers,

-Tiru

 

Please let me know if you have a recommendation for a change= , I saw questions but not real hiunt on how to act on them.

 

 

Many thanks again!

 

Pascal

 

 

--_000_MN2PR11MB3565C3CF04D7F17F70504449D8190MN2PR11MB3565namp_-- From nobody Tue Feb 11 10:49:19 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 160281208FA; Fri, 7 Feb 2020 10:54:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1581101649; bh=49Jj5Z1OPKA5Oka0igYz+K+h6EyAh/I/JP8WDN1+UTQ=; h=From:To:Date:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe; b=LLtpEctvFGVZHo7SJAVo5eMi7GYypyz0v63x2UNsI19f7ynPTkyvBoN8sP5994WGA eVpyPy193dy1idGEGVsCky+WTo8s5HLa09pN9+pd65ImSwrrjwoRpv9ja3lbKeBpIn H4JmiAGzOFdM9y8DZ05/DixWjKtqNunyBVPIlYLA= X-Mailbox-Line: From new-work-bounces@ietf.org Fri Feb 7 10:54:05 2020 Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6678412022D; Fri, 7 Feb 2020 10:53:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1581101637; bh=49Jj5Z1OPKA5Oka0igYz+K+h6EyAh/I/JP8WDN1+UTQ=; h=From:To:Date:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe; b=lm3KY4VwGAJd/mcRUTXCGflmG5GDfAZAJhkBEImZrDkRgPX2IjNrh62EwPb0IIYJ+ xDtK+vz3I5lQuh7viD8mz8mKmrDbA/9b8c8CjVNCqZ/UWtndr8eXDV2e08gIiHNZG+ RMZBqb/rQ6CmWa8QtPsMwB6QweRPSO6DTrtgMr7U= X-Original-To: new-work@ietf.org Delivered-To: new-work@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C19F71200F4 for ; Fri, 7 Feb 2020 10:53:50 -0800 (PST) MIME-Version: 1.0 From: The IESG To: X-Test-IDTracker: no X-IETF-IDTracker: 6.117.0 Auto-Submitted: auto-generated Precedence: bulk Reply_to: MIME-Version: 1.0 Message-ID: <158110163078.11714.14396802134469098484.idtracker@ietfa.amsl.com> Date: Fri, 07 Feb 2020 10:53:50 -0800 Archived-At: X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.29 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: new-work-bounces@ietf.org Sender: "new-work" Archived-At: X-Mailman-Approved-At: Tue, 11 Feb 2020 10:49:16 -0800 Subject: [secdir] [new-work] WG Review: Web Packaging (wpack) X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Feb 2020 18:54:13 -0000 A new IETF WG has been proposed in the Applications and Real-Time Area. The IESG has not made any determination yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org) by 2020-02-17. Web Packaging (wpack) ----------------------------------------------------------------------- Current status: BOF WG Chairs: Sean Turner Assigned Area Director: Alexey Melnikov Applications and Real-Time Area Directors: Adam Roach Alexey Melnikov Barry Leiba Mailing list: Address: wpack@ietf.org To subscribe: https://www.ietf.org/mailman/listinfo/wpack Archive: https://mailarchive.ietf.org/arch/browse/wpack/ Group page: https://datatracker.ietf.org/group/wpack/ Charter: https://datatracker.ietf.org/doc/charter-ietf-wpack/ The WPACK working group will develop a specification for a web packaging format that efficiently bundles multiple HTTP representations. It will also specify a way for the publisher to sign these resources such that a user agent can trust that they came from their claimed web origins. Key goals for WPACK are: * Efficient storage across a range of resource combinations. Three use cases to be supported are: a client-generated snapshot of a complete web page, a web page's tree of JavaScript modules, and a selection of the whole web for peer-to-peer distribution in a country when access to authoritative servers is unavailable. * The ability to create a snapshot of a web page without the cooperation of its publisher. * The ability to use a web app online or offline, with assurance of its publisher, after a package of it was received from a peer. * Low latency to load a subresource from a package, whether the package is signed or unsigned, and whether the package is streamed or loaded from random-access storage. * Being extensible and crypto agile. * Security and privacy properties of using signed bundles as close as practical to TLS 1.3 transport of the same resources. Where properties do change, the group will document exactly what changed and how affected people, including content publishers and users, can compensate. Part of this is analyzing how the shift from transport security to object security changes the security properties of the web's existing features. * Specifying constraints on how clients load the formats without describing specific loading algorithm to help achieve the above goals. The packaging format will also aim to achieve the following secondary goals as long as they don't compromise or delay the above properties. * Optimizations in encoding and processing when only a single resource (as opposed to a collection thereof) is being packaged * Support signed statements about subresources beyond just assertions that they're accurate representations of particular URLs. * Address the threat model of a website compromised after a user first uses the site. * Support books being published in the format. * Optimize transport of large numbers of small same-origin resources. * Allow publishers to efficiently combine sub-packages from other publishers. The following goals are out of scope under this charter: * DRM (Digital Rights Management) * A way to distribute the private portions of a website. For example, WPACK might define a way to distribute a messaging application but wouldn't define a way to distribute individual messages without a direct connection to the messaging application's origin server. * Defining the details of how web browsers load the formats and interact with any protocols we define here, aside from the constraints mentioned above. * A way to automatically discover the URL for an accessible package that includes specific content. Note that consensus is required both for changes to the initially proposed protocol mechanisms and for their retention. In particular, because something is in an initial working group draft does not imply that there is consensus around the feature or around how it is specified. Relationship to Other WGs and SDOs WPACK will work with the W3C and WHATWG to identify the existing security and privacy models for the web, and to ensure those SDOs can define how this format is used by web browsers. The WPACK working group will work closely with the HTTPbis working group, in particular WPACK will attempt to reuse HTTPBIS work on HTTP signing. Milestones: Jun 2020 - Working group adoption of use cases document (will not be published as an RFC) Jun 2020 - Working group adoption of bundling document Jun 2020 - Working group adoption of security analysis document Jun 2020 - Working group adoption of privacy analysis document Jun 2020 - Working group adoption of signing document Sep 2021 - Submit the Bundling document to IESG Mar 2022 - Submit the Privacy analysis document to IESG Mar 2022 - Submit the Security analysis document to IESG Mar 2022 - Submit the Signing document to IESG _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From nobody Tue Feb 11 10:49:22 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D97EE120A08; Tue, 11 Feb 2020 10:04:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1581444260; bh=aCa1l8EZlxKsvrEQVh9DJnlp+ao91lXqz6d0JdOYVsQ=; h=From:To:Date:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe; b=gkfacmHTfNnBpLS0/fuhTUJKNQ/w8KXV3mqj1LQLTapNatOiUKPcjDAxO6GFhbtKL c2mZSr3oPc6OzYTXjjH9Ud8WXP7kUvEpqDWIPCioRZt/oit6d7jGKx+rAzryO1562Q VsZQ0gEVHvgy2GvSNh/dZN2PtRSqz4qROMCqBrPQ= X-Mailbox-Line: From new-work-bounces@ietf.org Tue Feb 11 10:04:16 2020 Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 886DA120A00; Tue, 11 Feb 2020 10:04:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1581444248; bh=aCa1l8EZlxKsvrEQVh9DJnlp+ao91lXqz6d0JdOYVsQ=; h=From:To:Date:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe; b=wtzM3LUOyvBqv2ltvoDVyBliO2g8AE3EnZ4qX3+2ypDCXB79EPvBkFonVO0DBZpWA sD3EJyrvSarRRSY+r18LNiTQ48RYbMGyQlVU+XyGMoMBAFABRjU6sFxP0KtF8jCdlg 7jr+HpF9JfKMMEmLe3Z4kKpJEwvR1oxXbRS2z/tA= X-Original-To: new-work@ietf.org Delivered-To: new-work@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D4D121209C3 for ; Tue, 11 Feb 2020 10:04:01 -0800 (PST) MIME-Version: 1.0 From: The IESG To: X-Test-IDTracker: no X-IETF-IDTracker: 6.117.0 Auto-Submitted: auto-generated Precedence: bulk Reply_to: MIME-Version: 1.0 Message-ID: <158144424186.20019.5779032330149685522.idtracker@ietfa.amsl.com> Date: Tue, 11 Feb 2020 10:04:01 -0800 Archived-At: X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.29 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Errors-To: new-work-bounces@ietf.org Sender: "new-work" Archived-At: X-Mailman-Approved-At: Tue, 11 Feb 2020 10:49:16 -0800 Subject: [secdir] [new-work] WG Review: Drone Remote ID Protocol (drip) X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Feb 2020 18:04:25 -0000 QSBuZXcgSUVURiBXRyBoYXMgYmVlbiBwcm9wb3NlZCBpbiB0aGUgSW50ZXJuZXQgQXJlYS4gVGhl IElFU0cgaGFzIG5vdCBtYWRlCmFueSBkZXRlcm1pbmF0aW9uIHlldC4gVGhlIGZvbGxvd2luZyBk cmFmdCBjaGFydGVyIHdhcyBzdWJtaXR0ZWQsIGFuZCBpcwpwcm92aWRlZCBmb3IgaW5mb3JtYXRp b25hbCBwdXJwb3NlcyBvbmx5LiBQbGVhc2Ugc2VuZCB5b3VyIGNvbW1lbnRzIHRvIHRoZQpJRVNH IG1haWxpbmcgbGlzdCAoaWVzZ0BpZXRmLm9yZykgYnkgMjAyMC0wMi0xOC4KCkRyb25lIFJlbW90 ZSBJRCBQcm90b2NvbCAoZHJpcCkKLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KQ3VycmVudCBzdGF0dXM6IFByb3Bv c2VkIFdHCgpDaGFpcnM6CiAgR29uemFsbyBDYW1hcmlsbG8gPGdvbnphbG8uY2FtYXJpbGxvQGVy aWNzc29uLmNvbT4KICBEYW5pZWwgTWlnYXVsdCA8bWdsdC5pZXRmQGdtYWlsLmNvbT4KCkFzc2ln bmVkIEFyZWEgRGlyZWN0b3I6CiAgw4lyaWMgVnluY2tlIDxldnluY2tlQGNpc2NvLmNvbT4KCklu dGVybmV0IEFyZWEgRGlyZWN0b3JzOgogIFN1cmVzaCBLcmlzaG5hbiA8c3VyZXNoQGthbG9vbS5j b20+CiAgw4lyaWMgVnluY2tlIDxldnluY2tlQGNpc2NvLmNvbT4KCk1haWxpbmcgbGlzdDoKICBB ZGRyZXNzOiB0bS1yaWRAaWV0Zi5vcmcKICBUbyBzdWJzY3JpYmU6IGh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vdG0tcmlkCiAgQXJjaGl2ZTogaHR0cHM6Ly9tYWlsYXJjaGl2 ZS5pZXRmLm9yZy9hcmNoL2Jyb3dzZS90bS1yaWQvCgpHcm91cCBwYWdlOiBodHRwczovL2RhdGF0 cmFja2VyLmlldGYub3JnL2dyb3VwL2RyaXAvCgpDaGFydGVyOiBodHRwczovL2RhdGF0cmFja2Vy LmlldGYub3JnL2RvYy9jaGFydGVyLWlldGYtZHJpcC8KCkRyb25lIFJlbW90ZSBJRCBQcm90b2Nv bCAoRFJJUCkgV0cKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KCltwcmV2aW91c2x5 IFRNUklEIEJvRiBhbmQgdG0tcmlkQGlldGYub3JnIG1haWxpbmcgbGlzdF0KCkNpdmlsIEF2aWF0 aW9uIEF1dGhvcml0aWVzIChDQUFzKSB3b3JsZHdpZGUgaGF2ZSBpbml0aWF0ZWQgcnVsZSBtYWtp bmcgZm9yClVubWFubmVkIEFpcmNyYWZ0IFN5c3RlbXMgKFVBUykgUmVtb3RlIElkZW50aWZpY2F0 aW9uIChSSUQpLiBDQUFzIGN1cnJlbnRseQpwcm9tdWxnYXRlIHBlcmZvcm1hbmNlLWJhc2VkIHJl Z3VsYXRpb25zIHRoYXQgZG8gbm90IG1hbmRhdGUgc3BlY2lmaWMKdGVjaG5pcXVlcywgYnV0IHJh dGhlciBjaXRlIGluZHVzdHJ5LWNvbnNlbnN1cyB0ZWNobmljYWwgc3RhbmRhcmRzIGFzCmFjY2Vw dGFibGUgbWVhbnMgb2YgY29tcGxpYW5jZS4gT25lIGtleSBzdGFuZGFyZCBpcyBBU1RNIEludGVy bmF0aW9uYWwKKGZvcm1lcmx5IHRoZSBBbWVyaWNhbiBTb2NpZXR5IGZvciBUZXN0aW5nIGFuZCBN YXRlcmlhbHMpIFdLNjUwNDEgWzFdLiBUaGlzCnRlY2huaWNhbCBzcGVjaWZpY2F0aW9uIGRlZmlu ZXMgVUFTIFJJRCBtZXNzYWdlIGZvcm1hdHMsIGFuZCB0cmFuc21pc3Npb24KbWV0aG9kcy4gTmV0 d29yayBSSUQgZGVmaW5lcyBhIHNldCBvZiBpbmZvcm1hdGlvbiBmb3IgVUFTIHRvIGJlIG1hZGUK YXZhaWxhYmxlIGdsb2JhbGx5IHZpYSB0aGUgSW50ZXJuZXQuIEJyb2FkY2FzdCBSSUQgZGVmaW5l cyBhIHNldCBvZiBtZXNzYWdlcwpmb3IgVUFTIHRvIHNlbmQgbG9jYWxseSBvbmUtd2F5IG92ZXIg Qmx1ZXRvb3RoIG9yIFdpLUZpLiBXSzY1MDQxIGRvZXMgbm90CmFkZHJlc3MgaG93IHRvIHBvcHVs YXRlL3F1ZXJ5IHJlZ2lzdHJpZXMsIGhvdyB0byBlbnN1cmUgdHJ1c3R3b3J0aGluZXNzIG9mCmlu Zm9ybWF0aW9uLCBub3IgaG93IHRvIG1ha2UgdGhlIGluZm9ybWF0aW9uIHVzZWZ1bC4KCkRSSVDi gJlzIGdvYWwgaXMgdG8gc3BlY2lmeSBob3cgUklEIGNhbiBiZSBtYWRlIGF2YWlsYWJsZSBpbiBi b3RoIEludGVybmV0IGFuZApsb2NhbC1vbmx5IGNvbm5lY3RlZCBzY2VuYXJpb3MsIGVzcGVjaWFs bHkgaW4gZW1lcmdlbmN5IHNpdHVhdGlvbnMuIFNvbWUgVUFTCm9wZXJhdGUgaW4gZW52aXJvbm1l bnRzIHdoZXJlIHRoZSBuZXR3b3JrIG9yIHRoZSBkZXZpY2VzIG9yIGJvdGggYXJlIHNldmVyZWx5 CmNvbnN0cmFpbmVkIFsyXSBpbiB0ZXJtcyBvZiBwcm9jZXNzaW5nLCBiYW5kd2lkdGggKGUuZy4s IEJsdWV0b290aCA0IGJlYWNvbgpwYXlsb2FkIGlzIDI1IGJ5dGVzIGxvbmcpLCBvciBiYXR0ZXJ5 IGxpZmUsIGFuZCBEUklQIGFpbXMgdG8gZnVuY3Rpb24gaW4KdGhlc2UgZW52aXJvbm1lbnRzLiBU aGUgc3BlY2lmaWNhdGlvbnMgcHJvZHVjZWQgYnkgdGhlIFdHIHdpbGwgbmVlZCB0bwpiYWxhbmNl IHB1YmxpYyBzYWZldHkgYXV0aG9yaXRpZXPigJkgbmVlZCB0byBrbm93IHRydXN0d29ydGh5IGlu Zm9ybWF0aW9uIHdpdGgKVUFTIG9wZXJhdG9yc+KAmSBhbmQgb3RoZXIgaW52b2x2ZWQgcGFydGll c+KAmSBwcml2YWN5LgoKVGhlIHdvcmtpbmcgZ3JvdXAgd2lsbCBwcmltYXJpbHkgbGV2ZXJhZ2Ug SW50ZXJuZXQgc3RhbmRhcmRzIChpbmNsdWRpbmcgSElQLApFUFAsIFJEQVAsIGFuZCBETlMpIGFu ZCBpbmZyYXN0cnVjdHVyZSBhcyB3ZWxsIGFzIGRvbWFpbiBuYW1lIHJlZ2lzdHJhdGlvbgpidXNp bmVzcyBtb2RlbHMuIFRoZSBXRyB3aWxsIHRyYWNrIGFuZCBhbGlnbiB3aXRoIHRoZSByZXF1aXJl bWVudHMgYmVpbmcKZGV2ZWxvcGVkIGJ5IHJlZ3VsYXRvcnkgYXV0aG9yaXRpZXMsIGUuZy4sIHRo ZSBVUyBGZWRlcmFsIEF2aWF0aW9uCkFkbWluaXN0cmF0aW9uIChVUyBGQUEpIFszXSBhbmQgdGhl IEV1cm9wZWFuIFVuaW9uIEF2aWF0aW9uIFNhZmV0eSBBZ2VuY3kKKEVBU0EpIGRlbGVnYXRlZCBb NF0gYW5kIGltcGxlbWVudGluZyBbNV0gUmVndWxhdGlvbnMuCgpUaGUgd29ya2luZyBncm91cCB3 aWxsIHdvcmsgb24gdGhlIGZvbGxvd2luZyBpdGVtczoKKiBSZXF1aXJlbWVudHM6IHRoZSBXRyBp cyBleHBlY3RlZCB0byBwcm92aWRlIGFuIGluZm9ybWF0aW9uYWwgZG9jdW1lbnQgdGhhdApsaXN0 cyB0aGUgdGVjaG5pY2FsIHJlcXVpcmVtZW50cyBmb3IgYXBwbHlpbmcgSUVURiBwcm90b2NvbHMg dG8gdGhlIFVBUwpSZW1vdGUgSWRlbnRpZmljYXRpb24gKFVBUyBSSUQpIC0gdGhhdCBpcyB0aGUg c3lzdGVtIGZvciBpZGVudGlmeWluZyBVQQpkdXJpbmcgZmxpZ2h0IGJ5IG90aGVyIHBhcnRpZXMu IFRoZXNlIHJlcXVpcmVtZW50cyB3aWxsIGFsc28gaW5jbHVkZSB0aG9zZQphc3NvY2lhdGVkIHRv IHRoZSBVQVMgSWRlbnRpZmllciB0aGF0IG5lZWQgdG8gYm90aCBtZWV0IHNvbWUgY29uc3RyYWlu dHMgYXMKd2VsbCBhcyBzb21lIHNwZWNpZmljIHByb3BlcnRpZXMuICogQXJjaGl0ZWN0dXJlOiB0 aGUgV0cgd2lsbCBwcm9wb3NlIGEKc3RhbmRhcmQgZG9jdW1lbnQgdGhhdCBkZXNjcmliZXMgdGhl IGFyY2hpdGVjdHVyZSB0aGF0IGFkZHJlc3MgdGhlIHRlY2huaWNhbApyZXF1aXJlbWVudHMgYW5k IHRoYXQgd2lsbCBhdHRlbXB0IHRvIHJlLXVzZSBwcm90b2NvbHMgb3IgYXJjaGl0ZWN0dXJlcwph bHJlYWR5IHN0YW5kYXJkaXplZCBhdCB0aGUgSUVURi4gKiBQcm90b2NvbCBkZXNpZ246IHdoaWxl IHRoZSBwcmltYXJ5CnB1cnBvc2Ugb2YgRFJJUCBXRyBpcyB0byBsZXZlcmFnZSBleGlzdGluZyBw cm90b2NvbHMsIHRoZSBzcGVjaWZpY2l0aWVzIG9mCnRoZSBVQVMgZW52aXJvbm1lbnQgYXJlIGxp a2VseSB0byByZXF1aXJlIGV4aXN0aW5nIHByb3RvY29scyB0byBiZSBleHRlbmRlZApvciBuZXcg cHJvdG9jb2xzIHRvIGJlIGRlc2lnbmVkLiBUaGUgV0cgd2lsbCBmb2N1cyBvbiBnZXR0aW5nIHRo ZXNlIHByb3RvY29scwpvciBleHRlbnNpb25zIHN0YW5kYXJkaXplZCwgY29vcmRpbmF0aW5nIHdp dGggb3RoZXIgV0dzIHJlbGV2YW50IGZvciB0aGUKcHJvdG9jb2wocykgaW4gcXVlc3Rpb24gb24g dGhlIG1vc3QgYXBwcm9wcmlhdGUgaG9tZSBmb3IgYW55IGdpdmVuIHBpZWNlIG9mCndvcmsuCgpM aXN0IG9mIGNhbmRpZGF0ZSBkcmFmdHM6Ci0gZHJhZnQtY2FyZC10bXJpZC11YXMtcmVxcwotIGRy YWZ0LWNhcmQtdG1yaWQtdWFzLWFyY2gKLSBkcmFmdC13aWV0aHVlY2h0ZXItdG1yaWQtYXV0aAot IGRyYWZ0LW1vc2tvd2l0ei1oaXAtbmV3LWNyeXB0bwotIGRyYWZ0LW1vc2tvd2l0ei1vcmNoaWQt Y3NoYWtlCi0gZHJhZnQtbW9za293aXR6LWhpcC1oaWVyYXJjaGljYWwtaGl0Ci0gZHJhZnQtbW9z a293aXR6LWhpcC1oaGl0LXJlZ2lzdHJpZXMKClJlZmVyZW5jZXM6ClsxXSBBU1RNIEludGVybmF0 aW9uYWwgRjM4IENvbW1pdHRlZSBXb3JrIEl0ZW0gV0s2NTA0MSDigJxTdGFuZGFyZApTcGVjaWZp Y2F0aW9uIGZvciBVQVMgUmVtb3RlIElEIGFuZCBUcmFja2luZ+KAnQpodHRwczovL3d3dy5hc3Rt Lm9yZy9EQVRBQkFTRS5DQVJUL1dPUktJVEVNUy9XSzY1MDQxLmh0bSBbMl0gVUFTCklkZW50aWZp Y2F0aW9uIGFuZCBUcmFja2luZyBBdmlhdGlvbiBSdWxlbWFraW5nIENvbW1pdHRlZSBSZWNvbW1l bmRhdGlvbnMKRmluYWwgUmVwb3J0IDIwMTcgU0VQIDMwCmh0dHBzOi8vd3d3LmZhYS5nb3YvcmVn dWxhdGlvbnNfcG9saWNpZXMvcnVsZW1ha2luZy9jb21taXR0ZWVzL2RvY3VtZW50cy9tZWRpYS9V QVMlMjBJRCUyMEFSQyUyMEZpbmFsJTIwUmVwb3J0JTIwd2l0aCUyMEFwcGVuZGljZXMucGRmClsz XSBOb3RpY2Ugb2YgUHJvcG9zZWQgUnVsZSBNYWtpbmcgKE5QUk0pCmh0dHBzOi8vd3d3LmZlZGVy YWxyZWdpc3Rlci5nb3YvZG9jdW1lbnRzLzIwMTkvMTIvMzEvMjAxOS0yODEwMC9yZW1vdGUtaWRl bnRpZmljYXRpb24tb2YtdW5tYW5uZWQtYWlyY3JhZnQtc3lzdGVtcwpbNF0gaHR0cHM6Ly9ldXIt bGV4LmV1cm9wYS5ldS9lbGkvcmVnX2RlbC8yMDE5Lzk0NS9vaiBbNV0KaHR0cHM6Ly9ldXItbGV4 LmV1cm9wYS5ldS9lbGkvcmVnX2ltcGwvMjAxOS85NDcvb2oKCk1pbGVzdG9uZXM6CgogIE1hciAy MDIwIC0gUmVxdWlyZW1lbnRzIGFuZCBhcmNoaXRlY3R1cmUgZHJhZnRzCgogIE1hciAyMDIxIC0g U29sdXRpb24gc3BhY2UgZG9jdW1lbnRzCgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18KbmV3LXdvcmsgbWFpbGluZyBsaXN0Cm5ldy13b3JrQGlldGYub3Jn Cmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV3LXdvcmsK From nobody Thu Feb 13 05:44:34 2020 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 299FF1200C5 for ; Thu, 13 Feb 2020 05:44:32 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Tero Kivinen via Datatracker To: X-Test-IDTracker: no X-IETF-IDTracker: 6.117.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: secdir-secretary@mit.edu, Tero Kivinen Message-ID: <158160147209.20580.1612402184419285281.idtracker@ietfa.amsl.com> Date: Thu, 13 Feb 2020 05:44:32 -0800 Archived-At: Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2020 13:44:32 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview For telechat 2020-02-20 Reviewer LC end Draft Yaron Sheffer R2020-01-27 draft-ietf-nfsv4-rpcrdma-cm-pvt-data-07 Christopher Wood R2019-11-06 draft-ietf-dtn-tcpclv4-18 Last calls: Reviewer LC end Draft Shaun Cooley 2019-11-12 draft-ietf-regext-login-security-08 Roman Danyliw 2019-11-12 draft-ietf-dtn-bpbis-23 Alan DeKok 2019-06-04 draft-ietf-netvc-testing-09 Russ Mundy 2020-01-02 draft-ietf-dprive-bcp-op-08 Sandra Murphy 2019-10-04 draft-ietf-mpls-ldp-yang-06 Magnus Nystrom 2019-04-10 draft-ietf-avtcore-multiplex-guidelines-09 Stefan Santesson 2020-01-27 draft-ietf-dots-architecture-17 Yaron Sheffer R2020-01-27 draft-ietf-nfsv4-rpcrdma-cm-pvt-data-07 Takeshi Takahashi 2020-02-06 draft-ietf-mmusic-t140-usage-data-channel-11 Tina Tsou 2020-02-06 draft-ietf-6lo-backbone-router-16 Sean Turner None draft-ietf-opsawg-sdi-02 Mališa Vučinić 2020-03-09 draft-kuehlewind-system-ports-05 Carl Wallace 2020-02-26 draft-ietf-rmcat-eval-criteria-11 David Waltermire 2020-02-25 draft-ietf-6man-icmp-limits-07 Brian Weis 2020-02-24 draft-ietf-alto-cost-calendar-16 Klaas Wierenga 2020-02-21 draft-ietf-lamps-5480-ku-clarifications-00 Christopher Wood R2019-11-06 draft-ietf-dtn-tcpclv4-18 Paul Wouters 2020-02-20 draft-ietf-lpwan-coap-static-context-hc-12 Liang Xia 2020-02-20 draft-ietf-ntp-packet-timestamps-07 Dacheng Zhang 2019-11-05 draft-ietf-mpls-ri-rsvp-frr-07 Next in the reviewer rotation: Dacheng Zhang Derek Atkins John Bradley Nancy Cam-Winget From nobody Thu Feb 13 18:54:53 2020 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C58EF120059; Thu, 13 Feb 2020 18:54:47 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Christopher Wood via Datatracker To: Cc: last-call@ietf.org, draft-ietf-dtn-tcpclv4.all@ietf.org, dtn@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.117.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Christopher Wood Message-ID: <158164888774.20556.7623938203569597994@ietfa.amsl.com> Date: Thu, 13 Feb 2020 18:54:47 -0800 Archived-At: Subject: [secdir] Secdir telechat review of draft-ietf-dtn-tcpclv4-18 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2020 02:54:48 -0000 Reviewer: Christopher Wood Review result: Has Nits Thanks for updating this document! All of my comments from the previous review have been addressed. It reads much better now. I only have some minor nits to note below: - Section 8.5: This section title references ciphersuite downgrade, yet the text refers to configured use of less-good ciphersuites. Perhaps the title should be, "Threat: Weak TLS Configurations"? - Section 8.6: I don't quite follow this section. Certainly, describing how one validates certificates is out of scope. However, the title suggests this is part of how one "uses" certificates? I might just scratch this section altogether, and instead reference RFC5280 where certificate-based authentication is first presented. - Section 8.7: I might rename this title to, "Threat: Symmetric Key Limits." - Section 8.10.1: I would reference opportunistic security here, as an unauthenticated key exchange yields similar properties. From nobody Fri Feb 14 04:38:45 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E3C4120827; Fri, 14 Feb 2020 04:38:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.6 X-Spam-Level: *** X-Spam-Status: No, score=3.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, GB_SUMOF=5, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, 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 SF2C4dszXTJi; Fri, 14 Feb 2020 04:38:39 -0800 (PST) Received: from mail-io1-f66.google.com (mail-io1-f66.google.com [209.85.166.66]) (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 4DCF21200DE; Fri, 14 Feb 2020 04:38:36 -0800 (PST) Received: by mail-io1-f66.google.com with SMTP id d15so10394503iog.3; Fri, 14 Feb 2020 04:38:36 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=heQDP0TJ6o6Bx2f0n2S/flBq7YFQBrNHXZ2cqcWyZu0=; b=UVUtDtmNO7cI7bfDERqvg1rCHP045108eLrL/ozoLcOKlNAtS4wxfrGEMXA6SIRHNn 4LSRObGW6sfM3Og2OsIj/2vAGTj301NYokxoekSy7OLXjooWlfFtehzQ3XgxqpX/mHTi XKgohu9QHezc+nPzfmdz3daGO664XxGgZgnIzFiAIJtvkOeX5Ipw92N+f8O4tG0GVXu5 AJFpfqcy+TCB1aXbygBp9WpgQxptz5GtcwMfMvRiYprdqcY5v3vOh7VbY0fpjJ1LItnl SYYwtfSfZlavlyCZN75ymhNlF0Pc65SaGzQl0BSWmRXBA8V1pFRkQUPM/bY0KG+vIizW hjog== X-Gm-Message-State: APjAAAUyYp+RHy2eJgSKYxslERu1hTc8nV545mrF+LJ0BdAPRblM12IC qGJDYGY9d0ZMWnvgYkjsT8++hJ4HqQuJRIDzcvg= X-Google-Smtp-Source: APXvYqzbFf3VINyl3t9pIyRr3iHfq+H7/iupjE5Kbp+XdQKHGbWCxMWiNBtQH3HTUpTUyt065+xOBtNa8xuKB/WFNwo= X-Received: by 2002:a5e:8417:: with SMTP id h23mr1979199ioj.17.1581683915326; Fri, 14 Feb 2020 04:38:35 -0800 (PST) MIME-Version: 1.0 References: <157007038502.8860.1558861534319247512.idtracker@ietfa.amsl.com> <001601d57af9$405efcf0$c11cf6d0$@vocal.com> <6E58094ECC8D8344914996DAD28F1CCD23D79BC0@DGGEMM506-MBX.china.huawei.com> <034a01d58a73$f4d3a1c0$de7ae540$@vocal.com> <037e01d58a92$72287510$56795f30$@vocal.com> <20191101001153.GQ88302@kduck.mit.edu> <06e101d59f15$ee937b30$cbba7190$@vocal.com> <20191125064606.GL32847@mit.edu> In-Reply-To: <20191125064606.GL32847@mit.edu> From: Barry Leiba Date: Fri, 14 Feb 2020 07:38:24 -0500 Message-ID: To: Benjamin Kaduk Cc: victor.demjanenko@vocal.com, "Roni Even (A)" , The IESG , Catherine Meadows , IETF SecDir , draft-ietf-payload-tsvcis@ietf.org, Ali Begen , avtcore-chairs@ietf.org, avt@ietf.org, "Dave Satterlee (Vocal)" , IETF discussion list , draft-ietf-payload-tsvcis.all@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [secdir] Benjamin Kaduk's Discuss on draft-ietf-payload-tsvcis-03: (with DISCUSS and COMMENT) X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2020 12:38:43 -0000 This is still outstanding, since November. Victor, where are we on this one? Barry On Mon, Nov 25, 2019 at 1:46 AM Benjamin Kaduk wrote: > > Hi Victor, > > On Tue, Nov 19, 2019 at 03:14:21PM -0500, victor.demjanenko@vocal.com wrote: > > Hi Ben, > > > > Sorry I overlooked sending you a response. I would like to address the two > > concerns you have by explaining what the speech coders are doing. > > Thanks for the extra clarifications. To supply one of my own: I'm not > concerned that the protocol doesn't work as implemented, but just want to > make sure that the document includes enough information to admit new > implementations without guesswork. That is to say, "either tell me how to > do it or tell me where to look that tells me how to do it". > > > WRT to 600 bps MELP, there is one TSVCIS mode that uses one bit beyond the > > 54-bit frame for MELP 600 as a frame sync which alternates between frames. > > With two or more MELP 600bps frames in one RTP packet, if any frame > > indicates 600 bps by CODA being 0 and CODB being 1, then we know the stream > > is 600bps. If there is a single frame in an RTP packet, you can still > > deduce this by looking at every other RTP packet (every other MELP 600bps > > frame) and by the timestamp advance. Most likely the two ends would > > negotiate 600 bps in SDP anyways so there really should not be a problem. I > > know it's not pretty but its workable. I hope this explanation helps you > > with the concerns for this issue. > > In this case, the use as an "end-to-end framing bit" (i.e., the alternating > behavior you describe above) is not explicitly stated; one might imagine a > scheme where the framing usage is to have the bit cycle through 1, 1, 0, > and 0, or some other scheme. I'd suggest to note in the document that if > any instance of (CODA, CODB) == (0, 1) is observed, then the 600bps mode is > in use. It might also be helpful to include the observation that two > successive MELPe payloads with CODA == CODB == 0 indicates the 2400bps mode > (and that seeing them in a single RTP packet is decisive, whereas > additional information about packet non-loss would be needed in the > one-MELPe-frame-per-RTP-packet case), but that would be a fair bit of > additional text and might be diminishing returns. (Or, of course, the use > of CODB as an alternating 1/0 bit as the framing usage could be documented > instead.) > > > As for the TSVCIS parameter packing/unpacking, this is really simple. There > > is exactly on three bit parameter, exactly one five bit parameter and a > > variable number of eight bit parameters. In our view, the speech coder > > itself (or a wrapper for it) is responsible for preparing the block of > > octets. RTP then just transports it. On receive, the complementary wrapper > > reverses the packing operation. I hope this clarifies and explains the > > simplicity. > > That's exactly what I expected to happen; however, it's not what I believe > the current text of the document is describing. Specifically, I think that > the current text implies that the "preparing the block of octets" and > "complementary wrapper reverses the packing operation" are supposed to be > part of the RTP payload format that this document describes, but this > document does not have enough information to actually perform those > operations reversibly. If the packing is to be done in the speech coder, > then this document doesn't need to talk about the packing at all (e.g., at > the end of Section 2); if we need to keep the packing/wrapper in this > document then we need to indicate that there's a defined priority order for > the (8-octet) TSVCIS parameters in the TSVCIS references, to allow the > packing/unpacking to be deterministic. > > Thanks, > > Ben > > > > > -----Original Message----- > > From: Benjamin Kaduk > > Sent: Thursday, October 31, 2019 8:12 PM > > To: Barry Leiba > > Cc: victor.demjanenko@vocal.com; Roni Even (A) ; The > > IESG ; Catherine Meadows ; > > IETF SecDir ; draft-ietf-payload-tsvcis@ietf.org; Ali Begen > > ; avtcore-chairs@ietf.org; avt@ietf.org; Dave > > Satterlee (Vocal) ; IETF discussion list > > ; draft-ietf-payload-tsvcis.all@ietf.org > > Subject: Re: Benjamin Kaduk's Discuss on draft-ietf-payload-tsvcis-03: (with > > DISCUSS and COMMENT) > > > > I don't think so, unfortunately. > > > > I do see the clarification about CODB's potential for deviation from Table > > 1, that only the 600 bps MELPe is allowed to deviate, and that CODA gets us > > to "it's one of 2400 or 600 bps" and the RTP timestamp disambiguates that > > 600 bps is in use. But, it seems that this means that the recipient in > > general should not rely on CODB to differentiate 600 from 2400 bps, and > > instead is more robustly implemented by *always* using the RTP timestamp to > > detect 600 bps, since that will always work and CODB will sometimes not work > > under conditions not fully specified here. So, if we are unwilling or > > unable to clarify what those conditions are (e.g., whether at a minimum > > mutual agreement is required), then I think we need to describe this > > procedure of consulting the RTP timestamp as the default behavior and avoid > > giving the impression that CODB should be used to do so. > > > > Additionally, I don't see anything to address my concern about TSVCIS > > parameter decoding. To be clear, the procedure I see this document > > describing is that: > > - TSVCIS gives parameters (and their lengths in bits) to the codec > > described in this document > > - this document specifies how to densely encode those parameters into a > > byetstream > > - RTP transmits that encoded bytestream to the peer > > - the codec specified by this is responsible for turning that encoded > > bystream back into a list of TSVCIS parameters (and their length in bits) > > > > I don't see how that last step is attainable with only the information > > provided by this document. I *assume* that one of the TSVCIS specifications > > has a canonical (ordered) listing of parameters, and that the list of > > parmeters given to this codec in the first step will always be an initial > > prefix of that list, but that's just me guessing at how to make sense of the > > stated procedure given insufficient information. I don't think it's > > appropriate to make the reader of an RFC guess at what to do; we need to > > either say how to do it or give a pointer to an external reference that > > does. > > > > -Ben > > > > On Tue, Oct 29, 2019 at 02:26:09PM -0400, Barry Leiba wrote: > > > Ben, does the -04 version address everything? > > > > > > Barry > > > > > > On Thu, Oct 24, 2019 at 1:42 PM wrote: > > > > > > > > I forgot to address security comments in one email. The changes are: > > > > > > > > Section 8, second paragraph - Suggested edit by reviewer > > > > > > > > (was) > > > > This RTP payload format and the TSVCIS decoder do not exhibit any > > > > significant non-uniformity in the receiver-side computational > > > > complexity for packet processing and thus are unlikely to pose a > > > > denial-of-service threat due to the receipt of pathological data. > > > > Additionally, the RTP payload format does not contain any active > > > > content. > > > > > > > > (now) > > > > This RTP payload format and the TSVCIS decoder, to the best of our > > > > knowledge, do not exhibit any significant non-uniformity in the > > > > receiver-side computational complexity for packet processing and thus > > > > are unlikely to pose a denial-of-service threat due to the receipt of > > > > pathological data. Additionally, the RTP payload format does not > > > > contain any active content. > > > > > > > > > > > > Section 8, third paragraph - Suggested edit by reviewer > > > > > > > > (was) > > > > Please see the security considerations discussed in [RFC6562] > > > > regarding VAD and its effect on bitrates. > > > > > > > > (now) > > > > Please see the security considerations discussed in [RFC6562] > > > > regarding Voice Activity Detect (VAD) and its effect on bitrates. > > > > > > > > Victor > > > > > > > > -----Original Message----- > > > > From: victor.demjanenko@vocal.com > > > > Sent: Thursday, October 24, 2019 10:05 AM > > > > To: 'Roni Even (A)' ; 'Benjamin Kaduk' > > > > ; 'The IESG' > > > > Cc: draft-ietf-payload-tsvcis@ietf.org; 'Ali Begen' > > > > ; avtcore-chairs@ietf.org; avt@ietf.org; > > > > 'Dave Satterlee (Vocal)' > > > > Subject: RE: Benjamin Kaduk's Discuss on > > > > draft-ietf-payload-tsvcis-03: (with DISCUSS and COMMENT) > > > > > > > > Hi Everyone, > > > > > > > > First we want to thank everyone for their review and comments for this > > draft RFC. We believe we reviewed all the comments and suggestions and > > incorporated them adequately in the next draft (04). We'd like to send out > > this list of exact changes in case anyone has additional comments or thinks > > the clarifications are inadequate. We would be most happy to address > > concerns before publishing draft 04 tomorrow. > > > > > > > > With so many emails from a half dozen or more reviewers, we apologize > > that we cannot address each sender individually. We hope this detail is > > sufficient for everyone. > > > > > > > > Again, many thanks to all. > > > > > > > > Victor & Dave > > > > > > > > -------------------------------------------------------------------- > > > > -------------------------- > > > > > > > > Section 1.1 - Suggested reference to RFC 8088 added. > > > > > > > > (was) > > > > Best current practices for writing an RTP payload format > > > > specification were followed [RFC2736]. > > > > > > > > (now) > > > > Best current practices for writing an RTP payload format > > > > specification were followed [RFC2736] [RFC8088]. > > > > > > > > > > > > Section 2, paragraphs 3 and 4 - Suggested edits by reviewers > > > > > > > > (was) > > > > In addition to the augmented speech data, the TSVCIS specification > > > > identifies which speech coder and framing bits are to be encrypted, > > > > and how they are protected by forward error correction (FEC) > > > > techniques (using block codes). At the RTP transport layer, only the > > > > speech coder related bits need to be considered and are conveyed in > > > > unencrypted form. In most IP-based network deployments, standard > > > > link encryption methods (SRTP, VPNs, FIPS 140 link encryptors or Type > > > > 1 Ethernet encryptors) would be used to secure the RTP speech > > > > contents. Further, it is desirable to support the highest voice > > > > quality between endpoints which is only possible without the overhead > > > > of FEC. > > > > > > > > TSVCIS augmented speech data is derived from the signal processing > > > > and data already performed by the MELPe speech coder. For the > > > > purposes of this specification, only the general parameter nature of > > > > TSVCIS will be characterized. Depending on the bandwidth available > > > > (and FEC requirements), a varying number of TSVCIS specific speech > > > > coder parameters need to be transported. These are first byte-packed > > > > and then conveyed from encoder to decoder. > > > > > > > > (now) > > > > In addition to the augmented speech data, the TSVCIS specification > > > > identifies which speech coder and framing bits are to be encrypted, > > > > and how they are protected by forward error correction (FEC) > > > > techniques (using block codes). At the RTP transport layer, only the > > > > speech-coder-related bits need to be considered and are conveyed in > > > > unencrypted form. In most IP-based network deployments, standard > > > > link encryption methods (SRTP, VPNs, FIPS 140 link encryptors or Type > > > > 1 Ethernet encryptors) would be used to secure the RTP speech > > > > contents. > > > > > > > > TSVCIS augmented speech data is derived from the signal processing > > > > and data already performed by the MELPe speech coder. For the > > > > purposes of this specification, only the general parameter nature of > > > > TSVCIS will be characterized. Depending on the bandwidth available > > > > (and FEC requirements), a varying number of TSVCIS-specific speech > > > > coder parameters need to be transported. These are first byte-packed > > > > and then conveyed from encoder to decoder. > > > > > > > > > > > > Section 3, last sentence paragraph 3 - Suggested edit by reviewer > > > > > > > > (was) > > > > When more than one codec data frame is > > > > present in a single RTP packet, the timestamp is, as always, that of > > > > the oldest data frame represented in the RTP packet. > > > > > > > > (now) > > > > When more than one codec data frame is > > > > present in a single RTP packet, the timestamp specified is that of > > > > the oldest data frame represented in the RTP packet. > > > > > > > > > > > > Section 3.1, last paragraph - Clarified permission for MELP 600 > > > > end-to-end framing bit > > > > > > > > (was) > > > > It should be noted that CODB for both the 2400 and 600 bps modes MAY > > > > deviate from the values in Table 1 when bit 55 is used as an end-to- > > > > end framing bit. Frame decoding would remain distinct as CODA being > > > > zero on its own would indicate a 7-byte frame for either rate and the > > > > use of 600 bps speech coding could be deduced from the RTP timestamp > > > > (and anticipated by the SDP negotiations). > > > > > > > > (now) > > > > It should be noted that CODB for MELPe 600 bps mode MAY deviate from > > > > the value in Table 1 when bit 55 is used as an end-to-end framing > > > > bit. Frame decoding would remain distinct as CODA being zero on its > > > > own would indicate a 7-byte frame for either 2400 or 600 bps rate and > > > > the use of 600 bps speech coding could be deduced from the RTP > > > > timestamp (and anticipated by the SDP negotiations). > > > > > > > > > > > > Section 3.2, first paragraph - Clarifications requested by reviewers > > > > > > > > (was) > > > > The TSVCIS augmented speech data as packed parameters MUST be placed > > > > immediately after a corresponding MELPe 2400 bps payload in the same > > > > RTP packet. The packed parameters are counted in octets (TC). In > > > > the preferred placement, shown in Figure 6, a single trailing octet > > > > SHALL be appended to include a two-bit rate code, CODA and CODB, > > > > (both bits set to one) and a six-bit modified count (MTC). The > > > > special modified count value of all ones (representing a MTC value of > > > > 63) SHALL NOT be used for this format as it is used as the indicator > > > > for the alternate packing format shown next. In a standard > > > > implementation, the TSVCIS speech coder uses a minimum of 15 octets > > > > for parameters in octet packed form. The modified count (MTC) MUST > > > > be reduced by 15 from the full octet count (TC). Computed MTC = TC- > > > > 15. This accommodates a maximum of 77 parameter octets (maximum > > > > value of MTC is 62, 77 is the sum of 62+15). > > > > > > > > (now) > > > > The TSVCIS augmented speech data as packed parameters MUST be placed > > > > immediately after a corresponding MELPe 2400 bps payload in the same > > > > RTP packet. The packed parameters are counted in octets (TC). The > > > > preferred placement SHOULD be used for TSVCIS payloads with TC less > > > > than or equal to 77 octets, is shown in Figure 6. In the preferred > > > > placement, a single trailing octet SHALL be appended to include a > > > > two-bit rate code, CODA and CODB, (both bits set to one) and a six- > > > > bit modified count (MTC). The special modified count value of all > > > > ones (representing a MTC value of 63) SHALL NOT be used for this > > > > format as it is used as the indicator for the alternate packing > > > > format shown next. In a standard implementation, the TSVCIS speech > > > > coder uses a minimum of 15 octets for parameters in octet packed > > > > form. The modified count (MTC) MUST be reduced by 15 from the full > > > > octet count (TC). Computed MTC = TC-15. This accommodates a maximum > > > > of 77 parameter octets (maximum value of MTC is 62, 77 is the sum of > > > > 62+15). > > > > > > > > > > > > Section 3.3, first paragraph - Suggested edit by reviewer > > > > > > > > (was) > > > > A TSVCIS RTP packet consists of zero or more TSVCIS coder frames > > > > (each consisting of MELPe and TSVCIS coder data) followed by zero or > > > > one MELPe comfort noise frame. The presence of a comfort noise frame > > > > can be determined by its rate code bits in its last octet. > > > > > > > > (now) > > > > A TSVCIS RTP packet payload consists of zero or more consecutive > > > > TSVCIS coder frames (each consisting of MELPe 2400 and TSVCIS coder > > > > data), with the oldest frame first, followed by zero or one MELPe > > > > comfort noise frame. The presence of a comfort noise frame can be > > > > determined by its rate code bits in its last octet. > > > > > > > > > > > > Section 3.3, fourth paragraph - Clarification requested by reviewers > > > > > > > > (was) > > > > TSVCIS coder frames in a single RTP packet MAY be of different coder > > > > bitrates. With the exception for the variable length TSVCIS > > > > parameter frames, the coder rate bits in the trailing byte identify > > > > the contents and length as per Table 1. > > > > > > > > (now) > > > > TSVCIS coder frames in a single RTP packet MAY have varying TSVCIS > > > > parameter octet counts. Its packed parameter octet count (length) is > > > > indicated in the trailing byte(s). All MELPe frames in a single RTP > > > > packet MUST be of the same coder bitrate. For all MELPe coder > > > > frames, the coder rate bits in the trailing byte identify the > > > > contents and length as per Table 1. > > > > > > > > > > > > Section 4.1 - Editor note removed > > > > > > > > > > > > Section 4.1 - Change controller is now > > > > > > > > (now) > > > > Change controller: IETF, contact > > > > > > > > > > > > Section 5, first paragraph - Suggested edits by reviewers > > > > > > > > (was) > > > > A primary application of TSVCIS is for radio communications of voice > > > > conversations, and discontinuous transmissions are normal. When > > > > TSVCIS is used in an IP network, TSVCIS RTP packet transmissions may > > > > cease and resume frequently. RTP synchronization source (SSRC) > > > > sequence number gaps indicate lost packets to be filled by PLC, while > > > > abrupt loss of RTP packets indicates intended discontinuous > > > > transmissions. > > > > > > > > (now) > > > > A primary application of TSVCIS is for radio communications of voice > > > > conversations, and discontinuous transmissions are normal. When > > > > TSVCIS is used in an IP network, TSVCIS RTP packet transmissions may > > > > cease and resume frequently. RTP synchronization source (SSRC) > > > > sequence number gaps indicate lost packets to be filled by Packet > > > > Loss Concealment (PLC), while abrupt loss of RTP packets indicates > > > > intended discontinuous transmissions. Resumption of voice > > > > transmission SHOULD be indicated by the RTP marker bit (M) set to 1. > > > > > > > > > > > > Section 10 - Added reference > > > > > > > > (added) > > > > [RFC8088] Westerlund, M., "How to Write an RTP Payload Format", > > > > RFC 8088, DOI 10.17487/RFC8088, May 2017, > > > > . > > > > > > > > -------------------------------------------------------------------- > > > > ----------------------------- > > > > > > > > > > > > -----Original Message----- > > > > From: Roni Even (A) > > > > Sent: Sunday, October 6, 2019 2:09 AM > > > > To: victor.demjanenko@vocal.com; 'Benjamin Kaduk' ; > > > > 'The IESG' > > > > Cc: draft-ietf-payload-tsvcis@ietf.org; 'Ali Begen' > > > > ; avtcore-chairs@ietf.org; avt@ietf.org; > > > > 'Dave Satterlee (Vocal)' > > > > Subject: RE: Benjamin Kaduk's Discuss on > > > > draft-ietf-payload-tsvcis-03: (with DISCUSS and COMMENT) > > > > > > > > Hi, > > > > About the reference to TSVCIS. > > > > The RTP payload is about how to encapsulate the payload in an RTP > > packet. The objective is to define how an RTP stack can insert the tsvcis > > frames and extract the tsvcis frames from the RTP packet. Typically it is > > not required to understand the payload structure in order to be able to > > perform the encapsulation. > > > > This is why the reference to the payload is Informational and we did > > > > not require to have it publically available. If there is a need to > > > > understand the payload itself for the encapsulating than we need > > > > more information in the RTP payload specification and a publically > > > > available normative reference. I think this is not the case here > > > > > > > > Roni Even > > > > > > > > AVTCore co-chair (ex Payload) > > > > > > > > -----Original Message----- > > > > From: victor.demjanenko@vocal.com > > > > [mailto:victor.demjanenko@vocal.com] > > > > Sent: Saturday, October 05, 2019 12:18 AM > > > > To: 'Benjamin Kaduk'; 'The IESG' > > > > Cc: draft-ietf-payload-tsvcis@ietf.org; 'Ali Begen'; > > avtcore-chairs@ietf.org; avt@ietf.org; 'Victor Demjanenko, Ph.D.'; 'Dave > > Satterlee (Vocal)' > > > > Subject: RE: Benjamin Kaduk's Discuss on > > > > draft-ietf-payload-tsvcis-03: (with DISCUSS and COMMENT) > > > > > > > > Everyone, > > > > > > > > Thanks for the comments. I think I mis-understood the ambiguity with > > respect to to changing rates within a RTP packet. That was not plan. An > > RTP packet must have MELP speech frames of the same rate. What is possible > > is that the amount of augmented TSVCIS speech data may vary from one speech > > frame to the next. This allows for a dynamic VDR as suggested by the NRL > > paper. So an RTP packet may have varying TSVCIS data but must always have > > MELPe 2400 data. > > > > > > > > Again backwards parsing is necessary but the timestamp uniformly > > increments 22.5msec per combined MELP/TSVCIS speech frame. > > > > > > > > The NRL is a good public reference on the VDR aspects. The actual > > TSVCIS spec we had was FOUO so we could not replicate its detail. (I > > believe a later spec is public or at least partially public. I am trying to > > get this.) The opaque data is pretty obvious with the TSVCIS spec in hand. > > > > > > > > We will address the issues/concerns raised next week. Other business > > had priority. > > > > > > > > Thank you and enjoy the weekend. > > > > > > > > Regards, > > > > > > > > Victor & Dave > > > > > > > > -----Original Message----- > > > > From: Benjamin Kaduk via Datatracker > > > > Sent: Wednesday, October 2, 2019 10:40 PM > > > > To: The IESG > > > > Cc: draft-ietf-payload-tsvcis@ietf.org; Ali Begen > > > > ; avtcore-chairs@ietf.org; > > > > ali.begen@networked.media; avt@ietf.org > > > > Subject: Benjamin Kaduk's Discuss on draft-ietf-payload-tsvcis-03: > > > > (with DISCUSS and COMMENT) > > > > > > > > Benjamin Kaduk has entered the following ballot position for > > > > draft-ietf-payload-tsvcis-03: 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-payload-tsvcis/ > > > > > > > > > > > > > > > > -------------------------------------------------------------------- > > > > -- > > > > DISCUSS: > > > > -------------------------------------------------------------------- > > > > -- > > > > > > > > I support Magnus' point about the time-ordering of adjacent frames in a > > packet. > > > > > > > > Additionally, I am not sure that there's quite enough here to be > > interoperably implementable. Specifically, we seem to be lacking a > > description of how an encoder or decoder knows which TSVCIS parameters, and > > in what order, to byte-pack or unpack, respectively. One might surmise that > > there is a canonical listing in [TSVCIS], but this document does not say > > that, and furthermore [TSVCIS] is only listed as an informative reference. > > (I couldn't get my hands on my copy, at least on short notice.) If we > > limited ourselves to treating the TSVCIS parameters as an entirely opaque > > blob (codec, convey these N octets to the peer with the appropriate one- or > > two-byte trailer for payload type identification and framing), that would be > > interoperably implementable, since the black-box bits are up to some other > > codec to interpret. > > > > > > > > In a similar vein, we mention but do not completely specify the > > potential for using CODB as an end-to-end framing bit, in Section 3.1 (see > > Comment), which is not interoperably implementable without further details. > > > > > > > > > > > > -------------------------------------------------------------------- > > > > -- > > > > COMMENT: > > > > -------------------------------------------------------------------- > > > > -- > > > > > > > > Where is [TSVCIS] available? > > > > > > > > Is [NRLVDR] the same as > > > > https://apps.dtic.mil/dtic/tr/fulltext/u2/a588068.pdf ? A URL in the > > references would be helpful. > > > > > > > > Is additional TSVCIS data only present after 2400bps MELPe and the first > > thing to get dropped under bandwidth pressure? The abstract and > > introduction imply this by calling out MELPe 2400 bps speech parameters > > explicitly, but Section 3 says that TSVCIS augments standard 600, 1200, and > > 2400 bps MELP frames. > > > > > > > > It's helpful that Section 3.3 gives some general guidance for decoding > > this payload type ("[t]he way to determine the number of TSVCIS/MELPe frames > > is to identify each frame type and length"), but I think some generic > > considerations would be very helpful to the reader much earlier, along the > > lines of "MELPe and TSVCIS data payloads are decoded from the end, using the > > CODA and CODB (and, if necessary, CODC and others) bits to determine the > > type of payload. For MELPe payloads the type also indicates the payload > > length, whereas for TSVCIS data an additional length field is present, in > > one of two possible formats. A TSVCIS coder frame consists of a MELPe data > > payload followed by zero or one TSVCIS data payload; after the TSVCIS > > payload's presence/length is determined, then the preceding MELPe payload > > can be determined and decoded. Per Section 3.3, multiple TSVCIS frames can > > be present in a single RTP packet." This (or something like it) would also > > serve to clarify the role of the COD* bits, which is otherwise only > > implicitly introduced. > > > > > > > > Section 1.1 > > > > > > > > RFC 2736 is BCP 36 (but it's updated by RFC 8088 which is for some > > reason an Informational document and not part of BCP 36?!). > > > > > > > > Section 2 > > > > > > > > In addition to the augmented speech data, the TSVCIS specification > > > > identifies which speech coder and framing bits are to be encrypted, > > > > and how they are protected by forward error correction (FEC) > > > > techniques (using block codes). At the RTP transport layer, only the > > > > speech coder related bits need to be considered and are conveyed in > > > > unencrypted form. In most IP-based network deployments, standard > > > > > > > > Am I reading this correctly that this text is just summarizing what's in > > the TSVCIS spec in terms of what needs to be in unencrypted form, so the > > "only the speech coder related bits[...]" is not new information from this > > document? I'm not sure I agree with the conclusion, regardless -- won't the > > (MELPe) speech coder bits be enough to convey the semantic content of the > > audio stream, something that one might desire to keep confidential? > > > > > > > > link encryption methods (SRTP, VPNs, FIPS 140 link encryptors or Type > > > > 1 Ethernet encryptors) would be used to secure the RTP speech > > > > contents. Further, it is desirable to support the highest voice > > > > quality between endpoints which is only possible without the overhead > > > > of FEC. > > > > > > > > I think I'm missing a step in how this conclusion was reached. > > > > > > > > TSVCIS will be characterized. Depending on the bandwidth available > > > > (and FEC requirements), a varying number of TSVCIS specific speech > > > > coder parameters need to be transported. These are first byte-packed > > > > and then conveyed from encoder to decoder. > > > > > > > > Per the Discuss point, how do I know which parameters need to be > > transported, and in what order? > > > > > > > > Byte packing of TSVCIS speech data into packed parameters is > > > > processed as per the following example: > > > > > > > > Three-bit field: bits A, B, and C (A is MSB, C is LSB) > > > > Five-bit field: bits D, E, F, G, and H (D is MSB, H is LSB) > > > > > > > > MSB LSB > > > > 0 1 2 3 4 5 6 7 > > > > +------+------+------+------+------+------+------+------+ > > > > | H | G | F | E | D | C | B | A | > > > > +------+------+------+------+------+------+------+------+ > > > > > > > > This packing method places the three-bit field "first" in the lowest > > > > bits followed by the next five-bit field. Parameters may be split > > > > between octets with the most significant bits in the earlier octet. > > > > Any unfilled bits in the last octet MUST be filled with zero. > > > > > > > > I agree with Adam that this is very unclear. A is the MSB of the > > three-bit field but the LSB of the octet overall? > > > > We probably need an example of splitting a parameter across octets as > > well, to get the bit ordering right. > > > > > > > > Section 3.1 > > > > > > > > It should be noted that CODB for both the 2400 and 600 bps modes MAY > > > > deviate from the values in Table 1 when bit 55 is used as an end-to- > > > > end framing bit. Frame decoding would remain distinct as CODA > > > > being > > > > > > > > Where is the use of CODB as an end-to-end framing bit defined? If we're > > going to provide neither a complete description of how to do it nor a > > reference to a better description, we probably shouldn't mention it at all. > > > > > > > > Section 3.2 > > > > > > > > RTP packet. The packed parameters are counted in octets (TC). In > > > > the preferred placement, shown in Figure 6, a single trailing octet > > > > SHALL be appended to include a two-bit rate code, CODA and CODB, > > > > > > > > I'd consider saying something about this being the preferred format > > > > ("placement") due to its shorter length than the alternative, and say > > that it "SHOULD be used for TSVCIS payloads with TC less than or equal to 77 > > octetes". > > > > > > > > Section 3.3 > > > > > > > > When a longer packetization interval is used, is that indicated by > > signaling or RTP timestamps or otherwise? > > > > > > > > TSVCIS coder frames in a single RTP packet MAY be of different coder > > > > bitrates. With the exception for the variable length TSVCIS > > > > parameter frames, the coder rate bits in the trailing byte identify > > > > the contents and length as per Table 1. > > > > > > > > Maybe also note that the penultimate octet gives the length there? > > > > > > > > Information describing the number of frames contained in an RTP > > > > packet is not transmitted as part of the RTP payload. The way to > > > > determine the number of TSVCIS/MELPe frames is to identify each frame > > > > type and length thereby counting the total number of octets within > > > > the RTP packet. > > > > > > > > terminology nit: if a frame is the combination of MELPe and TSVCIS > > payload data units then there are two layres of decoding to get a length for > > the frame, since we have to get the TSVCIS length and then the MELPe length. > > > > > > > > Section 4.2 > > > > > > > > Parameter "ptime" cannot be used for the purpose of specifying > > > > the > > > > > > > > nit: missing article ("The parameter") > > > > > > > > will be impossible to distinguish which mode is about to be used > > > > (e.g., when ptime=68, it would be impossible to distinguish if the > > > > packet is carrying one frame of 67.5 ms or three frames of 22.5 ms). > > > > > > > > So how is the operating mode determined, then? > > > > (I think this is the same question I asked above) > > > > > > > > Section 4.4 > > > > > > > > For example, if offerer bitrates are "2400,600" and answer bitrates > > > > are "600,2400", the initial bitrate is 600. If other bitrates are > > > > provided by the answerer, any common bitrate between the offer and > > > > answer MAY be used at any time in the future. Activation of these > > > > other common bitrates is beyond the scope of this document. > > > > > > > > It seems important to specify whether this requires a new O/A exchange > > or can be done "spontaneously" by just encoding different frame types. > > > > (It seems like the latter is possible, on first glance, and this is > > > > implied by Section 3.3's discussion of mixing them in a single > > > > packet.) > > > > > > > > Section 5 > > > > > > > > Please expand PLC at first use (not second). > > > > > > > > Section 6 > > > > > > > > I don't understand the PLC usage. Is the idea that a receiver, on > > seeing an SSRC gap, constructs fictitious PLC frames to "fill the gap" > > > > and passes the resulting stream to the decoder? > > > > > > > > Section 8 > > > > > > > > and important considerations in [RFC7201]. Applications SHOULD use > > > > one or more appropriate strong security mechanisms. The rest of this > > > > section discusses the security-impacting properties of the payload > > > > format itself. > > > > > > > > I thought we described TSVCIS itself (much earlier in the document) as > > requiring encryption for some data; wouldn't that translate to a "MUST" > > > > here and not a "SHOULD"? > > > > > > > > > > > > > > From nobody Fri Feb 14 05:37:30 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D919120089 for ; Fri, 14 Feb 2020 05:37:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.101 X-Spam-Level: *** X-Spam-Status: No, score=3.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_SUMOF=5, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, 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 XvTr0WLSB7P7 for ; Fri, 14 Feb 2020 05:37:23 -0800 (PST) Received: from cuda.olm1.com (cuda.olm1.com [72.236.255.32]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 35A731200B4 for ; Fri, 14 Feb 2020 05:37:22 -0800 (PST) X-ASG-Debug-ID: 1581686456-1378646d531997f0001-mFDwdl Received: from host105.olm1.com (host105.olm1.com [72.236.255.15]) by cuda.olm1.com with ESMTP id eOEaYQdZZVuJB2t0 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 14 Feb 2020 08:20:56 -0500 (EST) X-Barracuda-Envelope-From: victor.demjanenko@vocal.com X-Barracuda-Effective-Source-IP: host105.olm1.com[72.236.255.15] X-Barracuda-Apparent-Source-IP: 72.236.255.15 Received: from HERTELLT (rrcs-72-43-202-98.nys.biz.rr.com [72.43.202.98]) by host105.olm1.com (Postfix) with ESMTPSA id B2AC4B8A4F6; Fri, 14 Feb 2020 08:20:55 -0500 (EST) From: To: "'Barry Leiba'" , "'Benjamin Kaduk'" Cc: "'Roni Even \(A\)'" , "'The IESG'" , "'Catherine Meadows'" , "'IETF SecDir'" , , "'Ali Begen'" , , , "'Dave Satterlee \(Vocal\)'" , "'IETF discussion list'" , , References: <157007038502.8860.1558861534319247512.idtracker@ietfa.amsl.com> <001601d57af9$405efcf0$c11cf6d0$@vocal.com> <6E58094ECC8D8344914996DAD28F1CCD23D79BC0@DGGEMM506-MBX.china.huawei.com> <034a01d58a73$f4d3a1c0$de7ae540$@vocal.com> <037e01d58a92$72287510$56795f30$@vocal.com> <20191101001153.GQ88302@kduck.mit.edu> <06e101d59f15$ee937b30$cbba7190$@vocal.com> <20191125064606.GL32847@mit.edu> In-Reply-To: Date: Fri, 14 Feb 2020 08:20:54 -0500 X-ASG-Orig-Subj: RE: Benjamin Kaduk's Discuss on draft-ietf-payload-tsvcis-03: (with DISCUSS and COMMENT) Message-ID: <00c601d5e339$965ebd90$c31c38b0$@vocal.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQKF5W0DvD42FGb/qFKkK3bBTKTeXwLglFUwAo/9rkMBQrixDgL+oF71AnDrF6QCpTAEFwHoAU1LAQ62R/UB0kz9YqYeH1og Content-Language: en-us X-Barracuda-Connect: host105.olm1.com[72.236.255.15] X-Barracuda-Start-Time: 1581686456 X-Barracuda-Encrypted: ECDHE-RSA-AES256-GCM-SHA384 X-Barracuda-URL: https://72.236.255.32:443/cgi-mod/mark.cgi X-Barracuda-BRTS-Status: 1 X-Virus-Scanned: by bsmtpd at olm1.com X-Barracuda-Scan-Msg-Size: 42104 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=4.7 tests=NO_REAL_NAME X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.79995 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 NO_REAL_NAME From: does not include a real name Archived-At: Subject: Re: [secdir] Benjamin Kaduk's Discuss on draft-ietf-payload-tsvcis-03: (with DISCUSS and COMMENT) X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2020 13:37:27 -0000 HI Barry, Thanks for recalling this was still outstanding. I had emailed Ben just = after the holidays and did not realize we had no response. The below is = what we suggested to Ben to address concerns he raised. -------------------- Hi Ben, Hope your holidays were good. Our were both good and busy. Deliveries = for two NASA projects and the holidays kept us from responding sooner. = But we do want to get this draft completed. With your permission, I=E2=80=99d like to address your comments = directly, resolve what changes we should make and then publish a new = version with a summary of our out-of-band discussions. We don=E2=80=99t = have a lot of experience with drafting such documents and would like to = know exactly what is needed to make this draft acceptable. I believe there are two comments/issues to address: 1) CODA, CODB Your comment ends by stating: =E2=80=9C(Or, of course, the use of CODB = as an alternating 1/0 bit as the framing usage could be documented = instead.)=E2=80=9D We can do this as follows: (original) It should be noted that CODB for MELPe 600 bps mode MAY deviate from the value in Table 1 when bit 55 is used as an end-to-end framing bit. Frame decoding would remain distinct as CODA being zero on its own would indicate a 7-byte frame for either 2400 or 600 bps rate and the use of 600 bps speech coding could be deduced from the RTP timestamp (and anticipated by the SDP negotiations). (adding =E2=80=9Calternating 1/0=E2=80=9D) It should be noted that CODB for MELPe 600 bps mode MAY deviate from the value in Table 1 when bit 55 is used as an alternating 1/0 = end-to-end framing bit. Frame decoding would remain distinct as CODA being zero on its own would indicate a 7-byte frame for either 2400 or 600 bps rate and the use of 600 bps speech coding could be deduced from the RTP timestamp (and anticipated by the SDP negotiations). I think this change would be sufficient to address your concern about = what to expect for CODB. 2. Packing and unpacking You are correct that I am trying to vaguely describe a middle layer shim = that is neither RTP nor speech coder. So it definitely does need to be = clear. The vagueness comes from the speech coder description being a = FOUO document. Its now unclassified so I can potentially say more (and = I did make some enhancements of the parameter description already). =20 So I am trying to understand exactly what you think is vague in our = current description: TSVCIS augmented speech data is derived from the signal processing and data already performed by the MELPe speech coder. For the purposes of this specification, only the general parameter nature of TSVCIS will be characterized. Depending on the bandwidth available (and FEC requirements), a varying number of TSVCIS-specific speech coder parameters need to be transported. These are first byte-packed and then conveyed from encoder to decoder. Byte packing of TSVCIS speech data into packed parameters is processed as per the following example: Three-bit field: bits A, B, and C (A is MSB, C is LSB) Five-bit field: bits D, E, F, G, and H (D is MSB, H is LSB) MSB LSB 0 1 2 3 4 5 6 7 +------+------+------+------+------+------+------+------+ | H | G | F | E | D | C | B | A |=20 +------+------+------+------+------+------+------+------+ This packing method places the three-bit field "first" in the lowest bits followed by the next five-bit field. Parameters may be split between octets with the most significant bits in the earlier octet. Any unfilled bits in the last octet MUST be filled with zero. In order to accommodate a varying amount of TSVCIS augmented speech data, it is only necessary to specify the number of octets containing the packed TSVCIS parameters. The encoding to do so is presented in Section 3.2. TSVCIS specifically uses the NRL VDR in two configurations using 15 and 35 packed octet parameters [TSVCIS]. =20 The speech coder description of the parameters is the following: =20 So the three bit pitch is first (bits 56 to 58), followed by a five bit = amplitude (bits 59 to 63) and then an array of spectral components, each = 8-bit wide (starting at bit 64). Based on this information, I=E2=80=99m not sure what we should add to = our draft to make the description of packing/unpacking clearer. Can you = make any suggestions or does this table help you with what you did not = know? (I don=E2=80=99t think I should put this table into the draft RFC = however.) Thanks for your attention and comments. Victor & Dave -----Original Message----- From: Barry Leiba =20 Sent: Friday, February 14, 2020 7:38 AM To: Benjamin Kaduk Cc: victor.demjanenko@vocal.com; Roni Even (A) ; = The IESG ; Catherine Meadows = ; IETF SecDir ; = draft-ietf-payload-tsvcis@ietf.org; Ali Begen = ; avtcore-chairs@ietf.org; avt@ietf.org; Dave = Satterlee (Vocal) ; IETF discussion list = ; draft-ietf-payload-tsvcis.all@ietf.org Subject: Re: Benjamin Kaduk's Discuss on draft-ietf-payload-tsvcis-03: = (with DISCUSS and COMMENT) This is still outstanding, since November. Victor, where are we on this = one? Barry On Mon, Nov 25, 2019 at 1:46 AM Benjamin Kaduk wrote: > > Hi Victor, > > On Tue, Nov 19, 2019 at 03:14:21PM -0500, victor.demjanenko@vocal.com = wrote: > > Hi Ben, > > > > Sorry I overlooked sending you a response. I would like to address=20 > > the two concerns you have by explaining what the speech coders are = doing. > > Thanks for the extra clarifications. To supply one of my own: I'm not = > concerned that the protocol doesn't work as implemented, but just want = > to make sure that the document includes enough information to admit=20 > new implementations without guesswork. That is to say, "either tell=20 > me how to do it or tell me where to look that tells me how to do it". > > > WRT to 600 bps MELP, there is one TSVCIS mode that uses one bit=20 > > beyond the 54-bit frame for MELP 600 as a frame sync which = alternates between frames. > > With two or more MELP 600bps frames in one RTP packet, if any frame=20 > > indicates 600 bps by CODA being 0 and CODB being 1, then we know the = > > stream is 600bps. If there is a single frame in an RTP packet, you=20 > > can still deduce this by looking at every other RTP packet (every=20 > > other MELP 600bps > > frame) and by the timestamp advance. Most likely the two ends would = > > negotiate 600 bps in SDP anyways so there really should not be a=20 > > problem. I know it's not pretty but its workable. I hope this=20 > > explanation helps you with the concerns for this issue. > > In this case, the use as an "end-to-end framing bit" (i.e., the=20 > alternating behavior you describe above) is not explicitly stated; one = > might imagine a scheme where the framing usage is to have the bit=20 > cycle through 1, 1, 0, and 0, or some other scheme. I'd suggest to=20 > note in the document that if any instance of (CODA, CODB) =3D=3D (0, = 1) is=20 > observed, then the 600bps mode is in use. It might also be helpful to = > include the observation that two successive MELPe payloads with CODA=20 > =3D=3D CODB =3D=3D 0 indicates the 2400bps mode (and that seeing them = in a=20 > single RTP packet is decisive, whereas additional information about=20 > packet non-loss would be needed in the one-MELPe-frame-per-RTP-packet=20 > case), but that would be a fair bit of additional text and might be=20 > diminishing returns. (Or, of course, the use of CODB as an=20 > alternating 1/0 bit as the framing usage could be documented > instead.) > > > As for the TSVCIS parameter packing/unpacking, this is really=20 > > simple. There is exactly on three bit parameter, exactly one five=20 > > bit parameter and a variable number of eight bit parameters. In our = > > view, the speech coder itself (or a wrapper for it) is responsible=20 > > for preparing the block of octets. RTP then just transports it. On = > > receive, the complementary wrapper reverses the packing operation. =20 > > I hope this clarifies and explains the simplicity. > > That's exactly what I expected to happen; however, it's not what I=20 > believe the current text of the document is describing. Specifically, = > I think that the current text implies that the "preparing the block of = > octets" and "complementary wrapper reverses the packing operation" are = > supposed to be part of the RTP payload format that this document=20 > describes, but this document does not have enough information to=20 > actually perform those operations reversibly. If the packing is to be = > done in the speech coder, then this document doesn't need to talk=20 > about the packing at all (e.g., at the end of Section 2); if we need=20 > to keep the packing/wrapper in this document then we need to indicate=20 > that there's a defined priority order for the (8-octet) TSVCIS=20 > parameters in the TSVCIS references, to allow the packing/unpacking to = be deterministic. > > Thanks, > > Ben > > > > > -----Original Message----- > > From: Benjamin Kaduk > > Sent: Thursday, October 31, 2019 8:12 PM > > To: Barry Leiba > > Cc: victor.demjanenko@vocal.com; Roni Even (A)=20 > > ; The IESG ; Catherine Meadows=20 > > ; IETF SecDir ;=20 > > draft-ietf-payload-tsvcis@ietf.org; Ali Begen=20 > > ; avtcore-chairs@ietf.org; avt@ietf.org;=20 > > Dave Satterlee (Vocal) ; IETF discussion=20 > > list ; draft-ietf-payload-tsvcis.all@ietf.org > > Subject: Re: Benjamin Kaduk's Discuss on=20 > > draft-ietf-payload-tsvcis-03: (with DISCUSS and COMMENT) > > > > I don't think so, unfortunately. > > > > I do see the clarification about CODB's potential for deviation from = > > Table 1, that only the 600 bps MELPe is allowed to deviate, and that = > > CODA gets us to "it's one of 2400 or 600 bps" and the RTP timestamp=20 > > disambiguates that > > 600 bps is in use. But, it seems that this means that the recipient = > > in general should not rely on CODB to differentiate 600 from 2400=20 > > bps, and instead is more robustly implemented by *always* using the=20 > > RTP timestamp to detect 600 bps, since that will always work and=20 > > CODB will sometimes not work under conditions not fully specified=20 > > here. So, if we are unwilling or unable to clarify what those=20 > > conditions are (e.g., whether at a minimum mutual agreement is=20 > > required), then I think we need to describe this procedure of=20 > > consulting the RTP timestamp as the default behavior and avoid = giving the impression that CODB should be used to do so. > > > > Additionally, I don't see anything to address my concern about=20 > > TSVCIS parameter decoding. To be clear, the procedure I see this=20 > > document describing is that: > > - TSVCIS gives parameters (and their lengths in bits) to the codec > > described in this document > > - this document specifies how to densely encode those parameters = into a > > byetstream > > - RTP transmits that encoded bytestream to the peer > > - the codec specified by this is responsible for turning that = encoded > > bystream back into a list of TSVCIS parameters (and their length=20 > > in bits) > > > > I don't see how that last step is attainable with only the=20 > > information provided by this document. I *assume* that one of the=20 > > TSVCIS specifications has a canonical (ordered) listing of=20 > > parameters, and that the list of parmeters given to this codec in=20 > > the first step will always be an initial prefix of that list, but=20 > > that's just me guessing at how to make sense of the stated procedure = > > given insufficient information. I don't think it's appropriate to=20 > > make the reader of an RFC guess at what to do; we need to either say = > > how to do it or give a pointer to an external reference that does. > > > > -Ben > > > > On Tue, Oct 29, 2019 at 02:26:09PM -0400, Barry Leiba wrote: > > > Ben, does the -04 version address everything? > > > > > > Barry > > > > > > On Thu, Oct 24, 2019 at 1:42 PM = wrote: > > > > > > > > I forgot to address security comments in one email. The changes = are: > > > > > > > > Section 8, second paragraph - Suggested edit by reviewer > > > > > > > > (was) > > > > This RTP payload format and the TSVCIS decoder do not exhibit = any > > > > significant non-uniformity in the receiver-side computational > > > > complexity for packet processing and thus are unlikely to = pose a > > > > denial-of-service threat due to the receipt of pathological = data. > > > > Additionally, the RTP payload format does not contain any = active > > > > content. > > > > > > > > (now) > > > > This RTP payload format and the TSVCIS decoder, to the best = of our > > > > knowledge, do not exhibit any significant non-uniformity in = the > > > > receiver-side computational complexity for packet processing = and thus > > > > are unlikely to pose a denial-of-service threat due to the = receipt of > > > > pathological data. Additionally, the RTP payload format does = not > > > > contain any active content. > > > > > > > > > > > > Section 8, third paragraph - Suggested edit by reviewer > > > > > > > > (was) > > > > Please see the security considerations discussed in [RFC6562] > > > > regarding VAD and its effect on bitrates. > > > > > > > > (now) > > > > Please see the security considerations discussed in [RFC6562] > > > > regarding Voice Activity Detect (VAD) and its effect on = bitrates. > > > > > > > > Victor > > > > > > > > -----Original Message----- > > > > From: victor.demjanenko@vocal.com > > > > Sent: Thursday, October 24, 2019 10:05 AM > > > > To: 'Roni Even (A)' ; 'Benjamin Kaduk' > > > > ; 'The IESG' > > > > Cc: draft-ietf-payload-tsvcis@ietf.org; 'Ali Begen' > > > > ; avtcore-chairs@ietf.org;=20 > > > > avt@ietf.org; 'Dave Satterlee (Vocal)'=20 > > > > > > > > Subject: RE: Benjamin Kaduk's Discuss on > > > > draft-ietf-payload-tsvcis-03: (with DISCUSS and COMMENT) > > > > > > > > Hi Everyone, > > > > > > > > First we want to thank everyone for their review and comments=20 > > > > for this > > draft RFC. We believe we reviewed all the comments and suggestions=20 > > and incorporated them adequately in the next draft (04). We'd like=20 > > to send out this list of exact changes in case anyone has additional = > > comments or thinks the clarifications are inadequate. We would be=20 > > most happy to address concerns before publishing draft 04 tomorrow. > > > > > > > > With so many emails from a half dozen or more reviewers, we=20 > > > > apologize > > that we cannot address each sender individually. We hope this=20 > > detail is sufficient for everyone. > > > > > > > > Again, many thanks to all. > > > > > > > > Victor & Dave > > > > > > > > ---------------------------------------------------------------- > > > > ---- > > > > -------------------------- > > > > > > > > Section 1.1 - Suggested reference to RFC 8088 added. > > > > > > > > (was) > > > > Best current practices for writing an RTP payload format > > > > specification were followed [RFC2736]. > > > > > > > > (now) > > > > Best current practices for writing an RTP payload format > > > > specification were followed [RFC2736] [RFC8088]. > > > > > > > > > > > > Section 2, paragraphs 3 and 4 - Suggested edits by reviewers > > > > > > > > (was) > > > > In addition to the augmented speech data, the TSVCIS = specification > > > > identifies which speech coder and framing bits are to be = encrypted, > > > > and how they are protected by forward error correction (FEC) > > > > techniques (using block codes). At the RTP transport layer, = only the > > > > speech coder related bits need to be considered and are = conveyed in > > > > unencrypted form. In most IP-based network deployments, = standard > > > > link encryption methods (SRTP, VPNs, FIPS 140 link encryptors = or Type > > > > 1 Ethernet encryptors) would be used to secure the RTP speech > > > > contents. Further, it is desirable to support the highest = voice > > > > quality between endpoints which is only possible without the = overhead > > > > of FEC. > > > > > > > > TSVCIS augmented speech data is derived from the signal = processing > > > > and data already performed by the MELPe speech coder. For = the > > > > purposes of this specification, only the general parameter = nature of > > > > TSVCIS will be characterized. Depending on the bandwidth = available > > > > (and FEC requirements), a varying number of TSVCIS specific = speech > > > > coder parameters need to be transported. These are first = byte-packed > > > > and then conveyed from encoder to decoder. > > > > > > > > (now) > > > > In addition to the augmented speech data, the TSVCIS = specification > > > > identifies which speech coder and framing bits are to be = encrypted, > > > > and how they are protected by forward error correction (FEC) > > > > techniques (using block codes). At the RTP transport layer, = only the > > > > speech-coder-related bits need to be considered and are = conveyed in > > > > unencrypted form. In most IP-based network deployments, = standard > > > > link encryption methods (SRTP, VPNs, FIPS 140 link encryptors = or Type > > > > 1 Ethernet encryptors) would be used to secure the RTP speech > > > > contents. > > > > > > > > TSVCIS augmented speech data is derived from the signal = processing > > > > and data already performed by the MELPe speech coder. For = the > > > > purposes of this specification, only the general parameter = nature of > > > > TSVCIS will be characterized. Depending on the bandwidth = available > > > > (and FEC requirements), a varying number of TSVCIS-specific = speech > > > > coder parameters need to be transported. These are first = byte-packed > > > > and then conveyed from encoder to decoder. > > > > > > > > > > > > Section 3, last sentence paragraph 3 - Suggested edit by=20 > > > > reviewer > > > > > > > > (was) > > > > When more than one codec data frame is > > > > present in a single RTP packet, the timestamp is, as always, = that of > > > > the oldest data frame represented in the RTP packet. > > > > > > > > (now) > > > > When more than one codec data frame is > > > > present in a single RTP packet, the timestamp specified is = that of > > > > the oldest data frame represented in the RTP packet. > > > > > > > > > > > > Section 3.1, last paragraph - Clarified permission for MELP 600=20 > > > > end-to-end framing bit > > > > > > > > (was) > > > > It should be noted that CODB for both the 2400 and 600 bps = modes MAY > > > > deviate from the values in Table 1 when bit 55 is used as an = end-to- > > > > end framing bit. Frame decoding would remain distinct as = CODA being > > > > zero on its own would indicate a 7-byte frame for either rate = and the > > > > use of 600 bps speech coding could be deduced from the RTP = timestamp > > > > (and anticipated by the SDP negotiations). > > > > > > > > (now) > > > > It should be noted that CODB for MELPe 600 bps mode MAY = deviate from > > > > the value in Table 1 when bit 55 is used as an end-to-end = framing > > > > bit. Frame decoding would remain distinct as CODA being zero = on its > > > > own would indicate a 7-byte frame for either 2400 or 600 bps = rate and > > > > the use of 600 bps speech coding could be deduced from the = RTP > > > > timestamp (and anticipated by the SDP negotiations). > > > > > > > > > > > > Section 3.2, first paragraph - Clarifications requested by=20 > > > > reviewers > > > > > > > > (was) > > > > The TSVCIS augmented speech data as packed parameters MUST be = placed > > > > immediately after a corresponding MELPe 2400 bps payload in = the same > > > > RTP packet. The packed parameters are counted in octets = (TC). In > > > > the preferred placement, shown in Figure 6, a single trailing = octet > > > > SHALL be appended to include a two-bit rate code, CODA and = CODB, > > > > (both bits set to one) and a six-bit modified count (MTC). = The > > > > special modified count value of all ones (representing a MTC = value of > > > > 63) SHALL NOT be used for this format as it is used as the = indicator > > > > for the alternate packing format shown next. In a standard > > > > implementation, the TSVCIS speech coder uses a minimum of 15 = octets > > > > for parameters in octet packed form. The modified count = (MTC) MUST > > > > be reduced by 15 from the full octet count (TC). Computed = MTC =3D TC- > > > > 15. This accommodates a maximum of 77 parameter octets = (maximum > > > > value of MTC is 62, 77 is the sum of 62+15). > > > > > > > > (now) > > > > The TSVCIS augmented speech data as packed parameters MUST be = placed > > > > immediately after a corresponding MELPe 2400 bps payload in = the same > > > > RTP packet. The packed parameters are counted in octets = (TC). The > > > > preferred placement SHOULD be used for TSVCIS payloads with = TC less > > > > than or equal to 77 octets, is shown in Figure 6. In the = preferred > > > > placement, a single trailing octet SHALL be appended to = include a > > > > two-bit rate code, CODA and CODB, (both bits set to one) and = a six- > > > > bit modified count (MTC). The special modified count value = of all > > > > ones (representing a MTC value of 63) SHALL NOT be used for = this > > > > format as it is used as the indicator for the alternate = packing > > > > format shown next. In a standard implementation, the TSVCIS = speech > > > > coder uses a minimum of 15 octets for parameters in octet = packed > > > > form. The modified count (MTC) MUST be reduced by 15 from = the full > > > > octet count (TC). Computed MTC =3D TC-15. This accommodates = a maximum > > > > of 77 parameter octets (maximum value of MTC is 62, 77 is the = sum of > > > > 62+15). > > > > > > > > > > > > Section 3.3, first paragraph - Suggested edit by reviewer > > > > > > > > (was) > > > > A TSVCIS RTP packet consists of zero or more TSVCIS coder = frames > > > > (each consisting of MELPe and TSVCIS coder data) followed by = zero or > > > > one MELPe comfort noise frame. The presence of a comfort = noise frame > > > > can be determined by its rate code bits in its last octet. > > > > > > > > (now) > > > > A TSVCIS RTP packet payload consists of zero or more = consecutive > > > > TSVCIS coder frames (each consisting of MELPe 2400 and TSVCIS = coder > > > > data), with the oldest frame first, followed by zero or one = MELPe > > > > comfort noise frame. The presence of a comfort noise frame = can be > > > > determined by its rate code bits in its last octet. > > > > > > > > > > > > Section 3.3, fourth paragraph - Clarification requested by=20 > > > > reviewers > > > > > > > > (was) > > > > TSVCIS coder frames in a single RTP packet MAY be of = different coder > > > > bitrates. With the exception for the variable length TSVCIS > > > > parameter frames, the coder rate bits in the trailing byte = identify > > > > the contents and length as per Table 1. > > > > > > > > (now) > > > > TSVCIS coder frames in a single RTP packet MAY have varying = TSVCIS > > > > parameter octet counts. Its packed parameter octet count = (length) is > > > > indicated in the trailing byte(s). All MELPe frames in a = single RTP > > > > packet MUST be of the same coder bitrate. For all MELPe = coder > > > > frames, the coder rate bits in the trailing byte identify the > > > > contents and length as per Table 1. > > > > > > > > > > > > Section 4.1 - Editor note removed > > > > > > > > > > > > Section 4.1 - Change controller is now > > > > > > > > (now) > > > > Change controller: IETF, contact > > > > > > > > > > > > Section 5, first paragraph - Suggested edits by reviewers > > > > > > > > (was) > > > > A primary application of TSVCIS is for radio communications = of voice > > > > conversations, and discontinuous transmissions are normal. = When > > > > TSVCIS is used in an IP network, TSVCIS RTP packet = transmissions may > > > > cease and resume frequently. RTP synchronization source = (SSRC) > > > > sequence number gaps indicate lost packets to be filled by = PLC, while > > > > abrupt loss of RTP packets indicates intended discontinuous > > > > transmissions. > > > > > > > > (now) > > > > A primary application of TSVCIS is for radio communications = of voice > > > > conversations, and discontinuous transmissions are normal. = When > > > > TSVCIS is used in an IP network, TSVCIS RTP packet = transmissions may > > > > cease and resume frequently. RTP synchronization source = (SSRC) > > > > sequence number gaps indicate lost packets to be filled by = Packet > > > > Loss Concealment (PLC), while abrupt loss of RTP packets = indicates > > > > intended discontinuous transmissions. Resumption of voice > > > > transmission SHOULD be indicated by the RTP marker bit (M) = set to 1. > > > > > > > > > > > > Section 10 - Added reference > > > > > > > > (added) > > > > [RFC8088] Westerlund, M., "How to Write an RTP Payload = Format", > > > > RFC 8088, DOI 10.17487/RFC8088, May 2017, > > > > . > > > > > > > > ---------------------------------------------------------------- > > > > ---- > > > > ----------------------------- > > > > > > > > > > > > -----Original Message----- > > > > From: Roni Even (A) > > > > Sent: Sunday, October 6, 2019 2:09 AM > > > > To: victor.demjanenko@vocal.com; 'Benjamin Kaduk'=20 > > > > ; 'The IESG' > > > > Cc: draft-ietf-payload-tsvcis@ietf.org; 'Ali Begen' > > > > ; avtcore-chairs@ietf.org;=20 > > > > avt@ietf.org; 'Dave Satterlee (Vocal)'=20 > > > > > > > > Subject: RE: Benjamin Kaduk's Discuss on > > > > draft-ietf-payload-tsvcis-03: (with DISCUSS and COMMENT) > > > > > > > > Hi, > > > > About the reference to TSVCIS. > > > > The RTP payload is about how to encapsulate the payload in an=20 > > > > RTP > > packet. The objective is to define how an RTP stack can insert the=20 > > tsvcis frames and extract the tsvcis frames from the RTP packet.=20 > > Typically it is not required to understand the payload structure in=20 > > order to be able to perform the encapsulation. > > > > This is why the reference to the payload is Informational and we = > > > > did not require to have it publically available. If there is a=20 > > > > need to understand the payload itself for the encapsulating than = > > > > we need more information in the RTP payload specification and a=20 > > > > publically available normative reference. I think this is not=20 > > > > the case here > > > > > > > > Roni Even > > > > > > > > AVTCore co-chair (ex Payload) > > > > > > > > -----Original Message----- > > > > From: victor.demjanenko@vocal.com=20 > > > > [mailto:victor.demjanenko@vocal.com] > > > > Sent: Saturday, October 05, 2019 12:18 AM > > > > To: 'Benjamin Kaduk'; 'The IESG' > > > > Cc: draft-ietf-payload-tsvcis@ietf.org; 'Ali Begen'; > > avtcore-chairs@ietf.org; avt@ietf.org; 'Victor Demjanenko, Ph.D.';=20 > > 'Dave Satterlee (Vocal)' > > > > Subject: RE: Benjamin Kaduk's Discuss on > > > > draft-ietf-payload-tsvcis-03: (with DISCUSS and COMMENT) > > > > > > > > Everyone, > > > > > > > > Thanks for the comments. I think I mis-understood the ambiguity = > > > > with > > respect to to changing rates within a RTP packet. That was not=20 > > plan. An RTP packet must have MELP speech frames of the same rate. = > > What is possible is that the amount of augmented TSVCIS speech data=20 > > may vary from one speech frame to the next. This allows for a=20 > > dynamic VDR as suggested by the NRL paper. So an RTP packet may=20 > > have varying TSVCIS data but must always have MELPe 2400 data. > > > > > > > > Again backwards parsing is necessary but the timestamp uniformly > > increments 22.5msec per combined MELP/TSVCIS speech frame. > > > > > > > > The NRL is a good public reference on the VDR aspects. The=20 > > > > actual > > TSVCIS spec we had was FOUO so we could not replicate its detail. =20 > > (I believe a later spec is public or at least partially public. I=20 > > am trying to get this.) The opaque data is pretty obvious with the = TSVCIS spec in hand. > > > > > > > > We will address the issues/concerns raised next week. Other=20 > > > > business > > had priority. > > > > > > > > Thank you and enjoy the weekend. > > > > > > > > Regards, > > > > > > > > Victor & Dave > > > > > > > > -----Original Message----- > > > > From: Benjamin Kaduk via Datatracker > > > > Sent: Wednesday, October 2, 2019 10:40 PM > > > > To: The IESG > > > > Cc: draft-ietf-payload-tsvcis@ietf.org; Ali Begen=20 > > > > ; avtcore-chairs@ietf.org;=20 > > > > ali.begen@networked.media; avt@ietf.org > > > > Subject: Benjamin Kaduk's Discuss on = draft-ietf-payload-tsvcis-03: > > > > (with DISCUSS and COMMENT) > > > > > > > > Benjamin Kaduk has entered the following ballot position for > > > > draft-ietf-payload-tsvcis-03: Discuss > > > > > > > > When responding, please keep the subject line intact and reply=20 > > > > to all email addresses included in the To and CC lines. (Feel=20 > > > > 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-payload-tsvcis/ > > > > > > > > > > > > > > > > ---------------------------------------------------------------- > > > > ---- > > > > -- > > > > DISCUSS: > > > > ---------------------------------------------------------------- > > > > ---- > > > > -- > > > > > > > > I support Magnus' point about the time-ordering of adjacent=20 > > > > frames in a > > packet. > > > > > > > > Additionally, I am not sure that there's quite enough here to be > > interoperably implementable. Specifically, we seem to be lacking a=20 > > description of how an encoder or decoder knows which TSVCIS=20 > > parameters, and in what order, to byte-pack or unpack, respectively. = =20 > > One might surmise that there is a canonical listing in [TSVCIS], but = > > this document does not say that, and furthermore [TSVCIS] is only = listed as an informative reference. > > (I couldn't get my hands on my copy, at least on short notice.) If=20 > > we limited ourselves to treating the TSVCIS parameters as an=20 > > entirely opaque blob (codec, convey these N octets to the peer with=20 > > the appropriate one- or two-byte trailer for payload type=20 > > identification and framing), that would be interoperably=20 > > implementable, since the black-box bits are up to some other codec = to interpret. > > > > > > > > In a similar vein, we mention but do not completely specify the > > potential for using CODB as an end-to-end framing bit, in Section=20 > > 3.1 (see Comment), which is not interoperably implementable without = further details. > > > > > > > > > > > > ---------------------------------------------------------------- > > > > ---- > > > > -- > > > > COMMENT: > > > > ---------------------------------------------------------------- > > > > ---- > > > > -- > > > > > > > > Where is [TSVCIS] available? > > > > > > > > Is [NRLVDR] the same as > > > > https://apps.dtic.mil/dtic/tr/fulltext/u2/a588068.pdf ? A URL=20 > > > > in the > > references would be helpful. > > > > > > > > Is additional TSVCIS data only present after 2400bps MELPe and=20 > > > > the first > > thing to get dropped under bandwidth pressure? The abstract and=20 > > introduction imply this by calling out MELPe 2400 bps speech=20 > > parameters explicitly, but Section 3 says that TSVCIS augments=20 > > standard 600, 1200, and > > 2400 bps MELP frames. > > > > > > > > It's helpful that Section 3.3 gives some general guidance for=20 > > > > decoding > > this payload type ("[t]he way to determine the number of=20 > > TSVCIS/MELPe frames is to identify each frame type and length"), but = > > I think some generic considerations would be very helpful to the=20 > > reader much earlier, along the lines of "MELPe and TSVCIS data=20 > > payloads are decoded from the end, using the CODA and CODB (and, if=20 > > necessary, CODC and others) bits to determine the type of payload. =20 > > For MELPe payloads the type also indicates the payload length,=20 > > whereas for TSVCIS data an additional length field is present, in=20 > > one of two possible formats. A TSVCIS coder frame consists of a=20 > > MELPe data payload followed by zero or one TSVCIS data payload;=20 > > after the TSVCIS payload's presence/length is determined, then the=20 > > preceding MELPe payload can be determined and decoded. Per Section=20 > > 3.3, multiple TSVCIS frames can be present in a single RTP packet." = > > This (or something like it) would also serve to clarify the role of = the COD* bits, which is otherwise only implicitly introduced. > > > > > > > > Section 1.1 > > > > > > > > RFC 2736 is BCP 36 (but it's updated by RFC 8088 which is for=20 > > > > some > > reason an Informational document and not part of BCP 36?!). > > > > > > > > Section 2 > > > > > > > > In addition to the augmented speech data, the TSVCIS = specification > > > > identifies which speech coder and framing bits are to be = encrypted, > > > > and how they are protected by forward error correction (FEC) > > > > techniques (using block codes). At the RTP transport layer, = only the > > > > speech coder related bits need to be considered and are = conveyed in > > > > unencrypted form. In most IP-based network deployments,=20 > > > > standard > > > > > > > > Am I reading this correctly that this text is just summarizing=20 > > > > what's in > > the TSVCIS spec in terms of what needs to be in unencrypted form, so = > > the "only the speech coder related bits[...]" is not new information = > > from this document? I'm not sure I agree with the conclusion,=20 > > regardless -- won't the > > (MELPe) speech coder bits be enough to convey the semantic content=20 > > of the audio stream, something that one might desire to keep = confidential? > > > > > > > > link encryption methods (SRTP, VPNs, FIPS 140 link encryptors = or Type > > > > 1 Ethernet encryptors) would be used to secure the RTP speech > > > > contents. Further, it is desirable to support the highest = voice > > > > quality between endpoints which is only possible without the = overhead > > > > of FEC. > > > > > > > > I think I'm missing a step in how this conclusion was reached. > > > > > > > > TSVCIS will be characterized. Depending on the bandwidth = available > > > > (and FEC requirements), a varying number of TSVCIS specific = speech > > > > coder parameters need to be transported. These are first = byte-packed > > > > and then conveyed from encoder to decoder. > > > > > > > > Per the Discuss point, how do I know which parameters need to be > > transported, and in what order? > > > > > > > > Byte packing of TSVCIS speech data into packed parameters is > > > > processed as per the following example: > > > > > > > > Three-bit field: bits A, B, and C (A is MSB, C is LSB) > > > > Five-bit field: bits D, E, F, G, and H (D is MSB, H is=20 > > > > LSB) > > > > > > > > MSB LSB > > > > 0 1 2 3 4 5 6 7 > > > > = +------+------+------+------+------+------+------+------+ > > > > | H | G | F | E | D | C | B | A = | > > > > =20 > > > > +------+------+------+------+------+------+------+------+ > > > > > > > > This packing method places the three-bit field "first" in the = lowest > > > > bits followed by the next five-bit field. Parameters may be = split > > > > between octets with the most significant bits in the earlier = octet. > > > > Any unfilled bits in the last octet MUST be filled with zero. > > > > > > > > I agree with Adam that this is very unclear. A is the MSB of=20 > > > > the > > three-bit field but the LSB of the octet overall? > > > > We probably need an example of splitting a parameter across=20 > > > > octets as > > well, to get the bit ordering right. > > > > > > > > Section 3.1 > > > > > > > > It should be noted that CODB for both the 2400 and 600 bps = modes MAY > > > > deviate from the values in Table 1 when bit 55 is used as an = end-to- > > > > end framing bit. Frame decoding would remain distinct as=20 > > > > CODA being > > > > > > > > Where is the use of CODB as an end-to-end framing bit defined? =20 > > > > If we're > > going to provide neither a complete description of how to do it nor=20 > > a reference to a better description, we probably shouldn't mention = it at all. > > > > > > > > Section 3.2 > > > > > > > > RTP packet. The packed parameters are counted in octets = (TC). In > > > > the preferred placement, shown in Figure 6, a single trailing = octet > > > > SHALL be appended to include a two-bit rate code, CODA and=20 > > > > CODB, > > > > > > > > I'd consider saying something about this being the preferred=20 > > > > format > > > > ("placement") due to its shorter length than the alternative,=20 > > > > and say > > that it "SHOULD be used for TSVCIS payloads with TC less than or=20 > > equal to 77 octetes". > > > > > > > > Section 3.3 > > > > > > > > When a longer packetization interval is used, is that indicated=20 > > > > by > > signaling or RTP timestamps or otherwise? > > > > > > > > TSVCIS coder frames in a single RTP packet MAY be of = different coder > > > > bitrates. With the exception for the variable length TSVCIS > > > > parameter frames, the coder rate bits in the trailing byte = identify > > > > the contents and length as per Table 1. > > > > > > > > Maybe also note that the penultimate octet gives the length = there? > > > > > > > > Information describing the number of frames contained in an = RTP > > > > packet is not transmitted as part of the RTP payload. The = way to > > > > determine the number of TSVCIS/MELPe frames is to identify = each frame > > > > type and length thereby counting the total number of octets = within > > > > the RTP packet. > > > > > > > > terminology nit: if a frame is the combination of MELPe and=20 > > > > TSVCIS > > payload data units then there are two layres of decoding to get a=20 > > length for the frame, since we have to get the TSVCIS length and = then the MELPe length. > > > > > > > > Section 4.2 > > > > > > > > Parameter "ptime" cannot be used for the purpose of=20 > > > > specifying the > > > > > > > > nit: missing article ("The parameter") > > > > > > > > will be impossible to distinguish which mode is about to be = used > > > > (e.g., when ptime=3D68, it would be impossible to distinguish = if the > > > > packet is carrying one frame of 67.5 ms or three frames of = 22.5 ms). > > > > > > > > So how is the operating mode determined, then? > > > > (I think this is the same question I asked above) > > > > > > > > Section 4.4 > > > > > > > > For example, if offerer bitrates are "2400,600" and answer = bitrates > > > > are "600,2400", the initial bitrate is 600. If other = bitrates are > > > > provided by the answerer, any common bitrate between the = offer and > > > > answer MAY be used at any time in the future. Activation of = these > > > > other common bitrates is beyond the scope of this document. > > > > > > > > It seems important to specify whether this requires a new O/A=20 > > > > exchange > > or can be done "spontaneously" by just encoding different frame = types. > > > > (It seems like the latter is possible, on first glance, and this = > > > > is implied by Section 3.3's discussion of mixing them in a=20 > > > > single > > > > packet.) > > > > > > > > Section 5 > > > > > > > > Please expand PLC at first use (not second). > > > > > > > > Section 6 > > > > > > > > I don't understand the PLC usage. Is the idea that a receiver,=20 > > > > on > > seeing an SSRC gap, constructs fictitious PLC frames to "fill the = gap" > > > > and passes the resulting stream to the decoder? > > > > > > > > Section 8 > > > > > > > > and important considerations in [RFC7201]. Applications = SHOULD use > > > > one or more appropriate strong security mechanisms. The rest = of this > > > > section discusses the security-impacting properties of the = payload > > > > format itself. > > > > > > > > I thought we described TSVCIS itself (much earlier in the=20 > > > > document) as > > requiring encryption for some data; wouldn't that translate to a = "MUST" > > > > here and not a "SHOULD"? > > > > > > > > > > > > > > From nobody Fri Feb 14 11:43:47 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3312120A99; Fri, 14 Feb 2020 11:43:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.801 X-Spam-Level: X-Spam-Status: No, score=0.801 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_SUMOF=5, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, 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 gYtTYumvHZCs; Fri, 14 Feb 2020 11:43:38 -0800 (PST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 AE950120B37; Fri, 14 Feb 2020 11:43:36 -0800 (PST) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 01EJhLg3026351 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 14 Feb 2020 14:43:24 -0500 Date: Fri, 14 Feb 2020 11:43:21 -0800 From: Benjamin Kaduk To: victor.demjanenko@vocal.com, "'Barry Leiba'" Cc: "'Roni Even (A)'" , "'The IESG'" , "'Catherine Meadows'" , "'IETF SecDir'" , draft-ietf-payload-tsvcis@ietf.org, "'Ali Begen'" , avtcore-chairs@ietf.org, avt@ietf.org, "'Dave Satterlee (Vocal)'" , "'IETF discussion list'" , draft-ietf-payload-tsvcis.all@ietf.org Message-ID: <20200214194321.GF43385@kduck.mit.edu> References: <001601d57af9$405efcf0$c11cf6d0$@vocal.com> <6E58094ECC8D8344914996DAD28F1CCD23D79BC0@DGGEMM506-MBX.china.huawei.com> <034a01d58a73$f4d3a1c0$de7ae540$@vocal.com> <037e01d58a92$72287510$56795f30$@vocal.com> <20191101001153.GQ88302@kduck.mit.edu> <06e101d59f15$ee937b30$cbba7190$@vocal.com> <20191125064606.GL32847@mit.edu> <00c601d5e339$965ebd90$c31c38b0$@vocal.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <00c601d5e339$965ebd90$c31c38b0$@vocal.com> User-Agent: Mutt/1.12.1 (2019-06-15) Archived-At: Subject: Re: [secdir] Benjamin Kaduk's Discuss on draft-ietf-payload-tsvcis-03: (with DISCUSS and COMMENT) X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2020 19:43:43 -0000 Hi Barry, As Victor notes, this one was/is waiting on me; he did reply (offlist) on 15 January but I seem to have missed it amid a deluge of other mail that arrived at that time. Thanks for the reminder, and thanks Victor for re-sending the comments. (inline) On Fri, Feb 14, 2020 at 08:20:54AM -0500, victor.demjanenko@vocal.com wrote: > HI Barry, > > Thanks for recalling this was still outstanding. I had emailed Ben just after the holidays and did not realize we had no response. The below is what we suggested to Ben to address concerns he raised. > > -------------------- > Hi Ben, > > Hope your holidays were good. Our were both good and busy. Deliveries for two NASA projects and the holidays kept us from responding sooner. But we do want to get this draft completed. > > With your permission, I’d like to address your comments directly, resolve what changes we should make and then publish a new version with a summary of our out-of-band discussions. We don’t have a lot of experience with drafting such documents and would like to know exactly what is needed to make this draft acceptable. > > I believe there are two comments/issues to address: > > 1) CODA, CODB > > Your comment ends by stating: “(Or, of course, the use of CODB as an alternating 1/0 bit as the framing usage could be documented instead.)” We can do this as follows: > > (original) > It should be noted that CODB for MELPe 600 bps mode MAY deviate from > the value in Table 1 when bit 55 is used as an end-to-end framing > bit. Frame decoding would remain distinct as CODA being zero on its > own would indicate a 7-byte frame for either 2400 or 600 bps rate and > the use of 600 bps speech coding could be deduced from the RTP > timestamp (and anticipated by the SDP negotiations). > > (adding “alternating 1/0”) > It should be noted that CODB for MELPe 600 bps mode MAY deviate from > the value in Table 1 when bit 55 is used as an alternating 1/0 end-to-end framing > bit. Frame decoding would remain distinct as CODA being zero on its > own would indicate a 7-byte frame for either 2400 or 600 bps rate and > the use of 600 bps speech coding could be deduced from the RTP > timestamp (and anticipated by the SDP negotiations). > > I think this change would be sufficient to address your concern about what to expect for CODB. This looks like the minimal sufficient change, yes. (I use "minimal" because I would say more if I was writing it, but I don't think I can insist that you write it the way I would -- it's your document after all!) > 2. Packing and unpacking > > You are correct that I am trying to vaguely describe a middle layer shim that is neither RTP nor speech coder. So it definitely does need to be clear. The vagueness comes from the speech coder description being a FOUO document. Its now unclassified so I can potentially say more (and I did make some enhancements of the parameter description already). > > So I am trying to understand exactly what you think is vague in our current description: > > TSVCIS augmented speech data is derived from the signal processing > and data already performed by the MELPe speech coder. For the > purposes of this specification, only the general parameter nature of > TSVCIS will be characterized. Depending on the bandwidth available > (and FEC requirements), a varying number of TSVCIS-specific speech > coder parameters need to be transported. These are first byte-packed > and then conveyed from encoder to decoder. > > Byte packing of TSVCIS speech data into packed parameters is > processed as per the following example: > > Three-bit field: bits A, B, and C (A is MSB, C is LSB) > Five-bit field: bits D, E, F, G, and H (D is MSB, H is LSB) > > MSB LSB > 0 1 2 3 4 5 6 7 > +------+------+------+------+------+------+------+------+ > | H | G | F | E | D | C | B | A | > +------+------+------+------+------+------+------+------+ > > This packing method places the three-bit field "first" in the lowest > bits followed by the next five-bit field. Parameters may be split > between octets with the most significant bits in the earlier octet. > Any unfilled bits in the last octet MUST be filled with zero. [not actually relevant to the Discuss part, but if there is always exactly one 3-bit parameter and one 5-bit parameter, then this text allowing splitting across octets will never be used and is potentially confusing to mention.] > In order to accommodate a varying amount of TSVCIS augmented speech > data, it is only necessary to specify the number of octets containing > the packed TSVCIS parameters. The encoding to do so is presented in I think the "only necessary to specify the number of octets" is the key stumbling point, for me -- I need to know the number of octets as well as the order of the parameters within the list, which is more information than just the number of octets. > Section 3.2. TSVCIS specifically uses the NRL VDR in two > configurations using 15 and 35 packed octet parameters [TSVCIS]. I think I failed to internalize the "two configurations using 15 and 35 packed octet parameters" the first time I read the document, as this does help give the reader a clue that [TSVCIS] gives a good picture of what parameters go where. So it seems like we could easily append to that, for "using a fixed set of 15 and 35 packed octet parameters in a fixed order [TSVCIS]" and that would resolve my concerns. > The speech coder description of the parameters is the following: > > > > So the three bit pitch is first (bits 56 to 58), followed by a five bit amplitude (bits 59 to 63) and then an array of spectral components, each 8-bit wide (starting at bit 64). [And maybe TSVCIS specifes that the spectral components are derived from some fundamental harmonic decomposition that naturally quantizes to a number-of-parameters/accuracy tradeoff with a natural order. If so, we could also rely on that instead of my proposed change above; let me know if you want to explore that path further.] > Based on this information, I’m not sure what we should add to our draft to make the description of packing/unpacking clearer. Can you make any suggestions or does this table help you with what you did not know? (I don’t think I should put this table into the draft RFC however.) Hopefully the above helps to clarify. Thanks, and sorry for the delay. -Ben > Thanks for your attention and comments. > > Victor & Dave > > > > -----Original Message----- > From: Barry Leiba > Sent: Friday, February 14, 2020 7:38 AM > To: Benjamin Kaduk > Cc: victor.demjanenko@vocal.com; Roni Even (A) ; The IESG ; Catherine Meadows ; IETF SecDir ; draft-ietf-payload-tsvcis@ietf.org; Ali Begen ; avtcore-chairs@ietf.org; avt@ietf.org; Dave Satterlee (Vocal) ; IETF discussion list ; draft-ietf-payload-tsvcis.all@ietf.org > Subject: Re: Benjamin Kaduk's Discuss on draft-ietf-payload-tsvcis-03: (with DISCUSS and COMMENT) > > This is still outstanding, since November. Victor, where are we on this one? > > Barry > > On Mon, Nov 25, 2019 at 1:46 AM Benjamin Kaduk wrote: > > > > Hi Victor, > > > > On Tue, Nov 19, 2019 at 03:14:21PM -0500, victor.demjanenko@vocal.com wrote: > > > Hi Ben, > > > > > > Sorry I overlooked sending you a response. I would like to address > > > the two concerns you have by explaining what the speech coders are doing. > > > > Thanks for the extra clarifications. To supply one of my own: I'm not > > concerned that the protocol doesn't work as implemented, but just want > > to make sure that the document includes enough information to admit > > new implementations without guesswork. That is to say, "either tell > > me how to do it or tell me where to look that tells me how to do it". > > > > > WRT to 600 bps MELP, there is one TSVCIS mode that uses one bit > > > beyond the 54-bit frame for MELP 600 as a frame sync which alternates between frames. > > > With two or more MELP 600bps frames in one RTP packet, if any frame > > > indicates 600 bps by CODA being 0 and CODB being 1, then we know the > > > stream is 600bps. If there is a single frame in an RTP packet, you > > > can still deduce this by looking at every other RTP packet (every > > > other MELP 600bps > > > frame) and by the timestamp advance. Most likely the two ends would > > > negotiate 600 bps in SDP anyways so there really should not be a > > > problem. I know it's not pretty but its workable. I hope this > > > explanation helps you with the concerns for this issue. > > > > In this case, the use as an "end-to-end framing bit" (i.e., the > > alternating behavior you describe above) is not explicitly stated; one > > might imagine a scheme where the framing usage is to have the bit > > cycle through 1, 1, 0, and 0, or some other scheme. I'd suggest to > > note in the document that if any instance of (CODA, CODB) == (0, 1) is > > observed, then the 600bps mode is in use. It might also be helpful to > > include the observation that two successive MELPe payloads with CODA > > == CODB == 0 indicates the 2400bps mode (and that seeing them in a > > single RTP packet is decisive, whereas additional information about > > packet non-loss would be needed in the one-MELPe-frame-per-RTP-packet > > case), but that would be a fair bit of additional text and might be > > diminishing returns. (Or, of course, the use of CODB as an > > alternating 1/0 bit as the framing usage could be documented > > instead.) > > > > > As for the TSVCIS parameter packing/unpacking, this is really > > > simple. There is exactly on three bit parameter, exactly one five > > > bit parameter and a variable number of eight bit parameters. In our > > > view, the speech coder itself (or a wrapper for it) is responsible > > > for preparing the block of octets. RTP then just transports it. On > > > receive, the complementary wrapper reverses the packing operation. > > > I hope this clarifies and explains the simplicity. > > > > That's exactly what I expected to happen; however, it's not what I > > believe the current text of the document is describing. Specifically, > > I think that the current text implies that the "preparing the block of > > octets" and "complementary wrapper reverses the packing operation" are > > supposed to be part of the RTP payload format that this document > > describes, but this document does not have enough information to > > actually perform those operations reversibly. If the packing is to be > > done in the speech coder, then this document doesn't need to talk > > about the packing at all (e.g., at the end of Section 2); if we need > > to keep the packing/wrapper in this document then we need to indicate > > that there's a defined priority order for the (8-octet) TSVCIS > > parameters in the TSVCIS references, to allow the packing/unpacking to be deterministic. > > > > Thanks, > > > > Ben > > > > > > > > -----Original Message----- > > > From: Benjamin Kaduk > > > Sent: Thursday, October 31, 2019 8:12 PM > > > To: Barry Leiba > > > Cc: victor.demjanenko@vocal.com; Roni Even (A) > > > ; The IESG ; Catherine Meadows > > > ; IETF SecDir ; > > > draft-ietf-payload-tsvcis@ietf.org; Ali Begen > > > ; avtcore-chairs@ietf.org; avt@ietf.org; > > > Dave Satterlee (Vocal) ; IETF discussion > > > list ; draft-ietf-payload-tsvcis.all@ietf.org > > > Subject: Re: Benjamin Kaduk's Discuss on > > > draft-ietf-payload-tsvcis-03: (with DISCUSS and COMMENT) > > > > > > I don't think so, unfortunately. > > > > > > I do see the clarification about CODB's potential for deviation from > > > Table 1, that only the 600 bps MELPe is allowed to deviate, and that > > > CODA gets us to "it's one of 2400 or 600 bps" and the RTP timestamp > > > disambiguates that > > > 600 bps is in use. But, it seems that this means that the recipient > > > in general should not rely on CODB to differentiate 600 from 2400 > > > bps, and instead is more robustly implemented by *always* using the > > > RTP timestamp to detect 600 bps, since that will always work and > > > CODB will sometimes not work under conditions not fully specified > > > here. So, if we are unwilling or unable to clarify what those > > > conditions are (e.g., whether at a minimum mutual agreement is > > > required), then I think we need to describe this procedure of > > > consulting the RTP timestamp as the default behavior and avoid giving the impression that CODB should be used to do so. > > > > > > Additionally, I don't see anything to address my concern about > > > TSVCIS parameter decoding. To be clear, the procedure I see this > > > document describing is that: > > > - TSVCIS gives parameters (and their lengths in bits) to the codec > > > described in this document > > > - this document specifies how to densely encode those parameters into a > > > byetstream > > > - RTP transmits that encoded bytestream to the peer > > > - the codec specified by this is responsible for turning that encoded > > > bystream back into a list of TSVCIS parameters (and their length > > > in bits) > > > > > > I don't see how that last step is attainable with only the > > > information provided by this document. I *assume* that one of the > > > TSVCIS specifications has a canonical (ordered) listing of > > > parameters, and that the list of parmeters given to this codec in > > > the first step will always be an initial prefix of that list, but > > > that's just me guessing at how to make sense of the stated procedure > > > given insufficient information. I don't think it's appropriate to > > > make the reader of an RFC guess at what to do; we need to either say > > > how to do it or give a pointer to an external reference that does. > > > > > > -Ben > > > > > > On Tue, Oct 29, 2019 at 02:26:09PM -0400, Barry Leiba wrote: > > > > Ben, does the -04 version address everything? > > > > > > > > Barry > > > > > > > > On Thu, Oct 24, 2019 at 1:42 PM wrote: > > > > > > > > > > I forgot to address security comments in one email. The changes are: > > > > > > > > > > Section 8, second paragraph - Suggested edit by reviewer > > > > > > > > > > (was) > > > > > This RTP payload format and the TSVCIS decoder do not exhibit any > > > > > significant non-uniformity in the receiver-side computational > > > > > complexity for packet processing and thus are unlikely to pose a > > > > > denial-of-service threat due to the receipt of pathological data. > > > > > Additionally, the RTP payload format does not contain any active > > > > > content. > > > > > > > > > > (now) > > > > > This RTP payload format and the TSVCIS decoder, to the best of our > > > > > knowledge, do not exhibit any significant non-uniformity in the > > > > > receiver-side computational complexity for packet processing and thus > > > > > are unlikely to pose a denial-of-service threat due to the receipt of > > > > > pathological data. Additionally, the RTP payload format does not > > > > > contain any active content. > > > > > > > > > > > > > > > Section 8, third paragraph - Suggested edit by reviewer > > > > > > > > > > (was) > > > > > Please see the security considerations discussed in [RFC6562] > > > > > regarding VAD and its effect on bitrates. > > > > > > > > > > (now) > > > > > Please see the security considerations discussed in [RFC6562] > > > > > regarding Voice Activity Detect (VAD) and its effect on bitrates. > > > > > > > > > > Victor > > > > > > > > > > -----Original Message----- > > > > > From: victor.demjanenko@vocal.com > > > > > Sent: Thursday, October 24, 2019 10:05 AM > > > > > To: 'Roni Even (A)' ; 'Benjamin Kaduk' > > > > > ; 'The IESG' > > > > > Cc: draft-ietf-payload-tsvcis@ietf.org; 'Ali Begen' > > > > > ; avtcore-chairs@ietf.org; > > > > > avt@ietf.org; 'Dave Satterlee (Vocal)' > > > > > > > > > > Subject: RE: Benjamin Kaduk's Discuss on > > > > > draft-ietf-payload-tsvcis-03: (with DISCUSS and COMMENT) > > > > > > > > > > Hi Everyone, > > > > > > > > > > First we want to thank everyone for their review and comments > > > > > for this > > > draft RFC. We believe we reviewed all the comments and suggestions > > > and incorporated them adequately in the next draft (04). We'd like > > > to send out this list of exact changes in case anyone has additional > > > comments or thinks the clarifications are inadequate. We would be > > > most happy to address concerns before publishing draft 04 tomorrow. > > > > > > > > > > With so many emails from a half dozen or more reviewers, we > > > > > apologize > > > that we cannot address each sender individually. We hope this > > > detail is sufficient for everyone. > > > > > > > > > > Again, many thanks to all. > > > > > > > > > > Victor & Dave > > > > > > > > > > ---------------------------------------------------------------- > > > > > ---- > > > > > -------------------------- > > > > > > > > > > Section 1.1 - Suggested reference to RFC 8088 added. > > > > > > > > > > (was) > > > > > Best current practices for writing an RTP payload format > > > > > specification were followed [RFC2736]. > > > > > > > > > > (now) > > > > > Best current practices for writing an RTP payload format > > > > > specification were followed [RFC2736] [RFC8088]. > > > > > > > > > > > > > > > Section 2, paragraphs 3 and 4 - Suggested edits by reviewers > > > > > > > > > > (was) > > > > > In addition to the augmented speech data, the TSVCIS specification > > > > > identifies which speech coder and framing bits are to be encrypted, > > > > > and how they are protected by forward error correction (FEC) > > > > > techniques (using block codes). At the RTP transport layer, only the > > > > > speech coder related bits need to be considered and are conveyed in > > > > > unencrypted form. In most IP-based network deployments, standard > > > > > link encryption methods (SRTP, VPNs, FIPS 140 link encryptors or Type > > > > > 1 Ethernet encryptors) would be used to secure the RTP speech > > > > > contents. Further, it is desirable to support the highest voice > > > > > quality between endpoints which is only possible without the overhead > > > > > of FEC. > > > > > > > > > > TSVCIS augmented speech data is derived from the signal processing > > > > > and data already performed by the MELPe speech coder. For the > > > > > purposes of this specification, only the general parameter nature of > > > > > TSVCIS will be characterized. Depending on the bandwidth available > > > > > (and FEC requirements), a varying number of TSVCIS specific speech > > > > > coder parameters need to be transported. These are first byte-packed > > > > > and then conveyed from encoder to decoder. > > > > > > > > > > (now) > > > > > In addition to the augmented speech data, the TSVCIS specification > > > > > identifies which speech coder and framing bits are to be encrypted, > > > > > and how they are protected by forward error correction (FEC) > > > > > techniques (using block codes). At the RTP transport layer, only the > > > > > speech-coder-related bits need to be considered and are conveyed in > > > > > unencrypted form. In most IP-based network deployments, standard > > > > > link encryption methods (SRTP, VPNs, FIPS 140 link encryptors or Type > > > > > 1 Ethernet encryptors) would be used to secure the RTP speech > > > > > contents. > > > > > > > > > > TSVCIS augmented speech data is derived from the signal processing > > > > > and data already performed by the MELPe speech coder. For the > > > > > purposes of this specification, only the general parameter nature of > > > > > TSVCIS will be characterized. Depending on the bandwidth available > > > > > (and FEC requirements), a varying number of TSVCIS-specific speech > > > > > coder parameters need to be transported. These are first byte-packed > > > > > and then conveyed from encoder to decoder. > > > > > > > > > > > > > > > Section 3, last sentence paragraph 3 - Suggested edit by > > > > > reviewer > > > > > > > > > > (was) > > > > > When more than one codec data frame is > > > > > present in a single RTP packet, the timestamp is, as always, that of > > > > > the oldest data frame represented in the RTP packet. > > > > > > > > > > (now) > > > > > When more than one codec data frame is > > > > > present in a single RTP packet, the timestamp specified is that of > > > > > the oldest data frame represented in the RTP packet. > > > > > > > > > > > > > > > Section 3.1, last paragraph - Clarified permission for MELP 600 > > > > > end-to-end framing bit > > > > > > > > > > (was) > > > > > It should be noted that CODB for both the 2400 and 600 bps modes MAY > > > > > deviate from the values in Table 1 when bit 55 is used as an end-to- > > > > > end framing bit. Frame decoding would remain distinct as CODA being > > > > > zero on its own would indicate a 7-byte frame for either rate and the > > > > > use of 600 bps speech coding could be deduced from the RTP timestamp > > > > > (and anticipated by the SDP negotiations). > > > > > > > > > > (now) > > > > > It should be noted that CODB for MELPe 600 bps mode MAY deviate from > > > > > the value in Table 1 when bit 55 is used as an end-to-end framing > > > > > bit. Frame decoding would remain distinct as CODA being zero on its > > > > > own would indicate a 7-byte frame for either 2400 or 600 bps rate and > > > > > the use of 600 bps speech coding could be deduced from the RTP > > > > > timestamp (and anticipated by the SDP negotiations). > > > > > > > > > > > > > > > Section 3.2, first paragraph - Clarifications requested by > > > > > reviewers > > > > > > > > > > (was) > > > > > The TSVCIS augmented speech data as packed parameters MUST be placed > > > > > immediately after a corresponding MELPe 2400 bps payload in the same > > > > > RTP packet. The packed parameters are counted in octets (TC). In > > > > > the preferred placement, shown in Figure 6, a single trailing octet > > > > > SHALL be appended to include a two-bit rate code, CODA and CODB, > > > > > (both bits set to one) and a six-bit modified count (MTC). The > > > > > special modified count value of all ones (representing a MTC value of > > > > > 63) SHALL NOT be used for this format as it is used as the indicator > > > > > for the alternate packing format shown next. In a standard > > > > > implementation, the TSVCIS speech coder uses a minimum of 15 octets > > > > > for parameters in octet packed form. The modified count (MTC) MUST > > > > > be reduced by 15 from the full octet count (TC). Computed MTC = TC- > > > > > 15. This accommodates a maximum of 77 parameter octets (maximum > > > > > value of MTC is 62, 77 is the sum of 62+15). > > > > > > > > > > (now) > > > > > The TSVCIS augmented speech data as packed parameters MUST be placed > > > > > immediately after a corresponding MELPe 2400 bps payload in the same > > > > > RTP packet. The packed parameters are counted in octets (TC). The > > > > > preferred placement SHOULD be used for TSVCIS payloads with TC less > > > > > than or equal to 77 octets, is shown in Figure 6. In the preferred > > > > > placement, a single trailing octet SHALL be appended to include a > > > > > two-bit rate code, CODA and CODB, (both bits set to one) and a six- > > > > > bit modified count (MTC). The special modified count value of all > > > > > ones (representing a MTC value of 63) SHALL NOT be used for this > > > > > format as it is used as the indicator for the alternate packing > > > > > format shown next. In a standard implementation, the TSVCIS speech > > > > > coder uses a minimum of 15 octets for parameters in octet packed > > > > > form. The modified count (MTC) MUST be reduced by 15 from the full > > > > > octet count (TC). Computed MTC = TC-15. This accommodates a maximum > > > > > of 77 parameter octets (maximum value of MTC is 62, 77 is the sum of > > > > > 62+15). > > > > > > > > > > > > > > > Section 3.3, first paragraph - Suggested edit by reviewer > > > > > > > > > > (was) > > > > > A TSVCIS RTP packet consists of zero or more TSVCIS coder frames > > > > > (each consisting of MELPe and TSVCIS coder data) followed by zero or > > > > > one MELPe comfort noise frame. The presence of a comfort noise frame > > > > > can be determined by its rate code bits in its last octet. > > > > > > > > > > (now) > > > > > A TSVCIS RTP packet payload consists of zero or more consecutive > > > > > TSVCIS coder frames (each consisting of MELPe 2400 and TSVCIS coder > > > > > data), with the oldest frame first, followed by zero or one MELPe > > > > > comfort noise frame. The presence of a comfort noise frame can be > > > > > determined by its rate code bits in its last octet. > > > > > > > > > > > > > > > Section 3.3, fourth paragraph - Clarification requested by > > > > > reviewers > > > > > > > > > > (was) > > > > > TSVCIS coder frames in a single RTP packet MAY be of different coder > > > > > bitrates. With the exception for the variable length TSVCIS > > > > > parameter frames, the coder rate bits in the trailing byte identify > > > > > the contents and length as per Table 1. > > > > > > > > > > (now) > > > > > TSVCIS coder frames in a single RTP packet MAY have varying TSVCIS > > > > > parameter octet counts. Its packed parameter octet count (length) is > > > > > indicated in the trailing byte(s). All MELPe frames in a single RTP > > > > > packet MUST be of the same coder bitrate. For all MELPe coder > > > > > frames, the coder rate bits in the trailing byte identify the > > > > > contents and length as per Table 1. > > > > > > > > > > > > > > > Section 4.1 - Editor note removed > > > > > > > > > > > > > > > Section 4.1 - Change controller is now > > > > > > > > > > (now) > > > > > Change controller: IETF, contact > > > > > > > > > > > > > > > Section 5, first paragraph - Suggested edits by reviewers > > > > > > > > > > (was) > > > > > A primary application of TSVCIS is for radio communications of voice > > > > > conversations, and discontinuous transmissions are normal. When > > > > > TSVCIS is used in an IP network, TSVCIS RTP packet transmissions may > > > > > cease and resume frequently. RTP synchronization source (SSRC) > > > > > sequence number gaps indicate lost packets to be filled by PLC, while > > > > > abrupt loss of RTP packets indicates intended discontinuous > > > > > transmissions. > > > > > > > > > > (now) > > > > > A primary application of TSVCIS is for radio communications of voice > > > > > conversations, and discontinuous transmissions are normal. When > > > > > TSVCIS is used in an IP network, TSVCIS RTP packet transmissions may > > > > > cease and resume frequently. RTP synchronization source (SSRC) > > > > > sequence number gaps indicate lost packets to be filled by Packet > > > > > Loss Concealment (PLC), while abrupt loss of RTP packets indicates > > > > > intended discontinuous transmissions. Resumption of voice > > > > > transmission SHOULD be indicated by the RTP marker bit (M) set to 1. > > > > > > > > > > > > > > > Section 10 - Added reference > > > > > > > > > > (added) > > > > > [RFC8088] Westerlund, M., "How to Write an RTP Payload Format", > > > > > RFC 8088, DOI 10.17487/RFC8088, May 2017, > > > > > . > > > > > > > > > > ---------------------------------------------------------------- > > > > > ---- > > > > > ----------------------------- > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: Roni Even (A) > > > > > Sent: Sunday, October 6, 2019 2:09 AM > > > > > To: victor.demjanenko@vocal.com; 'Benjamin Kaduk' > > > > > ; 'The IESG' > > > > > Cc: draft-ietf-payload-tsvcis@ietf.org; 'Ali Begen' > > > > > ; avtcore-chairs@ietf.org; > > > > > avt@ietf.org; 'Dave Satterlee (Vocal)' > > > > > > > > > > Subject: RE: Benjamin Kaduk's Discuss on > > > > > draft-ietf-payload-tsvcis-03: (with DISCUSS and COMMENT) > > > > > > > > > > Hi, > > > > > About the reference to TSVCIS. > > > > > The RTP payload is about how to encapsulate the payload in an > > > > > RTP > > > packet. The objective is to define how an RTP stack can insert the > > > tsvcis frames and extract the tsvcis frames from the RTP packet. > > > Typically it is not required to understand the payload structure in > > > order to be able to perform the encapsulation. > > > > > This is why the reference to the payload is Informational and we > > > > > did not require to have it publically available. If there is a > > > > > need to understand the payload itself for the encapsulating than > > > > > we need more information in the RTP payload specification and a > > > > > publically available normative reference. I think this is not > > > > > the case here > > > > > > > > > > Roni Even > > > > > > > > > > AVTCore co-chair (ex Payload) > > > > > > > > > > -----Original Message----- > > > > > From: victor.demjanenko@vocal.com > > > > > [mailto:victor.demjanenko@vocal.com] > > > > > Sent: Saturday, October 05, 2019 12:18 AM > > > > > To: 'Benjamin Kaduk'; 'The IESG' > > > > > Cc: draft-ietf-payload-tsvcis@ietf.org; 'Ali Begen'; > > > avtcore-chairs@ietf.org; avt@ietf.org; 'Victor Demjanenko, Ph.D.'; > > > 'Dave Satterlee (Vocal)' > > > > > Subject: RE: Benjamin Kaduk's Discuss on > > > > > draft-ietf-payload-tsvcis-03: (with DISCUSS and COMMENT) > > > > > > > > > > Everyone, > > > > > > > > > > Thanks for the comments. I think I mis-understood the ambiguity > > > > > with > > > respect to to changing rates within a RTP packet. That was not > > > plan. An RTP packet must have MELP speech frames of the same rate. > > > What is possible is that the amount of augmented TSVCIS speech data > > > may vary from one speech frame to the next. This allows for a > > > dynamic VDR as suggested by the NRL paper. So an RTP packet may > > > have varying TSVCIS data but must always have MELPe 2400 data. > > > > > > > > > > Again backwards parsing is necessary but the timestamp uniformly > > > increments 22.5msec per combined MELP/TSVCIS speech frame. > > > > > > > > > > The NRL is a good public reference on the VDR aspects. The > > > > > actual > > > TSVCIS spec we had was FOUO so we could not replicate its detail. > > > (I believe a later spec is public or at least partially public. I > > > am trying to get this.) The opaque data is pretty obvious with the TSVCIS spec in hand. > > > > > > > > > > We will address the issues/concerns raised next week. Other > > > > > business > > > had priority. > > > > > > > > > > Thank you and enjoy the weekend. > > > > > > > > > > Regards, > > > > > > > > > > Victor & Dave > > > > > > > > > > -----Original Message----- > > > > > From: Benjamin Kaduk via Datatracker > > > > > Sent: Wednesday, October 2, 2019 10:40 PM > > > > > To: The IESG > > > > > Cc: draft-ietf-payload-tsvcis@ietf.org; Ali Begen > > > > > ; avtcore-chairs@ietf.org; > > > > > ali.begen@networked.media; avt@ietf.org > > > > > Subject: Benjamin Kaduk's Discuss on draft-ietf-payload-tsvcis-03: > > > > > (with DISCUSS and COMMENT) > > > > > > > > > > Benjamin Kaduk has entered the following ballot position for > > > > > draft-ietf-payload-tsvcis-03: 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-payload-tsvcis/ > > > > > > > > > > > > > > > > > > > > ---------------------------------------------------------------- > > > > > ---- > > > > > -- > > > > > DISCUSS: > > > > > ---------------------------------------------------------------- > > > > > ---- > > > > > -- > > > > > > > > > > I support Magnus' point about the time-ordering of adjacent > > > > > frames in a > > > packet. > > > > > > > > > > Additionally, I am not sure that there's quite enough here to be > > > interoperably implementable. Specifically, we seem to be lacking a > > > description of how an encoder or decoder knows which TSVCIS > > > parameters, and in what order, to byte-pack or unpack, respectively. > > > One might surmise that there is a canonical listing in [TSVCIS], but > > > this document does not say that, and furthermore [TSVCIS] is only listed as an informative reference. > > > (I couldn't get my hands on my copy, at least on short notice.) If > > > we limited ourselves to treating the TSVCIS parameters as an > > > entirely opaque blob (codec, convey these N octets to the peer with > > > the appropriate one- or two-byte trailer for payload type > > > identification and framing), that would be interoperably > > > implementable, since the black-box bits are up to some other codec to interpret. > > > > > > > > > > In a similar vein, we mention but do not completely specify the > > > potential for using CODB as an end-to-end framing bit, in Section > > > 3.1 (see Comment), which is not interoperably implementable without further details. > > > > > > > > > > > > > > > ---------------------------------------------------------------- > > > > > ---- > > > > > -- > > > > > COMMENT: > > > > > ---------------------------------------------------------------- > > > > > ---- > > > > > -- > > > > > > > > > > Where is [TSVCIS] available? > > > > > > > > > > Is [NRLVDR] the same as > > > > > https://apps.dtic.mil/dtic/tr/fulltext/u2/a588068.pdf ? A URL > > > > > in the > > > references would be helpful. > > > > > > > > > > Is additional TSVCIS data only present after 2400bps MELPe and > > > > > the first > > > thing to get dropped under bandwidth pressure? The abstract and > > > introduction imply this by calling out MELPe 2400 bps speech > > > parameters explicitly, but Section 3 says that TSVCIS augments > > > standard 600, 1200, and > > > 2400 bps MELP frames. > > > > > > > > > > It's helpful that Section 3.3 gives some general guidance for > > > > > decoding > > > this payload type ("[t]he way to determine the number of > > > TSVCIS/MELPe frames is to identify each frame type and length"), but > > > I think some generic considerations would be very helpful to the > > > reader much earlier, along the lines of "MELPe and TSVCIS data > > > payloads are decoded from the end, using the CODA and CODB (and, if > > > necessary, CODC and others) bits to determine the type of payload. > > > For MELPe payloads the type also indicates the payload length, > > > whereas for TSVCIS data an additional length field is present, in > > > one of two possible formats. A TSVCIS coder frame consists of a > > > MELPe data payload followed by zero or one TSVCIS data payload; > > > after the TSVCIS payload's presence/length is determined, then the > > > preceding MELPe payload can be determined and decoded. Per Section > > > 3.3, multiple TSVCIS frames can be present in a single RTP packet." > > > This (or something like it) would also serve to clarify the role of the COD* bits, which is otherwise only implicitly introduced. > > > > > > > > > > Section 1.1 > > > > > > > > > > RFC 2736 is BCP 36 (but it's updated by RFC 8088 which is for > > > > > some > > > reason an Informational document and not part of BCP 36?!). > > > > > > > > > > Section 2 > > > > > > > > > > In addition to the augmented speech data, the TSVCIS specification > > > > > identifies which speech coder and framing bits are to be encrypted, > > > > > and how they are protected by forward error correction (FEC) > > > > > techniques (using block codes). At the RTP transport layer, only the > > > > > speech coder related bits need to be considered and are conveyed in > > > > > unencrypted form. In most IP-based network deployments, > > > > > standard > > > > > > > > > > Am I reading this correctly that this text is just summarizing > > > > > what's in > > > the TSVCIS spec in terms of what needs to be in unencrypted form, so > > > the "only the speech coder related bits[...]" is not new information > > > from this document? I'm not sure I agree with the conclusion, > > > regardless -- won't the > > > (MELPe) speech coder bits be enough to convey the semantic content > > > of the audio stream, something that one might desire to keep confidential? > > > > > > > > > > link encryption methods (SRTP, VPNs, FIPS 140 link encryptors or Type > > > > > 1 Ethernet encryptors) would be used to secure the RTP speech > > > > > contents. Further, it is desirable to support the highest voice > > > > > quality between endpoints which is only possible without the overhead > > > > > of FEC. > > > > > > > > > > I think I'm missing a step in how this conclusion was reached. > > > > > > > > > > TSVCIS will be characterized. Depending on the bandwidth available > > > > > (and FEC requirements), a varying number of TSVCIS specific speech > > > > > coder parameters need to be transported. These are first byte-packed > > > > > and then conveyed from encoder to decoder. > > > > > > > > > > Per the Discuss point, how do I know which parameters need to be > > > transported, and in what order? > > > > > > > > > > Byte packing of TSVCIS speech data into packed parameters is > > > > > processed as per the following example: > > > > > > > > > > Three-bit field: bits A, B, and C (A is MSB, C is LSB) > > > > > Five-bit field: bits D, E, F, G, and H (D is MSB, H is > > > > > LSB) > > > > > > > > > > MSB LSB > > > > > 0 1 2 3 4 5 6 7 > > > > > +------+------+------+------+------+------+------+------+ > > > > > | H | G | F | E | D | C | B | A | > > > > > > > > > > +------+------+------+------+------+------+------+------+ > > > > > > > > > > This packing method places the three-bit field "first" in the lowest > > > > > bits followed by the next five-bit field. Parameters may be split > > > > > between octets with the most significant bits in the earlier octet. > > > > > Any unfilled bits in the last octet MUST be filled with zero. > > > > > > > > > > I agree with Adam that this is very unclear. A is the MSB of > > > > > the > > > three-bit field but the LSB of the octet overall? > > > > > We probably need an example of splitting a parameter across > > > > > octets as > > > well, to get the bit ordering right. > > > > > > > > > > Section 3.1 > > > > > > > > > > It should be noted that CODB for both the 2400 and 600 bps modes MAY > > > > > deviate from the values in Table 1 when bit 55 is used as an end-to- > > > > > end framing bit. Frame decoding would remain distinct as > > > > > CODA being > > > > > > > > > > Where is the use of CODB as an end-to-end framing bit defined? > > > > > If we're > > > going to provide neither a complete description of how to do it nor > > > a reference to a better description, we probably shouldn't mention it at all. > > > > > > > > > > Section 3.2 > > > > > > > > > > RTP packet. The packed parameters are counted in octets (TC). In > > > > > the preferred placement, shown in Figure 6, a single trailing octet > > > > > SHALL be appended to include a two-bit rate code, CODA and > > > > > CODB, > > > > > > > > > > I'd consider saying something about this being the preferred > > > > > format > > > > > ("placement") due to its shorter length than the alternative, > > > > > and say > > > that it "SHOULD be used for TSVCIS payloads with TC less than or > > > equal to 77 octetes". > > > > > > > > > > Section 3.3 > > > > > > > > > > When a longer packetization interval is used, is that indicated > > > > > by > > > signaling or RTP timestamps or otherwise? > > > > > > > > > > TSVCIS coder frames in a single RTP packet MAY be of different coder > > > > > bitrates. With the exception for the variable length TSVCIS > > > > > parameter frames, the coder rate bits in the trailing byte identify > > > > > the contents and length as per Table 1. > > > > > > > > > > Maybe also note that the penultimate octet gives the length there? > > > > > > > > > > Information describing the number of frames contained in an RTP > > > > > packet is not transmitted as part of the RTP payload. The way to > > > > > determine the number of TSVCIS/MELPe frames is to identify each frame > > > > > type and length thereby counting the total number of octets within > > > > > the RTP packet. > > > > > > > > > > terminology nit: if a frame is the combination of MELPe and > > > > > TSVCIS > > > payload data units then there are two layres of decoding to get a > > > length for the frame, since we have to get the TSVCIS length and then the MELPe length. > > > > > > > > > > Section 4.2 > > > > > > > > > > Parameter "ptime" cannot be used for the purpose of > > > > > specifying the > > > > > > > > > > nit: missing article ("The parameter") > > > > > > > > > > will be impossible to distinguish which mode is about to be used > > > > > (e.g., when ptime=68, it would be impossible to distinguish if the > > > > > packet is carrying one frame of 67.5 ms or three frames of 22.5 ms). > > > > > > > > > > So how is the operating mode determined, then? > > > > > (I think this is the same question I asked above) > > > > > > > > > > Section 4.4 > > > > > > > > > > For example, if offerer bitrates are "2400,600" and answer bitrates > > > > > are "600,2400", the initial bitrate is 600. If other bitrates are > > > > > provided by the answerer, any common bitrate between the offer and > > > > > answer MAY be used at any time in the future. Activation of these > > > > > other common bitrates is beyond the scope of this document. > > > > > > > > > > It seems important to specify whether this requires a new O/A > > > > > exchange > > > or can be done "spontaneously" by just encoding different frame types. > > > > > (It seems like the latter is possible, on first glance, and this > > > > > is implied by Section 3.3's discussion of mixing them in a > > > > > single > > > > > packet.) > > > > > > > > > > Section 5 > > > > > > > > > > Please expand PLC at first use (not second). > > > > > > > > > > Section 6 > > > > > > > > > > I don't understand the PLC usage. Is the idea that a receiver, > > > > > on > > > seeing an SSRC gap, constructs fictitious PLC frames to "fill the gap" > > > > > and passes the resulting stream to the decoder? > > > > > > > > > > Section 8 > > > > > > > > > > and important considerations in [RFC7201]. Applications SHOULD use > > > > > one or more appropriate strong security mechanisms. The rest of this > > > > > section discusses the security-impacting properties of the payload > > > > > format itself. > > > > > > > > > > I thought we described TSVCIS itself (much earlier in the > > > > > document) as > > > requiring encryption for some data; wouldn't that translate to a "MUST" > > > > > here and not a "SHOULD"? > > > > > > > > > > > > > > > > > > > From nobody Mon Feb 17 18:17:28 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AB6912085A; Fri, 14 Feb 2020 07:20:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1581693632; bh=YAWrlmSGyD69vkugfUZCzz8+GPkpXtQxi9zdn9//4uM=; h=From:To:Date:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe; b=Cq15OOrKv9A+qd4AtcdfO1YcZR7rS9fYiJpaEMDowhDNX7L8SV87cILwTB5AZ/h5X N+WdI7AXolXGoQvx9ssxdoii4t1DN1y3+vxmGsPNl7ASAZPoMBRmV3kV9syXZYCg4M EtwGkhvbB9a38leXDsyPz2w38CehDgIBlMZcX05E= X-Mailbox-Line: From new-work-bounces@ietf.org Fri Feb 14 07:20:28 2020 Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 97573120885; Fri, 14 Feb 2020 07:20:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1581693612; bh=YAWrlmSGyD69vkugfUZCzz8+GPkpXtQxi9zdn9//4uM=; h=From:To:Date:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe; b=McohhlsVyD1iaQLlj+mtt/T7ioCyRXA4Y8cgnwH6kyVuqUlWVGutTTSssPWyOo3Ii eRvJJy7JQkUmp6rZXq1vbMZGbvarDRMNWXffsgPb9Q7aoQ74ZkrB8xPEtXv6iVHA9j an9fmxQrVk8zgA3ncyrhWJa9gYSOVE0+SMeuhe3k= X-Original-To: new-work@ietf.org Delivered-To: new-work@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A834A12083E for ; Fri, 14 Feb 2020 07:20:04 -0800 (PST) MIME-Version: 1.0 From: The IESG To: X-Test-IDTracker: no X-IETF-IDTracker: 6.117.0 Auto-Submitted: auto-generated Precedence: bulk Reply_to: MIME-Version: 1.0 Message-ID: <158169360468.16309.7395422563332503063.idtracker@ietfa.amsl.com> Date: Fri, 14 Feb 2020 07:20:04 -0800 Archived-At: X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.29 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Errors-To: new-work-bounces@ietf.org Sender: "new-work" Archived-At: X-Mailman-Approved-At: Sun, 16 Feb 2020 20:00:03 -0800 Subject: [secdir] [new-work] WG Review: WebTransport (webtrans) X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2020 15:20:36 -0000 QSBuZXcgSUVURiBXRyBoYXMgYmVlbiBwcm9wb3NlZCBpbiB0aGUgQXBwbGljYXRpb25zIGFuZCBS ZWFsLVRpbWUgQXJlYS4gVGhlCklFU0cgaGFzIG5vdCBtYWRlIGFueSBkZXRlcm1pbmF0aW9uIHll dC4gVGhlIGZvbGxvd2luZyBkcmFmdCBjaGFydGVyIHdhcwpzdWJtaXR0ZWQsIGFuZCBpcyBwcm92 aWRlZCBmb3IgaW5mb3JtYXRpb25hbCBwdXJwb3NlcyBvbmx5LiBQbGVhc2Ugc2VuZCB5b3VyCmNv bW1lbnRzIHRvIHRoZSBJRVNHIG1haWxpbmcgbGlzdCAoaWVzZ0BpZXRmLm9yZykgYnkgMjAyMC0w Mi0yNC4KCldlYlRyYW5zcG9ydCAod2VidHJhbnMpCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCkN1cnJlbnQgc3Rh dHVzOiBQcm9wb3NlZCBXRwoKQ2hhaXJzOgogIEJlcm5hcmQgQWJvYmEgPGJlcm5hcmQuYWJvYmFA Z21haWwuY29tPgogIERhdmlkIFNjaGluYXppIDxkc2NoaW5hemkuaWV0ZkBnbWFpbC5jb20+CgpB c3NpZ25lZCBBcmVhIERpcmVjdG9yOgogIEJhcnJ5IExlaWJhIDxiYXJyeWxlaWJhQGNvbXB1dGVy Lm9yZz4KCkFwcGxpY2F0aW9ucyBhbmQgUmVhbC1UaW1lIEFyZWEgRGlyZWN0b3JzOgogIEFkYW0g Um9hY2ggPGFkYW1Abm9zdHJ1bS5jb20+CiAgQWxleGV5IE1lbG5pa292IDxhYW1lbG5pa292QGZh c3RtYWlsLmZtPgogIEJhcnJ5IExlaWJhIDxiYXJyeWxlaWJhQGNvbXB1dGVyLm9yZz4KCk1haWxp bmcgbGlzdDoKICBBZGRyZXNzOiB3ZWJ0cmFuc3BvcnRAaWV0Zi5vcmcKICBUbyBzdWJzY3JpYmU6 IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vd2VidHJhbnNwb3J0CiAgQXJj aGl2ZTogaHR0cHM6Ly9tYWlsYXJjaGl2ZS5pZXRmLm9yZy9hcmNoL2Jyb3dzZS93ZWJ0cmFuc3Bv cnQvCgpHcm91cCBwYWdlOiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2dyb3VwL3dlYnRy YW5zLwoKQ2hhcnRlcjogaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvY2hhcnRlci1p ZXRmLXdlYnRyYW5zLwoKRGVzY3JpcHRpb24gb2YgV29ya2luZyBHcm91cAoKVGhlIFdlYlRyYW5z cG9ydCB3b3JraW5nIGdyb3VwIHdpbGwgZGVmaW5lIG5ldyBjbGllbnQtc2VydmVyIHByb3RvY29s cyBvcgpwcm90b2NvbCBleHRlbnNpb25zIGluIG9yZGVyIHRvIHN1cHBvcnQgdGhlIGRldmVsb3Bt ZW50IG9mIHRoZSBXZWJUcmFuc3BvcnQKQVBJIGh0dHBzOi8vd2ljZy5naXRodWIuaW8vd2ViLXRy YW5zcG9ydC4KClRoZSBXZWJUcmFuc3BvcnQgd29ya2luZyBncm91cCB3aWxsIGRlZmluZSBhbiBh cHBsaWNhdGlvbi1sYXllciBwcm90b2NvbApvciBzdWl0ZSBvZiBhcHBsaWNhdGlvbi1sYXllciBw cm90b2NvbHMgdGhhdCBzdXBwb3J0IGEgcmFuZ2Ugb2Ygc2ltcGxlCmNvbW11bmljYXRpb24gbWV0 aG9kcy4gVGhlc2UgbXVzdCBpbmNsdWRlIHVucmVsaWFibGUgbWVzc2FnZXMgKHRoYXQgbWlnaHQK YmUgbGltaXRlZCBieSB0aGUgcGF0aCBNVFUpLCByZWxpYWJsZSBtZXNzYWdlcywgYW5kIG9yZGVy ZWQgc3RyZWFtcyBvZgpyZWxpYWJsZSBtZXNzYWdlcy4gQXR0ZW50aW9uIHdpbGwgYmUgcGFpZCB0 byB0aGUgcGVyZm9ybWFuY2Ugb2YgdGhlCnByb3RvY29sLCB3aXRoIHBhcnRpY3VsYXIgYXR0ZW50 aW9uIHRvIHRoZSBwcm90b2NvbOKAmXMgb3ZlcmhlYWQgYW5kIHRoZQpwb3RlbnRpYWwgZm9yIGhl YWQtb2YtbGluZSBibG9ja2luZzsgaXRzIGFiaWxpdHkgdG8gYmUgZGVwbG95ZWQgYW5kIHVzZWQK cmVsaWFibHkgdW5kZXIgZGlmZmVyZW50IG5ldHdvcmsgY29uZGl0aW9uczsgYW5kIGl0cyBhYmls aXR5IHRvIGludGVncmF0ZQppbnRvIHRoZSBXZWIgc2VjdXJpdHkgbW9kZWwuIFRoZSB3b3JraW5n IGdyb3VwIHdpbGwgbm90IGRlZmluZSBuZXcKdHJhbnNwb3J0IHByb3RvY29scyBidXQgd2lsbCBp bnN0ZWFkIHVzZSBleGlzdGluZyBwcm90b2NvbHMgc3VjaCBhcyBRVUlDCmFuZCBUTFMvVENQLgoK VGhlIGdyb3VwIHdpbGwgcGF5IGF0dGVudGlvbiB0byBzZWN1cml0eSBpc3N1ZXMgYXJpc2luZyBm cm9tIHRoZSBhYm92ZQpzY2VuYXJpb3Mgc28gYXMgdG8gcHJvdGVjdCBhZ2FpbnN0IGNyZWF0aW9u IG9mIG5ldyBtb2RlcyBvZiBhdHRhY2suCgpUbyBhc3Npc3QgaW4gdGhlIGNvb3JkaW5hdGlvbiB3 aXRoIG93bmVycyBvZiB0aGUgV2ViVHJhbnNwb3J0IEFQSSwgdGhlCmdyb3VwIHdpbGwgaW5pdGlh bGx5IGRldmVsb3AgYW4gb3ZlcnZpZXcgZG9jdW1lbnQgY29udGFpbmluZyB1c2UgY2FzZXMKYW5k IHJlcXVpcmVtZW50cyBpbiBvcmRlciB0byBjbGFyaWZ5IHRoZSBnb2FscyBvZiB0aGUgZWZmb3J0 LiBUaGUKcmVxdWlyZW1lbnRzIHdpbGwgaW5jbHVkZSB0aG9zZSBhcmlzaW5nIGZyb20gdGhlIFdl YlRyYW5zcG9ydCBBUEkuCkZlZWRiYWNrIHdpbGwgYWxzbyBiZSBzb2xpY2l0ZWQgYXQgdmFyaW91 cyBwb2ludHMgYWxvbmcgdGhlIHdheSBpbiBvcmRlcgp0byBlbnN1cmUgdGhlIGJlc3QgcG9zc2li bGUgbWF0Y2ggYmV0d2VlbiB0aGUgcHJvdG9jb2wgZXh0ZW5zaW9ucyBhbmQgdGhlCm5lZWRzIG9m IHRoZSBXZWJUcmFuc3BvcnQgQVBJLgoKVGhlIGdyb3VwIHdpbGwgYWxzbyBjb29yZGluYXRlIHdp dGggcmVsYXRlZCB3b3JraW5nIGdyb3VwcyB3aXRoaW4gdGhlIElFVEYsCnN1Y2ggYXMgUVVJQyBh bmQgSFRUUEJJUywgYXMgYXBwcm9wcmlhdGUuICBJbiBwYXJ0aWN1bGFyLCBpZiB0aGUgd29ya2lu Zwpncm91cCBuZWVkcyBhbnkgY2hhbmdlcyB0byBvciBleHRlbnNpb25zIG9mIHRoZSBjb3JlIHBy b3RvY29scywgdGhvc2UKaXNzdWVzIHdpbGwgYmUgcmFpc2VkIHdpdGggdGhlIHJlbGV2YW50IHdv cmtpbmcgZ3JvdXBzIGZvciBkZWNpc2lvbnMgb24gaG93CmJlc3QgdG8gaGFuZGxlIHRoZW0uICBJ ZiB0aG9zZSBkZWNpc2lvbnMgcmVzdWx0IGluIHdvcmsgaW4gV2ViVHJhbnMsIHRoZQp3b3JraW5n IGdyb3VwIGxhc3QgY2FsbHMgZm9yIHRoYXQgd29yayB3aWxsIGFnYWluIGJlIHNlbnQgdG8gdGhl IHJlbGV2YW50CndvcmtpbmcgZ3JvdXBzLgoKTWlsZXN0b25lczoKCiAgTWFyIDIwMjAgLSBBZG9w dCBhIFdlYlRyYW5zcG9ydCBPdmVydmlldyBkcmFmdCBhcyBhIFdHIHdvcmsgaXRlbQoKICBNYXIg MjAyMCAtIEFkb3B0IGEgZHJhZnQgZGVmaW5pbmcgYSBXZWJUcmFuc3BvcnQgcHJvdG9jb2wgYXMg YSBXRyB3b3JrIGl0ZW0KCiAgT2N0IDIwMjAgLSBJc3N1ZSBXRyBsYXN0IGNhbGwgb2YgdGhlIFdl YlRyYW5zcG9ydCBPdmVydmlldyBkb2N1bWVudC4KCiAgSmFuIDIwMjEgLSBJc3N1ZSBXRyBsYXN0 IGNhbGwgb24gdGhlIGZpcnN0IFdlYlRyYW5zcG9ydCBwcm90b2NvbCBkb2N1bWVudAoKCl9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCm5ldy13b3JrIG1haWxp bmcgbGlzdApuZXctd29ya0BpZXRmLm9yZwpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL25ldy13b3JrCg== From nobody Mon Feb 17 18:51:36 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 220621200F5; Mon, 17 Feb 2020 15:09:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.219 X-Spam-Level: X-Spam-Status: No, score=-1.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.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 QH_qfYug0BsW; Mon, 17 Feb 2020 15:09:12 -0800 (PST) Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (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 B531A120048; Mon, 17 Feb 2020 15:09:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=Content-Type:In-Reply-To:MIME-Version:Date: Message-ID:From:To:References:Subject:Sender:Reply-To:Cc: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=AXREkpb/OMnCgDUvN+Xhq21PZpA9BH4bh4+XuYd0vsk=; b=BDzpcuRY1kpSFUhdVFZDfPwvx dOGnvYL1+DfFgyhZ713+jxHmwoCSWc+PvzrQrEfivAwCS7xa6+lUy3SCygRgsBUHAKjxVS1EHpTEh Rm8eOmPNCZ5sjP0I0P7Jmk0t4PFRvgJMViqxjL5sUZ0TqepgWeeWnfhzMkORspQuRR2vL2XlwLT6b kpsC4DvgP1xeKAcbQ3c0kYf81Mnq3TVUBPdOwaxCQKaiE5CPb46R6jsWPS1AsZSj+NnIxHnThfzG1 RohW96OZp7cKImjwe17wsucn+IN6AcRUGCRO0LMdtOXXgcJCi8G46nk+a83ipkT+sU5LxiJ21BUiJ JJ5EMCAOg==; Received: from cpe-172-250-225-198.socal.res.rr.com ([172.250.225.198]:50560 helo=[192.168.1.8]) by server217.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.92) (envelope-from ) id 1j3pVk-003AtC-5L; Mon, 17 Feb 2020 18:09:12 -0500 References: To: secdir@ietf.org, "gen-art@ietf.org" , "tsv-art@ietf.org" From: Joe Touch X-Forwarded-Message-Id: Message-ID: Date: Mon, 17 Feb 2020 15:09:07 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------3F156B0CD923E1ACD866FF78" Content-Language: en-US X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server217.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - strayalpha.com X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: [secdir] Fwd: CALL to revoke last call: Re: [tsvwg] Request for working group feedback on draft-kuehlewind-system-ports (6th March, 2020) X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Feb 2020 23:09:14 -0000 This is a multi-part message in MIME format. --------------3F156B0CD923E1ACD866FF78 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit FYI to the ARTs involved. Discussion appears to at least be started in TSVWG finally, but claiming this first-call as "last call" is ridiculous. Joe -------- Forwarded Message -------- Subject: CALL to revoke last call: Re: [tsvwg] Request for working group feedback on draft-kuehlewind-system-ports (6th March, 2020) Date: Mon, 17 Feb 2020 15:06:40 -0800 From: Joe Touch To: Gorry Fairhurst , tsvwg@ietf.org I object on process grounds at a minimum and call for its "last calls" to be revoked by the sponsoring AD and WG chair as follows: 1) this doc went to "IETF last call" (according to the doc tracker) without ever being announced on the IETF-wide last call list 2) this doc went to "last call" both there and (via this announcement) here without ever being posted for open discussion on any IETF list     - it is my understanding that first call != last call 3) this doc falls clearly within the purview of TSVWG, as it *should* be handled similar to RFCs 6335 and 7605; it should have been submitted for WG consideration FIRST - before being posted even for LC. The fact that this doc is being rushed through as an individual submission by the transport AD as sponsored by another AD of the IESG is highly suspicious and IMO inappropriate. Regarding content, I've already provided feedback, including the above, that has been largely ignored since mid-Dec privately by author and IESG ADs alike. To repeat: the authors need to DO THEIR HOMEWORK as follows: - correct the errors     - RFC 6335 defines reassignment and the appeals process, in contrast to the claims of this doc, including when a party is no longer reachable (the IESG or IAB appeal would decide how to proceed)     - RFC 6335 also explains the process for deassignment, which is much more involved than described here     - if this doc is intended to update RFC 6335, it should say so AND BE A TSVWG adopted item, not merely an individual submission - show an empirical need for dealing with standards-track ports in bulk rather than on a per-issue basis     - especially given at least some of the issues in this doc, such as "orphaned" ports (whose contact is no longer reachable), represent an ongoing problem that cannot be corrected  by a single pass - provide a COMPLETE list of the impacted standards-track ports not already assigned to the IESG, *including* those in the user ports space (not merely system, which RFC 7605 already suggests not treating as privileged anyway) - NOT attempt to "reclaim unused" system ports, for several reasons:     a) see the hazards of deassignment per RFC 6335     b) see the recommendation to not treat system ports as privileged and thus there would be no utility in focusing on reclaiming entries from that range - limit the scope of this doc to those such ports, rather than implying the IESG will be "reclaiming" the entire system ports space (including rewriting the title and abstract) - NOT attempt to subvert the appeals process for port reassignment as per RFC6335 - NOT attempt to subvert the WG process by submitting this as "individual" Joe On 2/17/2020 12:15 AM, Gorry Fairhurst wrote: > This is notice to request for working group feedback on “Reassignment > of System Ports to the IESG”, to conclude 6th March, 2020. Please > review this document and send comments to the list (or respond to the > concurrent IETF LC). > > The draft proposes a process where System Ports can be reassigned to > the IESG. This would enable the current assignee in the IANA ports > registry to be replaced under some conditions. > > https://www.ietf.org/id/draft-kuehlewind-system-ports > > Although this is not a working group document, I'm expecting some > people in TSVWG to have expertise to review this draft based on RFC > 6335 (was draft-ietf-tsvwg-iana-ports), which described Internet > Assigned Numbers Authority (IANA) Procedures for the Management of the > Service Name and Transport Protocol Port Number Registry. > > -- Gorry Fairhurst > TSVWG co-chair > --------------3F156B0CD923E1ACD866FF78 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

FYI to the ARTs involved.

Discussion appears to at least be started in TSVWG finally, but claiming this first-call as "last call" is ridiculous.

Joe


-------- Forwarded Message --------
Subject: CALL to revoke last call: Re: [tsvwg] Request for working group feedback on draft-kuehlewind-system-ports (6th March, 2020)
Date: Mon, 17 Feb 2020 15:06:40 -0800
From: Joe Touch <touch@strayalpha.com>
To: Gorry Fairhurst <gorry@erg.abdn.ac.uk>, tsvwg@ietf.org <tsvwg@ietf.org>


I object on process grounds at a minimum and call for its "last calls" to be revoked by the sponsoring AD and WG chair as follows:

1) this doc went to "IETF last call" (according to the doc tracker) without ever being announced on the IETF-wide last call list

2) this doc went to "last call" both there and (via this announcement) here without ever being posted for open discussion on any IETF list

    - it is my understanding that first call != last call

3) this doc falls clearly within the purview of TSVWG, as it *should* be handled similar to RFCs 6335 and 7605; it should have been submitted for WG consideration FIRST - before being posted even for LC.

The fact that this doc is being rushed through as an individual submission by the transport AD as sponsored by another AD of the IESG is highly suspicious and IMO inappropriate.

Regarding content, I've already provided feedback, including the above, that has been largely ignored since mid-Dec privately by author and IESG ADs alike.

To repeat: the authors need to DO THEIR HOMEWORK as follows:

- correct the errors

    - RFC 6335 defines reassignment and the appeals process, in contrast to the claims of this doc, including when a party is no longer reachable (the IESG or IAB appeal would decide how to proceed)

    - RFC 6335 also explains the process for deassignment, which is much more involved than described here

    - if this doc is intended to update RFC 6335, it should say so AND BE A TSVWG adopted item, not merely an individual submission

- show an empirical need for dealing with standards-track ports in bulk rather than on a per-issue basis

    - especially given at least some of the issues in this doc, such as "orphaned" ports (whose contact is no longer reachable), represent an ongoing problem that cannot be corrected  by a single pass

- provide a COMPLETE list of the impacted standards-track ports not already assigned to the IESG, *including* those in the user ports space (not merely system, which RFC 7605 already suggests not treating as privileged anyway)

- NOT attempt to "reclaim unused" system ports, for several reasons:

    a) see the hazards of deassignment per RFC 6335

    b) see the recommendation to not treat system ports as privileged and thus there would be no utility in focusing on reclaiming entries from that range

- limit the scope of this doc to those such ports, rather than implying the IESG will be "reclaiming" the entire system ports space (including rewriting the title and abstract)

- NOT attempt to subvert the appeals process for port reassignment as per RFC6335

- NOT attempt to subvert the WG process by submitting this as "individual"

Joe

On 2/17/2020 12:15 AM, Gorry Fairhurst wrote:
This is notice to request for working group feedback on “Reassignment of System Ports to the IESG”, to conclude 6th March, 2020. Please review this document and send comments to the list (or respond to the concurrent IETF LC).

The draft proposes a process where System Ports can be reassigned to the IESG. This would enable the current assignee in the IANA ports registry to be replaced under some conditions.

https://www.ietf.org/id/draft-kuehlewind-system-ports

Although this is not a working group document, I'm expecting some people in TSVWG to have expertise to review this draft based on RFC 6335 (was draft-ietf-tsvwg-iana-ports), which described Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry.

-- Gorry Fairhurst
TSVWG co-chair

--------------3F156B0CD923E1ACD866FF78-- From nobody Tue Feb 18 09:25:22 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A266120152; Tue, 18 Feb 2020 09:25:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.678 X-Spam-Level: X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=nostrum.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MjrJK7omCfJe; Tue, 18 Feb 2020 09:25:11 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F7AF120018; Tue, 18 Feb 2020 09:25:11 -0800 (PST) Received: from unescapeable.local ([47.186.30.41]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id 01IHP9p3097562 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 18 Feb 2020 11:25:09 -0600 (CST) (envelope-from rjsparks@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1582046710; bh=NjdxQBow5uE1ll4CS7ZZkx1ZHO+cNPWQt69YEWWUsuk=; h=Subject:To:References:From:Date:In-Reply-To; b=Ru3cYOahMy37y7WQfJ+ey03tyoGc7Kr54Xr3Vs+k9PjQvuav8cRhEQ0udmD/IqIZK r6s0DvpXrnH+eBXdpEFIOxwdiFVlMp/TBkQaEIhObbdw0D95ztooL0eaNHDpCTsmNy 4PNFzvLPdrla1x9a9CwUJmNzX1HT/yiZuUA2NE84= X-Authentication-Warning: raven.nostrum.com: Host [47.186.30.41] claimed to be unescapeable.local To: Joe Touch , secdir@ietf.org, "gen-art@ietf.org" , "tsv-art@ietf.org" References: From: Robert Sparks Message-ID: Date: Tue, 18 Feb 2020 11:25:09 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0) Gecko/20100101 Thunderbird/68.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------8306C709C1FDD3DAE14A2810" Content-Language: en-US Archived-At: Subject: Re: [secdir] [Gen-art] Fwd: CALL to revoke last call: Re: [tsvwg] Request for working group feedback on draft-kuehlewind-system-ports (6th March, 2020) X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Feb 2020 17:25:13 -0000 This is a multi-part message in MIME format. --------------8306C709C1FDD3DAE14A2810 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hi Joe - Thanks for the heads up. I haven't been following this and am just starting to read the threads on tsvwg, so apologies if my question below has already been addressed. On 2/17/20 5:09 PM, Joe Touch wrote: > > FYI to the ARTs involved. > > Discussion appears to at least be started in TSVWG finally, but > claiming this first-call as "last call" is ridiculous. > > Joe > > > -------- Forwarded Message -------- > Subject: CALL to revoke last call: Re: [tsvwg] Request for working > group feedback on draft-kuehlewind-system-ports (6th March, 2020) > Date: Mon, 17 Feb 2020 15:06:40 -0800 > From: Joe Touch > To: Gorry Fairhurst , tsvwg@ietf.org > > > > > I object on process grounds at a minimum and call for its "last calls" > to be revoked by the sponsoring AD and WG chair as follows: > > 1) this doc went to "IETF last call" (according to the doc tracker) > without ever being announced on the IETF-wide last call list I received an announcement of the last call via ietf-announce on 10Feb2020. It made it into the archives at: Is this the announcement you were looking for? > > 2) this doc went to "last call" both there and (via this announcement) > here without ever being posted for open discussion on any IETF list > >     - it is my understanding that first call != last call > > 3) this doc falls clearly within the purview of TSVWG, as it *should* > be handled similar to RFCs 6335 and 7605; it should have been > submitted for WG consideration FIRST - before being posted even for LC. > > The fact that this doc is being rushed through as an individual > submission by the transport AD as sponsored by another AD of the IESG > is highly suspicious and IMO inappropriate. > > Regarding content, I've already provided feedback, including the > above, that has been largely ignored since mid-Dec privately by author > and IESG ADs alike. > > To repeat: the authors need to DO THEIR HOMEWORK as follows: > > - correct the errors > >     - RFC 6335 defines reassignment and the appeals process, in > contrast to the claims of this doc, including when a party is no > longer reachable (the IESG or IAB appeal would decide how to proceed) > >     - RFC 6335 also explains the process for deassignment, which is > much more involved than described here > >     - if this doc is intended to update RFC 6335, it should say so AND > BE A TSVWG adopted item, not merely an individual submission > > - show an empirical need for dealing with standards-track ports in > bulk rather than on a per-issue basis > >     - especially given at least some of the issues in this doc, such > as "orphaned" ports (whose contact is no longer reachable), represent > an ongoing problem that cannot be corrected  by a single pass > > - provide a COMPLETE list of the impacted standards-track ports not > already assigned to the IESG, *including* those in the user ports > space (not merely system, which RFC 7605 already suggests not treating > as privileged anyway) > > - NOT attempt to "reclaim unused" system ports, for several reasons: > >     a) see the hazards of deassignment per RFC 6335 > >     b) see the recommendation to not treat system ports as privileged > and thus there would be no utility in focusing on reclaiming entries > from that range > > - limit the scope of this doc to those such ports, rather than > implying the IESG will be "reclaiming" the entire system ports space > (including rewriting the title and abstract) > > - NOT attempt to subvert the appeals process for port reassignment as > per RFC6335 > > - NOT attempt to subvert the WG process by submitting this as "individual" > > Joe > > On 2/17/2020 12:15 AM, Gorry Fairhurst wrote: >> This is notice to request for working group feedback on “Reassignment >> of System Ports to the IESG”, to conclude 6th March, 2020. Please >> review this document and send comments to the list (or respond to the >> concurrent IETF LC). >> >> The draft proposes a process where System Ports can be reassigned to >> the IESG. This would enable the current assignee in the IANA ports >> registry to be replaced under some conditions. >> >> https://www.ietf.org/id/draft-kuehlewind-system-ports >> >> Although this is not a working group document, I'm expecting some >> people in TSVWG to have expertise to review this draft based on RFC >> 6335 (was draft-ietf-tsvwg-iana-ports), which described Internet >> Assigned Numbers Authority (IANA) Procedures for the Management of >> the Service Name and Transport Protocol Port Number Registry. >> >> -- Gorry Fairhurst >> TSVWG co-chair >> > > _______________________________________________ > Gen-art mailing list > Gen-art@ietf.org > https://www.ietf.org/mailman/listinfo/gen-art --------------8306C709C1FDD3DAE14A2810 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Hi Joe -

Thanks for the heads up. I haven't been following this and am just starting to read the threads on tsvwg, so apologies if my question below has already been addressed.


On 2/17/20 5:09 PM, Joe Touch wrote:

FYI to the ARTs involved.

Discussion appears to at least be started in TSVWG finally, but claiming this first-call as "last call" is ridiculous.

Joe


-------- Forwarded Message --------
Subject: CALL to revoke last call: Re: [tsvwg] Request for working group feedback on draft-kuehlewind-system-ports (6th March, 2020)
Date: Mon, 17 Feb 2020 15:06:40 -0800
From: Joe Touch <touch@strayalpha.com>
To: Gorry Fairhurst <gorry@erg.abdn.ac.uk>, tsvwg@ietf.org <tsvwg@ietf.org>


I object on process grounds at a minimum and call for its "last calls" to be revoked by the sponsoring AD and WG chair as follows:

1) this doc went to "IETF last call" (according to the doc tracker) without ever being announced on the IETF-wide last call list

I received an announcement of the last call via ietf-announce on 10Feb2020. It made it into the archives at:

<https://mailarchive.ietf.org/arch/msg/ietf-announce/C3YU0i15ZSTaYHPMKOe_8sGVmLk>

Is this the announcement you were looking for?


2) this doc went to "last call" both there and (via this announcement) here without ever being posted for open discussion on any IETF list

    - it is my understanding that first call != last call

3) this doc falls clearly within the purview of TSVWG, as it *should* be handled similar to RFCs 6335 and 7605; it should have been submitted for WG consideration FIRST - before being posted even for LC.

The fact that this doc is being rushed through as an individual submission by the transport AD as sponsored by another AD of the IESG is highly suspicious and IMO inappropriate.

Regarding content, I've already provided feedback, including the above, that has been largely ignored since mid-Dec privately by author and IESG ADs alike.

To repeat: the authors need to DO THEIR HOMEWORK as follows:

- correct the errors

    - RFC 6335 defines reassignment and the appeals process, in contrast to the claims of this doc, including when a party is no longer reachable (the IESG or IAB appeal would decide how to proceed)

    - RFC 6335 also explains the process for deassignment, which is much more involved than described here

    - if this doc is intended to update RFC 6335, it should say so AND BE A TSVWG adopted item, not merely an individual submission

- show an empirical need for dealing with standards-track ports in bulk rather than on a per-issue basis

    - especially given at least some of the issues in this doc, such as "orphaned" ports (whose contact is no longer reachable), represent an ongoing problem that cannot be corrected  by a single pass

- provide a COMPLETE list of the impacted standards-track ports not already assigned to the IESG, *including* those in the user ports space (not merely system, which RFC 7605 already suggests not treating as privileged anyway)

- NOT attempt to "reclaim unused" system ports, for several reasons:

    a) see the hazards of deassignment per RFC 6335

    b) see the recommendation to not treat system ports as privileged and thus there would be no utility in focusing on reclaiming entries from that range

- limit the scope of this doc to those such ports, rather than implying the IESG will be "reclaiming" the entire system ports space (including rewriting the title and abstract)

- NOT attempt to subvert the appeals process for port reassignment as per RFC6335

- NOT attempt to subvert the WG process by submitting this as "individual"

Joe

On 2/17/2020 12:15 AM, Gorry Fairhurst wrote:
This is notice to request for working group feedback on “Reassignment of System Ports to the IESG”, to conclude 6th March, 2020. Please review this document and send comments to the list (or respond to the concurrent IETF LC).

The draft proposes a process where System Ports can be reassigned to the IESG. This would enable the current assignee in the IANA ports registry to be replaced under some conditions.

https://www.ietf.org/id/draft-kuehlewind-system-ports

Although this is not a working group document, I'm expecting some people in TSVWG to have expertise to review this draft based on RFC 6335 (was draft-ietf-tsvwg-iana-ports), which described Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry.

-- Gorry Fairhurst
TSVWG co-chair


_______________________________________________
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
--------------8306C709C1FDD3DAE14A2810-- From nobody Thu Feb 20 01:26:04 2020 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id F14C2120867; Thu, 20 Feb 2020 01:25:48 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Liang Xia via Datatracker To: Cc: last-call@ietf.org, ntp@ietf.org, draft-ietf-ntp-packet-timestamps.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.118.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Liang Xia Message-ID: <158219074887.12472.2580172227467394593@ietfa.amsl.com> Date: Thu, 20 Feb 2020 01:25:48 -0800 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-ntp-packet-timestamps-07 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Feb 2020 09:25:49 -0000 Reviewer: Liang Xia Review result: Ready Reviewer: Liang Xia Review result: Ready I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document specifies guidelines for defining packet timestamp formats in networking protocols at various layers. It also presents three recommended timestamp formats. This document is well written, and the security considerations section discusses the potential security issues comprehensively, I don't see any other issues missed. In summary, I think this document is ready to go. From nobody Thu Feb 20 03:52:58 2020 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CA3A012001A for ; Thu, 20 Feb 2020 03:52:56 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Tero Kivinen via Datatracker To: X-Test-IDTracker: no X-IETF-IDTracker: 6.118.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: secdir-secretary@mit.edu, Tero Kivinen Message-ID: <158219957682.12440.9171121386794706559.idtracker@ietfa.amsl.com> Date: Thu, 20 Feb 2020 03:52:56 -0800 Archived-At: Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Feb 2020 11:52:57 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview For telechat 2020-02-20 Reviewer LC end Draft Yaron Sheffer R2020-01-27 draft-ietf-nfsv4-rpcrdma-cm-pvt-data-07 Valery Smyslov R2019-10-30 draft-ietf-core-senml-more-units-05 Tina Tsou 2020-02-06 draft-ietf-6lo-backbone-router-16 For telechat 2020-03-05 Reviewer LC end Draft Charlie Kaufman R2019-09-02 draft-ietf-ecrit-data-only-ea-21 Magnus Nystrom 2019-04-10 draft-ietf-avtcore-multiplex-guidelines-11 Vincent Roca R2019-10-14 draft-ietf-dmm-pmipv6-dlif-05 Joseph Salowey R2019-10-14 draft-ietf-dmm-distributed-mobility-anchoring-14 Last calls: Reviewer LC end Draft Derek Atkins 2020-03-03 draft-ietf-git-using-github-04 John Bradley 2020-02-28 draft-ietf-regext-data-escrow-04 Nancy Cam-Winget 2020-02-28 draft-ietf-git-github-wg-configuration-06 Shaun Cooley 2019-11-12 draft-ietf-regext-login-security-08 Roman Danyliw 2020-02-28 draft-ietf-tcpm-converters-16 Roman Danyliw 2019-11-12 draft-ietf-dtn-bpbis-23 Alan DeKok 2019-06-04 draft-ietf-netvc-testing-09 Linda Dunbar 2020-02-28 draft-ietf-dnsop-7706bis-07 Donald Eastlake 2020-02-27 draft-ietf-6tisch-msf-10 Charlie Kaufman R2019-09-02 draft-ietf-ecrit-data-only-ea-21 Russ Mundy 2020-01-02 draft-ietf-dprive-bcp-op-08 Sandra Murphy 2019-10-04 draft-ietf-mpls-ldp-yang-06 Magnus Nystrom 2019-04-10 draft-ietf-avtcore-multiplex-guidelines-11 Vincent Roca R2019-10-14 draft-ietf-dmm-pmipv6-dlif-05 Joseph Salowey R2019-10-14 draft-ietf-dmm-distributed-mobility-anchoring-14 Stefan Santesson 2020-01-27 draft-ietf-dots-architecture-17 Yaron Sheffer R2020-01-27 draft-ietf-nfsv4-rpcrdma-cm-pvt-data-07 Valery Smyslov R2019-10-30 draft-ietf-core-senml-more-units-05 Takeshi Takahashi 2020-02-06 draft-ietf-mmusic-t140-usage-data-channel-11 Tina Tsou 2020-02-06 draft-ietf-6lo-backbone-router-16 Sean Turner None draft-ietf-opsawg-sdi-02 Mališa Vučinić 2020-03-09 draft-kuehlewind-system-ports-05 Carl Wallace 2020-02-26 draft-ietf-rmcat-eval-criteria-11 David Waltermire 2020-02-25 draft-ietf-6man-icmp-limits-07 Brian Weis 2020-02-24 draft-ietf-alto-cost-calendar-16 Klaas Wierenga 2020-02-21 draft-ietf-lamps-5480-ku-clarifications-00 Paul Wouters 2020-02-20 draft-ietf-lpwan-coap-static-context-hc-12 Dacheng Zhang 2020-03-12 draft-nottingham-how-did-that-get-into-the-repo-01 Dacheng Zhang 2019-11-05 draft-ietf-mpls-ri-rsvp-frr-07 Next in the reviewer rotation: Shawn Emery Stephen Farrell Daniel Franke Daniel Gillmor Phillip Hallam-Baker Steve Hanna Dan Harkins Russ Housley Christian Huitema Leif Johansson From nobody Thu Feb 20 04:37:07 2020 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 639681200F7; Thu, 20 Feb 2020 04:37:05 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Valery Smyslov via Datatracker To: Cc: last-call@ietf.org, draft-ietf-core-senml-more-units.all@ietf.org, core@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.118.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Valery Smyslov Message-ID: <158220222533.12408.17424909984121572707@ietfa.amsl.com> Date: Thu, 20 Feb 2020 04:37:05 -0800 Archived-At: Subject: [secdir] Secdir telechat review of draft-ietf-core-senml-more-units-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Feb 2020 12:37:06 -0000 Reviewer: Valery Smyslov Review result: Ready I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. For some reason I've got the assignment to re-review this document past its deadline (I've got the assignment today, 20 February, and the indicated deadline for the review is 18 February, so I'm not sure whether this review is still useful). Anyway, the document has received some changes from -02 version which I reviewed last time. In particular, Security Considerations section is enhanced with the text describing a potential for a confusion about the proper unit to use. While I'm not sure it's really a security condideration and not an interoperability consideration, I agree that there are no additional threats from security point of view. And my concern about improper use of normative language is resolved. From nobody Thu Feb 20 05:32:39 2020 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CDE512011E; Thu, 20 Feb 2020 05:32:13 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Yaron Sheffer via Datatracker To: Cc: last-call@ietf.org, nfsv4@ietf.org, draft-ietf-nfsv4-rpcrdma-cm-pvt-data.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.118.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Yaron Sheffer Message-ID: <158220553334.12533.2364545616247001180@ietfa.amsl.com> Date: Thu, 20 Feb 2020 05:32:13 -0800 Archived-At: Subject: [secdir] Secdir telechat review of draft-ietf-nfsv4-rpcrdma-cm-pvt-data-07 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Feb 2020 13:32:14 -0000 Reviewer: Yaron Sheffer Review result: Ready The latest version fully addresses the issues I raised in my previous review. Thank you! From nobody Thu Feb 20 09:33:14 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6875412012E for ; Thu, 20 Feb 2020 09:33:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=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 UjWumCMB59td for ; Thu, 20 Feb 2020 09:33:11 -0800 (PST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 5A2C21200FE for ; Thu, 20 Feb 2020 09:33:11 -0800 (PST) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 01KHX5Lf015456 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 20 Feb 2020 12:33:08 -0500 Date: Thu, 20 Feb 2020 09:33:05 -0800 From: Benjamin Kaduk To: Christopher Wood Cc: secdir@ietf.org Message-ID: <20200220173305.GE97652@kduck.mit.edu> References: <158164888774.20556.7623938203569597994@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <158164888774.20556.7623938203569597994@ietfa.amsl.com> User-Agent: Mutt/1.12.1 (2019-06-15) Archived-At: Subject: Re: [secdir] [Last-Call] Secdir telechat review of draft-ietf-dtn-tcpclv4-18 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Feb 2020 17:33:13 -0000 Hi Chris, Thanks for doing this and the initial review; that helped the document out quite a bit! (I did still have a couple discuss points, but they're largely about high-level topics relating to how much policy should be encoded in the protocol spec.) -Ben On Thu, Feb 13, 2020 at 06:54:47PM -0800, Christopher Wood via Datatracker wrote: > Reviewer: Christopher Wood > Review result: Has Nits > > Thanks for updating this document! All of my comments from the previous review > have been addressed. It reads much better now. I only have some minor nits to > note below: > > - Section 8.5: This section title references ciphersuite downgrade, yet the > text refers to configured use of less-good ciphersuites. Perhaps the title > should be, "Threat: Weak TLS Configurations"? - Section 8.6: I don't quite > follow this section. Certainly, describing how one validates certificates is > out of scope. However, the title suggests this is part of how one "uses" > certificates? I might just scratch this section altogether, and instead > reference RFC5280 where certificate-based authentication is first presented. - > Section 8.7: I might rename this title to, "Threat: Symmetric Key Limits." - > Section 8.10.1: I would reference opportunistic security here, as an > unauthenticated key exchange yields similar properties. > > -- > last-call mailing list > last-call@ietf.org > https://www.ietf.org/mailman/listinfo/last-call From nobody Thu Feb 20 17:50:21 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC063120808 for ; Thu, 20 Feb 2020 17:50:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_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=heapingbits.net header.b=kKzLY2Us; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=0vaK0dzX 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 geSisSqVBCqk for ; Thu, 20 Feb 2020 17:50:18 -0800 (PST) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 24B0C120806 for ; Thu, 20 Feb 2020 17:50:18 -0800 (PST) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 0CC1421FFC; Thu, 20 Feb 2020 20:50:17 -0500 (EST) Received: from imap4 ([10.202.2.54]) by compute6.internal (MEProxy); Thu, 20 Feb 2020 20:50:17 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heapingbits.net; h=mime-version:message-id:in-reply-to:references:date:from:to :cc:subject:content-type:content-transfer-encoding; s=fm3; bh=yw x4i5fyhg7mLRMN69p4Tgwr/XyhsAFiPQfoU8xWv90=; b=kKzLY2Uss2MORxG/oD VusrWe2YKYJUpezxyQv5EN4rb2Fs0LqC6yBvlcDtJKxxXg4Q7Ryy8e0cXRLa2Mcq xj/QZ2D16pXS0OAGy/idHeN1AgYczzbY/I1/hyBMSA4kc5hzxrVa3035MFXY0IXE X/S7MfXZsTcnKjbXq9vvWkhQrYXF4FIJSZ1fFDZtWbrPEDy9YZgb+2CM0exKpLwV 7uZKBL+TbIczGqzm52MfTz35h+1KApO6+jv4xWOu/W6hc1JpStm79kG/m+8gFY89 9O64+9XRZ8L2kj5YxQktA3SlKKVgKQTux0WEyw8B+hjnLUcg92FLF2LLseG7nDh6 rolw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=ywx4i5fyhg7mLRMN69p4Tgwr/XyhsAFiPQfoU8xWv 90=; b=0vaK0dzXGLbl7Wc5jIbzdv/HdhuAfdLcayRZRCj+rniaZWSgbupMN7bTm 1TgOZ+T+0MCl41gy5cjJ6zf8ipar5sQCE00vnxU72malnOT+TAL2l+CLvNCLaV1Y FGdetyuzj21RMOpGmK79/S8cTRvGGS52+4vwO201IfWtd6JMaHLRF7nT6DqoHFDz fXmqlRNcOSoSb0HGmBR1c/p1nbbWgFdu32ZKw2BcA3DhjcOHCmd5jG0y/D/t4HaH 7GEldPnfqTfWbGSewZpr81nh40Iv4/zpGoNrf6SFoQjqtfJrFoacNrE5zfaRh7wE zDX1oQInjbWoEkFfOOqihTygTlpaw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedugedrkeefgdegtdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefofgggkfgjfhffhffvufgtgfesthhqredtreerjeenucfhrhhomhepfdevhhhr ihhsthhophhhvghrucghohhougdfuceotggrfieshhgvrghpihhnghgsihhtshdrnhgvth eqnecuffhomhgrihhnpehivghtfhdrohhrghenucevlhhushhtvghrufhiiigvpedtnecu rfgrrhgrmhepmhgrihhlfhhrohhmpegtrgifsehhvggrphhinhhgsghithhsrdhnvght X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 932893C00A1; Thu, 20 Feb 2020 20:50:16 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.7-802-g7a41c81-fmstable-20200203v1 Mime-Version: 1.0 Message-Id: In-Reply-To: <20200220173305.GE97652@kduck.mit.edu> References: <158164888774.20556.7623938203569597994@ietfa.amsl.com> <20200220173305.GE97652@kduck.mit.edu> Date: Thu, 20 Feb 2020 17:49:55 -0800 From: "Christopher Wood" To: "Benjamin Kaduk" Cc: "secdir@ietf.org" Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [secdir] [Last-Call] Secdir telechat review of draft-ietf-dtn-tcpclv4-18 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Feb 2020 01:50:20 -0000 My pleasure! I=E2=80=99m glad it helped. Best, Chris=20 On Thu, Feb 20, 2020, at 9:33 AM, Benjamin Kaduk wrote: > Hi Chris, >=20 > Thanks for doing this and the initial review; that helped the document= out > quite a bit! (I did still have a couple discuss points, but they're > largely about high-level topics relating to how much policy should be > encoded in the protocol spec.) >=20 > -Ben >=20 > On Thu, Feb 13, 2020 at 06:54:47PM -0800, Christopher Wood via=20 > Datatracker wrote: > > Reviewer: Christopher Wood > > Review result: Has Nits > >=20 > > Thanks for updating this document! All of my comments from the previ= ous review > > have been addressed. It reads much better now. I only have some mino= r nits to > > note below: > >=20 > > - Section 8.5: This section title references ciphersuite downgrade, = yet the > > text refers to configured use of less-good ciphersuites. Perhaps the= title > > should be, "Threat: Weak TLS Configurations"? - Section 8.6: I don't= quite > > follow this section. Certainly, describing how one validates certifi= cates is > > out of scope. However, the title suggests this is part of how one "u= ses" > > certificates? I might just scratch this section altogether, and inst= ead > > reference RFC5280 where certificate-based authentication is first pr= esented. - > > Section 8.7: I might rename this title to, "Threat: Symmetric Key Li= mits." - > > Section 8.10.1: I would reference opportunistic security here, as an= > > unauthenticated key exchange yields similar properties. > >=20 > > --=20 > > last-call mailing list > > last-call@ietf.org > > https://www.ietf.org/mailman/listinfo/last-call > From nobody Thu Feb 20 17:53:57 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D7F47120818; Thu, 20 Feb 2020 17:52:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1582249929; bh=inIEAELHkDfd6JbuEHGhZBBHZeEEgUXgMJ/fRLAL+58=; h=From:To:Date:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe:Cc; b=p+u9SxQtYJBE5VfRtMdFDxjHTsE5jDt/9sj4LOJK77sca7WuzP9scpbjJiPMoshmo 0/Ow7OcVuZHD/0P/XKC9lmgRacMFA6HLW61f2TBB5p9U/j9HWZqZUB/Nh128DiXMT8 GNhmoeaJPhma5qdzSeDsQ3Bpp8NZr6QaNK3HPNQ4= X-Mailbox-Line: From new-work-bounces@ietf.org Thu Feb 20 17:52:09 2020 Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 370B4120809; Thu, 20 Feb 2020 17:52:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1582249929; bh=J2HPHkxN7g8JfXHr1md1wiTdKGHZX6X8fyGOVeRco6M=; h=From:To:Date:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe:Cc; b=rP9E5t282wNRTXMNTEmoabmtTX1dvObBx13UUwydqKzb2gifoHb5znpT7+WCnT0be NiFwXgHV4QkrjsI10/o4lEkcOyB7Cc+pyiKdCGIUZP90Z2P4Crfu7xk6Z7Xbar2Cxw khx3yR/8SJFxP4pqAXyOBC4TktdJtt7u3JtlMUlI= X-Original-To: new-work@ietfa.amsl.com Delivered-To: new-work@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2535E120808 for ; Thu, 20 Feb 2020 17:52:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, 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 a5McKBuzJQ8D for ; Thu, 20 Feb 2020 17:52:04 -0800 (PST) Received: from mail-pg1-x52f.google.com (mail-pg1-x52f.google.com [IPv6:2607:f8b0:4864:20::52f]) (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 BED59120809 for ; Thu, 20 Feb 2020 17:52:04 -0800 (PST) Received: by mail-pg1-x52f.google.com with SMTP id z12so182905pgl.4 for ; Thu, 20 Feb 2020 17:52:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id:mime-version:thread-index :content-language; bh=YSwFjwF2gy0OYGHVG4YFAn/Avty6RvM7260hK49L7Oc=; b=eOb+ni/aQaIP2stBmCFZ68IdniCX8DArtzvG+9DcuwDAk+nXhXB3MB90WBxDy3vdrU +CzFmUiSNRm0WLKQbXQWXIfSgT5Iw+5+UTwCjJXUpTxkdPKqSoDl1oSOKXRBuglB2seT kkwPLi3T3LNlC1ejLYj38ogkNUdKii43BIOn+J+7QHrPwxXHkl0ApGa/nVOqk8GMThBy /Rvr6z9bb5c0ZhcUBXsqciJjpPQP1MF/SMJqBNC9FAdJqWz7+mksyofFL6AsObk0xucu Smz/nJ3rJyfuiFRWNwf6dYdqBo/uJl7bbA7iHXIJewyc2gxbRMCeYP6nXM2QiH4ROrgL kt7A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:mime-version :thread-index:content-language; bh=YSwFjwF2gy0OYGHVG4YFAn/Avty6RvM7260hK49L7Oc=; b=emwdVVweShXouDI8wzjoUoWl+tbHBUN55SXS6XA9+gd0FtxJTCPha7HjBXOtrZEsFA PZRZ8uZN+Hk16qlnKxjFKIVulz/uOLxhLbm+ApD7PqGaeCqBUHD6e8TJQapuvDJ+cZdz GiJKfgfJXHBL8QdEkqbTpdsweyShXucXjxHYUePqOp5LpMf0L5JLaWtLs4J70zMeHYlc 35A15a0VzTT6noTKvRGGgYTNRi7TI/b1gEF39GSHG6uglta6w1RqblhJcvWXKzDSuFw3 ezkmPc0Kc3ZwsU404bPUtnV++sFoIHl2iRjsTJwaVN49La/B6M3zFYQtZgf+opP7OcB7 qCnA== X-Gm-Message-State: APjAAAXEcjRkbHZA2qgE1WdQtfeHva9uMLe7iOPe9kBgDymLhlEVDuvZ 03rv3h7NhFhok3cJGLoB0ag= X-Google-Smtp-Source: APXvYqzetmmklVEgxgVfS6XXIo5/TsEm+FOgaV27uk/TuqZQJJaKpcTYCH6L9w1e1juvb9xVw0LQYA== X-Received: by 2002:a63:ae0a:: with SMTP id q10mr35979863pgf.178.1582249924004; Thu, 20 Feb 2020 17:52:04 -0800 (PST) Received: from DESKTOP6VF5FH7 ([216.9.110.9]) by smtp.gmail.com with ESMTPSA id 10sm821126pfu.132.2020.02.20.17.52.03 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 20 Feb 2020 17:52:03 -0800 (PST) From: To: Date: Thu, 20 Feb 2020 17:52:03 -0800 Message-ID: <01e501d5e859$8441dd20$8cc59760$@gmail.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 16.0 Thread-Index: AdXoWYNSf5M4ToWwTb2RCQoyHO1fUQ== Content-Language: en-us Archived-At: X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.29 Precedence: list Cc: "'Stanley, Dorothy'" , Paul Nikolich Content-Type: multipart/mixed; boundary="===============3967303174593252956==" Errors-To: new-work-bounces@ietf.org Sender: "new-work" Archived-At: X-Mailman-Approved-At: Thu, 20 Feb 2020 17:53:56 -0800 Subject: [secdir] [new-work] IEEE 802 Mar 2020 PARs Under Consideration X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Feb 2020 01:52:12 -0000 This is a multipart message in MIME format. --===============3967303174593252956== Content-Type: multipart/alternative; boundary="----=_NextPart_000_01E6_01D5E816.76210E20" Content-Language: en-us This is a multipart message in MIME format. ------=_NextPart_000_01E6_01D5E816.76210E20 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit All, The following Project Authorization Requests (PARs) will be considered at the IEEE 802 Mar 2020 Plenary: * 802.1ASdm Amendment: Hot Standby, PAR and CSD * 802.1CQ Amendment: Multicast and Local Address Assignment, PAR Extension and CSD * 802.3cy Amendment: Greater than 10 Gb/s Automotive Ethernet Electrical PHYs, PAR and CSD * 802.3cz Amendment: Multi-Gigabit Automotive Optical PHYs, PAR and CSD * 802.3da Amendment: 10Mb/s Single Pair Ethernet Multidrop Enhancements, PAR and CSD * 802.3db Amendment: 100 Gb/s Wavelength Short Reach PHYs, PAR and CSD * 802.15.7a - Amendment - Defining High Data Rate Optical Camera Communications (OCC), PAR and CSD The PARs and ICAID can be found at http://www.ieee802.org/PARs.shtml along with the supporting IEEE 802 Criteria for Standards Development, or CSD, (which includes the 5 criteria, i.e. the explanations of how they fit the IEEE 802 criteria for initiating new work). Any comments on a proposed PAR / ICAID should be sent to the Working Group chair identified on the respective document to be received by 6:30 PM EDT (Eastern Daylight Time), Tuesday, Mar 17. Regards, John D'Ambrosia Recording Secretary, IEEE 802 LMSC ------=_NextPart_000_01E6_01D5E816.76210E20 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

All,

The following = Project Authorization Requests (PARs) will be considered at the IEEE = 802 Mar 2020 = Plenary:

  • 802.1ASdm = Amendment: Hot Standby, PAR and CSD
  • 802.1CQ = Amendment: Multicast and Local Address Assignment, PAR Extension and CSD
  • 802.3cy = Amendment: Greater than 10 Gb/s Automotive Ethernet Electrical PHYs, PAR and CSD
  • 802.3cz = Amendment: Multi-Gigabit Automotive Optical PHYs, PAR and CSD
  • 802.3da = Amendment: 10Mb/s Single Pair Ethernet Multidrop Enhancements, PAR and CSD
  • 802.3db = Amendment: 100 Gb/s Wavelength Short Reach PHYs, PAR and CSD
  • 802.15.7a = - Amendment - Defining High Data Rate Optical Camera Communications = (OCC), PAR and CSD

The = PARs and ICAID can be found at http://www.ieee802.org/PARs.sh= tml along with the supporting IEEE 802 Criteria for Standards = Development, or CSD, (which includes the 5 criteria, i.e. the = explanations of how they fit the IEEE 802 criteria for initiating new = work).

Any = comments on a proposed PAR / ICAID should be sent to the Working Group = chair identified on the respective document to be received by 6:30 PM = EDT (Eastern Daylight Time), Tuesday, Mar 17.  =

Regards,

John = D’Ambrosia

Recording Secretary, IEEE 802 LMSC =

 

------=_NextPart_000_01E6_01D5E816.76210E20-- --===============3967303174593252956== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work --===============3967303174593252956==-- From nobody Fri Feb 21 01:59:53 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 344ED1200C5; Fri, 21 Feb 2020 01:59:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=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 dhde4hOfbpnd; Fri, 21 Feb 2020 01:59:49 -0800 (PST) Received: from wp513.webpack.hosteurope.de (wp513.webpack.hosteurope.de [IPv6:2a01:488:42:1000:50ed:8223::]) (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 32A2F1200B6; Fri, 21 Feb 2020 01:59:49 -0800 (PST) Received: from 200116b824c4be0061570d07dc536186.dip.versatel-1u1.de ([2001:16b8:24c4:be00:6157:d07:dc53:6186]); authenticated by wp513.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1j555t-0007Re-00; Fri, 21 Feb 2020 10:59:37 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Mirja Kuehlewind In-Reply-To: <202001210619.00L6JdAc025427@rumpleteazer.rhmr.com> Date: Fri, 21 Feb 2020 10:59:36 +0100 Cc: The IESG , secdir@ietf.org, draft-ietf-rmcat-wireless-tests.all@tools.ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <49CC1810-636F-4655-BD4C-FD2FE727F3EE@kuehlewind.net> References: <202001210619.00L6JdAc025427@rumpleteazer.rhmr.com> To: Hilarie Orman X-Mailer: Apple Mail (2.3445.104.11) X-bounce-key: webpack.hosteurope.de;ietf@kuehlewind.net;1582279189;be6a9218; X-HE-SMSGID: 1j555t-0007Re-00 Archived-At: Subject: Re: [secdir] Security review of draft-ietf-rmcat-wireless-tests-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Feb 2020 09:59:51 -0000 Hi Hilarie, Thanks for this review. Please see below. > On 21. Jan 2020, at 07:19, Hilarie Orman = wrote: >=20 > Security review of Evaluation Test Cases for Interactive > Real-Time Media over Wireless Networks > draft-ietf-rmcat-wireless-tests-08 >=20 > Do not be alarmed. I generated this review of this document as part > of the security directorate's ongoing effort to review all IETF > documents being processed by the IESG. These comments were written > with the intent of improving security requirements and considerations > in IETF drafts. Comments not addressed in last call may be included > in AD reviews during the IESG review. Document editors and WG chairs > should treat these comments just like any other last call comments. >=20 > The focus of this document is the definition of test cases that can be > used evaluate congestion control algorithms for cellular and Wi-Fi > networks. If the testing is done on isolated testbed networks, there > are are few, if any, security considerations. >=20 > The Security Considerations section mentions safeguards to avoid > "congestion collapse of the Internet" and "leaking non-responsive > traffic from unproven congestion avoidance techniques onto the open > Internet". The former seems overly general (shouldn't all IETF > protocols strive to avoid breaking the Internet?), and I am not at all > sure what the latter means. This document belongs to a set of two documents where the other one is = draft-ietf-rmcat-eval-test. Both documents have the same text in the = security considerations section and for draft-ietf-rmcat-eval-test we = created this text based on the SECDIR review feedback.=20 You are right that this text is rather general but the main purpose was = to provide people the right pointers. And yes all protocol should not = break the Internet; this is one thing we usually look for in TSV = reviews, however, in this case it=E2=80=99s a bit a chicken and egg = problem because the whole testing in this doc is about figuring out if = the proposed congestion control is safe enough to test on the Internet = or not. =20 >=20 > I would recommend that test setups use passwords and keys that are > specific to the test environment, but that is a generic recommendation > for all test environments. It is probably not needed in this > document. I think that is really a point that is out of scope for this document. = However, passwords and keys still don=E2=80=99t help if your test setup = is wrongly configured and traffic can =E2=80=9Cescape=E2=80=9D. We = usually assume that test setups are used that are not connected to the = internet at all, or only to ssh into the machines but all other traffic = is by default blocked. That=E2=80=99s what=E2=80=99s meant with =E2=80=9Ca= void leaking=E2=80=9D. Mirja >=20 > Hilarie >=20 >=20 From nobody Fri Feb 21 02:29:53 2020 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DD68A1200DF; Fri, 21 Feb 2020 02:29:50 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: =?utf-8?b?TWFsacWhYSBWdcSNaW5pxIcgdmlhIERhdGF0cmFja2Vy?= To: Cc: last-call@ietf.org, draft-kuehlewind-system-ports.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.118.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: =?utf-8?b?TWFsacWhYSBWdcSNaW5pxIc=?= Message-ID: <158228099071.29085.17375165161369723615@ietfa.amsl.com> Date: Fri, 21 Feb 2020 02:29:50 -0800 Archived-At: Subject: [secdir] Secdir last call review of draft-kuehlewind-system-ports-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Feb 2020 10:29:51 -0000 Reviewer: Mališa Vučinić Review result: Ready I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. The document requests the reassignment of well-known ports in the IANA Service Name and Transport Protocol Port Number Registry from individuals or companies who have registered the port for use before RFC6335 was published to the IESG. The document is well written. It does not change the use of the ports, and so does not raise new security considerations, which is clearly described in the Security Considerations section. As such, the document is ready. From nobody Fri Feb 21 07:17:46 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64BF11201DC for ; Fri, 21 Feb 2020 07:17:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.132 X-Spam-Level: **** X-Spam-Status: No, score=4.132 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FROM_MISSP_DYNIP=1.914, FROM_MISSP_SPF_FAIL=0.001, KHOP_HELO_FCRDNS=0.399, RCVD_IN_RP_RNBL=1.31, RDNS_DYNAMIC=0.982, SPF_FAIL=0.001, SPF_HELO_NONE=0.001, TO_EQ_FM_DOM_SPF_FAIL=0.177, TO_EQ_FM_SPF_FAIL=0.028, TO_NO_BRKTS_FROM_MSSP=1.218, 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 dFaPIW38DF3o for ; Fri, 21 Feb 2020 07:17:42 -0800 (PST) Received: from spammx02.iasl.com (ip-206-210-112-178.FTTH.standardbroadband.ca [206.210.112.178]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6EA60120099 for ; Fri, 21 Feb 2020 07:17:42 -0800 (PST) X-ASG-Debug-ID: 1582298020-13ceae16f03e3f10006-mFDwdl Received: from fixed-189-203-132-241.totalplay.net (ip-206-210-112-177.FTTH.standardbroadband.ca [206.210.112.177]) by spammx02.iasl.com with ESMTP id XCsMQjkVlD39JyvS for ; Fri, 21 Feb 2020 10:14:18 -0500 (EST) X-Barracuda-Envelope-From: secdir@ietf.org X-Barracuda-Effective-Source-IP: ip-206-210-112-177.FTTH.standardbroadband.ca[206.210.112.177] X-Barracuda-Apparent-Source-IP: 206.210.112.177 From: Antonio Amezcua To: secdir@ietf.org Date: 21 Feb 2020 09:14:18 -0600 X-ASG-Orig-Subj: Anunciese con 100 mil clientes potenciales. Message-ID: <20200221091418.92C1B3CB87EC4AE4@ietf.org> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Barracuda-Connect: ip-206-210-112-177.FTTH.standardbroadband.ca[206.210.112.177] X-Barracuda-Start-Time: 1582298058 X-Barracuda-URL: https://206.210.112.178:443/cgi-mod/mark.cgi X-Barracuda-BRTS-Status: 1 X-Virus-Scanned: by bsmtpd at iasl.com X-Barracuda-Scan-Msg-Size: 483 X-Barracuda-Spam-Score: 0.50 X-Barracuda-Spam-Status: No, SCORE=0.50 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests=BSF_SC0_SA_TO_FROM_ADDR_MATCH X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.80161 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.50 BSF_SC0_SA_TO_FROM_ADDR_MATCH Sender Address Matches Recipient Address Archived-At: Subject: [secdir] Anunciese con 100 mil clientes potenciales. X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Feb 2020 15:17:44 -0000 Promocione su empresa o negocio ante 100 mil clientes potenciales=20 en Mexico. Por tan solo 99 USD. Resultados inmediatos, medibles y tangibles. Contamos con bases actualizadas y segmentadas de industrias,=20 comercios, prestadores de servicios y profesionistas en todo el pais. Para mayor informacion escribanos a=20 publidirecto.mx(arroba)gmail.com con el subject "informacion" --------------------- Oferta valida por tiempo limitado para secdir@ietf.org. From nobody Fri Feb 21 10:52:30 2020 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A4CA120024; Fri, 21 Feb 2020 10:52:13 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Paul Wouters via Datatracker To: Cc: lp-wan@ietf.org, last-call@ietf.org, draft-ietf-lpwan-coap-static-context-hc.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.118.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Paul Wouters Message-ID: <158231113340.29033.17150460168186400041@ietfa.amsl.com> Date: Fri, 21 Feb 2020 10:52:13 -0800 Archived-At: Subject: [secdir] Secdir last call partial review of draft-ietf-lpwan-coap-static-context-hc-12 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Feb 2020 18:52:14 -0000 Review is partially done. Another assignment may be needed to complete it. Reviewer: Paul Wouters Review result: Serious Issues I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. I agree with the comments raised by the genart review by Theresa Enghardt. The Security Section is just a reference to another document that specifies in its own Security Consideration: As explained in Section 5, SCHC is expected to be implemented on top of LPWAN technologies, which are expected to implement security measures. This document explains that packets are wrapped in CoAP and then this document can be used to compress fields, similar to the references document. But now this is happening in the most outer layer, which the referenced document basically states that in its Security Considerations, it assumes the outer layer has some kind of LPWAN based security meassures in place. It seems these two drafts need some coordination to determine where, how and which Security Considerations are relevant. Additionally, I'm a bit worried about multiple layers doing compression. Can this lead to security issues? If not, why not? Where is it sais that compression states need to be checked for bogus instructions? How are these prevented? Think of the ever-decompressing zip file hacks of the past. How are these DoS attacks prevented ? Other than this issue, I found Section 1 Introducion a bit confusing. It seems to drop a reference to another document and then explain that other document, without really talking about this document? Or if it does, it was not very clear to me. I did not review this document for nits - my apologies but I ran out of time. From nobody Fri Feb 21 12:23:58 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA87812007A; Fri, 21 Feb 2020 12:23:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=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 jA6iVltQZVxr; Fri, 21 Feb 2020 12:23:41 -0800 (PST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 AC24D12006B; Fri, 21 Feb 2020 12:23:38 -0800 (PST) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 01LKNX3R014204 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 21 Feb 2020 15:23:35 -0500 Date: Fri, 21 Feb 2020 12:23:32 -0800 From: Benjamin Kaduk To: Paul Wouters Cc: secdir@ietf.org, lp-wan@ietf.org, last-call@ietf.org, draft-ietf-lpwan-coap-static-context-hc.all@ietf.org Message-ID: <20200221202332.GC53538@kduck.mit.edu> References: <158231113340.29033.17150460168186400041@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <158231113340.29033.17150460168186400041@ietfa.amsl.com> User-Agent: Mutt/1.12.1 (2019-06-15) Archived-At: Subject: Re: [secdir] [Last-Call] Secdir last call partial review of draft-ietf-lpwan-coap-static-context-hc-12 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Feb 2020 20:23:44 -0000 Hi Paul, Thanks for doing the review and raising the potentially serious issues. On Fri, Feb 21, 2020 at 10:52:13AM -0800, Paul Wouters via Datatracker wrote: > > Review is partially done. Another assignment may be needed to complete it. > > Reviewer: Paul Wouters > Review result: Serious Issues > > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the > IESG. These comments were written primarily for the benefit of the > security area directors. Document editors and WG chairs should treat > these comments just like any other last call comments. > > I agree with the comments raised by the genart review by Theresa Enghardt. The > Security Section is just a reference to another document that specifies in its > own Security Consideration: > > As explained in Section 5, SCHC is expected to be implemented on top > of LPWAN technologies, which are expected to implement security > measures. > > This document explains that packets are wrapped in CoAP and then this document > can be used to compress fields, similar to the references document. But now > this is happening in the most outer layer, which the referenced document > basically states that in its Security Considerations, it assumes the outer > layer has some kind of LPWAN based security meassures in place. > > It seems these two drafts need some coordination to determine where, how and > which Security Considerations are relevant. It does seem like it, since CoAP is not guaranteed to be used over a physical medium with integrated security technologies (though many expected use cases do). > Additionally, I'm a bit worried about multiple layers doing compression. Can > this lead to security issues? If not, why not? > > Where is it sais that compression states need to be checked for bogus > instructions? How are these prevented? Think of the ever-decompressing zip file > hacks of the past. How are these DoS attacks prevented ? I think the "static context" nature of this compression mechanism prevents issues with near-infinite expansion, at least, though there would of course still be room for bugs when handling noncompliant input. -Ben > Other than this issue, I found Section 1 Introducion a bit confusing. It seems > to drop a reference to another document and then explain that other document, > without really talking about this document? Or if it does, it was not very > clear to me. > > I did not review this document for nits - my apologies but I ran out of time. > > > -- > last-call mailing list > last-call@ietf.org > https://www.ietf.org/mailman/listinfo/last-call From nobody Sat Feb 22 20:35:04 2020 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C17A3A0CA0; Sat, 22 Feb 2020 20:34:55 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Joseph Salowey via Datatracker To: Cc: last-call@ietf.org, draft-ietf-dmm-distributed-mobility-anchoring.all@ietf.org, dmm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.118.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <158243249541.8748.14672819496821719492@ietfa.amsl.com> Reply-To: Joseph Salowey Date: Sat, 22 Feb 2020 20:34:55 -0800 Archived-At: Subject: [secdir] Secdir telechat review of draft-ietf-dmm-distributed-mobility-anchoring-14 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Feb 2020 04:34:56 -0000 Reviewer: Joseph Salowey Review result: Ready This revision addresses my previous comments. Thanks, Joe From nobody Sun Feb 23 21:34:16 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66FF13A0853; Sun, 23 Feb 2020 21:34:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.602 X-Spam-Level: *** X-Spam-Status: No, score=3.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, GB_SUMOF=5, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, 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 q83dqme-zUa0; Sun, 23 Feb 2020 21:34:03 -0800 (PST) Received: from mail-il1-f175.google.com (mail-il1-f175.google.com [209.85.166.175]) (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 5B15A3A0851; Sun, 23 Feb 2020 21:33:57 -0800 (PST) Received: by mail-il1-f175.google.com with SMTP id g12so6710486ild.2; Sun, 23 Feb 2020 21:33:57 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=7kQzvjvhCIP8+wJHp8u/GcGurGtgNg3L3QgDn40b7aA=; b=U/PEubEzF27Veokte+QodWZ4NVxYBED8zEVQINzWB2n2y9NHFaDmb1PjSFETgz2FE5 tn02OhxqtqPHSu6rPbvJ8Psw8R0VkvriS9RdinOnSIlE6Aof1BveThGcH9sdwqfc2OIe 8zerc+Ju4uKGOEM3CBxwNoOyXVmvoTlqQhdRfSSaxAU69/WBTCqcQcVlOLVpV1qG2Brf y0wEQES9jkRVcADyU+PtRB8XCdH7EgCO+rBeXEkgAlaOq4TNQVLXHvbWt51c0b5QTJxR OJ1EpvZv3GBc0rmG9Z9+j9qJQqOoFq6fSVrzZByGTE3WjeJOpAXe55BHqQT1FRwAD/XL ncFA== X-Gm-Message-State: APjAAAVg10FYuZ3rURL3IcH6mFY9os/4ckcyrQVUhJGOa9orBtETIGt+ A6ei7Ac6wILN3X7Z2F2PNeFTW0XYYM8OsLzVqww= X-Google-Smtp-Source: APXvYqymbNtc4xi5cLvQxwxhjteedt9EI5c9TtvZmjDzZ5PhQGPMjZEL9HS3tsSx3e/tCTap30c4TgPLDzZciFSGvms= X-Received: by 2002:a92:d3cc:: with SMTP id c12mr56712107ilh.266.1582522436178; Sun, 23 Feb 2020 21:33:56 -0800 (PST) MIME-Version: 1.0 References: <001601d57af9$405efcf0$c11cf6d0$@vocal.com> <6E58094ECC8D8344914996DAD28F1CCD23D79BC0@DGGEMM506-MBX.china.huawei.com> <034a01d58a73$f4d3a1c0$de7ae540$@vocal.com> <037e01d58a92$72287510$56795f30$@vocal.com> <20191101001153.GQ88302@kduck.mit.edu> <06e101d59f15$ee937b30$cbba7190$@vocal.com> <20191125064606.GL32847@mit.edu> <00c601d5e339$965ebd90$c31c38b0$@vocal.com> <20200214194321.GF43385@kduck.mit.edu> In-Reply-To: <20200214194321.GF43385@kduck.mit.edu> From: Barry Leiba Date: Sun, 23 Feb 2020 21:33:45 -0800 Message-ID: To: Benjamin Kaduk Cc: Ali Begen , Catherine Meadows , "Dave Satterlee (Vocal)" , IETF SecDir , IETF discussion list , "Roni Even (A)" , The IESG , avt@ietf.org, avtcore-chairs@ietf.org, draft-ietf-payload-tsvcis@ietf.org, draft-ietf-payload-tsvcis.all@ietf.org, victor.demjanenko@vocal.com Content-Type: multipart/alternative; boundary="000000000000a85af0059f4bb74a" Archived-At: Subject: Re: [secdir] Benjamin Kaduk's Discuss on draft-ietf-payload-tsvcis-03: (with DISCUSS and COMMENT) X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Feb 2020 05:34:10 -0000 --000000000000a85af0059f4bb74a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, Victor... your turn now... Barry On Fri, Feb 14, 2020 at 11:43 AM Benjamin Kaduk wrote: > Hi Barry, > > As Victor notes, this one was/is waiting on me; he did reply (offlist) on > 15 January but I seem to have missed it amid a deluge of other mail that > arrived at that time. Thanks for the reminder, and thanks Victor for > re-sending the comments. > (inline) > > On Fri, Feb 14, 2020 at 08:20:54AM -0500, victor.demjanenko@vocal.com > wrote: > > HI Barry, > > > > Thanks for recalling this was still outstanding. I had emailed Ben jus= t > after the holidays and did not realize we had no response. The below is > what we suggested to Ben to address concerns he raised. > > > > -------------------- > > Hi Ben, > > > > Hope your holidays were good. Our were both good and busy. Deliveries > for two NASA projects and the holidays kept us from responding sooner. B= ut > we do want to get this draft completed. > > > > With your permission, I=E2=80=99d like to address your comments directl= y, > resolve what changes we should make and then publish a new version with a > summary of our out-of-band discussions. We don=E2=80=99t have a lot of e= xperience > with drafting such documents and would like to know exactly what is neede= d > to make this draft acceptable. > > > > I believe there are two comments/issues to address: > > > > 1) CODA, CODB > > > > Your comment ends by stating: =E2=80=9C(Or, of course, the use of CODB= as an > alternating 1/0 bit as the framing usage could be documented instead.)=E2= =80=9D We > can do this as follows: > > > > (original) > > It should be noted that CODB for MELPe 600 bps mode MAY deviate from > > the value in Table 1 when bit 55 is used as an end-to-end framing > > bit. Frame decoding would remain distinct as CODA being zero on its > > own would indicate a 7-byte frame for either 2400 or 600 bps rate an= d > > the use of 600 bps speech coding could be deduced from the RTP > > timestamp (and anticipated by the SDP negotiations). > > > > (adding =E2=80=9Calternating 1/0=E2=80=9D) > > It should be noted that CODB for MELPe 600 bps mode MAY deviate from > > the value in Table 1 when bit 55 is used as an alternating 1/0 > end-to-end framing > > bit. Frame decoding would remain distinct as CODA being zero on its > > own would indicate a 7-byte frame for either 2400 or 600 bps rate an= d > > the use of 600 bps speech coding could be deduced from the RTP > > timestamp (and anticipated by the SDP negotiations). > > > > I think this change would be sufficient to address your concern about > what to expect for CODB. > > This looks like the minimal sufficient change, yes. (I use "minimal" > because I would say more if I was writing it, but I don't think I can > insist that you write it the way I would -- it's your document after all!= ) > > > 2. Packing and unpacking > > > > You are correct that I am trying to vaguely describe a middle layer shi= m > that is neither RTP nor speech coder. So it definitely does need to be > clear. The vagueness comes from the speech coder description being a FOU= O > document. Its now unclassified so I can potentially say more (and I did > make some enhancements of the parameter description already). > > > > So I am trying to understand exactly what you think is vague in our > current description: > > > > TSVCIS augmented speech data is derived from the signal processing > > and data already performed by the MELPe speech coder. For the > > purposes of this specification, only the general parameter nature of > > TSVCIS will be characterized. Depending on the bandwidth available > > (and FEC requirements), a varying number of TSVCIS-specific speech > > coder parameters need to be transported. These are first byte-packe= d > > and then conveyed from encoder to decoder. > > > > Byte packing of TSVCIS speech data into packed parameters is > > processed as per the following example: > > > > Three-bit field: bits A, B, and C (A is MSB, C is LSB) > > Five-bit field: bits D, E, F, G, and H (D is MSB, H is LSB) > > > > MSB LSB > > 0 1 2 3 4 5 6 7 > > +------+------+------+------+------+------+------+------+ > > | H | G | F | E | D | C | B | A | > > +------+------+------+------+------+------+------+------+ > > > > This packing method places the three-bit field "first" in the lowest > > bits followed by the next five-bit field. Parameters may be split > > between octets with the most significant bits in the earlier octet. > > Any unfilled bits in the last octet MUST be filled with zero. > > [not actually relevant to the Discuss part, but if there is always exactl= y > one 3-bit parameter and one 5-bit parameter, then this text allowing > splitting across octets will never be used and is potentially confusing t= o > mention.] > > > In order to accommodate a varying amount of TSVCIS augmented speech > > data, it is only necessary to specify the number of octets containin= g > > the packed TSVCIS parameters. The encoding to do so is presented in > > I think the "only necessary to specify the number of octets" is the key > stumbling point, for me -- I need to know the number of octets as well as > the order of the parameters within the list, which is more information th= an > just the number of octets. > > > Section 3.2. TSVCIS specifically uses the NRL VDR in two > > configurations using 15 and 35 packed octet parameters [TSVCIS]. > > I think I failed to internalize the "two configurations using 15 and 35 > packed octet parameters" the first time I read the document, as this does > help give the reader a clue that [TSVCIS] gives a good picture of what > parameters go where. So it seems like we could easily append to that, fo= r > "using a fixed set of 15 and 35 packed octet parameters in a fixed order > [TSVCIS]" and that would resolve my concerns. > > > The speech coder description of the parameters is the following: > > > > > > > > So the three bit pitch is first (bits 56 to 58), followed by a five bit > amplitude (bits 59 to 63) and then an array of spectral components, each > 8-bit wide (starting at bit 64). > > [And maybe TSVCIS specifes that the spectral components are derived from > some fundamental harmonic decomposition that naturally quantizes to a > number-of-parameters/accuracy tradeoff with a natural order. If so, we > could also rely on that instead of my proposed change above; let me know = if > you want to explore that path further.] > > > Based on this information, I=E2=80=99m not sure what we should add to o= ur draft > to make the description of packing/unpacking clearer. Can you make any > suggestions or does this table help you with what you did not know? (I > don=E2=80=99t think I should put this table into the draft RFC however.) > > Hopefully the above helps to clarify. > > Thanks, and sorry for the delay. > > -Ben > > > Thanks for your attention and comments. > > > > Victor & Dave > > > > > > > > -----Original Message----- > > From: Barry Leiba > > Sent: Friday, February 14, 2020 7:38 AM > > To: Benjamin Kaduk > > Cc: victor.demjanenko@vocal.com; Roni Even (A) ; > The IESG ; Catherine Meadows < > catherine.meadows@nrl.navy.mil>; IETF SecDir ; > draft-ietf-payload-tsvcis@ietf.org; Ali Begen = ; > avtcore-chairs@ietf.org; avt@ietf.org; Dave Satterlee (Vocal) < > Dave.Satterlee@vocal.com>; IETF discussion list ; > draft-ietf-payload-tsvcis.all@ietf.org > > Subject: Re: Benjamin Kaduk's Discuss on draft-ietf-payload-tsvcis-03: > (with DISCUSS and COMMENT) > > > > This is still outstanding, since November. Victor, where are we on thi= s > one? > > > > Barry > > > > On Mon, Nov 25, 2019 at 1:46 AM Benjamin Kaduk wrote: > > > > > > Hi Victor, > > > > > > On Tue, Nov 19, 2019 at 03:14:21PM -0500, victor.demjanenko@vocal.com > wrote: > > > > Hi Ben, > > > > > > > > Sorry I overlooked sending you a response. I would like to address > > > > the two concerns you have by explaining what the speech coders are > doing. > > > > > > Thanks for the extra clarifications. To supply one of my own: I'm no= t > > > concerned that the protocol doesn't work as implemented, but just wan= t > > > to make sure that the document includes enough information to admit > > > new implementations without guesswork. That is to say, "either tell > > > me how to do it or tell me where to look that tells me how to do it". > > > > > > > WRT to 600 bps MELP, there is one TSVCIS mode that uses one bit > > > > beyond the 54-bit frame for MELP 600 as a frame sync which > alternates between frames. > > > > With two or more MELP 600bps frames in one RTP packet, if any frame > > > > indicates 600 bps by CODA being 0 and CODB being 1, then we know th= e > > > > stream is 600bps. If there is a single frame in an RTP packet, you > > > > can still deduce this by looking at every other RTP packet (every > > > > other MELP 600bps > > > > frame) and by the timestamp advance. Most likely the two ends woul= d > > > > negotiate 600 bps in SDP anyways so there really should not be a > > > > problem. I know it's not pretty but its workable. I hope this > > > > explanation helps you with the concerns for this issue. > > > > > > In this case, the use as an "end-to-end framing bit" (i.e., the > > > alternating behavior you describe above) is not explicitly stated; on= e > > > might imagine a scheme where the framing usage is to have the bit > > > cycle through 1, 1, 0, and 0, or some other scheme. I'd suggest to > > > note in the document that if any instance of (CODA, CODB) =3D=3D (0, = 1) is > > > observed, then the 600bps mode is in use. It might also be helpful t= o > > > include the observation that two successive MELPe payloads with CODA > > > =3D=3D CODB =3D=3D 0 indicates the 2400bps mode (and that seeing them= in a > > > single RTP packet is decisive, whereas additional information about > > > packet non-loss would be needed in the one-MELPe-frame-per-RTP-packet > > > case), but that would be a fair bit of additional text and might be > > > diminishing returns. (Or, of course, the use of CODB as an > > > alternating 1/0 bit as the framing usage could be documented > > > instead.) > > > > > > > As for the TSVCIS parameter packing/unpacking, this is really > > > > simple. There is exactly on three bit parameter, exactly one five > > > > bit parameter and a variable number of eight bit parameters. In ou= r > > > > view, the speech coder itself (or a wrapper for it) is responsible > > > > for preparing the block of octets. RTP then just transports it. O= n > > > > receive, the complementary wrapper reverses the packing operation. > > > > I hope this clarifies and explains the simplicity. > > > > > > That's exactly what I expected to happen; however, it's not what I > > > believe the current text of the document is describing. Specifically= , > > > I think that the current text implies that the "preparing the block o= f > > > octets" and "complementary wrapper reverses the packing operation" ar= e > > > supposed to be part of the RTP payload format that this document > > > describes, but this document does not have enough information to > > > actually perform those operations reversibly. If the packing is to b= e > > > done in the speech coder, then this document doesn't need to talk > > > about the packing at all (e.g., at the end of Section 2); if we need > > > to keep the packing/wrapper in this document then we need to indicate > > > that there's a defined priority order for the (8-octet) TSVCIS > > > parameters in the TSVCIS references, to allow the packing/unpacking t= o > be deterministic. > > > > > > Thanks, > > > > > > Ben > > > > > > > > > > > -----Original Message----- > > > > From: Benjamin Kaduk > > > > Sent: Thursday, October 31, 2019 8:12 PM > > > > To: Barry Leiba > > > > Cc: victor.demjanenko@vocal.com; Roni Even (A) > > > > ; The IESG ; Catherine Meadows > > > > ; IETF SecDir ; > > > > draft-ietf-payload-tsvcis@ietf.org; Ali Begen > > > > ; avtcore-chairs@ietf.org; avt@ietf.org; > > > > Dave Satterlee (Vocal) ; IETF discussion > > > > list ; draft-ietf-payload-tsvcis.all@ietf.org > > > > Subject: Re: Benjamin Kaduk's Discuss on > > > > draft-ietf-payload-tsvcis-03: (with DISCUSS and COMMENT) > > > > > > > > I don't think so, unfortunately. > > > > > > > > I do see the clarification about CODB's potential for deviation fro= m > > > > Table 1, that only the 600 bps MELPe is allowed to deviate, and tha= t > > > > CODA gets us to "it's one of 2400 or 600 bps" and the RTP timestamp > > > > disambiguates that > > > > 600 bps is in use. But, it seems that this means that the recipien= t > > > > in general should not rely on CODB to differentiate 600 from 2400 > > > > bps, and instead is more robustly implemented by *always* using the > > > > RTP timestamp to detect 600 bps, since that will always work and > > > > CODB will sometimes not work under conditions not fully specified > > > > here. So, if we are unwilling or unable to clarify what those > > > > conditions are (e.g., whether at a minimum mutual agreement is > > > > required), then I think we need to describe this procedure of > > > > consulting the RTP timestamp as the default behavior and avoid > giving the impression that CODB should be used to do so. > > > > > > > > Additionally, I don't see anything to address my concern about > > > > TSVCIS parameter decoding. To be clear, the procedure I see this > > > > document describing is that: > > > > - TSVCIS gives parameters (and their lengths in bits) to the codec > > > > described in this document > > > > - this document specifies how to densely encode those parameters > into a > > > > byetstream > > > > - RTP transmits that encoded bytestream to the peer > > > > - the codec specified by this is responsible for turning that encod= ed > > > > bystream back into a list of TSVCIS parameters (and their length > > > > in bits) > > > > > > > > I don't see how that last step is attainable with only the > > > > information provided by this document. I *assume* that one of the > > > > TSVCIS specifications has a canonical (ordered) listing of > > > > parameters, and that the list of parmeters given to this codec in > > > > the first step will always be an initial prefix of that list, but > > > > that's just me guessing at how to make sense of the stated procedur= e > > > > given insufficient information. I don't think it's appropriate to > > > > make the reader of an RFC guess at what to do; we need to either sa= y > > > > how to do it or give a pointer to an external reference that does. > > > > > > > > -Ben > > > > > > > > On Tue, Oct 29, 2019 at 02:26:09PM -0400, Barry Leiba wrote: > > > > > Ben, does the -04 version address everything? > > > > > > > > > > Barry > > > > > > > > > > On Thu, Oct 24, 2019 at 1:42 PM > wrote: > > > > > > > > > > > > I forgot to address security comments in one email. The change= s > are: > > > > > > > > > > > > Section 8, second paragraph - Suggested edit by reviewer > > > > > > > > > > > > (was) > > > > > > This RTP payload format and the TSVCIS decoder do not exhibi= t > any > > > > > > significant non-uniformity in the receiver-side computationa= l > > > > > > complexity for packet processing and thus are unlikely to > pose a > > > > > > denial-of-service threat due to the receipt of pathological > data. > > > > > > Additionally, the RTP payload format does not contain any > active > > > > > > content. > > > > > > > > > > > > (now) > > > > > > This RTP payload format and the TSVCIS decoder, to the best > of our > > > > > > knowledge, do not exhibit any significant non-uniformity in > the > > > > > > receiver-side computational complexity for packet processing > and thus > > > > > > are unlikely to pose a denial-of-service threat due to the > receipt of > > > > > > pathological data. Additionally, the RTP payload format does > not > > > > > > contain any active content. > > > > > > > > > > > > > > > > > > Section 8, third paragraph - Suggested edit by reviewer > > > > > > > > > > > > (was) > > > > > > Please see the security considerations discussed in [RFC6562= ] > > > > > > regarding VAD and its effect on bitrates. > > > > > > > > > > > > (now) > > > > > > Please see the security considerations discussed in [RFC6562= ] > > > > > > regarding Voice Activity Detect (VAD) and its effect on > bitrates. > > > > > > > > > > > > Victor > > > > > > > > > > > > -----Original Message----- > > > > > > From: victor.demjanenko@vocal.com > > > > > > Sent: Thursday, October 24, 2019 10:05 AM > > > > > > To: 'Roni Even (A)' ; 'Benjamin Kaduk' > > > > > > ; 'The IESG' > > > > > > Cc: draft-ietf-payload-tsvcis@ietf.org; 'Ali Begen' > > > > > > ; avtcore-chairs@ietf.org; > > > > > > avt@ietf.org; 'Dave Satterlee (Vocal)' > > > > > > > > > > > > Subject: RE: Benjamin Kaduk's Discuss on > > > > > > draft-ietf-payload-tsvcis-03: (with DISCUSS and COMMENT) > > > > > > > > > > > > Hi Everyone, > > > > > > > > > > > > First we want to thank everyone for their review and comments > > > > > > for this > > > > draft RFC. We believe we reviewed all the comments and suggestions > > > > and incorporated them adequately in the next draft (04). We'd like > > > > to send out this list of exact changes in case anyone has additiona= l > > > > comments or thinks the clarifications are inadequate. We would be > > > > most happy to address concerns before publishing draft 04 tomorrow. > > > > > > > > > > > > With so many emails from a half dozen or more reviewers, we > > > > > > apologize > > > > that we cannot address each sender individually. We hope this > > > > detail is sufficient for everyone. > > > > > > > > > > > > Again, many thanks to all. > > > > > > > > > > > > Victor & Dave > > > > > > > > > > > > ---------------------------------------------------------------= - > > > > > > ---- > > > > > > -------------------------- > > > > > > > > > > > > Section 1.1 - Suggested reference to RFC 8088 added. > > > > > > > > > > > > (was) > > > > > > Best current practices for writing an RTP payload format > > > > > > specification were followed [RFC2736]. > > > > > > > > > > > > (now) > > > > > > Best current practices for writing an RTP payload format > > > > > > specification were followed [RFC2736] [RFC8088]. > > > > > > > > > > > > > > > > > > Section 2, paragraphs 3 and 4 - Suggested edits by reviewers > > > > > > > > > > > > (was) > > > > > > In addition to the augmented speech data, the TSVCIS > specification > > > > > > identifies which speech coder and framing bits are to be > encrypted, > > > > > > and how they are protected by forward error correction (FEC) > > > > > > techniques (using block codes). At the RTP transport layer, > only the > > > > > > speech coder related bits need to be considered and are > conveyed in > > > > > > unencrypted form. In most IP-based network deployments, > standard > > > > > > link encryption methods (SRTP, VPNs, FIPS 140 link encryptor= s > or Type > > > > > > 1 Ethernet encryptors) would be used to secure the RTP speec= h > > > > > > contents. Further, it is desirable to support the highest > voice > > > > > > quality between endpoints which is only possible without the > overhead > > > > > > of FEC. > > > > > > > > > > > > TSVCIS augmented speech data is derived from the signal > processing > > > > > > and data already performed by the MELPe speech coder. For t= he > > > > > > purposes of this specification, only the general parameter > nature of > > > > > > TSVCIS will be characterized. Depending on the bandwidth > available > > > > > > (and FEC requirements), a varying number of TSVCIS specific > speech > > > > > > coder parameters need to be transported. These are first > byte-packed > > > > > > and then conveyed from encoder to decoder. > > > > > > > > > > > > (now) > > > > > > In addition to the augmented speech data, the TSVCIS > specification > > > > > > identifies which speech coder and framing bits are to be > encrypted, > > > > > > and how they are protected by forward error correction (FEC) > > > > > > techniques (using block codes). At the RTP transport layer, > only the > > > > > > speech-coder-related bits need to be considered and are > conveyed in > > > > > > unencrypted form. In most IP-based network deployments, > standard > > > > > > link encryption methods (SRTP, VPNs, FIPS 140 link encryptor= s > or Type > > > > > > 1 Ethernet encryptors) would be used to secure the RTP speec= h > > > > > > contents. > > > > > > > > > > > > TSVCIS augmented speech data is derived from the signal > processing > > > > > > and data already performed by the MELPe speech coder. For t= he > > > > > > purposes of this specification, only the general parameter > nature of > > > > > > TSVCIS will be characterized. Depending on the bandwidth > available > > > > > > (and FEC requirements), a varying number of TSVCIS-specific > speech > > > > > > coder parameters need to be transported. These are first > byte-packed > > > > > > and then conveyed from encoder to decoder. > > > > > > > > > > > > > > > > > > Section 3, last sentence paragraph 3 - Suggested edit by > > > > > > reviewer > > > > > > > > > > > > (was) > > > > > > When more than one codec data frame is > > > > > > present in a single RTP packet, the timestamp is, as always, > that of > > > > > > the oldest data frame represented in the RTP packet. > > > > > > > > > > > > (now) > > > > > > When more than one codec data frame is > > > > > > present in a single RTP packet, the timestamp specified is > that of > > > > > > the oldest data frame represented in the RTP packet. > > > > > > > > > > > > > > > > > > Section 3.1, last paragraph - Clarified permission for MELP 600 > > > > > > end-to-end framing bit > > > > > > > > > > > > (was) > > > > > > It should be noted that CODB for both the 2400 and 600 bps > modes MAY > > > > > > deviate from the values in Table 1 when bit 55 is used as an > end-to- > > > > > > end framing bit. Frame decoding would remain distinct as > CODA being > > > > > > zero on its own would indicate a 7-byte frame for either rat= e > and the > > > > > > use of 600 bps speech coding could be deduced from the RTP > timestamp > > > > > > (and anticipated by the SDP negotiations). > > > > > > > > > > > > (now) > > > > > > It should be noted that CODB for MELPe 600 bps mode MAY > deviate from > > > > > > the value in Table 1 when bit 55 is used as an end-to-end > framing > > > > > > bit. Frame decoding would remain distinct as CODA being zero > on its > > > > > > own would indicate a 7-byte frame for either 2400 or 600 bps > rate and > > > > > > the use of 600 bps speech coding could be deduced from the R= TP > > > > > > timestamp (and anticipated by the SDP negotiations). > > > > > > > > > > > > > > > > > > Section 3.2, first paragraph - Clarifications requested by > > > > > > reviewers > > > > > > > > > > > > (was) > > > > > > The TSVCIS augmented speech data as packed parameters MUST b= e > placed > > > > > > immediately after a corresponding MELPe 2400 bps payload in > the same > > > > > > RTP packet. The packed parameters are counted in octets > (TC). In > > > > > > the preferred placement, shown in Figure 6, a single trailin= g > octet > > > > > > SHALL be appended to include a two-bit rate code, CODA and > CODB, > > > > > > (both bits set to one) and a six-bit modified count (MTC). > The > > > > > > special modified count value of all ones (representing a MTC > value of > > > > > > 63) SHALL NOT be used for this format as it is used as the > indicator > > > > > > for the alternate packing format shown next. In a standard > > > > > > implementation, the TSVCIS speech coder uses a minimum of 15 > octets > > > > > > for parameters in octet packed form. The modified count > (MTC) MUST > > > > > > be reduced by 15 from the full octet count (TC). Computed > MTC =3D TC- > > > > > > 15. This accommodates a maximum of 77 parameter octets > (maximum > > > > > > value of MTC is 62, 77 is the sum of 62+15). > > > > > > > > > > > > (now) > > > > > > The TSVCIS augmented speech data as packed parameters MUST b= e > placed > > > > > > immediately after a corresponding MELPe 2400 bps payload in > the same > > > > > > RTP packet. The packed parameters are counted in octets > (TC). The > > > > > > preferred placement SHOULD be used for TSVCIS payloads with > TC less > > > > > > than or equal to 77 octets, is shown in Figure 6. In the > preferred > > > > > > placement, a single trailing octet SHALL be appended to > include a > > > > > > two-bit rate code, CODA and CODB, (both bits set to one) and > a six- > > > > > > bit modified count (MTC). The special modified count value > of all > > > > > > ones (representing a MTC value of 63) SHALL NOT be used for > this > > > > > > format as it is used as the indicator for the alternate > packing > > > > > > format shown next. In a standard implementation, the TSVCIS > speech > > > > > > coder uses a minimum of 15 octets for parameters in octet > packed > > > > > > form. The modified count (MTC) MUST be reduced by 15 from > the full > > > > > > octet count (TC). Computed MTC =3D TC-15. This accommodate= s a > maximum > > > > > > of 77 parameter octets (maximum value of MTC is 62, 77 is th= e > sum of > > > > > > 62+15). > > > > > > > > > > > > > > > > > > Section 3.3, first paragraph - Suggested edit by reviewer > > > > > > > > > > > > (was) > > > > > > A TSVCIS RTP packet consists of zero or more TSVCIS coder > frames > > > > > > (each consisting of MELPe and TSVCIS coder data) followed by > zero or > > > > > > one MELPe comfort noise frame. The presence of a comfort > noise frame > > > > > > can be determined by its rate code bits in its last octet. > > > > > > > > > > > > (now) > > > > > > A TSVCIS RTP packet payload consists of zero or more > consecutive > > > > > > TSVCIS coder frames (each consisting of MELPe 2400 and TSVCI= S > coder > > > > > > data), with the oldest frame first, followed by zero or one > MELPe > > > > > > comfort noise frame. The presence of a comfort noise frame > can be > > > > > > determined by its rate code bits in its last octet. > > > > > > > > > > > > > > > > > > Section 3.3, fourth paragraph - Clarification requested by > > > > > > reviewers > > > > > > > > > > > > (was) > > > > > > TSVCIS coder frames in a single RTP packet MAY be of > different coder > > > > > > bitrates. With the exception for the variable length TSVCIS > > > > > > parameter frames, the coder rate bits in the trailing byte > identify > > > > > > the contents and length as per Table 1. > > > > > > > > > > > > (now) > > > > > > TSVCIS coder frames in a single RTP packet MAY have varying > TSVCIS > > > > > > parameter octet counts. Its packed parameter octet count > (length) is > > > > > > indicated in the trailing byte(s). All MELPe frames in a > single RTP > > > > > > packet MUST be of the same coder bitrate. For all MELPe cod= er > > > > > > frames, the coder rate bits in the trailing byte identify th= e > > > > > > contents and length as per Table 1. > > > > > > > > > > > > > > > > > > Section 4.1 - Editor note removed > > > > > > > > > > > > > > > > > > Section 4.1 - Change controller is now > > > > > > > > > > > > (now) > > > > > > Change controller: IETF, contact > > > > > > > > > > > > > > > > > > Section 5, first paragraph - Suggested edits by reviewers > > > > > > > > > > > > (was) > > > > > > A primary application of TSVCIS is for radio communications > of voice > > > > > > conversations, and discontinuous transmissions are normal. > When > > > > > > TSVCIS is used in an IP network, TSVCIS RTP packet > transmissions may > > > > > > cease and resume frequently. RTP synchronization source > (SSRC) > > > > > > sequence number gaps indicate lost packets to be filled by > PLC, while > > > > > > abrupt loss of RTP packets indicates intended discontinuous > > > > > > transmissions. > > > > > > > > > > > > (now) > > > > > > A primary application of TSVCIS is for radio communications > of voice > > > > > > conversations, and discontinuous transmissions are normal. > When > > > > > > TSVCIS is used in an IP network, TSVCIS RTP packet > transmissions may > > > > > > cease and resume frequently. RTP synchronization source > (SSRC) > > > > > > sequence number gaps indicate lost packets to be filled by > Packet > > > > > > Loss Concealment (PLC), while abrupt loss of RTP packets > indicates > > > > > > intended discontinuous transmissions. Resumption of voice > > > > > > transmission SHOULD be indicated by the RTP marker bit (M) > set to 1. > > > > > > > > > > > > > > > > > > Section 10 - Added reference > > > > > > > > > > > > (added) > > > > > > [RFC8088] Westerlund, M., "How to Write an RTP Payload > Format", > > > > > > RFC 8088, DOI 10.17487/RFC8088, May 2017, > > > > > > . > > > > > > > > > > > > ---------------------------------------------------------------= - > > > > > > ---- > > > > > > ----------------------------- > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: Roni Even (A) > > > > > > Sent: Sunday, October 6, 2019 2:09 AM > > > > > > To: victor.demjanenko@vocal.com; 'Benjamin Kaduk' > > > > > > ; 'The IESG' > > > > > > Cc: draft-ietf-payload-tsvcis@ietf.org; 'Ali Begen' > > > > > > ; avtcore-chairs@ietf.org; > > > > > > avt@ietf.org; 'Dave Satterlee (Vocal)' > > > > > > > > > > > > Subject: RE: Benjamin Kaduk's Discuss on > > > > > > draft-ietf-payload-tsvcis-03: (with DISCUSS and COMMENT) > > > > > > > > > > > > Hi, > > > > > > About the reference to TSVCIS. > > > > > > The RTP payload is about how to encapsulate the payload in an > > > > > > RTP > > > > packet. The objective is to define how an RTP stack can insert the > > > > tsvcis frames and extract the tsvcis frames from the RTP packet. > > > > Typically it is not required to understand the payload structure in > > > > order to be able to perform the encapsulation. > > > > > > This is why the reference to the payload is Informational and w= e > > > > > > did not require to have it publically available. If there is a > > > > > > need to understand the payload itself for the encapsulating tha= n > > > > > > we need more information in the RTP payload specification and a > > > > > > publically available normative reference. I think this is not > > > > > > the case here > > > > > > > > > > > > Roni Even > > > > > > > > > > > > AVTCore co-chair (ex Payload) > > > > > > > > > > > > -----Original Message----- > > > > > > From: victor.demjanenko@vocal.com > > > > > > [mailto:victor.demjanenko@vocal.com] > > > > > > Sent: Saturday, October 05, 2019 12:18 AM > > > > > > To: 'Benjamin Kaduk'; 'The IESG' > > > > > > Cc: draft-ietf-payload-tsvcis@ietf.org; 'Ali Begen'; > > > > avtcore-chairs@ietf.org; avt@ietf.org; 'Victor Demjanenko, Ph.D.'; > > > > 'Dave Satterlee (Vocal)' > > > > > > Subject: RE: Benjamin Kaduk's Discuss on > > > > > > draft-ietf-payload-tsvcis-03: (with DISCUSS and COMMENT) > > > > > > > > > > > > Everyone, > > > > > > > > > > > > Thanks for the comments. I think I mis-understood the ambiguit= y > > > > > > with > > > > respect to to changing rates within a RTP packet. That was not > > > > plan. An RTP packet must have MELP speech frames of the same rate. > > > > What is possible is that the amount of augmented TSVCIS speech data > > > > may vary from one speech frame to the next. This allows for a > > > > dynamic VDR as suggested by the NRL paper. So an RTP packet may > > > > have varying TSVCIS data but must always have MELPe 2400 data. > > > > > > > > > > > > Again backwards parsing is necessary but the timestamp uniforml= y > > > > increments 22.5msec per combined MELP/TSVCIS speech frame. > > > > > > > > > > > > The NRL is a good public reference on the VDR aspects. The > > > > > > actual > > > > TSVCIS spec we had was FOUO so we could not replicate its detail. > > > > (I believe a later spec is public or at least partially public. I > > > > am trying to get this.) The opaque data is pretty obvious with the > TSVCIS spec in hand. > > > > > > > > > > > > We will address the issues/concerns raised next week. Other > > > > > > business > > > > had priority. > > > > > > > > > > > > Thank you and enjoy the weekend. > > > > > > > > > > > > Regards, > > > > > > > > > > > > Victor & Dave > > > > > > > > > > > > -----Original Message----- > > > > > > From: Benjamin Kaduk via Datatracker > > > > > > Sent: Wednesday, October 2, 2019 10:40 PM > > > > > > To: The IESG > > > > > > Cc: draft-ietf-payload-tsvcis@ietf.org; Ali Begen > > > > > > ; avtcore-chairs@ietf.org; > > > > > > ali.begen@networked.media; avt@ietf.org > > > > > > Subject: Benjamin Kaduk's Discuss on > draft-ietf-payload-tsvcis-03: > > > > > > (with DISCUSS and COMMENT) > > > > > > > > > > > > Benjamin Kaduk has entered the following ballot position for > > > > > > draft-ietf-payload-tsvcis-03: 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-payload-tsvcis/ > > > > > > > > > > > > > > > > > > > > > > > > ---------------------------------------------------------------= - > > > > > > ---- > > > > > > -- > > > > > > DISCUSS: > > > > > > ---------------------------------------------------------------= - > > > > > > ---- > > > > > > -- > > > > > > > > > > > > I support Magnus' point about the time-ordering of adjacent > > > > > > frames in a > > > > packet. > > > > > > > > > > > > Additionally, I am not sure that there's quite enough here to b= e > > > > interoperably implementable. Specifically, we seem to be lacking a > > > > description of how an encoder or decoder knows which TSVCIS > > > > parameters, and in what order, to byte-pack or unpack, > respectively. > > > > One might surmise that there is a canonical listing in [TSVCIS], bu= t > > > > this document does not say that, and furthermore [TSVCIS] is only > listed as an informative reference. > > > > (I couldn't get my hands on my copy, at least on short notice.) If > > > > we limited ourselves to treating the TSVCIS parameters as an > > > > entirely opaque blob (codec, convey these N octets to the peer with > > > > the appropriate one- or two-byte trailer for payload type > > > > identification and framing), that would be interoperably > > > > implementable, since the black-box bits are up to some other codec > to interpret. > > > > > > > > > > > > In a similar vein, we mention but do not completely specify the > > > > potential for using CODB as an end-to-end framing bit, in Section > > > > 3.1 (see Comment), which is not interoperably implementable without > further details. > > > > > > > > > > > > > > > > > > ---------------------------------------------------------------= - > > > > > > ---- > > > > > > -- > > > > > > COMMENT: > > > > > > ---------------------------------------------------------------= - > > > > > > ---- > > > > > > -- > > > > > > > > > > > > Where is [TSVCIS] available? > > > > > > > > > > > > Is [NRLVDR] the same as > > > > > > https://apps.dtic.mil/dtic/tr/fulltext/u2/a588068.pdf ? A URL > > > > > > in the > > > > references would be helpful. > > > > > > > > > > > > Is additional TSVCIS data only present after 2400bps MELPe and > > > > > > the first > > > > thing to get dropped under bandwidth pressure? The abstract and > > > > introduction imply this by calling out MELPe 2400 bps speech > > > > parameters explicitly, but Section 3 says that TSVCIS augments > > > > standard 600, 1200, and > > > > 2400 bps MELP frames. > > > > > > > > > > > > It's helpful that Section 3.3 gives some general guidance for > > > > > > decoding > > > > this payload type ("[t]he way to determine the number of > > > > TSVCIS/MELPe frames is to identify each frame type and length"), bu= t > > > > I think some generic considerations would be very helpful to the > > > > reader much earlier, along the lines of "MELPe and TSVCIS data > > > > payloads are decoded from the end, using the CODA and CODB (and, if > > > > necessary, CODC and others) bits to determine the type of payload. > > > > For MELPe payloads the type also indicates the payload length, > > > > whereas for TSVCIS data an additional length field is present, in > > > > one of two possible formats. A TSVCIS coder frame consists of a > > > > MELPe data payload followed by zero or one TSVCIS data payload; > > > > after the TSVCIS payload's presence/length is determined, then the > > > > preceding MELPe payload can be determined and decoded. Per Section > > > > 3.3, multiple TSVCIS frames can be present in a single RTP packet." > > > > This (or something like it) would also serve to clarify the role of > the COD* bits, which is otherwise only implicitly introduced. > > > > > > > > > > > > Section 1.1 > > > > > > > > > > > > RFC 2736 is BCP 36 (but it's updated by RFC 8088 which is for > > > > > > some > > > > reason an Informational document and not part of BCP 36?!). > > > > > > > > > > > > Section 2 > > > > > > > > > > > > In addition to the augmented speech data, the TSVCIS > specification > > > > > > identifies which speech coder and framing bits are to be > encrypted, > > > > > > and how they are protected by forward error correction (FEC) > > > > > > techniques (using block codes). At the RTP transport layer, > only the > > > > > > speech coder related bits need to be considered and are > conveyed in > > > > > > unencrypted form. In most IP-based network deployments, > > > > > > standard > > > > > > > > > > > > Am I reading this correctly that this text is just summarizing > > > > > > what's in > > > > the TSVCIS spec in terms of what needs to be in unencrypted form, s= o > > > > the "only the speech coder related bits[...]" is not new informatio= n > > > > from this document? I'm not sure I agree with the conclusion, > > > > regardless -- won't the > > > > (MELPe) speech coder bits be enough to convey the semantic content > > > > of the audio stream, something that one might desire to keep > confidential? > > > > > > > > > > > > link encryption methods (SRTP, VPNs, FIPS 140 link encryptor= s > or Type > > > > > > 1 Ethernet encryptors) would be used to secure the RTP speec= h > > > > > > contents. Further, it is desirable to support the highest > voice > > > > > > quality between endpoints which is only possible without the > overhead > > > > > > of FEC. > > > > > > > > > > > > I think I'm missing a step in how this conclusion was reached. > > > > > > > > > > > > TSVCIS will be characterized. Depending on the bandwidth > available > > > > > > (and FEC requirements), a varying number of TSVCIS specific > speech > > > > > > coder parameters need to be transported. These are first > byte-packed > > > > > > and then conveyed from encoder to decoder. > > > > > > > > > > > > Per the Discuss point, how do I know which parameters need to b= e > > > > transported, and in what order? > > > > > > > > > > > > Byte packing of TSVCIS speech data into packed parameters is > > > > > > processed as per the following example: > > > > > > > > > > > > Three-bit field: bits A, B, and C (A is MSB, C is LSB) > > > > > > Five-bit field: bits D, E, F, G, and H (D is MSB, H is > > > > > > LSB) > > > > > > > > > > > > MSB LSB > > > > > > 0 1 2 3 4 5 6 7 > > > > > > +------+------+------+------+------+------+------+-----= -+ > > > > > > | H | G | F | E | D | C | B | A = | > > > > > > > > > > > > +------+------+------+------+------+------+------+------+ > > > > > > > > > > > > This packing method places the three-bit field "first" in th= e > lowest > > > > > > bits followed by the next five-bit field. Parameters may be > split > > > > > > between octets with the most significant bits in the earlier > octet. > > > > > > Any unfilled bits in the last octet MUST be filled with zero= . > > > > > > > > > > > > I agree with Adam that this is very unclear. A is the MSB of > > > > > > the > > > > three-bit field but the LSB of the octet overall? > > > > > > We probably need an example of splitting a parameter across > > > > > > octets as > > > > well, to get the bit ordering right. > > > > > > > > > > > > Section 3.1 > > > > > > > > > > > > It should be noted that CODB for both the 2400 and 600 bps > modes MAY > > > > > > deviate from the values in Table 1 when bit 55 is used as an > end-to- > > > > > > end framing bit. Frame decoding would remain distinct as > > > > > > CODA being > > > > > > > > > > > > Where is the use of CODB as an end-to-end framing bit defined? > > > > > > If we're > > > > going to provide neither a complete description of how to do it nor > > > > a reference to a better description, we probably shouldn't mention > it at all. > > > > > > > > > > > > Section 3.2 > > > > > > > > > > > > RTP packet. The packed parameters are counted in octets > (TC). In > > > > > > the preferred placement, shown in Figure 6, a single trailin= g > octet > > > > > > SHALL be appended to include a two-bit rate code, CODA and > > > > > > CODB, > > > > > > > > > > > > I'd consider saying something about this being the preferred > > > > > > format > > > > > > ("placement") due to its shorter length than the alternative, > > > > > > and say > > > > that it "SHOULD be used for TSVCIS payloads with TC less than or > > > > equal to 77 octetes". > > > > > > > > > > > > Section 3.3 > > > > > > > > > > > > When a longer packetization interval is used, is that indicated > > > > > > by > > > > signaling or RTP timestamps or otherwise? > > > > > > > > > > > > TSVCIS coder frames in a single RTP packet MAY be of > different coder > > > > > > bitrates. With the exception for the variable length TSVCIS > > > > > > parameter frames, the coder rate bits in the trailing byte > identify > > > > > > the contents and length as per Table 1. > > > > > > > > > > > > Maybe also note that the penultimate octet gives the length > there? > > > > > > > > > > > > Information describing the number of frames contained in an > RTP > > > > > > packet is not transmitted as part of the RTP payload. The > way to > > > > > > determine the number of TSVCIS/MELPe frames is to identify > each frame > > > > > > type and length thereby counting the total number of octets > within > > > > > > the RTP packet. > > > > > > > > > > > > terminology nit: if a frame is the combination of MELPe and > > > > > > TSVCIS > > > > payload data units then there are two layres of decoding to get a > > > > length for the frame, since we have to get the TSVCIS length and > then the MELPe length. > > > > > > > > > > > > Section 4.2 > > > > > > > > > > > > Parameter "ptime" cannot be used for the purpose of > > > > > > specifying the > > > > > > > > > > > > nit: missing article ("The parameter") > > > > > > > > > > > > will be impossible to distinguish which mode is about to be > used > > > > > > (e.g., when ptime=3D68, it would be impossible to distinguis= h > if the > > > > > > packet is carrying one frame of 67.5 ms or three frames of > 22.5 ms). > > > > > > > > > > > > So how is the operating mode determined, then? > > > > > > (I think this is the same question I asked above) > > > > > > > > > > > > Section 4.4 > > > > > > > > > > > > For example, if offerer bitrates are "2400,600" and answer > bitrates > > > > > > are "600,2400", the initial bitrate is 600. If other > bitrates are > > > > > > provided by the answerer, any common bitrate between the > offer and > > > > > > answer MAY be used at any time in the future. Activation of > these > > > > > > other common bitrates is beyond the scope of this document. > > > > > > > > > > > > It seems important to specify whether this requires a new O/A > > > > > > exchange > > > > or can be done "spontaneously" by just encoding different frame > types. > > > > > > (It seems like the latter is possible, on first glance, and thi= s > > > > > > is implied by Section 3.3's discussion of mixing them in a > > > > > > single > > > > > > packet.) > > > > > > > > > > > > Section 5 > > > > > > > > > > > > Please expand PLC at first use (not second). > > > > > > > > > > > > Section 6 > > > > > > > > > > > > I don't understand the PLC usage. Is the idea that a receiver, > > > > > > on > > > > seeing an SSRC gap, constructs fictitious PLC frames to "fill the > gap" > > > > > > and passes the resulting stream to the decoder? > > > > > > > > > > > > Section 8 > > > > > > > > > > > > and important considerations in [RFC7201]. Applications > SHOULD use > > > > > > one or more appropriate strong security mechanisms. The res= t > of this > > > > > > section discusses the security-impacting properties of the > payload > > > > > > format itself. > > > > > > > > > > > > I thought we described TSVCIS itself (much earlier in the > > > > > > document) as > > > > requiring encryption for some data; wouldn't that translate to a > "MUST" > > > > > > here and not a "SHOULD"? > > > > > > > > > > > > > > > > > > > > > > > > > > --000000000000a85af0059f4bb74a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi, Victor... your turn now...

Barry

On Fri, Feb 14, 2020 at 11:= 43 AM Benjamin Kaduk <kaduk@mit.edu= > wrote:
Hi Barry,

As Victor notes, this one was/is waiting on me; he did reply (offlist) on 15 January but I seem to have missed it amid a deluge of other mail that arrived at that time.=C2=A0 Thanks for the reminder, and thanks Victor for<= br> re-sending the comments.
(inline)

On Fri, Feb 14, 2020 at 08:20:54AM -0500, victor.demjanenko@vocal.com wrote:
> HI Barry,
>
> Thanks for recalling this was still outstanding.=C2=A0 I had emailed B= en just after the holidays and did not realize we had no response.=C2=A0 Th= e below is what we suggested to Ben to address concerns he raised.
>
> --------------------
> Hi Ben,
>
> Hope your holidays were good.=C2=A0 Our were both good and busy.=C2=A0= Deliveries for two NASA projects and the holidays kept us from responding = sooner.=C2=A0 But we do want to get this draft completed.
>
> With your permission, I=E2=80=99d like to address your comments direct= ly, resolve what changes we should make and then publish a new version with= a summary of our out-of-band discussions.=C2=A0 We don=E2=80=99t have a lo= t of experience with drafting such documents and would like to know exactly= what is needed to make this draft acceptable.
>
> I believe there are two comments/issues to address:
>
> 1)=C2=A0 =C2=A0 CODA, CODB
>
> Your comment ends by stating:=C2=A0 =E2=80=9C(Or, of course, the use o= f CODB as an alternating 1/0 bit as the framing usage could be documented i= nstead.)=E2=80=9D=C2=A0 We can do this as follows:
>
> (original)
> It should be noted that CODB for MELPe 600 bps mode MAY deviate from >=C2=A0 =C2=A0 the value in Table 1 when bit 55 is used as an end-to-end= framing
>=C2=A0 =C2=A0 bit. Frame decoding would remain distinct as CODA being z= ero on its
>=C2=A0 =C2=A0 own would indicate a 7-byte frame for either 2400 or 600 = bps rate and
>=C2=A0 =C2=A0 the use of 600 bps speech coding could be deduced from th= e RTP
>=C2=A0 =C2=A0 timestamp (and anticipated by the SDP negotiations).
>
> (adding =E2=80=9Calternating 1/0=E2=80=9D)
> It should be noted that CODB for MELPe 600 bps mode MAY deviate from >=C2=A0 =C2=A0 the value in Table 1 when bit 55 is used as an alternatin= g 1/0 end-to-end framing
>=C2=A0 =C2=A0 bit. Frame decoding would remain distinct as CODA being z= ero on its
>=C2=A0 =C2=A0 own would indicate a 7-byte frame for either 2400 or 600 = bps rate and
>=C2=A0 =C2=A0 the use of 600 bps speech coding could be deduced from th= e RTP
>=C2=A0 =C2=A0 timestamp (and anticipated by the SDP negotiations).
>
> I think this change would be sufficient to address your concern about = what to expect for CODB.

This looks like the minimal sufficient change, yes.=C2=A0 (I use "mini= mal"
because I would say more if I was writing it, but I don't think I can insist that you write it the way I would -- it's your document after al= l!)

> 2.=C2=A0 =C2=A0 Packing and unpacking
>
> You are correct that I am trying to vaguely describe a middle layer sh= im that is neither RTP nor speech coder.=C2=A0 So it definitely does need t= o be clear.=C2=A0 The vagueness comes from the speech coder description bei= ng a FOUO document.=C2=A0 Its now unclassified so I can potentially say mor= e (and I did make some enhancements of the parameter description already).= =C2=A0
>
> So I am trying to understand exactly what you think is vague in our cu= rrent description:
>
> TSVCIS augmented speech data is derived from the signal processing
>=C2=A0 =C2=A0 and data already performed by the MELPe speech coder.=C2= =A0 For the
>=C2=A0 =C2=A0 purposes of this specification, only the general paramete= r nature of
>=C2=A0 =C2=A0 TSVCIS will be characterized.=C2=A0 Depending on the band= width available
>=C2=A0 =C2=A0 (and FEC requirements), a varying number of TSVCIS-specif= ic speech
>=C2=A0 =C2=A0 coder parameters need to be transported.=C2=A0 These are = first byte-packed
>=C2=A0 =C2=A0 and then conveyed from encoder to decoder.
>
>=C2=A0 =C2=A0 Byte packing of TSVCIS speech data into packed parameters= is
>=C2=A0 =C2=A0 processed as per the following example:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Three-bit field: bits A, B, and C (A is MSB,= C is LSB)
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Five-bit field: bits D, E, F, G, and H (D is= MSB, H is LSB)
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 MSB=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 LSB
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A00=C2=A0 =C2=A0 =C2=A0 1= =C2=A0 =C2=A0 =C2=A0 2=C2=A0 =C2=A0 =C2=A0 3=C2=A0 =C2=A0 =C2=A0 4=C2=A0 = =C2=A0 =C2=A0 5=C2=A0 =C2=A0 =C2=A0 6=C2=A0 =C2=A0 =C2=A0 7
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+------+------+------+------+------+-= -----+------+------+
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0H=C2=A0 |=C2=A0 =C2=A0G= =C2=A0 |=C2=A0 =C2=A0F=C2=A0 |=C2=A0 =C2=A0E=C2=A0 |=C2=A0 =C2=A0D=C2=A0 |= =C2=A0 =C2=A0C=C2=A0 |=C2=A0 =C2=A0B=C2=A0 |=C2=A0 =C2=A0A=C2=A0 |
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+------+------+------+------+------+-= -----+------+------+
>
>=C2=A0 =C2=A0 This packing method places the three-bit field "firs= t" in the lowest
>=C2=A0 =C2=A0 bits followed by the next five-bit field.=C2=A0 Parameter= s may be split
>=C2=A0 =C2=A0 between octets with the most significant bits in the earl= ier octet.
>=C2=A0 =C2=A0 Any unfilled bits in the last octet MUST be filled with z= ero.

[not actually relevant to the Discuss part, but if there is always exactly<= br> one 3-bit parameter and one 5-bit parameter, then this text allowing
splitting across octets will never be used and is potentially confusing to<= br> mention.]

>=C2=A0 =C2=A0 In order to accommodate a varying amount of TSVCIS augmen= ted speech
>=C2=A0 =C2=A0 data, it is only necessary to specify the number of octet= s containing
>=C2=A0 =C2=A0 the packed TSVCIS parameters.=C2=A0 The encoding to do so= is presented in

I think the "only necessary to specify the number of octets" is t= he key
stumbling point, for me -- I need to know the number of octets as well as the order of the parameters within the list, which is more information than=
just the number of octets.

>=C2=A0 =C2=A0 Section 3.2.=C2=A0 TSVCIS specifically uses the NRL VDR i= n two
>=C2=A0 =C2=A0 configurations using 15 and 35 packed octet parameters [T= SVCIS].=C2=A0

I think I failed to internalize the "two configurations using 15 and 3= 5
packed octet parameters" the first time I read the document, as this d= oes
help give the reader a clue that [TSVCIS] gives a good picture of what
parameters go where.=C2=A0 So it seems like we could easily append to that,= for
"using a fixed set of 15 and 35 packed octet parameters in a fixed ord= er
[TSVCIS]" and that would resolve my concerns.

> The speech coder description of the parameters is the following:
>
>=C2=A0
>
> So the three bit pitch is first (bits 56 to 58), followed by a five bi= t amplitude (bits 59 to 63) and then an array of spectral components, each = 8-bit wide (starting at bit 64).

[And maybe TSVCIS specifes that the spectral components are derived from some fundamental harmonic decomposition that naturally quantizes to a
number-of-parameters/accuracy tradeoff with a natural order.=C2=A0 If so, w= e
could also rely on that instead of my proposed change above; let me know if=
you want to explore that path further.]

> Based on this information, I=E2=80=99m not sure what we should add to = our draft to make the description of packing/unpacking clearer.=C2=A0 Can y= ou make any suggestions or does this table help you with what you did not k= now?=C2=A0 (I don=E2=80=99t think I should put this table into the draft RF= C however.)

Hopefully the above helps to clarify.

Thanks, and sorry for the delay.

-Ben

> Thanks for your attention and comments.
>
> Victor & Dave
>
>
>
> -----Original Message-----
> From: Barry Leiba <barryleiba@computer.org>
> Sent: Friday, February 14, 2020 7:38 AM
> To: Benjamin Kaduk <kaduk@mit.edu>
> Cc: v= ictor.demjanenko@vocal.com; Roni Even (A) <roni.even@huawei.com>; The IESG <= ;iesg@ietf.org>; = Catherine Meadows <catherine.meadows@nrl.navy.mil>; IETF SecDir <secdir@ietf.org>; <= a href=3D"mailto:draft-ietf-payload-tsvcis@ietf.org" target=3D"_blank">draf= t-ietf-payload-tsvcis@ietf.org; Ali Begen <ali.begen@networked.media= >; avtcore-= chairs@ietf.org; avt@= ietf.org; Dave Satterlee (Vocal) <Dave.Satterlee@vocal.com>; IETF discussi= on list <ietf@ietf.or= g>; draft-ietf-payload-tsvcis.all@ietf.org
> Subject: Re: Benjamin Kaduk's Discuss on draft-ietf-payload-tsvcis= -03: (with DISCUSS and COMMENT)
>
> This is still outstanding, since November.=C2=A0 Victor, where are we = on this one?
>
> Barry
>
> On Mon, Nov 25, 2019 at 1:46 AM Benjamin Kaduk <kaduk@mit.edu> wrote:
> >
> > Hi Victor,
> >
> > On Tue, Nov 19, 2019 at 03:14:21PM -0500, victor.demjanenko@vocal.com w= rote:
> > > Hi Ben,
> > >
> > > Sorry I overlooked sending you a response.=C2=A0 I would lik= e to address
> > > the two concerns you have by explaining what the speech code= rs are doing.
> >
> > Thanks for the extra clarifications.=C2=A0 To supply one of my ow= n: I'm not
> > concerned that the protocol doesn't work as implemented, but = just want
> > to make sure that the document includes enough information to adm= it
> > new implementations without guesswork.=C2=A0 That is to say, &quo= t;either tell
> > me how to do it or tell me where to look that tells me how to do = it".
> >
> > > WRT to 600 bps MELP, there is one TSVCIS mode that uses one = bit
> > > beyond the 54-bit frame for MELP 600 as a frame sync which a= lternates between frames.
> > > With two or more MELP 600bps frames in one RTP packet, if an= y frame
> > > indicates 600 bps by CODA being 0 and CODB being 1, then we = know the
> > > stream is 600bps.=C2=A0 If there is a single frame in an RTP= packet, you
> > > can still deduce this by looking at every other RTP packet (= every
> > > other MELP 600bps
> > > frame) and by the timestamp advance.=C2=A0 Most likely the t= wo ends would
> > > negotiate 600 bps in SDP anyways so there really should not = be a
> > > problem.=C2=A0 I know it's not pretty but its workable.= =C2=A0 I hope this
> > > explanation helps you with the concerns for this issue.
> >
> > In this case, the use as an "end-to-end framing bit" (i= .e., the
> > alternating behavior you describe above) is not explicitly stated= ; one
> > might imagine a scheme where the framing usage is to have the bit=
> > cycle through 1, 1, 0, and 0, or some other scheme.=C2=A0 I'd= suggest to
> > note in the document that if any instance of (CODA, CODB) =3D=3D = (0, 1) is
> > observed, then the 600bps mode is in use.=C2=A0 It might also be = helpful to
> > include the observation that two successive MELPe payloads with C= ODA
> > =3D=3D CODB =3D=3D 0 indicates the 2400bps mode (and that seeing = them in a
> > single RTP packet is decisive, whereas additional information abo= ut
> > packet non-loss would be needed in the one-MELPe-frame-per-RTP-pa= cket
> > case), but that would be a fair bit of additional text and might = be
> > diminishing returns.=C2=A0 (Or, of course, the use of CODB as an =
> > alternating 1/0 bit as the framing usage could be documented
> > instead.)
> >
> > > As for the TSVCIS parameter packing/unpacking, this is reall= y
> > > simple.=C2=A0 There is exactly on three bit parameter, exact= ly one five
> > > bit parameter and a variable number of eight bit parameters.= =C2=A0 In our
> > > view, the speech coder itself (or a wrapper for it) is respo= nsible
> > > for preparing the block of octets.=C2=A0 RTP then just trans= ports it.=C2=A0 On
> > > receive, the complementary wrapper reverses the packing oper= ation.=C2=A0
> > > I hope this clarifies and explains the simplicity.
> >
> > That's exactly what I expected to happen; however, it's n= ot what I
> > believe the current text of the document is describing.=C2=A0 Spe= cifically,
> > I think that the current text implies that the "preparing th= e block of
> > octets" and "complementary wrapper reverses the packing= operation" are
> > supposed to be part of the RTP payload format that this document =
> > describes, but this document does not have enough information to =
> > actually perform those operations reversibly.=C2=A0 If the packin= g is to be
> > done in the speech coder, then this document doesn't need to = talk
> > about the packing at all (e.g., at the end of Section 2); if we n= eed
> > to keep the packing/wrapper in this document then we need to indi= cate
> > that there's a defined priority order for the (8-octet) TSVCI= S
> > parameters in the TSVCIS references, to allow the packing/unpacki= ng to be deterministic.
> >
> > Thanks,
> >
> > Ben
> >
> > >
> > > -----Original Message-----
> > > From: Benjamin Kaduk <kaduk@mit.edu>
> > > Sent: Thursday, October 31, 2019 8:12 PM
> > > To: Barry Leiba <barryleiba@computer.org>
> > > Cc: victor.demjanenko@vocal.com; Roni Even (A)
> > > <roni.even@huawei.com>; The IESG <iesg@ietf.org>; Catherine Meadows
> > > <catherine.meadows@nrl.navy.mil>; IETF SecDir <secdir@ietf.org>;
> > > draft-ietf-payload-tsvcis@ietf.org; Ali Begen
> > > <ali.begen@networked.media>; avtcore-chairs@ietf.org; avt@ietf.org;
> > > Dave Satterlee (Vocal) <Dave.Satterlee@vocal.com>; IETF discuss= ion
> > > list <= ietf@ietf.org>; draft-ietf-payload-tsvcis.all@ietf.org
> > > Subject: Re: Benjamin Kaduk's Discuss on
> > > draft-ietf-payload-tsvcis-03: (with DISCUSS and COMMENT)
> > >
> > > I don't think so, unfortunately.
> > >
> > > I do see the clarification about CODB's potential for de= viation from
> > > Table 1, that only the 600 bps MELPe is allowed to deviate, = and that
> > > CODA gets us to "it's one of 2400 or 600 bps" = and the RTP timestamp
> > > disambiguates that
> > > 600 bps is in use.=C2=A0 But, it seems that this means that = the recipient
> > > in general should not rely on CODB to differentiate 600 from= 2400
> > > bps, and instead is more robustly implemented by *always* us= ing the
> > > RTP timestamp to detect 600 bps, since that will always work= and
> > > CODB will sometimes not work under conditions not fully spec= ified
> > > here.=C2=A0 So, if we are unwilling or unable to clarify wha= t those
> > > conditions are (e.g., whether at a minimum mutual agreement = is
> > > required), then I think we need to describe this procedure o= f
> > > consulting the RTP timestamp as the default behavior and avo= id giving the impression that CODB should be used to do so.
> > >
> > > Additionally, I don't see anything to address my concern= about
> > > TSVCIS parameter decoding.=C2=A0 To be clear, the procedure = I see this
> > > document describing is that:
> > > - TSVCIS gives parameters (and their lengths in bits) to the= codec
> > >=C2=A0 =C2=A0described in this document
> > > - this document specifies how to densely encode those parame= ters into a
> > >=C2=A0 =C2=A0byetstream
> > > - RTP transmits that encoded bytestream to the peer
> > > - the codec specified by this is responsible for turning tha= t encoded
> > >=C2=A0 =C2=A0bystream back into a list of TSVCIS parameters (= and their length
> > > in bits)
> > >
> > > I don't see how that last step is attainable with only t= he
> > > information provided by this document.=C2=A0 I *assume* that= one of the
> > > TSVCIS specifications has a canonical (ordered) listing of <= br> > > > parameters, and that the list of parmeters given to this cod= ec in
> > > the first step will always be an initial prefix of that list= , but
> > > that's just me guessing at how to make sense of the stat= ed procedure
> > > given insufficient information.=C2=A0 I don't think it&#= 39;s appropriate to
> > > make the reader of an RFC guess at what to do; we need to ei= ther say
> > > how to do it or give a pointer to an external reference that= does.
> > >
> > > -Ben
> > >
> > > On Tue, Oct 29, 2019 at 02:26:09PM -0400, Barry Leiba wrote:=
> > > > Ben, does the -04 version address everything?
> > > >
> > > > Barry
> > > >
> > > > On Thu, Oct 24, 2019 at 1:42 PM <victor.demjanenko@vocal.com> wrote:
> > > > >
> > > > > I forgot to address security comments in one email= .=C2=A0 The changes are:
> > > > >
> > > > > Section 8, second paragraph - Suggested edit by re= viewer
> > > > >
> > > > > (was)
> > > > >=C2=A0 =C2=A0 This RTP payload format and the TSVCI= S decoder do not exhibit any
> > > > >=C2=A0 =C2=A0 significant non-uniformity in the rec= eiver-side computational
> > > > >=C2=A0 =C2=A0 complexity for packet processing and = thus are unlikely to pose a
> > > > >=C2=A0 =C2=A0 denial-of-service threat due to the r= eceipt of pathological data.
> > > > >=C2=A0 =C2=A0 Additionally, the RTP payload format = does not contain any active
> > > > >=C2=A0 =C2=A0 content.
> > > > >
> > > > > (now)
> > > > >=C2=A0 =C2=A0 This RTP payload format and the TSVCI= S decoder, to the best of our
> > > > >=C2=A0 =C2=A0 knowledge, do not exhibit any signifi= cant non-uniformity in the
> > > > >=C2=A0 =C2=A0 receiver-side computational complexit= y for packet processing and thus
> > > > >=C2=A0 =C2=A0 are unlikely to pose a denial-of-serv= ice threat due to the receipt of
> > > > >=C2=A0 =C2=A0 pathological data. Additionally, the = RTP payload format does not
> > > > >=C2=A0 =C2=A0 contain any active content.
> > > > >
> > > > >
> > > > > Section 8, third paragraph - Suggested edit by rev= iewer
> > > > >
> > > > > (was)
> > > > >=C2=A0 =C2=A0 Please see the security consideration= s discussed in [RFC6562]
> > > > >=C2=A0 =C2=A0 regarding VAD and its effect on bitra= tes.
> > > > >
> > > > > (now)
> > > > >=C2=A0 =C2=A0 Please see the security consideration= s discussed in [RFC6562]
> > > > >=C2=A0 =C2=A0 regarding Voice Activity Detect (VAD)= and its effect on bitrates.
> > > > >
> > > > > Victor
> > > > >
> > > > > -----Original Message-----
> > > > > From: victor.demjanenko@vocal.com <victor.demjanenko@vocal.com<= /a>>
> > > > > Sent: Thursday, October 24, 2019 10:05 AM
> > > > > To: 'Roni Even (A)' <roni.even@huawei.com>; '= Benjamin Kaduk'
> > > > > <kaduk@mit.edu>; 'The IESG' <iesg@ietf.org>
> > > > > Cc: draft-ietf-payload-tsvcis@ietf.org; 'Ali = Begen'
> > > > > <ali.begen@networked.media>; avtcore-chairs@ietf.org; =
> > > > > = avt@ietf.org; 'Dave Satterlee (Vocal)'
> > > > > <Dave.Satterlee@vocal.com>
> > > > > Subject: RE: Benjamin Kaduk's Discuss on
> > > > > draft-ietf-payload-tsvcis-03: (with DISCUSS and CO= MMENT)
> > > > >
> > > > > Hi Everyone,
> > > > >
> > > > > First we want to thank everyone for their review a= nd comments
> > > > > for this
> > > draft RFC.=C2=A0 We believe we reviewed all the comments and= suggestions
> > > and incorporated them adequately in the next draft (04).=C2= =A0 We'd like
> > > to send out this list of exact changes in case anyone has ad= ditional
> > > comments or thinks the clarifications are inadequate.=C2=A0 = We would be
> > > most happy to address concerns before publishing draft 04 to= morrow.
> > > > >
> > > > > With so many emails from a half dozen or more revi= ewers, we
> > > > > apologize
> > > that we cannot address each sender individually.=C2=A0 We ho= pe this
> > > detail is sufficient for everyone.
> > > > >
> > > > > Again, many thanks to all.
> > > > >
> > > > > Victor & Dave
> > > > >
> > > > > --------------------------------------------------= --------------
> > > > > ----
> > > > > --------------------------
> > > > >
> > > > > Section 1.1 - Suggested reference to RFC 8088 adde= d.
> > > > >
> > > > > (was)
> > > > >=C2=A0 =C2=A0 Best current practices for writing an= RTP payload format
> > > > >=C2=A0 =C2=A0 specification were followed [RFC2736]= .
> > > > >
> > > > > (now)
> > > > >=C2=A0 =C2=A0 Best current practices for writing an= RTP payload format
> > > > >=C2=A0 =C2=A0 specification were followed [RFC2736]= [RFC8088].
> > > > >
> > > > >
> > > > > Section 2, paragraphs 3 and 4 - Suggested edits by= reviewers
> > > > >
> > > > > (was)
> > > > >=C2=A0 =C2=A0 In addition to the augmented speech d= ata, the TSVCIS specification
> > > > >=C2=A0 =C2=A0 identifies which speech coder and fra= ming bits are to be encrypted,
> > > > >=C2=A0 =C2=A0 and how they are protected by forward= error correction (FEC)
> > > > >=C2=A0 =C2=A0 techniques (using block codes).=C2=A0= At the RTP transport layer, only the
> > > > >=C2=A0 =C2=A0 speech coder related bits need to be = considered and are conveyed in
> > > > >=C2=A0 =C2=A0 unencrypted form.=C2=A0 In most IP-ba= sed network deployments, standard
> > > > >=C2=A0 =C2=A0 link encryption methods (SRTP, VPNs, = FIPS 140 link encryptors or Type
> > > > >=C2=A0 =C2=A0 1 Ethernet encryptors) would be used = to secure the RTP speech
> > > > >=C2=A0 =C2=A0 contents.=C2=A0 Further, it is desira= ble to support the highest voice
> > > > >=C2=A0 =C2=A0 quality between endpoints which is on= ly possible without the overhead
> > > > >=C2=A0 =C2=A0 of FEC.
> > > > >
> > > > >=C2=A0 =C2=A0 TSVCIS augmented speech data is deriv= ed from the signal processing
> > > > >=C2=A0 =C2=A0 and data already performed by the MEL= Pe speech coder.=C2=A0 For the
> > > > >=C2=A0 =C2=A0 purposes of this specification, only = the general parameter nature of
> > > > >=C2=A0 =C2=A0 TSVCIS will be characterized.=C2=A0 D= epending on the bandwidth available
> > > > >=C2=A0 =C2=A0 (and FEC requirements), a varying num= ber of TSVCIS specific speech
> > > > >=C2=A0 =C2=A0 coder parameters need to be transport= ed.=C2=A0 These are first byte-packed
> > > > >=C2=A0 =C2=A0 and then conveyed from encoder to dec= oder.
> > > > >
> > > > > (now)
> > > > >=C2=A0 =C2=A0 In addition to the augmented speech d= ata, the TSVCIS specification
> > > > >=C2=A0 =C2=A0 identifies which speech coder and fra= ming bits are to be encrypted,
> > > > >=C2=A0 =C2=A0 and how they are protected by forward= error correction (FEC)
> > > > >=C2=A0 =C2=A0 techniques (using block codes).=C2=A0= At the RTP transport layer, only the
> > > > >=C2=A0 =C2=A0 speech-coder-related bits need to be = considered and are conveyed in
> > > > >=C2=A0 =C2=A0 unencrypted form.=C2=A0 In most IP-ba= sed network deployments, standard
> > > > >=C2=A0 =C2=A0 link encryption methods (SRTP, VPNs, = FIPS 140 link encryptors or Type
> > > > >=C2=A0 =C2=A0 1 Ethernet encryptors) would be used = to secure the RTP speech
> > > > >=C2=A0 =C2=A0 contents.
> > > > >
> > > > >=C2=A0 =C2=A0 TSVCIS augmented speech data is deriv= ed from the signal processing
> > > > >=C2=A0 =C2=A0 and data already performed by the MEL= Pe speech coder.=C2=A0 For the
> > > > >=C2=A0 =C2=A0 purposes of this specification, only = the general parameter nature of
> > > > >=C2=A0 =C2=A0 TSVCIS will be characterized.=C2=A0 D= epending on the bandwidth available
> > > > >=C2=A0 =C2=A0 (and FEC requirements), a varying num= ber of TSVCIS-specific speech
> > > > >=C2=A0 =C2=A0 coder parameters need to be transport= ed.=C2=A0 These are first byte-packed
> > > > >=C2=A0 =C2=A0 and then conveyed from encoder to dec= oder.
> > > > >
> > > > >
> > > > > Section 3, last sentence paragraph 3 - Suggested e= dit by
> > > > > reviewer
> > > > >
> > > > > (was)
> > > > >=C2=A0 =C2=A0 When more than one codec data frame i= s
> > > > >=C2=A0 =C2=A0 present in a single RTP packet, the t= imestamp is, as always, that of
> > > > >=C2=A0 =C2=A0 the oldest data frame represented in = the RTP packet.
> > > > >
> > > > > (now)
> > > > >=C2=A0 =C2=A0 When more than one codec data frame i= s
> > > > >=C2=A0 =C2=A0 present in a single RTP packet, the t= imestamp specified is that of
> > > > >=C2=A0 =C2=A0 the oldest data frame represented in = the RTP packet.
> > > > >
> > > > >
> > > > > Section 3.1, last paragraph - Clarified permission= for MELP 600
> > > > > end-to-end framing bit
> > > > >
> > > > > (was)
> > > > >=C2=A0 =C2=A0 It should be noted that CODB for both= the 2400 and 600 bps modes MAY
> > > > >=C2=A0 =C2=A0 deviate from the values in Table 1 wh= en bit 55 is used as an end-to-
> > > > >=C2=A0 =C2=A0 end framing bit.=C2=A0 Frame decoding= would remain distinct as CODA being
> > > > >=C2=A0 =C2=A0 zero on its own would indicate a 7-by= te frame for either rate and the
> > > > >=C2=A0 =C2=A0 use of 600 bps speech coding could be= deduced from the RTP timestamp
> > > > >=C2=A0 =C2=A0 (and anticipated by the SDP negotiati= ons).
> > > > >
> > > > > (now)
> > > > >=C2=A0 =C2=A0 It should be noted that CODB for MELP= e 600 bps mode MAY deviate from
> > > > >=C2=A0 =C2=A0 the value in Table 1 when bit 55 is u= sed as an end-to-end framing
> > > > >=C2=A0 =C2=A0 bit. Frame decoding would remain dist= inct as CODA being zero on its
> > > > >=C2=A0 =C2=A0 own would indicate a 7-byte frame for= either 2400 or 600 bps rate and
> > > > >=C2=A0 =C2=A0 the use of 600 bps speech coding coul= d be deduced from the RTP
> > > > >=C2=A0 =C2=A0 timestamp (and anticipated by the SDP= negotiations).
> > > > >
> > > > >
> > > > > Section 3.2, first paragraph - Clarifications requ= ested by
> > > > > reviewers
> > > > >
> > > > > (was)
> > > > >=C2=A0 =C2=A0 The TSVCIS augmented speech data as p= acked parameters MUST be placed
> > > > >=C2=A0 =C2=A0 immediately after a corresponding MEL= Pe 2400 bps payload in the same
> > > > >=C2=A0 =C2=A0 RTP packet.=C2=A0 The packed paramete= rs are counted in octets (TC).=C2=A0 In
> > > > >=C2=A0 =C2=A0 the preferred placement, shown in Fig= ure 6, a single trailing octet
> > > > >=C2=A0 =C2=A0 SHALL be appended to include a two-bi= t rate code, CODA and CODB,
> > > > >=C2=A0 =C2=A0 (both bits set to one) and a six-bit = modified count (MTC).=C2=A0 The
> > > > >=C2=A0 =C2=A0 special modified count value of all o= nes (representing a MTC value of
> > > > >=C2=A0 =C2=A0 63) SHALL NOT be used for this format= as it is used as the indicator
> > > > >=C2=A0 =C2=A0 for the alternate packing format show= n next.=C2=A0 In a standard
> > > > >=C2=A0 =C2=A0 implementation, the TSVCIS speech cod= er uses a minimum of 15 octets
> > > > >=C2=A0 =C2=A0 for parameters in octet packed form.= =C2=A0 The modified count (MTC) MUST
> > > > >=C2=A0 =C2=A0 be reduced by 15 from the full octet = count (TC).=C2=A0 Computed MTC =3D TC-
> > > > >=C2=A0 =C2=A0 15.=C2=A0 This accommodates a maximum= of 77 parameter octets (maximum
> > > > >=C2=A0 =C2=A0 value of MTC is 62, 77 is the sum of = 62+15).
> > > > >
> > > > > (now)
> > > > >=C2=A0 =C2=A0 The TSVCIS augmented speech data as p= acked parameters MUST be placed
> > > > >=C2=A0 =C2=A0 immediately after a corresponding MEL= Pe 2400 bps payload in the same
> > > > >=C2=A0 =C2=A0 RTP packet.=C2=A0 The packed paramete= rs are counted in octets (TC).=C2=A0 The
> > > > >=C2=A0 =C2=A0 preferred placement SHOULD be used fo= r TSVCIS payloads with TC less
> > > > >=C2=A0 =C2=A0 than or equal to 77 octets, is shown = in Figure 6.=C2=A0 In the preferred
> > > > >=C2=A0 =C2=A0 placement, a single trailing octet SH= ALL be appended to include a
> > > > >=C2=A0 =C2=A0 two-bit rate code, CODA and CODB, (bo= th bits set to one) and a six-
> > > > >=C2=A0 =C2=A0 bit modified count (MTC).=C2=A0 The s= pecial modified count value of all
> > > > >=C2=A0 =C2=A0 ones (representing a MTC value of 63)= SHALL NOT be used for this
> > > > >=C2=A0 =C2=A0 format as it is used as the indicator= for the alternate packing
> > > > >=C2=A0 =C2=A0 format shown next.=C2=A0 In a standar= d implementation, the TSVCIS speech
> > > > >=C2=A0 =C2=A0 coder uses a minimum of 15 octets for= parameters in octet packed
> > > > >=C2=A0 =C2=A0 form.=C2=A0 The modified count (MTC) = MUST be reduced by 15 from the full
> > > > >=C2=A0 =C2=A0 octet count (TC).=C2=A0 Computed MTC = =3D TC-15.=C2=A0 This accommodates a maximum
> > > > >=C2=A0 =C2=A0 of 77 parameter octets (maximum value= of MTC is 62, 77 is the sum of
> > > > >=C2=A0 =C2=A0 62+15).
> > > > >
> > > > >
> > > > > Section 3.3, first paragraph - Suggested edit by r= eviewer
> > > > >
> > > > > (was)
> > > > >=C2=A0 =C2=A0 A TSVCIS RTP packet consists of zero = or more TSVCIS coder frames
> > > > >=C2=A0 =C2=A0 (each consisting of MELPe and TSVCIS = coder data) followed by zero or
> > > > >=C2=A0 =C2=A0 one MELPe comfort noise frame.=C2=A0 = The presence of a comfort noise frame
> > > > >=C2=A0 =C2=A0 can be determined by its rate code bi= ts in its last octet.
> > > > >
> > > > > (now)
> > > > >=C2=A0 =C2=A0 A TSVCIS RTP packet payload consists = of zero or more consecutive
> > > > >=C2=A0 =C2=A0 TSVCIS coder frames (each consisting = of MELPe 2400 and TSVCIS coder
> > > > >=C2=A0 =C2=A0 data), with the oldest frame first, f= ollowed by zero or one MELPe
> > > > >=C2=A0 =C2=A0 comfort noise frame.=C2=A0 The presen= ce of a comfort noise frame can be
> > > > >=C2=A0 =C2=A0 determined by its rate code bits in i= ts last octet.
> > > > >
> > > > >
> > > > > Section 3.3, fourth paragraph - Clarification requ= ested by
> > > > > reviewers
> > > > >
> > > > > (was)
> > > > >=C2=A0 =C2=A0 TSVCIS coder frames in a single RTP p= acket MAY be of different coder
> > > > >=C2=A0 =C2=A0 bitrates.=C2=A0 With the exception fo= r the variable length TSVCIS
> > > > >=C2=A0 =C2=A0 parameter frames, the coder rate bits= in the trailing byte identify
> > > > >=C2=A0 =C2=A0 the contents and length as per Table = 1.
> > > > >
> > > > > (now)
> > > > >=C2=A0 =C2=A0 TSVCIS coder frames in a single RTP p= acket MAY have varying TSVCIS
> > > > >=C2=A0 =C2=A0 parameter octet counts.=C2=A0 Its pac= ked parameter octet count (length) is
> > > > >=C2=A0 =C2=A0 indicated in the trailing byte(s).=C2= =A0 All MELPe frames in a single RTP
> > > > >=C2=A0 =C2=A0 packet MUST be of the same coder bitr= ate.=C2=A0 For all MELPe coder
> > > > >=C2=A0 =C2=A0 frames, the coder rate bits in the tr= ailing byte identify the
> > > > >=C2=A0 =C2=A0 contents and length as per Table 1. > > > > >
> > > > >
> > > > > Section 4.1 - Editor note removed
> > > > >
> > > > >
> > > > > Section 4.1 - Change controller is now
> > > > >
> > > > > (now)
> > > > >=C2=A0 =C2=A0 Change controller: IETF, contact <= avt@ietf.org>
> > > > >
> > > > >
> > > > > Section 5, first paragraph - Suggested edits by re= viewers
> > > > >
> > > > > (was)
> > > > >=C2=A0 =C2=A0 A primary application of TSVCIS is fo= r radio communications of voice
> > > > >=C2=A0 =C2=A0 conversations, and discontinuous tran= smissions are normal.=C2=A0 When
> > > > >=C2=A0 =C2=A0 TSVCIS is used in an IP network, TSVC= IS RTP packet transmissions may
> > > > >=C2=A0 =C2=A0 cease and resume frequently.=C2=A0 RT= P synchronization source (SSRC)
> > > > >=C2=A0 =C2=A0 sequence number gaps indicate lost pa= ckets to be filled by PLC, while
> > > > >=C2=A0 =C2=A0 abrupt loss of RTP packets indicates = intended discontinuous
> > > > >=C2=A0 =C2=A0 transmissions.
> > > > >
> > > > > (now)
> > > > >=C2=A0 =C2=A0 A primary application of TSVCIS is fo= r radio communications of voice
> > > > >=C2=A0 =C2=A0 conversations, and discontinuous tran= smissions are normal.=C2=A0 When
> > > > >=C2=A0 =C2=A0 TSVCIS is used in an IP network, TSVC= IS RTP packet transmissions may
> > > > >=C2=A0 =C2=A0 cease and resume frequently.=C2=A0 RT= P synchronization source (SSRC)
> > > > >=C2=A0 =C2=A0 sequence number gaps indicate lost pa= ckets to be filled by Packet
> > > > >=C2=A0 =C2=A0 Loss Concealment (PLC), while abrupt = loss of RTP packets indicates
> > > > >=C2=A0 =C2=A0 intended discontinuous transmissions.= =C2=A0 Resumption of voice
> > > > >=C2=A0 =C2=A0 transmission SHOULD be indicated by t= he RTP marker bit (M) set to 1.
> > > > >
> > > > >
> > > > > Section 10 - Added reference
> > > > >
> > > > > (added)
> > > > >=C2=A0 =C2=A0 [RFC8088]=C2=A0 Westerlund, M., "= ;How to Write an RTP Payload Format",
> > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0RFC 8088, DOI 10.17487/RFC8088, May 2017,
> > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0<http://www.rfc-editor.org/info/rfc8088>.
> > > > >
> > > > > --------------------------------------------------= --------------
> > > > > ----
> > > > > -----------------------------
> > > > >
> > > > >
> > > > > -----Original Message-----
> > > > > From: Roni Even (A) <roni.even@huawei.com>
> > > > > Sent: Sunday, October 6, 2019 2:09 AM
> > > > > To: victor.demjanenko@vocal.com; 'Benjamin Kaduk'= ;
> > > > > <kaduk@mit.edu>; 'The IESG' <iesg@ietf.org>
> > > > > Cc: draft-ietf-payload-tsvcis@ietf.org; 'Ali = Begen'
> > > > > <ali.begen@networked.media>; avtcore-chairs@ietf.org; =
> > > > > = avt@ietf.org; 'Dave Satterlee (Vocal)'
> > > > > <Dave.Satterlee@vocal.com>
> > > > > Subject: RE: Benjamin Kaduk's Discuss on
> > > > > draft-ietf-payload-tsvcis-03: (with DISCUSS and CO= MMENT)
> > > > >
> > > > > Hi,
> > > > > About the reference to TSVCIS.
> > > > > The RTP payload is about how to encapsulate the pa= yload in an
> > > > > RTP
> > > packet. The objective is to define how an RTP stack can inse= rt the
> > > tsvcis frames and=C2=A0 extract the tsvcis frames from the R= TP packet.
> > > Typically it is not required to understand the payload struc= ture in
> > > order to be able to perform the encapsulation.
> > > > > This is why the reference to the payload is Inform= ational and we
> > > > > did not require to have it publically available.= =C2=A0 If there is a
> > > > > need to understand the payload itself for the enca= psulating than
> > > > > we need more information in the RTP payload specif= ication and a
> > > > > publically available normative reference. I think = this is not
> > > > > the case here
> > > > >
> > > > > Roni Even
> > > > >
> > > > > AVTCore co-chair (ex Payload)
> > > > >
> > > > > -----Original Message-----
> > > > > From: victor.demjanenko@vocal.com
> > > > > [mailto:victor.demjanenko@vocal.com]
> > > > > Sent: Saturday, October 05, 2019 12:18 AM
> > > > > To: 'Benjamin Kaduk'; 'The IESG' > > > > > Cc: draft-ietf-payload-tsvcis@ietf.org; 'Ali = Begen';
> > > avtcore-chairs@ietf.org; avt@ietf.org; 'Victor Demjanenko, Ph.D.';
> > > 'Dave Satterlee (Vocal)'
> > > > > Subject: RE: Benjamin Kaduk's Discuss on
> > > > > draft-ietf-payload-tsvcis-03: (with DISCUSS and CO= MMENT)
> > > > >
> > > > > Everyone,
> > > > >
> > > > > Thanks for the comments.=C2=A0 I think I mis-under= stood the ambiguity
> > > > > with
> > > respect to to changing rates within a RTP packet.=C2=A0 That= was not
> > > plan.=C2=A0 An RTP packet must have MELP speech frames of th= e same rate.=C2=A0
> > > What is possible is that the amount of augmented TSVCIS spee= ch data
> > > may vary from one speech frame to the next.=C2=A0 This allow= s for a
> > > dynamic VDR as suggested by the NRL paper.=C2=A0 So an RTP p= acket may
> > > have varying TSVCIS data but must always have MELPe 2400 dat= a.
> > > > >
> > > > > Again backwards parsing is necessary but the times= tamp uniformly
> > > increments 22.5msec per combined MELP/TSVCIS speech frame. > > > > >
> > > > > The NRL is a good public reference on the VDR aspe= cts.=C2=A0 The
> > > > > actual
> > > TSVCIS spec we had was FOUO so we could not replicate its de= tail.=C2=A0
> > > (I believe a later spec is public or at least partially publ= ic.=C2=A0 I
> > > am trying to get this.)=C2=A0 The opaque data is pretty obvi= ous with the TSVCIS spec in hand.
> > > > >
> > > > > We will address the issues/concerns raised next we= ek.=C2=A0 Other
> > > > > business
> > > had priority.
> > > > >
> > > > > Thank you and enjoy the weekend.
> > > > >
> > > > > Regards,
> > > > >
> > > > > Victor & Dave
> > > > >
> > > > > -----Original Message-----
> > > > > From: Benjamin Kaduk via Datatracker <noreply@ietf.org>
> > > > > Sent: Wednesday, October 2, 2019 10:40 PM
> > > > > To: The IESG <iesg@ietf.org>
> > > > > Cc: draft-ietf-payload-tsvcis@ietf.org; Ali Begen=
> > > > > <ali.begen@networked.media>; avtcore-chairs@ietf.org; =
> > > > > ali.begen@networked.media; avt@ietf.org
> > > > > Subject: Benjamin Kaduk's Discuss on draft-iet= f-payload-tsvcis-03:
> > > > > (with DISCUSS and COMMENT)
> > > > >
> > > > > Benjamin Kaduk has entered the following ballot po= sition for
> > > > > draft-ietf-payload-tsvcis-03: Discuss
> > > > >
> > > > > When responding, please keep the subject line inta= ct and reply
> > > > > to all email addresses included in the To and CC l= ines. (Feel
> > > > > free to cut this introductory paragraph, however.)=
> > > > >
> > > > >
> > > > > Please refer to
> > > > > https://www.ietf.o= rg/iesg/statement/discuss-criteria.html
> > > > > for more information about IESG DISCUSS and COMMEN= T positions.
> > > > >
> > > > >
> > > > > The document, along with other ballot positions, c= an be found here:
> > > > > https://datatrac= ker.ietf.org/doc/draft-ietf-payload-tsvcis/
> > > > >
> > > > >
> > > > >
> > > > > --------------------------------------------------= --------------
> > > > > ----
> > > > > --
> > > > > DISCUSS:
> > > > > --------------------------------------------------= --------------
> > > > > ----
> > > > > --
> > > > >
> > > > > I support Magnus' point about the time-orderin= g of adjacent
> > > > > frames in a
> > > packet.
> > > > >
> > > > > Additionally, I am not sure that there's quite= enough here to be
> > > interoperably implementable.=C2=A0 Specifically, we seem to = be lacking a
> > > description of how an encoder or decoder knows which TSVCIS =
> > > parameters, and in what order, to byte-pack or unpack, respe= ctively.=C2=A0
> > > One might surmise that there is a canonical listing in [TSVC= IS], but
> > > this document does not say that, and furthermore [TSVCIS] is= only listed as an informative reference.
> > > (I couldn't get my hands on my copy, at least on short n= otice.)=C2=A0 If
> > > we limited ourselves to treating the TSVCIS parameters as an=
> > > entirely opaque blob (codec, convey these N octets to the pe= er with
> > > the appropriate one- or two-byte trailer for payload type > > > identification and framing), that would be interoperably > > > implementable, since the black-box bits are up to some other= codec to interpret.
> > > > >
> > > > > In a similar vein, we mention but do not completel= y specify the
> > > potential for using CODB as an end-to-end framing bit, in Se= ction
> > > 3.1 (see Comment), which is not interoperably implementable = without further details.
> > > > >
> > > > >
> > > > > --------------------------------------------------= --------------
> > > > > ----
> > > > > --
> > > > > COMMENT:
> > > > > --------------------------------------------------= --------------
> > > > > ----
> > > > > --
> > > > >
> > > > > Where is [TSVCIS] available?
> > > > >
> > > > > Is [NRLVDR] the same as
> > > > > https://apps.dtic.mil/= dtic/tr/fulltext/u2/a588068.pdf ?=C2=A0 A URL
> > > > > in the
> > > references would be helpful.
> > > > >
> > > > > Is additional TSVCIS data only present after 2400b= ps MELPe and
> > > > > the first
> > > thing to get dropped under bandwidth pressure?=C2=A0 The abs= tract and
> > > introduction imply this by calling out MELPe 2400 bps speech=
> > > parameters explicitly, but Section 3 says that TSVCIS augmen= ts
> > > standard 600, 1200, and
> > > 2400 bps MELP frames.
> > > > >
> > > > > It's helpful that Section 3.3 gives some gener= al guidance for
> > > > > decoding
> > > this payload type ("[t]he way to determine the number o= f
> > > TSVCIS/MELPe frames is to identify each frame type and lengt= h"), but
> > > I think some generic considerations would be very helpful to= the
> > > reader much earlier, along the lines of "MELPe and TSVC= IS data
> > > payloads are decoded from the end, using the CODA and CODB (= and, if
> > > necessary, CODC and others) bits to determine the type of pa= yload.=C2=A0
> > > For MELPe payloads the type also indicates the payload lengt= h,
> > > whereas for TSVCIS data an additional length field is presen= t, in
> > > one of two possible formats.=C2=A0 A TSVCIS coder frame cons= ists of a
> > > MELPe data payload followed by zero or one TSVCIS data paylo= ad;
> > > after the TSVCIS payload's presence/length is determined= , then the
> > > preceding MELPe payload can be determined and decoded.=C2=A0= Per Section
> > > 3.3, multiple TSVCIS frames can be present in a single RTP p= acket."=C2=A0
> > > This (or something like it) would also serve to clarify the = role of the COD* bits, which is otherwise only implicitly introduced.
> > > > >
> > > > > Section 1.1
> > > > >
> > > > > RFC 2736 is BCP 36 (but it's updated by RFC 80= 88 which is for
> > > > > some
> > > reason an Informational document and not part of BCP 36?!).<= br> > > > > >
> > > > > Section 2
> > > > >
> > > > >=C2=A0 =C2=A0 In addition to the augmented speech d= ata, the TSVCIS specification
> > > > >=C2=A0 =C2=A0 identifies which speech coder and fra= ming bits are to be encrypted,
> > > > >=C2=A0 =C2=A0 and how they are protected by forward= error correction (FEC)
> > > > >=C2=A0 =C2=A0 techniques (using block codes).=C2=A0= At the RTP transport layer, only the
> > > > >=C2=A0 =C2=A0 speech coder related bits need to be = considered and are conveyed in
> > > > >=C2=A0 =C2=A0 unencrypted form.=C2=A0 In most IP-ba= sed network deployments,
> > > > > standard
> > > > >
> > > > > Am I reading this correctly that this text is just= summarizing
> > > > > what's in
> > > the TSVCIS spec in terms of what needs to be in unencrypted = form, so
> > > the "only the speech coder related bits[...]" is n= ot new information
> > > from this document?=C2=A0 I'm not sure I agree with the = conclusion,
> > > regardless -- won't the
> > > (MELPe) speech coder bits be enough to convey the semantic c= ontent
> > > of the audio stream, something that one might desire to keep= confidential?
> > > > >
> > > > >=C2=A0 =C2=A0 link encryption methods (SRTP, VPNs, = FIPS 140 link encryptors or Type
> > > > >=C2=A0 =C2=A0 1 Ethernet encryptors) would be used = to secure the RTP speech
> > > > >=C2=A0 =C2=A0 contents.=C2=A0 Further, it is desira= ble to support the highest voice
> > > > >=C2=A0 =C2=A0 quality between endpoints which is on= ly possible without the overhead
> > > > >=C2=A0 =C2=A0 of FEC.
> > > > >
> > > > > I think I'm missing a step in how this conclus= ion was reached.
> > > > >
> > > > >=C2=A0 =C2=A0 TSVCIS will be characterized.=C2=A0 D= epending on the bandwidth available
> > > > >=C2=A0 =C2=A0 (and FEC requirements), a varying num= ber of TSVCIS specific speech
> > > > >=C2=A0 =C2=A0 coder parameters need to be transport= ed.=C2=A0 These are first byte-packed
> > > > >=C2=A0 =C2=A0 and then conveyed from encoder to dec= oder.
> > > > >
> > > > > Per the Discuss point, how do I know which paramet= ers need to be
> > > transported, and in what order?
> > > > >
> > > > >=C2=A0 =C2=A0 Byte packing of TSVCIS speech data in= to packed parameters is
> > > > >=C2=A0 =C2=A0 processed as per the following exampl= e:
> > > > >
> > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0Three-bit field: bits A,= B, and C (A is MSB, C is LSB)
> > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0Five-bit field: bits D, = E, F, G, and H (D is MSB, H is
> > > > > LSB)
> > > > >
> > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 MSB=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 LSB
> > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A00= =C2=A0 =C2=A0 =C2=A0 1=C2=A0 =C2=A0 =C2=A0 2=C2=A0 =C2=A0 =C2=A0 3=C2=A0 = =C2=A0 =C2=A0 4=C2=A0 =C2=A0 =C2=A0 5=C2=A0 =C2=A0 =C2=A0 6=C2=A0 =C2=A0 = =C2=A0 7
> > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+------+------+--= ----+------+------+------+------+------+
> > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0H= =C2=A0 |=C2=A0 =C2=A0G=C2=A0 |=C2=A0 =C2=A0F=C2=A0 |=C2=A0 =C2=A0E=C2=A0 |= =C2=A0 =C2=A0D=C2=A0 |=C2=A0 =C2=A0C=C2=A0 |=C2=A0 =C2=A0B=C2=A0 |=C2=A0 = =C2=A0A=C2=A0 |
> > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0
> > > > > +------+------+------+------+------+------+------+= ------+
> > > > >
> > > > >=C2=A0 =C2=A0 This packing method places the three-= bit field "first" in the lowest
> > > > >=C2=A0 =C2=A0 bits followed by the next five-bit fi= eld.=C2=A0 Parameters may be split
> > > > >=C2=A0 =C2=A0 between octets with the most signific= ant bits in the earlier octet.
> > > > >=C2=A0 =C2=A0 Any unfilled bits in the last octet M= UST be filled with zero.
> > > > >
> > > > > I agree with Adam that this is very unclear.=C2=A0= A is the MSB of
> > > > > the
> > > three-bit field but the LSB of the octet overall?
> > > > > We probably need an example of splitting a paramet= er across
> > > > > octets as
> > > well, to get the bit ordering right.
> > > > >
> > > > > Section 3.1
> > > > >
> > > > >=C2=A0 =C2=A0 It should be noted that CODB for both= the 2400 and 600 bps modes MAY
> > > > >=C2=A0 =C2=A0 deviate from the values in Table 1 wh= en bit 55 is used as an end-to-
> > > > >=C2=A0 =C2=A0 end framing bit.=C2=A0 Frame decoding= would remain distinct as
> > > > > CODA being
> > > > >
> > > > > Where is the use of CODB as an end-to-end framing = bit defined?=C2=A0
> > > > > If we're
> > > going to provide neither a complete description of how to do= it nor
> > > a reference to a better description, we probably shouldn'= ;t mention it at all.
> > > > >
> > > > > Section 3.2
> > > > >
> > > > >=C2=A0 =C2=A0 RTP packet.=C2=A0 The packed paramete= rs are counted in octets (TC).=C2=A0 In
> > > > >=C2=A0 =C2=A0 the preferred placement, shown in Fig= ure 6, a single trailing octet
> > > > >=C2=A0 =C2=A0 SHALL be appended to include a two-bi= t rate code, CODA and
> > > > > CODB,
> > > > >
> > > > > I'd consider saying something about this being= the preferred
> > > > > format
> > > > > ("placement") due to its shorter length = than the alternative,
> > > > > and say
> > > that it "SHOULD be used for TSVCIS payloads with TC les= s than or
> > > equal to 77 octetes".
> > > > >
> > > > > Section 3.3
> > > > >
> > > > > When a longer packetization interval is used, is t= hat indicated
> > > > > by
> > > signaling or RTP timestamps or otherwise?
> > > > >
> > > > >=C2=A0 =C2=A0 TSVCIS coder frames in a single RTP p= acket MAY be of different coder
> > > > >=C2=A0 =C2=A0 bitrates.=C2=A0 With the exception fo= r the variable length TSVCIS
> > > > >=C2=A0 =C2=A0 parameter frames, the coder rate bits= in the trailing byte identify
> > > > >=C2=A0 =C2=A0 the contents and length as per Table = 1.
> > > > >
> > > > > Maybe also note that the penultimate octet gives t= he length there?
> > > > >
> > > > >=C2=A0 =C2=A0 Information describing the number of = frames contained in an RTP
> > > > >=C2=A0 =C2=A0 packet is not transmitted as part of = the RTP payload.=C2=A0 The way to
> > > > >=C2=A0 =C2=A0 determine the number of TSVCIS/MELPe = frames is to identify each frame
> > > > >=C2=A0 =C2=A0 type and length thereby counting the = total number of octets within
> > > > >=C2=A0 =C2=A0 the RTP packet.
> > > > >
> > > > > terminology nit: if a frame is the combination of = MELPe and
> > > > > TSVCIS
> > > payload data units then there are two layres of decoding to = get a
> > > length for the frame, since we have to get the TSVCIS length= and then the MELPe length.
> > > > >
> > > > > Section 4.2
> > > > >
> > > > >=C2=A0 =C2=A0 Parameter "ptime" cannot be= used for the purpose of
> > > > > specifying the
> > > > >
> > > > > nit: missing article ("The parameter") > > > > >
> > > > >=C2=A0 =C2=A0 will be impossible to distinguish whi= ch mode is about to be used
> > > > >=C2=A0 =C2=A0 (e.g., when ptime=3D68, it would be i= mpossible to distinguish if the
> > > > >=C2=A0 =C2=A0 packet is carrying one frame of 67.5 = ms or three frames of 22.5 ms).
> > > > >
> > > > > So how is the operating mode determined, then?
> > > > > (I think this is the same question I asked above)<= br> > > > > >
> > > > > Section 4.4
> > > > >
> > > > >=C2=A0 =C2=A0 For example, if offerer bitrates are = "2400,600" and answer bitrates
> > > > >=C2=A0 =C2=A0 are "600,2400", the initial= bitrate is 600.=C2=A0 If other bitrates are
> > > > >=C2=A0 =C2=A0 provided by the answerer, any common = bitrate between the offer and
> > > > >=C2=A0 =C2=A0 answer MAY be used at any time in the= future.=C2=A0 Activation of these
> > > > >=C2=A0 =C2=A0 other common bitrates is beyond the s= cope of this document.
> > > > >
> > > > > It seems important to specify whether this require= s a new O/A
> > > > > exchange
> > > or can be done "spontaneously" by just encoding di= fferent frame types.
> > > > > (It seems like the latter is possible, on first gl= ance, and this
> > > > > is implied by Section 3.3's discussion of mixi= ng them in a
> > > > > single
> > > > > packet.)
> > > > >
> > > > > Section 5
> > > > >
> > > > > Please expand PLC at first use (not second).
> > > > >
> > > > > Section 6
> > > > >
> > > > > I don't understand the PLC usage.=C2=A0 Is the= idea that a receiver,
> > > > > on
> > > seeing an SSRC gap, constructs fictitious PLC frames to &quo= t;fill the gap"
> > > > > and passes the resulting stream to the decoder? > > > > >
> > > > > Section 8
> > > > >
> > > > >=C2=A0 =C2=A0 and important considerations in [RFC7= 201].=C2=A0 Applications SHOULD use
> > > > >=C2=A0 =C2=A0 one or more appropriate strong securi= ty mechanisms.=C2=A0 The rest of this
> > > > >=C2=A0 =C2=A0 section discusses the security-impact= ing properties of the payload
> > > > >=C2=A0 =C2=A0 format itself.
> > > > >
> > > > > I thought we described TSVCIS itself (much earlier= in the
> > > > > document) as
> > > requiring encryption for some data; wouldn't that transl= ate to a "MUST"
> > > > > here and not a "SHOULD"?
> > > > >
> > > > >
> > > > >
> > >
>

--000000000000a85af0059f4bb74a-- From nobody Mon Feb 24 15:06:29 2020 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BF1CE3A1510; Mon, 24 Feb 2020 15:06:27 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Linda Dunbar via Datatracker To: Cc: last-call@ietf.org, draft-ietf-dnsop-7706bis.all@ietf.org, dnsop@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.118.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <158258558771.24222.13223272462077841258@ietfa.amsl.com> Reply-To: Linda Dunbar Date: Mon, 24 Feb 2020 15:06:27 -0800 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-dnsop-7706bis-07 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Feb 2020 23:06:28 -0000 Reviewer: Linda Dunbar Review result: Has Nits Reviewer: Linda Dunbar Review result: Ready with questions I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. The Abstract of This document claims that this document shows how to start and maintain a copy of the root zone in the Recursive Resolvers so that the Resolvers don't need to send query to another node. Two questions: - What if the node is not authorized to have the entire records? It would desirable for the Resolvers to have all the records of the root zone. Is there any scenario that the Resolvers simply cannot get all the records of the root zone? - How to detect if any records stored in the Resolver are STALE? Page 3, last sentence of the 3rd paragraph: is it a typo? or miss a verb? "... it would all responses from a remote root server" Cheers, Linda Dunbar From nobody Mon Feb 24 21:56:58 2020 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E11E43A0A94; Mon, 24 Feb 2020 21:56:39 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Brian Weis via Datatracker To: Cc: alto@ietf.org, draft-ietf-alto-cost-calendar.all@ietf.org, last-call@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.118.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <158261019978.24286.6282703976329096776@ietfa.amsl.com> Reply-To: Brian Weis Date: Mon, 24 Feb 2020 21:56:39 -0800 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-alto-cost-calendar-17 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Feb 2020 05:56:40 -0000 Reviewer: Brian Weis Review result: Ready I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document defines the ALTO Cost Calendar, an extension to the base Application-Layer Traffic Optimization (ALTO) protocol. Currently, the ALTO cost information service provides applications with guidance about current costs of a desired resource, but not for resources with a cost that changes dramatically over time. The ALTO Cost Calendar allows for specifying costs for varying time periods in the future. The extensions in this document are to the existing network flows, with policy defined in JSON. As such, additional security considerations are few. The well-written Security Considerations document does define a few considerations that come from announcing events that are expected to happen in the future. I have only one suggestion for additional text. The second paragraph on page 27 (draft -17) describes risks of a client using the calendaring information for their own selfish purposes. The suggested mitigation in the next paragraph is to limit the information “being leaked to malicious clients or third parties“ by authenticating clients with TLS. This strategy may thwart “third parties”, but it will not help in the case of “malicious clients” possessing valid credentials to authenticate. The threat here might be legitimate clients that have become subverted by an attacker and are now ‘bots’ being asked to participate in a DDoS attack. The calendar information would be valuable information for when to persecute a DDoS attack, and this should be noted here. From nobody Tue Feb 25 15:21:48 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 979B23A0810 for ; Tue, 25 Feb 2020 15:21:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=redhoundsoftware.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 QCekqWVhc9sU for ; Tue, 25 Feb 2020 15:21:45 -0800 (PST) Received: from mail-qk1-x736.google.com (mail-qk1-x736.google.com [IPv6:2607:f8b0:4864:20::736]) (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 667B33A0813 for ; Tue, 25 Feb 2020 15:21:45 -0800 (PST) Received: by mail-qk1-x736.google.com with SMTP id 145so936373qkl.2 for ; Tue, 25 Feb 2020 15:21:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhoundsoftware.com; s=google; h=user-agent:date:subject:from:to:message-id:thread-topic :mime-version:content-transfer-encoding; bh=6vl2UFc9R/FXbyyI803JKDv/dY2vq04ixtx6lP3DyB0=; b=zSbYv2Ly04E6BEIzULMxhoHGD2aHsap7BGeoJHZhnxH84z8CUiFy/2NUDmwJGimE1v JsK+Exr8eSRh4daH4wFO/KHOQsP0CRtdrOVwTVNmxi8txxFWDKFBJbYk6LNFivtescYO we8J+a4uNakc3m9l8KA2Wpj7G532WSFvxnAz0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:user-agent:date:subject:from:to:message-id :thread-topic:mime-version:content-transfer-encoding; bh=6vl2UFc9R/FXbyyI803JKDv/dY2vq04ixtx6lP3DyB0=; b=sTk7aaV29l2u5yT30bAGdnEhIiKe0f95nS4rBorz8RjphQON7jc8di1zPqEwI+94ti 6V4PJvv3ZtwphJI/hZUpIc10bEuIH8g81qpLZYpbum5v+ngEo6muciVagsLS/EHoKbsL CEfi/Sxels5UgJhvBnGvY+spEZNh2VMw4OI0lw8qQfOAwVElb2lsy/J53iVOPjU8Q7y9 WbR/EVUxj3pPlR5yRrpl7w91gIzDkEiVGBf25ICaTCBuaigouI9dJSp37bPa+KX16+yo 3UU7N5UkYreBPw/5IWZt3xuzrUBB1Ff8qaL7Cc1CrOBcifoO0GXqmCWseaTbp3kqKUeV hQaA== X-Gm-Message-State: APjAAAUx54w6gPKoxJ0P/coAjyiLLxFiHzJbhG1Ot4cR1ilq5vQaonHJ 6iTAMkpZe/ecborte8PRGduJVyDhc7g= X-Google-Smtp-Source: APXvYqwfgOAAC5Sdawh1kTnE9nqHYAiK0vg19Ne835f1kntXHpkwxzNxG3F7ULB8P7/TOQKV2Psfxg== X-Received: by 2002:a37:e86:: with SMTP id 128mr1570076qko.403.1582672904151; Tue, 25 Feb 2020 15:21:44 -0800 (PST) Received: from [192.168.2.16] (pool-173-73-189-140.washdc.fios.verizon.net. [173.73.189.140]) by smtp.gmail.com with ESMTPSA id w53sm50008qtb.91.2020.02.25.15.21.43 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 25 Feb 2020 15:21:43 -0800 (PST) User-Agent: Microsoft-MacOutlook/10.10.13.200210 Date: Tue, 25 Feb 2020 18:21:43 -0500 From: Carl Wallace To: , , Message-ID: <935224C2-2342-4254-91AF-A8C1551215FF@redhoundsoftware.com> Thread-Topic: secdir review of draft-ietf-rmcat-eval-criteria Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: 7bit Archived-At: Subject: [secdir] secdir review of draft-ietf-rmcat-eval-criteria X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Feb 2020 23:21:47 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document describes the guidelines to evaluate new congestion control algorithms for interactive point-to-point real-time media. It asserts that as a document providing evaluation criteria and parameters for assessing and comparing performance that it is not subject to security considerations, but that evaluated protocols may be. This seems sufficient. The document is ready with some minor nits like an incomplete sentence in third paragraph of first section and some difficult to parse language in the jitter section ("jitter is a smoothed estimate of jitter", for example). From nobody Tue Feb 25 15:24:00 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 543FB3A0814; Tue, 25 Feb 2020 15:23:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.398 X-Spam-Level: X-Spam-Status: No, score=-1.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, 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 xEbi5TIysBQw; Tue, 25 Feb 2020 15:23:52 -0800 (PST) Received: from mail-vk1-f196.google.com (mail-vk1-f196.google.com [209.85.221.196]) (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 6880B3A0813; Tue, 25 Feb 2020 15:23:52 -0800 (PST) Received: by mail-vk1-f196.google.com with SMTP id t129so259474vkg.6; Tue, 25 Feb 2020 15:23:52 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=2AxyDr3riA4UsNeff9VdanLSUXNhImQD/A7/f5mg3cc=; b=Q+a2YwBEqYwEUqqlrC3pXUBm7v+NZJh1nWmvmfUX9IBuOdX7hXNdIexKUkFnJtl+lM m0fNSrqMT65tHGzsu1IqSFVudK59FDnGDeqeEm9nHpBw2hlsuRV/z90R8jB3o5ox/NZB mtYuPy1XBMSMLjwQNZ2XUklQScEHSYB4ZiuZJ6/sevqtjNobdIaeW1Qw8KFM832ShJU0 FhmihOnyYVC+OggsSTXO0fyHWRyAJjktrvf5kmRYdfVTek4byrTjtBMerzahrUuSrwqU jsYN+rhu90c9HlqAbEmCVMyz31olxlfmKsBXhgDLtRCXU/4A01cWa7PYRnfDGsjgZop3 1LUA== X-Gm-Message-State: APjAAAW7p/fSRglIT+3Yh01bGFX9nhTtBJAqomHLBU0hNLaQ/C5cpfb5 vVv0AGXiWllF6IwqUbHqVyfAF7GWailfbTsiu6KrBZWG X-Google-Smtp-Source: APXvYqwU6JGJyV+X6WmSra+7ep5kfKjeVq737C/Ef3krLeVYl9Jc+uEzi1yeT8Ti40emJQl3R/8Z63Z3wTMA0PH9LfE= X-Received: by 2002:a05:6122:1066:: with SMTP id k6mr1391075vko.68.1582673031248; Tue, 25 Feb 2020 15:23:51 -0800 (PST) MIME-Version: 1.0 References: <158261019978.24286.6282703976329096776@ietfa.amsl.com> In-Reply-To: <158261019978.24286.6282703976329096776@ietfa.amsl.com> From: "Y. Richard Yang" Date: Tue, 25 Feb 2020 18:23:40 -0500 Message-ID: To: Brian Weis Cc: secdir@ietf.org, IETF ALTO , draft-ietf-alto-cost-calendar.all@ietf.org, last-call@ietf.org Content-Type: multipart/alternative; boundary="000000000000d2bea7059f6ec7a9" Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-alto-cost-calendar-17 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Feb 2020 23:23:55 -0000 --000000000000d2bea7059f6ec7a9 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Dear Brian, Thank you so much for the review. Please see inline below. On Tue, Feb 25, 2020 at 12:56 AM Brian Weis via Datatracker < noreply@ietf.org> wrote: > Reviewer: Brian Weis > Review result: Ready > > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the IESG. > These comments were written primarily for the benefit of the security > area directors. Document editors and WG chairs should treat these > comments just like any other last call comments. > > This document defines the ALTO Cost Calendar, an extension to the base > Application-Layer Traffic Optimization (ALTO) protocol. Currently, the > ALTO cost information service provides applications with guidance about > current costs of a desired resource, but not for resources with a cost th= at > changes dramatically over time. The ALTO Cost Calendar allows for > specifying costs for varying time periods in the future. > > The extensions in this document are to the existing network flows, with > policy defined in JSON. As such, additional security considerations are > few. The well-written Security Considerations document does define a few > considerations that come from announcing events that are expected to > happen in the future. > > I have only one suggestion for additional text. The second > paragraph on page 27 (draft -17) describes risks of a client using the > calendaring information for their own selfish purposes. The suggested > mitigation in the next paragraph is to limit the information =E2=80=9Cbei= ng > leaked to malicious clients or third parties=E2=80=9C by authenticating c= lients > with TLS. This strategy may thwart =E2=80=9Cthird parties=E2=80=9D, but i= t will not help > in the case of =E2=80=9Cmalicious clients=E2=80=9D possessing valid crede= ntials to > authenticate. The threat here might be legitimate clients that have > become subverted by an attacker and are now =E2=80=98bots=E2=80=99 being = asked to > participate in a DDoS attack. The calendar information would be valuable > information for when to persecute a DDoS attack, and this should be > noted here. > This is an excellent point. The compromised-but-still-appear-to-be-legitimate is a quite reasonable setting. We have added the following paragraph, by borrowing your excellent text above, right after the paragraph "[RFC8446] specifies TLS 1.3 and writes in its section 1: ..." New paragraph: The operator should be should be cognizant that the preceding mechanisms do not address all security risks. In particular, they will not help in the case of =E2=80=9Cmalicious clients=E2=80=9D possessing valid credent= ials to authenticate. The threat here can be that legitimate clients have become subverted by an attacker and are now =E2=80=98bots=E2=80=99 being= asked to participate in a DDoS attack. The Calendar information would be valuable information for when to persecute a DDoS attack. A mechanism such as a monitoring system that detects abnormal behaviors may still be needed.= " How does it look? Thanks a lot, Richard --000000000000d2bea7059f6ec7a9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear Brian,

Thank you = so much for the review. Please see inline below.

On Tue, Feb 25, 2020= at 12:56 AM Brian Weis via Datatracker <noreply@ietf.org> wrote:
Reviewer: Brian Weis
Review result: Ready

I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security
area directors.=C2=A0 Document editors and WG chairs should treat these
comments just like any other last call comments.

This document defines the ALTO Cost Calendar, an extension to the base
Application-Layer Traffic Optimization (ALTO) protocol. Currently, the
ALTO cost information service provides applications with guidance about
current costs of a desired resource, but not for resources with a cost that=
changes dramatically over time. The ALTO Cost Calendar allows for
specifying costs for varying time periods in the future.

The extensions in this document are to the existing network flows, with
policy defined in JSON. As such, additional security considerations are
few. The well-written Security Considerations document does define a few considerations that come from announcing events that are expected to
happen in the future.

I have only one suggestion for additional text. The second
paragraph on page 27 (draft -17) describes risks of a client using the
calendaring information for their own selfish purposes. The suggested
mitigation in the next paragraph is to limit the information =E2=80=9Cbeing=
leaked to malicious clients or third parties=E2=80=9C by authenticating cli= ents
with TLS. This strategy may thwart =E2=80=9Cthird parties=E2=80=9D, but it = will not help
in the case of =E2=80=9Cmalicious clients=E2=80=9D possessing valid credent= ials to
authenticate. The threat here might be legitimate clients that have
become subverted by an attacker and are now =E2=80=98bots=E2=80=99 being as= ked to
participate in a DDoS attack. The calendar information would be valuable information for when to persecute a DDoS attack, and this should be
noted here.

This is an excellent point. The compromis= ed-but-still-appear-to-be-legitimate
is a quite reasonable setting. We = have added the following paragraph, by
borrowing your excellent text ab= ove, right after the paragraph
"[RFC8446] specifies TLS 1.3 and wr= ites in its section 1: ..."

New paragraph:

= =C2=A0 The operator should be should be cognizant that the preceding mechan= isms
=C2=A0 =C2=A0do not address all security risks. In particular, they= will not help in
=C2=A0 =C2=A0the case of =E2=80=9Cmalicious clients= =E2=80=9D possessing valid credentials to
=C2=A0 =C2=A0authenticate. The= threat here can be that legitimate clients have
=C2=A0 =C2=A0become sub= verted by an attacker and are now =E2=80=98bots=E2=80=99 being asked to
= =C2=A0 =C2=A0participate in a DDoS attack. The Calendar information would b= e valuable
=C2=A0 =C2=A0information for when to persecute a DDoS attack.= A mechanism such as
=C2=A0 =C2=A0a monitoring system that detects abnor= mal behaviors may still be needed."

How does = it look?

Thanks a lot,
Richard



--000000000000d2bea7059f6ec7a9-- From nobody Tue Feb 25 16:00:29 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00F223A08FD; Tue, 25 Feb 2020 16:00:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, SPF_HELO_NONE=0.001, 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 TF4Gh9R5qiRr; Tue, 25 Feb 2020 16:00:22 -0800 (PST) Received: from mail-pf1-x42e.google.com (mail-pf1-x42e.google.com [IPv6:2607:f8b0:4864:20::42e]) (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 48F0E3A08F6; Tue, 25 Feb 2020 16:00:22 -0800 (PST) Received: by mail-pf1-x42e.google.com with SMTP id k29so416505pfp.13; Tue, 25 Feb 2020 16:00:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=wlz6v+FrMAjVAOr4InYype6tZALQazUguEcJOo0UY8E=; b=s2gmei8/WwIIs5IlannCw3x2M+NQ/6+peMPGF/krAwZUcF59QFwRE8XAJjEsoBj+vt dUG6D2+d5ckDHctODhv4KVu2Wu0CksMYQn94Y3Priog5BmtdM4x7OCkXy3HUq9FaoIPn C/D9GpDAxq8+qQfzfUW4PEZXPC1oqiZFRXT6SwQPKvfMaJLodnO/N9zUN399ys8Mrmec n/FBeuLuXHuNfEReAA/J/Clp2pdQ7IyKV7cR4az++zrLAfnMZ7yauRrCI/kK0KZg7G1F xkRnh/sf0hZODwkRmzXsRWxPAndsi2f5sMFD4N8Scbznjc2YKtt3e0CTV8MkgnsA3ZcU lJuQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=wlz6v+FrMAjVAOr4InYype6tZALQazUguEcJOo0UY8E=; b=oatQFUDMjM+hMH/N1cGIIkfaTGKfFAJRkhFWA2OPq+m30EdQGEABLiSqybDsmF1Lr4 MQRP3ZciL98aBJTdUaIM+OAkZd652zYvs7MmM2nHoI1MXHMzwLVtsV401KHSlilBXIYd k9c3Nz6zjWY0kS90CMZGO1AF0oGefYsiMYwEX4JNINhEGLdRetkm0mAjyhI4gzGo9RxR yMmXpJLI6q+3bLLBbG6UxNbLwiY4DO4BZ9BtqT25CL0xftW/L9Ekr5uCfkjWpgl8g5tF I9N1JDtxvjRk2o0sMSmBJMx7kprWgVqO9DAhyY9DVj8bPEQbjA2eYFsxcBZO3LK6NNBC 4fdA== X-Gm-Message-State: APjAAAWhScgmiJ+4o5Uv7WDQUqAiK/lTXwxern8IEbcjsgSFtMa6vZuN XHvRnomuNmgQmvOw7/+OP4+CVKOaELU= X-Google-Smtp-Source: APXvYqxofMwp/tnn0sWFd829bk+CmOoq4LHEP23xYRbIP/goX2aTIlJYwWx0D2HvSdWGaxJrEZwwuA== X-Received: by 2002:a63:3c4b:: with SMTP id i11mr984654pgn.123.1582675221690; Tue, 25 Feb 2020 16:00:21 -0800 (PST) Received: from [192.168.0.104] ([76.126.242.154]) by smtp.gmail.com with ESMTPSA id d69sm221807pfd.72.2020.02.25.16.00.20 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 25 Feb 2020 16:00:20 -0800 (PST) Content-Type: multipart/alternative; boundary=Apple-Mail-FD4A8BB7-8FBE-4DEC-BDEA-F86C7634EE02 Content-Transfer-Encoding: 7bit From: Brian Weis Mime-Version: 1.0 (1.0) Date: Tue, 25 Feb 2020 16:00:18 -0800 Message-Id: References: Cc: secdir@ietf.org, IETF ALTO , draft-ietf-alto-cost-calendar.all@ietf.org, last-call@ietf.org In-Reply-To: To: "Y. Richard Yang" X-Mailer: iPhone Mail (17C54) Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-alto-cost-calendar-17 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Feb 2020 00:00:24 -0000 --Apple-Mail-FD4A8BB7-8FBE-4DEC-BDEA-F86C7634EE02 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Richard, The new text looks great to me. Thanks, Brian > On Feb 25, 2020, at 3:23 PM, Y. Richard Yang wrote: >=20 > =EF=BB=BF > Dear Brian, >=20 > Thank you so much for the review. Please see inline below. >=20 >> On Tue, Feb 25, 2020 at 12:56 AM Brian Weis via Datatracker wrote: >> Reviewer: Brian Weis >> Review result: Ready >>=20 >> I have reviewed this document as part of the security directorate's >> ongoing effort to review all IETF documents being processed by the IESG. >> These comments were written primarily for the benefit of the security >> area directors. Document editors and WG chairs should treat these >> comments just like any other last call comments. >>=20 >> This document defines the ALTO Cost Calendar, an extension to the base >> Application-Layer Traffic Optimization (ALTO) protocol. Currently, the >> ALTO cost information service provides applications with guidance about >> current costs of a desired resource, but not for resources with a cost th= at >> changes dramatically over time. The ALTO Cost Calendar allows for >> specifying costs for varying time periods in the future. >>=20 >> The extensions in this document are to the existing network flows, with >> policy defined in JSON. As such, additional security considerations are >> few. The well-written Security Considerations document does define a few >> considerations that come from announcing events that are expected to >> happen in the future. >>=20 >> I have only one suggestion for additional text. The second >> paragraph on page 27 (draft -17) describes risks of a client using the >> calendaring information for their own selfish purposes. The suggested >> mitigation in the next paragraph is to limit the information =E2=80=9Cbei= ng >> leaked to malicious clients or third parties=E2=80=9C by authenticating c= lients >> with TLS. This strategy may thwart =E2=80=9Cthird parties=E2=80=9D, but i= t will not help >> in the case of =E2=80=9Cmalicious clients=E2=80=9D possessing valid crede= ntials to >> authenticate. The threat here might be legitimate clients that have >> become subverted by an attacker and are now =E2=80=98bots=E2=80=99 being a= sked to >> participate in a DDoS attack. The calendar information would be valuable >> information for when to persecute a DDoS attack, and this should be >> noted here. >=20 >=20 > This is an excellent point. The compromised-but-still-appear-to-be-legitim= ate=20 > is a quite reasonable setting. We have added the following paragraph, by=20= > borrowing your excellent text above, right after the paragraph=20 > "[RFC8446] specifies TLS 1.3 and writes in its section 1: ..." >=20 > New paragraph: >=20 > The operator should be should be cognizant that the preceding mechanisms= > do not address all security risks. In particular, they will not help in= =20 > the case of =E2=80=9Cmalicious clients=E2=80=9D possessing valid creden= tials to > authenticate. The threat here can be that legitimate clients have > become subverted by an attacker and are now =E2=80=98bots=E2=80=99 bein= g asked to > participate in a DDoS attack. The Calendar information would be valuabl= e > information for when to persecute a DDoS attack. A mechanism such as > a monitoring system that detects abnormal behaviors may still be needed= ." >=20 > How does it look? >=20 > Thanks a lot, > Richard >=20 >=20 >=20 >=20 --Apple-Mail-FD4A8BB7-8FBE-4DEC-BDEA-F86C7634EE02 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Richard,

The new text= looks great to me.

Thanks,
Brian

On Feb 25, 2020, at 3:23 PM, Y. Richard Y= ang <yry@cs.yale.edu> wrote:

=EF=BB=BF
Dear B= rian,

Thank you so much for the review. Please see inline= below.

On Tue, Feb 25, 2020 at 12:56 AM Brian Weis via Datatracker <= noreply@ietf.org> wrote:
Reviewer: Brian Weis
Review result: Ready

I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the IESG.
= These comments were written primarily for the benefit of the security
area directors.  Document editors and WG chairs should treat these
comments just like any other last call comments.

This document defines the ALTO Cost Calendar, an extension to the base
Application-Layer Traffic Optimization (ALTO) protocol. Currently, the
ALTO cost information service provides applications with guidance about
current costs of a desired resource, but not for resources with a cost that<= br> changes dramatically over time. The ALTO Cost Calendar allows for
specifying costs for varying time periods in the future.

The extensions in this document are to the existing network flows, with
policy defined in JSON. As such, additional security considerations are
few. The well-written Security Considerations document does define a few
= considerations that come from announcing events that are expected to
happen in the future.

I have only one suggestion for additional text. The second
paragraph on page 27 (draft -17) describes risks of a client using the
calendaring information for their own selfish purposes. The suggested
mitigation in the next paragraph is to limit the information =E2=80=9Cbeing<= br> leaked to malicious clients or third parties=E2=80=9C by authenticating clie= nts
with TLS. This strategy may thwart =E2=80=9Cthird parties=E2=80=9D, but it w= ill not help
in the case of =E2=80=9Cmalicious clients=E2=80=9D possessing valid credenti= als to
authenticate. The threat here might be legitimate clients that have
become subverted by an attacker and are now =E2=80=98bots=E2=80=99 being ask= ed to
participate in a DDoS attack. The calendar information would be valuable
= information for when to persecute a DDoS attack, and this should be
noted here.

This is an excellent point. The compromise= d-but-still-appear-to-be-legitimate
is a quite reasonable setting. We ha= ve added the following paragraph, by
borrowing your excellent text above= , right after the paragraph
"[RFC8446] specifies TLS 1.3 and writes in i= ts section 1: ..."

New paragraph:

  The opera= tor should be should be cognizant that the preceding mechanisms
  &n= bsp;do not address all security risks. In particular, they will not help in <= br>   the case of =E2=80=9Cmalicious clients=E2=80=9D possessing v= alid credentials to
   authenticate. The threat here can be tha= t legitimate clients have
   become subverted by an attacker an= d are now =E2=80=98bots=E2=80=99 being asked to
   participate i= n a DDoS attack. The Calendar information would be valuable
   = information for when to persecute a DDoS attack. A mechanism such as
&nbs= p;  a monitoring system that detects abnormal behaviors may still be ne= eded."

How does it look?

T= hanks a lot,
Richard




= --Apple-Mail-FD4A8BB7-8FBE-4DEC-BDEA-F86C7634EE02-- From nobody Tue Feb 25 16:13:45 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C61E83A0940; Tue, 25 Feb 2020 16:13:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.398 X-Spam-Level: X-Spam-Status: No, score=-1.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, 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 KV0P82GabEKC; Tue, 25 Feb 2020 16:13:42 -0800 (PST) Received: from mail-vs1-f52.google.com (mail-vs1-f52.google.com [209.85.217.52]) (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 D81273A093D; Tue, 25 Feb 2020 16:13:41 -0800 (PST) Received: by mail-vs1-f52.google.com with SMTP id x18so687209vsq.4; Tue, 25 Feb 2020 16:13:41 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=LFogasuhqWj0IbuyTGlLUQQRhfZ0D4pju2pz7HvMAzw=; b=R+3WWTp7XJvDCbZP+2gCoN1rjoIDMW+MyVVZZ+5TOyg6+zOLpVYJdNMCyLxgzzwYIx KfRt1QKd6PU8Aqrz6ENnsSS1QrwW8PE9NUVQXdaZkyw0NUDzJbw3oI9c/7aFRDX4f5Zb XlpyWCpfs65DycSTV52ZAiQL6h0vt7KceEFFJyIP+5k3xdhF7t7OYAWvUK4vfiBsxOfi 5fPOgy7dJwjVyjafa+Ij41mhazguoWnjv7gAoJ8f2GjhtTNxvF55dipBPm/nxhpa9ekN tSO6fwYadRVSkWDTsbo82+ePqAVcjnt2F1g8tvN7WUs6+s1jMFdeOg47CocEDIbXnv79 Jvbw== X-Gm-Message-State: APjAAAVj19QAqHlKq1YffAFou5xr5Cvx5b20wQu7vYoOKTUTuj2pnmsT fNoPk1g+w1LPNjvTrkvez6AzhFkzpbkqqkBStyo= X-Google-Smtp-Source: APXvYqwc9P0ldu739gMb7axu9HA4xsm87ut/1rOmBrQrZzjUl33cf5sAuTqte8xjJmEwGumLPBMbeVwGLAt7y0yzN+I= X-Received: by 2002:a67:ef03:: with SMTP id j3mr1713786vsr.102.1582676020850; Tue, 25 Feb 2020 16:13:40 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: "Y. Richard Yang" Date: Tue, 25 Feb 2020 19:13:29 -0500 Message-ID: To: Brian Weis Cc: secdir@ietf.org, IETF ALTO , draft-ietf-alto-cost-calendar.all@ietf.org, last-call@ietf.org Content-Type: multipart/alternative; boundary="00000000000004730e059f6f7a61" Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-alto-cost-calendar-17 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Feb 2020 00:13:44 -0000 --00000000000004730e059f6f7a61 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Dear Brian, This is great. We will include the paragraph when we upload the new version soon. Thank you so much! Richard On Tue, Feb 25, 2020 at 7:00 PM Brian Weis wrote: > Hi Richard, > > The new text looks great to me. > > Thanks, > Brian > > On Feb 25, 2020, at 3:23 PM, Y. Richard Yang wrote: > > =EF=BB=BF > Dear Brian, > > Thank you so much for the review. Please see inline below. > > On Tue, Feb 25, 2020 at 12:56 AM Brian Weis via Datatracker < > noreply@ietf.org> wrote: > >> Reviewer: Brian Weis >> Review result: Ready >> >> I have reviewed this document as part of the security directorate's >> ongoing effort to review all IETF documents being processed by the IESG. >> These comments were written primarily for the benefit of the security >> area directors. Document editors and WG chairs should treat these >> comments just like any other last call comments. >> >> This document defines the ALTO Cost Calendar, an extension to the base >> Application-Layer Traffic Optimization (ALTO) protocol. Currently, the >> ALTO cost information service provides applications with guidance about >> current costs of a desired resource, but not for resources with a cost >> that >> changes dramatically over time. The ALTO Cost Calendar allows for >> specifying costs for varying time periods in the future. >> >> The extensions in this document are to the existing network flows, with >> policy defined in JSON. As such, additional security considerations are >> few. The well-written Security Considerations document does define a few >> considerations that come from announcing events that are expected to >> happen in the future. >> >> I have only one suggestion for additional text. The second >> paragraph on page 27 (draft -17) describes risks of a client using the >> calendaring information for their own selfish purposes. The suggested >> mitigation in the next paragraph is to limit the information =E2=80=9Cbe= ing >> leaked to malicious clients or third parties=E2=80=9C by authenticating = clients >> with TLS. This strategy may thwart =E2=80=9Cthird parties=E2=80=9D, but = it will not help >> in the case of =E2=80=9Cmalicious clients=E2=80=9D possessing valid cred= entials to >> authenticate. The threat here might be legitimate clients that have >> become subverted by an attacker and are now =E2=80=98bots=E2=80=99 being= asked to >> participate in a DDoS attack. The calendar information would be valuable >> information for when to persecute a DDoS attack, and this should be >> noted here. >> > > This is an excellent point. The > compromised-but-still-appear-to-be-legitimate > is a quite reasonable setting. We have added the following paragraph, by > borrowing your excellent text above, right after the paragraph > "[RFC8446] specifies TLS 1.3 and writes in its section 1: ..." > > New paragraph: > > The operator should be should be cognizant that the preceding mechanism= s > do not address all security risks. In particular, they will not help i= n > the case of =E2=80=9Cmalicious clients=E2=80=9D possessing valid crede= ntials to > authenticate. The threat here can be that legitimate clients have > become subverted by an attacker and are now =E2=80=98bots=E2=80=99 bei= ng asked to > participate in a DDoS attack. The Calendar information would be valuab= le > information for when to persecute a DDoS attack. A mechanism such as > a monitoring system that detects abnormal behaviors may still be > needed." > > How does it look? > > Thanks a lot, > Richard > > > > > --=20 --=20 =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 | Y. Richard Yang | | Professor of Computer Science | | http://www.cs.yale.edu/~yry/ | =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 --00000000000004730e059f6f7a61 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear Brian,

This is great. We will incl= ude the paragraph when we upload the new version soon.

T= hank=C2=A0you so much!
Richard

On Tue, Feb 25, 2020 at= 7:00 PM Brian Weis <bew.stds@gmai= l.com> wrote:
Hi Richard,

The new text looks gr= eat to me.

Thanks,
Brian
<= br>
On Feb 25, 2020, at 3:23 PM, Y. Richard Yang &= lt;yry@cs.yale.edu= > wrote:

=EF=BB=BF
Dear Brian,

=
Thank you so much for the review. Please see inline below.
=
On Tue= , Feb 25, 2020 at 12:56 AM Brian Weis via Datatracker <noreply@ietf.org> wrote:
Reviewer: Brian Weis Review result: Ready

I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security
area directors.=C2=A0 Document editors and WG chairs should treat these
comments just like any other last call comments.

This document defines the ALTO Cost Calendar, an extension to the base
Application-Layer Traffic Optimization (ALTO) protocol. Currently, the
ALTO cost information service provides applications with guidance about
current costs of a desired resource, but not for resources with a cost that=
changes dramatically over time. The ALTO Cost Calendar allows for
specifying costs for varying time periods in the future.

The extensions in this document are to the existing network flows, with
policy defined in JSON. As such, additional security considerations are
few. The well-written Security Considerations document does define a few considerations that come from announcing events that are expected to
happen in the future.

I have only one suggestion for additional text. The second
paragraph on page 27 (draft -17) describes risks of a client using the
calendaring information for their own selfish purposes. The suggested
mitigation in the next paragraph is to limit the information =E2=80=9Cbeing=
leaked to malicious clients or third parties=E2=80=9C by authenticating cli= ents
with TLS. This strategy may thwart =E2=80=9Cthird parties=E2=80=9D, but it = will not help
in the case of =E2=80=9Cmalicious clients=E2=80=9D possessing valid credent= ials to
authenticate. The threat here might be legitimate clients that have
become subverted by an attacker and are now =E2=80=98bots=E2=80=99 being as= ked to
participate in a DDoS attack. The calendar information would be valuable information for when to persecute a DDoS attack, and this should be
noted here.

This is an excellent point. The compromis= ed-but-still-appear-to-be-legitimate
is a quite reasonable setting. We = have added the following paragraph, by
borrowing your excellent text ab= ove, right after the paragraph
"[RFC8446] specifies TLS 1.3 and wr= ites in its section 1: ..."

New paragraph:

= =C2=A0 The operator should be should be cognizant that the preceding mechan= isms
=C2=A0 =C2=A0do not address all security risks. In particular, they= will not help in
=C2=A0 =C2=A0the case of =E2=80=9Cmalicious clients= =E2=80=9D possessing valid credentials to
=C2=A0 =C2=A0authenticate. The= threat here can be that legitimate clients have
=C2=A0 =C2=A0become sub= verted by an attacker and are now =E2=80=98bots=E2=80=99 being asked to
= =C2=A0 =C2=A0participate in a DDoS attack. The Calendar information would b= e valuable
=C2=A0 =C2=A0information for when to persecute a DDoS attack.= A mechanism such as
=C2=A0 =C2=A0a monitoring system that detects abnor= mal behaviors may still be needed."

How does = it look?

Thanks a lot,
Richard




--
=
--=C2=A0
=C2=A0=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=
| Y. Richard Yang &= lt;yry@cs.yale.edu= > =C2=A0 |
| Prof= essor of Computer Science =C2=A0 =C2=A0 =C2=A0 |
| http://www.cs.yale.edu/~yry/ =C2=A0 =C2=A0 =C2=A0 =C2=A0= |
=C2=A0=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
--00000000000004730e059f6f7a61-- From nobody Wed Feb 26 08:11:42 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03C373A0A06; Wed, 26 Feb 2020 08:11:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.572 X-Spam-Level: X-Spam-Status: No, score=-0.572 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, T_SPF_HELO_TEMPERROR=0.01, URIBL_BLOCKED=0.001, URIBL_RHS_DOB=1.514] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmail.fm header.b=QBL833F+; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=Db2qVIgV 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 VMpVTer4-jSe; Wed, 26 Feb 2020 08:11:07 -0800 (PST) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F9DD3A09ED; Wed, 26 Feb 2020 08:08:04 -0800 (PST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 430E92209B; Wed, 26 Feb 2020 11:07:56 -0500 (EST) Received: from imap21 ([10.202.2.71]) by compute7.internal (MEProxy); Wed, 26 Feb 2020 11:07:56 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.fm; h= mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type; s=fm2; bh=0JD1ow8X1xWreAF1uoZzjUUhOPM0mTu FGQqU+2b2l6I=; b=QBL833F+dKSdLrdgdhXuf9oU0g9JiENoM1WwVPo7wmGIFBE KVBprR/DDIokxkL9y5q+iOjtrjmqW3f0Cyh/l4PQ3xQG7wWHIZCiEEKW/2QJwALK YgTcUPNtWWhPnNPR9qDLLd+7xLEYbNZKfXjDgV5CNtYmR7TTICiQlgbuRAcSK+FT lpsYMcEQvktz2DhuJpazOu2qvRy9IDC4XLX7jtkch8u67KZOXK9e1rbMdVqkYRpj HLd9OkWzQ01Hiht+gp2m4xnHxgGo6tzxqWCNR8sCejJDRhKgJ+/EUmLjHfSL+rio /gNub0rhudJwrNg4pVOcB2017Dxr2q2gTXUFaQg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=0JD1ow 8X1xWreAF1uoZzjUUhOPM0mTuFGQqU+2b2l6I=; b=Db2qVIgVby5LHHPGxi6dh2 ysrXPKYzQmwNo6hU1Ym24OW+sxiLXlTgjhskUSiyQgfR81jnRu85emDj1Odk/cCo Ku4XmozUQeQyBmwSQTM+5q6YMH/1M4b9JHf8yM2XYcwFotGHq4xDvkiH4kpURtVU GMiH3Hm8vZ/xBMozCdhg/ueIbhAVCqYed5OUwD92nruFQ1cS8K7cJcf2NCi/eE6Q 4aVFy2tCzFlSPWJ0BFg6GvXyqiVJFLhsOJ+CZ78y7Q8vtyCm16K7fyBTilYnKF9K L+8t/h/xPKqXohTRIP+VqVdqMmGIUTb44qccCyN72xQ/BUmkzeuGMuqIfIueFjCQ == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedugedrleeggdekiecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefofgggkfgjfhffhffvufgtsegrtderreerreejnecuhfhrohhmpedftehlvgig vgihucfovghlnhhikhhovhdfuceorggrmhgvlhhnihhkohhvsehfrghsthhmrghilhdrfh hmqeenucffohhmrghinhepihgvthhfrdhorhhgnecuvehluhhsthgvrhfuihiivgeptden ucfrrghrrghmpehmrghilhhfrhhomheprggrmhgvlhhnihhkohhvsehfrghsthhmrghilh drfhhm X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id BC7D966006E; Wed, 26 Feb 2020 11:07:55 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.7-947-gbed3ff6-fmstable-20200220v2 Mime-Version: 1.0 Message-Id: <5bd3c981-d3fe-4798-a439-47bd0907b1f1@www.fastmail.com> In-Reply-To: References: Date: Wed, 26 Feb 2020 16:07:27 +0000 From: "Alexey Melnikov" To: "Joe Touch" , secdir@ietf.org, "gen-art@ietf.org" , "tsv-art@ietf.org" Content-Type: multipart/alternative; boundary=ce76362824624613b4b79589e0b72446 Archived-At: Subject: Re: [secdir] =?utf-8?q?=5BGen-art=5D_Fwd=3A_CALL_to_revoke_last_call?= =?utf-8?q?=3A_Re=3A_=5Btsvwg=5D_Request_for_working_group_feedback_on_dra?= =?utf-8?q?ft-kuehlewind-system-ports_=286th_March=2C_2020=29?= X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Feb 2020 16:11:22 -0000 --ce76362824624613b4b79589e0b72446 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Joe, I discussed this document with TSV ADs and here is what is going to happ= en next: 1) IETF LC on this document will run to the end (i.e. will not be cancel= led), so that we can collect more information from people about what the= y want and don't want IESG to do. This includes comments from TSVWG mail= ing list and port experts. Once the IETF LC is finished, the draft will need to be revised to refle= ct this feedback. I will not have this document in IESG review before th= e Vancouver IETF, as it is clear at this point that some suggested actio= ns in this draft are controversial and/or not worded clearly enough. Another Transport Area AD will take over shepherding of the document aft= er the Vancouver IETF. 2) IESG and IANA will create a list of RFC references that should be add= ed to registered system ports. No action will be taken without consultin= g IETF community. 3) IESG might also ask IANA to contact existing change controllers for e= xisting system port registrations in order to see if current contact det= ails are accurate. Best Regards, Alexey On Mon, Feb 17, 2020, at 11:09 PM, Joe Touch wrote: > FYI to the ARTs involved. > Discussion appears to at least be started in TSVWG finally, but claimi= ng this first-call as "last call" is ridiculous. > Joe >=20 > -------- Forwarded Message -------- > Subject: > CALL to revoke last call: Re: [tsvwg] Request for working group feedba= ck on draft-kuehlewind-system-ports (6th March, 2020) > Date: > Mon, 17 Feb 2020 15:06:40 -0800 > From: > Joe Touch > To: > Gorry Fairhurst , tsvwg@ietf.org >=20 >=20 > I object on process grounds at a minimum and call for its "last calls"= to be revoked by the sponsoring AD and WG chair as follows: >=20 > 1) this doc went to "IETF last call" (according to the doc tracker) wi= thout ever being announced on the IETF-wide last call list >=20 > 2) this doc went to "last call" both there and (via this announcement)= here without ever being posted for open discussion on any IETF list >=20 > - it is my understanding that first call !=3D last call >=20 > 3) this doc falls clearly within the purview of TSVWG, as it *should* = be handled similar to RFCs 6335 and 7605; it should have been submitted = for WG consideration FIRST - before being posted even for LC. >=20 > The fact that this doc is being rushed through as an individual submis= sion by the transport AD as sponsored by another AD of the IESG is highl= y suspicious and IMO inappropriate. >=20 > Regarding content, I've already provided feedback, including the above= , that has been largely ignored since mid-Dec privately by author and IE= SG ADs alike. >=20 > To repeat: the authors need to DO THEIR HOMEWORK as follows: >=20 > - correct the errors >=20 > - RFC 6335 defines reassignment and the appeals process, in contrast = to the claims of this doc, including when a party is no longer reachable= (the IESG or IAB appeal would decide how to proceed) >=20 > - RFC 6335 also explains the process for deassignment, which is much = more involved than described here >=20 > - if this doc is intended to update RFC 6335, it should say so AND BE= A TSVWG adopted item, not merely an individual submission >=20 > - show an empirical need for dealing with standards-track ports in bul= k rather than on a per-issue basis >=20 > - especially given at least some of the issues in this doc, such as "= orphaned" ports (whose contact is no longer reachable), represent an ong= oing problem that cannot be corrected by a single pass >=20 > - provide a COMPLETE list of the impacted standards-track ports not al= ready assigned to the IESG, *including* those in the user ports space (n= ot merely system, which RFC 7605 already suggests not treating as privil= eged anyway) >=20 > - NOT attempt to "reclaim unused" system ports, for several reasons: >=20 > a) see the hazards of deassignment per RFC 6335 >=20 > b) see the recommendation to not treat system ports as privileged and= thus there would be no utility in focusing on reclaiming entries from t= hat range >=20 > - limit the scope of this doc to those such ports, rather than implyin= g the IESG will be "reclaiming" the entire system ports space (including= rewriting the title and abstract) >=20 > - NOT attempt to subvert the appeals process for port reassignment as = per RFC6335 >=20 > - NOT attempt to subvert the WG process by submitting this as "individ= ual" >=20 > Joe >=20 > On 2/17/2020 12:15 AM, Gorry Fairhurst wrote: >=20 >> This is notice to request for working group feedback on =E2=80=9CReas= signment of System Ports to the IESG=E2=80=9D, to conclude 6th March, 20= 20. Please review this document and send comments to the list (or respon= d to the concurrent IETF LC). >>=20 >> The draft proposes a process where System Ports can be reassigned to = the IESG. This would enable the current assignee in the IANA ports regis= try to be replaced under some conditions. >>=20 >> https://www.ietf.org/id/draft-kuehlewind-system-ports >>=20 >> Although this is not a working group document, I'm expecting some peo= ple in TSVWG to have expertise to review this draft based on RFC 6335 (w= as draft-ietf-tsvwg-iana-ports), which described Internet Assigned Numbe= rs Authority (IANA) Procedures for the Management of the Service Name an= d Transport Protocol Port Number Registry. >>=20 >> -- Gorry Fairhurst >> TSVWG co-chair >>=20 > _______________________________________________ > Gen-art mailing list > Gen-art@ietf.org > https://www.ietf.org/mailman/listinfo/gen-art >=20 --ce76362824624613b4b79589e0b72446 Content-Type: text/html;charset=utf-8 Content-Transfer-Encoding: quoted-printable
Hi Joe,

I discussed this document with TSV ADs and he= re is what is going to happen next:

1) = ;IETF LC on this document will run to the end (i.e. will not be cancelle= d), so that we can collect more information from people about what they = want and don't want IESG to do. This includes comments from TSVWG mailin= g list and port experts.

Once the IETF LC i= s finished, the draft will need to be revised to reflect this feedback. = I will not have this document in IESG review before the Vancouver IETF, = as it is clear at this point that some suggested actions in this draft a= re controversial and/or not worded clearly enough.

Another Transport Area AD will take over shepherding of the docu= ment after the Vancouver IETF.

2) IESG and = IANA will create a list of RFC references that should be added to regist= ered system ports. No action will be taken without consulting IETF commu= nity.

3) IESG might also ask IANA to contac= t existing change controllers for existing system port registrations in = order to see if current contact details are accurate.

=
Best Regards,
Alexey

On Mon, Feb 17, 2020, at 11:09 PM, Joe Touch wrote:

FYI to the ARTs involved.

Discu= ssion appears to at least be started in TSVWG finally, but claiming this first-call as "last call" is ridiculous.

J= oe


--= ------ Forwarded Message --------
<= tr>=
Subject:CALL to revoke last call: Re: [tsvwg] Request for working group feedback on draft-kuehlewind-system-ports (6th March, 2020)
Date:
Mon, 17 Feb 2020 15= :06:40 -0800
From:
Joe Touch <touch@strayalpha.com&= gt;
To:
Gorry Fairhurst <gorry@erg.abdn.ac.uk&g= t;, tsvwg@ietf.org <tsvwg@ietf.org>


I object on process grounds a= t a minimum and call for its "last calls" to be revoked by the sponsoring AD and WG chair as follows:=

1) this doc went to "IETF last call" (acco= rding to the doc tracker) without ever being announced on the IETF-wide last call list

2) this doc went to "last call" = both there and (via this announcement) here without ever being posted for open discussion on any IETF list

    -= it is my understanding that first call !=3D last call
3) this doc falls clearly within the purview of TSVWG, as it= *should* be handled similar to RFCs 6335 and 7605; it should have been submitted for WG consideration FIRST - before being posted even for LC.

The fact that this doc i= s being rushed through as an individual submission by the transport AD as sponsored by another AD of the IESG is highly suspicious and IMO inappropriate.
Regarding content, I've already provided feedback, including= the above, that has been largely ignored since mid-Dec privately by author and IESG ADs alike.

To repeat:= the authors need to DO THEIR HOMEWORK as follows:

- correct the errors

  &n= bsp; - RFC 6335 defines reassignment and the appeals process, in contrast to the claims of this doc, including when a party is no longer reachable (the IESG or IAB appeal would decide how to proceed)

    - RFC 633= 5 also explains the process for deassignment, which is much more involved than described here

=
    - if this doc is intended to update RFC 6335, it= should say so AND BE A TSVWG adopted item, not merely an individual submission

- show an empirical need for dealing with st= andards-track ports in bulk rather than on a per-issue basis

    - especially given at least some of the issues in th= is doc, such as "orphaned" ports (whose contact is no longer reachable), represent an ongoing problem that cannot be corrected  by a s= ingle pass

- provide a COMPLETE list of the= impacted standards-track ports not already assigned to the IESG, *including* those in the user ports space (not merely system, which RFC 7605 already suggests not treating as privileged anyway)

- = NOT attempt to "reclaim unused" system ports, for several reasons:

    a) see th= e hazards of deassignment per RFC 6335

&nbs= p;   b) see the recommendation to not treat system ports as privileged and thus there would be no utility in focusing on reclaiming entries from that range

- = limit the scope of this doc to those such ports, rather than implying the IESG will be "reclaiming" the entire system ports space (including rewriting the title and abstract)
<= br>
- NOT attempt to subvert the appeals process for port reas= signment as per RFC6335

- NOT attempt to subve= rt the WG process by submitting this as "individual"

Joe

On 2/17/2020 12:15 AM, Gorry Fairhurst wrote:
This is notice to request for work= ing group feedback on =E2=80=9CReassignment of System Ports to the I= ESG=E2=80=9D, to conclude 6th March, 2020. Please review this document and send comments to the list (or respond to the concurrent IETF LC).
=

The draft proposes a process where System Port= s can be reassigned to the IESG. This would enable the current assignee in the IANA ports registry to be replaced under some conditions.=


Although this is not a working group document, I'm expecting some people in TSVWG to have expertise to review this draft based on RFC 6335 (was draft-ietf-tsvwg-iana-ports), which described Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry.

-- Gorry Fair= hurst
TSVWG co-chair

=
_______________________________________________
Gen-art mailing list
Gen-art@ietf.org
https= ://www.ietf.org/mailman/listinfo/gen-art


--ce76362824624613b4b79589e0b72446-- From nobody Wed Feb 26 15:20:22 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F4213A0A3A; Wed, 26 Feb 2020 15:20:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.318 X-Spam-Level: X-Spam-Status: No, score=-1.318 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.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 xaxEnrpEtkXT; Wed, 26 Feb 2020 15:20:10 -0800 (PST) Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (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 4C90A3A0A37; Wed, 26 Feb 2020 15:20:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id:Cc:Date:In-Reply-To: From:Subject:Mime-Version:Content-Type:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=dEu8VYijDRqOZIJTkegmIpEq37e3MzxoX+46kI2RxDE=; b=hCKQfnZaCML08hCSS8YrIR0BF S4GlG3JrjrGD2xGf/2rek/OMv5Z2d7WZjviZOg/K1e5X9V7pHlYXhw066bNm4ir3YKiNOghYz1faJ qhsSmz7Ch9bvbvHyehEmSDg39D4R748QoukAPT4v+pcN3cO2sGe+HRIo2l1xR/2CitWiyc5rlWgWl Zf8JdxsvaBLIGsqgZjAFyZe5WSmSdTz67GWKDc7A2ZkxvNNr2u5hKL2oItD5rxdzJBasd/UGPs1c1 M+uMOCnTgBrkmvBtsl0QxmoXZAQtaZTXm5MAklg08qKCoNUy7o0u0NiFuiGmOIplarNLM9vGp32yb hoNOsrxbg==; Received: from [38.64.80.138] (port=55184 helo=[172.21.13.151]) by server217.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92) (envelope-from ) id 1j75yH-000ywt-Hb; Wed, 26 Feb 2020 18:20:10 -0500 Content-Type: multipart/alternative; boundary="Apple-Mail=_CC9F832D-AD0D-4061-8029-6A255E977CC2" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Joseph Touch In-Reply-To: <5bd3c981-d3fe-4798-a439-47bd0907b1f1@www.fastmail.com> Date: Wed, 26 Feb 2020 15:20:04 -0800 Cc: secdir@ietf.org, "gen-art@ietf.org" , "tsv-art@ietf.org" Message-Id: <0A1CCE3D-D9BE-423C-A68B-E12D1A3C76F9@strayalpha.com> References: <5bd3c981-d3fe-4798-a439-47bd0907b1f1@www.fastmail.com> To: Alexey Melnikov X-Mailer: Apple Mail (2.3445.9.1) X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server217.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - strayalpha.com X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [secdir] [Gen-art] CALL to revoke last call: Re: [tsvwg] Request for working group feedback on draft-kuehlewind-system-ports (6th March, 2020) X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Feb 2020 23:20:13 -0000 --Apple-Mail=_CC9F832D-AD0D-4061-8029-6A255E977CC2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, Alexey, Thanks for letting me know. Joe > On Feb 26, 2020, at 8:07 AM, Alexey Melnikov = wrote: >=20 > Hi Joe, >=20 > I discussed this document with TSV ADs and here is what is going to = happen next: >=20 > 1) IETF LC on this document will run to the end (i.e. will not be = cancelled), so that we can collect more information from people about = what they want and don't want IESG to do. This includes comments from = TSVWG mailing list and port experts. >=20 > Once the IETF LC is finished, the draft will need to be revised to = reflect this feedback. I will not have this document in IESG review = before the Vancouver IETF, as it is clear at this point that some = suggested actions in this draft are controversial and/or not worded = clearly enough. >=20 > Another Transport Area AD will take over shepherding of the document = after the Vancouver IETF. >=20 > 2) IESG and IANA will create a list of RFC references that should be = added to registered system ports. No action will be taken without = consulting IETF community. >=20 > 3) IESG might also ask IANA to contact existing change controllers for = existing system port registrations in order to see if current contact = details are accurate. >=20 > Best Regards, > Alexey >=20 > On Mon, Feb 17, 2020, at 11:09 PM, Joe Touch wrote: >> FYI to the ARTs involved. >>=20 >> Discussion appears to at least be started in TSVWG finally, but = claiming this first-call as "last call" is ridiculous. >>=20 >> Joe >>=20 >>=20 >> -------- Forwarded Message -------- >> Subject: >> CALL to revoke last call: Re: [tsvwg] Request for working group = feedback on draft-kuehlewind-system-ports (6th March, 2020) >> Date: >> Mon, 17 Feb 2020 15:06:40 -0800 >> From: >> Joe Touch >> To: >> Gorry Fairhurst , = tsvwg@ietf.org = >>=20 >>=20 >> I object on process grounds at a minimum and call for its "last = calls" to be revoked by the sponsoring AD and WG chair as follows: >>=20 >> 1) this doc went to "IETF last call" (according to the doc tracker) = without ever being announced on the IETF-wide last call list >>=20 >> 2) this doc went to "last call" both there and (via this = announcement) here without ever being posted for open discussion on any = IETF list >>=20 >> - it is my understanding that first call !=3D last call >>=20 >> 3) this doc falls clearly within the purview of TSVWG, as it *should* = be handled similar to RFCs 6335 and 7605; it should have been submitted = for WG consideration FIRST - before being posted even for LC. >>=20 >> The fact that this doc is being rushed through as an individual = submission by the transport AD as sponsored by another AD of the IESG is = highly suspicious and IMO inappropriate. >>=20 >> Regarding content, I've already provided feedback, including the = above, that has been largely ignored since mid-Dec privately by author = and IESG ADs alike. >>=20 >> To repeat: the authors need to DO THEIR HOMEWORK as follows: >>=20 >> - correct the errors >>=20 >> - RFC 6335 defines reassignment and the appeals process, in = contrast to the claims of this doc, including when a party is no longer = reachable (the IESG or IAB appeal would decide how to proceed) >>=20 >> - RFC 6335 also explains the process for deassignment, which is = much more involved than described here >>=20 >> - if this doc is intended to update RFC 6335, it should say so = AND BE A TSVWG adopted item, not merely an individual submission >>=20 >> - show an empirical need for dealing with standards-track ports in = bulk rather than on a per-issue basis >>=20 >> - especially given at least some of the issues in this doc, such = as "orphaned" ports (whose contact is no longer reachable), represent an = ongoing problem that cannot be corrected by a single pass >>=20 >> - provide a COMPLETE list of the impacted standards-track ports not = already assigned to the IESG, *including* those in the user ports space = (not merely system, which RFC 7605 already suggests not treating as = privileged anyway) >>=20 >> - NOT attempt to "reclaim unused" system ports, for several reasons: >>=20 >> a) see the hazards of deassignment per RFC 6335 >>=20 >> b) see the recommendation to not treat system ports as privileged = and thus there would be no utility in focusing on reclaiming entries = from that range >>=20 >> - limit the scope of this doc to those such ports, rather than = implying the IESG will be "reclaiming" the entire system ports space = (including rewriting the title and abstract) >>=20 >> - NOT attempt to subvert the appeals process for port reassignment as = per RFC6335 >>=20 >> - NOT attempt to subvert the WG process by submitting this as = "individual" >>=20 >> Joe >>=20 >> On 2/17/2020 12:15 AM, Gorry Fairhurst wrote: >>=20 >>> This is notice to request for working group feedback on = =E2=80=9CReassignment of System Ports to the IESG=E2=80=9D, to conclude = 6th March, 2020. Please review this document and send comments to the = list (or respond to the concurrent IETF LC). >>>=20 >>> The draft proposes a process where System Ports can be reassigned to = the IESG. This would enable the current assignee in the IANA ports = registry to be replaced under some conditions. >>>=20 >>> https://www.ietf.org/id/draft-kuehlewind-system-ports = >>>=20 >>> Although this is not a working group document, I'm expecting some = people in TSVWG to have expertise to review this draft based on RFC 6335 = (was draft-ietf-tsvwg-iana-ports), which described Internet Assigned = Numbers Authority (IANA) Procedures for the Management of the Service = Name and Transport Protocol Port Number Registry. >>>=20 >>> -- Gorry Fairhurst >>> TSVWG co-chair >>>=20 >>=20 >> _______________________________________________ >> Gen-art mailing list >> Gen-art@ietf.org >> https://www.ietf.org/mailman/listinfo/gen-art = --Apple-Mail=_CC9F832D-AD0D-4061-8029-6A255E977CC2 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi, = Alexey,

Thanks for = letting me know.

Joe

On Feb 26, 2020, at 8:07 AM, Alexey Melnikov = <aamelnikov@fastmail.fm> wrote:

Hi = Joe,

I = discussed this document with TSV ADs and here is what is going to happen = next:

1) IETF LC on this document will run to the end (i.e. = will not be cancelled), so that we can collect more information from = people about what they want and don't want IESG to do. This includes = comments from TSVWG mailing list and port experts.

Once the IETF LC is finished, the = draft will need to be revised to reflect this feedback. I will not have = this document in IESG review before the Vancouver IETF, as it is clear = at this point that some suggested actions in this draft are = controversial and/or not worded clearly enough.

Another Transport Area AD will take over shepherding = of the document after the Vancouver IETF.

2) IESG and IANA will create a list of RFC references = that should be added to registered system ports. No action will be taken = without consulting IETF community.

3) IESG might also ask IANA to contact existing change = controllers for existing system port registrations in order to see if = current contact details are accurate.

Best Regards,
Alexey

On = Mon, Feb 17, 2020, at 11:09 PM, Joe Touch wrote:

FYI to the ARTs involved.

Discussion appears to at least be started in TSVWG finally, = but claiming this first-call as "last call" is ridiculous.

Joe


-------- Forwarded Message --------
Subject:
CALL to revoke = last call: Re: [tsvwg] Request for working group feedback on = draft-kuehlewind-system-ports (6th March, 2020)
Date:
Mon, 17 Feb 2020 15:06:40 -0800
From:
Joe Touch <touch@strayalpha.com>
To:
Gorry Fairhurst <gorry@erg.abdn.ac.uk>, tsvwg@ietf.org <tsvwg@ietf.org>


I = object on process grounds at a minimum and call for its "last calls" to = be revoked by the sponsoring AD and WG chair as follows:

1) = this doc went to "IETF last call" (according to the doc tracker) without = ever being announced on the IETF-wide last call list

2) = this doc went to "last call" both there and (via this announcement) here = without ever being posted for open discussion on any IETF list

    - it is my understanding that first call = !=3D last call

3) this doc falls clearly within the = purview of TSVWG, as it *should* be handled similar to RFCs 6335 and = 7605; it should have been submitted for WG consideration FIRST - before = being posted even for LC.

The fact that this doc is being rushed = through as an individual submission by the transport AD as sponsored by = another AD of the IESG is highly suspicious and IMO inappropriate.

Regarding content, I've already provided feedback, including = the above, that has been largely ignored since mid-Dec privately by = author and IESG ADs alike.

To repeat: the authors need to DO THEIR = HOMEWORK as follows:

- correct the errors

    - RFC 6335 defines reassignment and the = appeals process, in contrast to the claims of this doc, including when a = party is no longer reachable (the IESG or IAB appeal would decide how to = proceed)

    - RFC 6335 also explains the process for = deassignment, which is much more involved than described here

    - if this doc is intended to update RFC = 6335, it should say so AND BE A TSVWG adopted item, not merely an = individual submission

- show an empirical need for dealing = with standards-track ports in bulk rather than on a per-issue basis

    - especially given at least some of the = issues in this doc, such as "orphaned" ports (whose contact is no longer = reachable), represent an ongoing problem that cannot be corrected  = by a single pass

- provide a COMPLETE list of the = impacted standards-track ports not already assigned to the IESG, = *including* those in the user ports space (not merely system, which RFC = 7605 already suggests not treating as privileged anyway)

- = NOT attempt to "reclaim unused" system ports, for several reasons:

    a) see the hazards of deassignment per RFC = 6335

    b) see the recommendation to not treat = system ports as privileged and thus there would be no utility in = focusing on reclaiming entries from that range

- limit the scope of = this doc to those such ports, rather than implying the IESG will be = "reclaiming" the entire system ports space (including rewriting the = title and abstract)

- NOT attempt to subvert the appeals = process for port reassignment as per RFC6335

- NOT attempt to subvert = the WG process by submitting this as "individual"

Joe

On = 2/17/2020 12:15 AM, Gorry Fairhurst wrote:

This is notice to request for working group feedback on = =E2=80=9CReassignment of System Ports to the IESG=E2=80=9D, to conclude = 6th March, 2020. Please review this document and send comments to the = list (or respond to the concurrent IETF LC).

The draft proposes a = process where System Ports can be reassigned to the IESG. This would = enable the current assignee in the IANA ports registry to be replaced = under some conditions.

https://www= .ietf.org/id/draft-kuehlewind-system-ports

Although this is not a = working group document, I'm expecting some people in TSVWG to have = expertise to review this draft based on RFC 6335 (was = draft-ietf-tsvwg-iana-ports), which described Internet Assigned Numbers = Authority (IANA) Procedures for the Management of the Service Name and = Transport Protocol Port Number Registry.

-- Gorry Fairhurst
TSVWG co-chair

_______________________________________________
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

= --Apple-Mail=_CC9F832D-AD0D-4061-8029-6A255E977CC2-- From nobody Wed Feb 26 22:50:37 2020 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C9AA33A1336 for ; Wed, 26 Feb 2020 22:50:34 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Tero Kivinen via Datatracker To: X-Test-IDTracker: no X-IETF-IDTracker: 6.118.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: secdir-secretary@mit.edu, Tero Kivinen Message-ID: <158278623474.3382.2006073407217093637.idtracker@ietfa.amsl.com> Date: Wed, 26 Feb 2020 22:50:34 -0800 Archived-At: Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Feb 2020 06:50:35 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview For telechat 2020-03-05 Reviewer LC end Draft Donald Eastlake R2019-11-14 draft-ietf-hip-dex-13 Charlie Kaufman R2019-09-02 draft-ietf-ecrit-data-only-ea-21 Magnus Nystrom 2019-04-10 draft-ietf-avtcore-multiplex-guidelines-11 Vincent Roca R2019-10-14 draft-ietf-dmm-pmipv6-dlif-05 Carl Wallace R2018-02-26 draft-ietf-hip-native-nat-traversal-30 Klaas Wierenga 2020-02-21 draft-ietf-lamps-5480-ku-clarifications-01 For telechat 2020-03-12 Reviewer LC end Draft Dan Harkins 2020-03-06 draft-ietf-alto-incr-update-sse-20 Last calls: Reviewer LC end Draft Derek Atkins 2020-03-03 draft-ietf-git-using-github-04 John Bradley 2020-02-28 draft-ietf-regext-data-escrow-04 Nancy Cam-Winget 2020-02-28 draft-ietf-git-github-wg-configuration-06 Shaun Cooley 2019-11-12 draft-ietf-regext-login-security-10 Alan DeKok 2019-06-04 draft-ietf-netvc-testing-09 Donald Eastlake 2020-02-27 draft-ietf-6tisch-msf-10 Donald Eastlake R2019-11-14 draft-ietf-hip-dex-13 Shawn Emery 2020-03-31 draft-gellens-lost-validation-05 Stephen Farrell 2020-03-10 draft-ietf-tsvwg-datagram-plpmtud-15 Daniel Franke 2020-03-09 draft-ietf-regext-dnrd-objects-mapping-06 Phillip Hallam-Baker 2020-03-09 draft-ietf-calext-jscalendar-25 Steve Hanna 2020-03-06 draft-ietf-ippm-multipoint-alt-mark-06 Dan Harkins 2020-03-06 draft-ietf-alto-incr-update-sse-20 Christian Huitema 2020-02-28 draft-ietf-tcpm-converters-16 Leif Johansson 2020-02-28 draft-ietf-tcpm-converters-16 Charlie Kaufman 2020-02-20 draft-ietf-lpwan-coap-static-context-hc-12 Charlie Kaufman R2019-09-02 draft-ietf-ecrit-data-only-ea-21 Russ Mundy 2020-01-02 draft-ietf-dprive-bcp-op-08 Sandra Murphy 2019-10-04 draft-ietf-mpls-ldp-yang-06 Magnus Nystrom 2019-04-10 draft-ietf-avtcore-multiplex-guidelines-11 Vincent Roca R2019-10-14 draft-ietf-dmm-pmipv6-dlif-05 Stefan Santesson 2020-01-27 draft-ietf-dots-architecture-17 Takeshi Takahashi 2020-02-06 draft-ietf-mmusic-t140-usage-data-channel-11 Tina Tsou 2020-02-06 draft-ietf-6lo-backbone-router-17 Sean Turner None draft-ietf-opsawg-sdi-02 Carl Wallace R2018-02-26 draft-ietf-hip-native-nat-traversal-30 David Waltermire 2020-02-25 draft-ietf-6man-icmp-limits-07 Klaas Wierenga 2020-02-21 draft-ietf-lamps-5480-ku-clarifications-01 Dacheng Zhang 2020-03-12 draft-nottingham-how-did-that-get-into-the-repo-01 Dacheng Zhang 2019-11-05 draft-ietf-mpls-ri-rsvp-frr-07 Next in the reviewer rotation: Scott Kelly Stephen Kent Tero Kivinen Watson Ladd Chris Lonvick Aanchal Malhotra David Mandelberg Catherine Meadows Daniel Migault Adam Montville From nobody Thu Feb 27 06:57:54 2020 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F00D3A0AF8; Thu, 27 Feb 2020 06:57:42 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Vincent Roca via Datatracker To: Cc: dmm@ietf.org, last-call@ietf.org, draft-ietf-dmm-pmipv6-dlif.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.118.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <158281546210.2262.1845082722013562869@ietfa.amsl.com> Reply-To: Vincent Roca Date: Thu, 27 Feb 2020 06:57:42 -0800 Archived-At: Subject: [secdir] Secdir telechat review of draft-ietf-dmm-pmipv6-dlif-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Feb 2020 14:57:49 -0000 Reviewer: Vincent Roca Review result: Has Nits Hello, I have reviewed this document as part of the security directorate’s ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. Summary: Has Nits Thank you for the clarification of the Security Considerations section. I just have a minor comment and a typo. - It is said (section 6): "The CMD SHOULD use a pacing approach to limit this amplification risk." I agree, but where do you intend to apply pacing? In the incoming queue (i.e., by delaying some PBU/PBA messages) or in the outgoing queue (i.e., to limit output traffic), or both? It's a bit unclear. - Typo: remove one "exist" in sentence: "there may exist multiple previous (e.g., k) MAARs exist." Regards, Vincent From nobody Thu Feb 27 09:25:15 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 868543A0D82; Thu, 27 Feb 2020 09:25:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=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 yEkRIwP9tTF2; Thu, 27 Feb 2020 09:25:05 -0800 (PST) Received: from smtp-out-02.aalto.fi (smtp-out-02.aalto.fi [130.233.228.121]) (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 95FEF3A0D7D; Thu, 27 Feb 2020 09:25:04 -0800 (PST) Received: from smtp-out-02.aalto.fi (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id 9EAEC2713BA_E57FB6BB; Thu, 27 Feb 2020 17:24:59 +0000 (GMT) Received: from smtp.netlab.hut.fi (luuri.netlab.hut.fi [130.233.154.177]) by smtp-out-02.aalto.fi (Sophos Email Appliance) with ESMTP id 7A7442712D0_E57FB6BF; Thu, 27 Feb 2020 17:24:59 +0000 (GMT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp.netlab.hut.fi (Postfix) with ESMTP id 670CB1E138; Thu, 27 Feb 2020 19:24:59 +0200 (EET) X-Virus-Scanned: by amavisd-new at luuri.netlab.hut.fi Received: from smtp.netlab.hut.fi ([127.0.0.1]) by localhost (luuri.netlab.hut.fi [127.0.0.1]) (amavisd-new, port 10024) with LMTP id v4P_JnwqbWnL; Thu, 27 Feb 2020 19:24:54 +0200 (EET) Received: from alf.local (ip5f5bede2.dynamic.kabel-deutschland.de [95.91.237.226]) by smtp.netlab.hut.fi (Postfix) with ESMTPSA id AC8351E045; Thu, 27 Feb 2020 19:24:53 +0200 (EET) To: Carl Wallace , secdir@ietf.org, draft-ietf-rmcat-eval-criteria.all@ietf.org, last-call@ietf.org References: <935224C2-2342-4254-91AF-A8C1551215FF@redhoundsoftware.com> From: Joerg Ott Message-ID: <5e4c9eb3-ac35-b4ec-09f9-ef681701a119@netlab.tkk.fi> Date: Thu, 27 Feb 2020 18:24:46 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.4.2 MIME-Version: 1.0 In-Reply-To: <935224C2-2342-4254-91AF-A8C1551215FF@redhoundsoftware.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-SASI-RCODE: 200 Archived-At: Subject: Re: [secdir] secdir review of draft-ietf-rmcat-eval-criteria X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Feb 2020 17:25:07 -0000 Thanks much for the review, Carl. Both points fixed and a new I-D submitted. Best, Jörg On 26.02.20 00:21, Carl Wallace wrote: > I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. > > This document describes the guidelines to evaluate new congestion control algorithms for interactive point-to-point real-time media. It asserts that as a document providing evaluation criteria and parameters for assessing and comparing performance that it is not subject to security considerations, but that evaluated protocols may be. This seems sufficient. The document is ready with some minor nits like an incomplete sentence in third paragraph of first section and some difficult to parse language in the jitter section ("jitter is a smoothed estimate of jitter", for example). > > From nobody Thu Feb 27 20:26:58 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF19E3A0F07; Thu, 27 Feb 2020 20:26:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.597 X-Spam-Level: X-Spam-Status: No, score=-9.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=QCLxRVgp; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=phFel9dn 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 nJVA4lcPPkMd; Thu, 27 Feb 2020 20:26:54 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B9D73A0F05; Thu, 27 Feb 2020 20:26:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=18763; q=dns/txt; s=iport; t=1582864014; x=1584073614; h=from:to:cc:subject:date:message-id:mime-version; bh=+i/O4kzRVqmxTaNxAa0WYPJV6pYKNjMLm/3kMH67PYA=; b=QCLxRVgprLKcqpCKtX6G0w/lHc6j45vgLW4FvrXOnQW7Q0dc9MPOltKc 6MF7PuiX+OxQN2qD4r4Enqo1smcF2MxYWiHHE17J/3OFFAPZZnLhVM3Eo g5I3pG1USt9ethT8fHK2tYG6rrgkF5ZMSyG7n0jpzGgm6bhoUbs8lkPUx 4=; IronPort-PHdr: =?us-ascii?q?9a23=3AI2xNyBMPebhZdUyGRrQl6mtXPHoupqn0MwgJ65?= =?us-ascii?q?Eul7NJdOG58o//OFDEuKQ/l0fHCIPc7f8My/HbtaztQyQh2d6AqzhDFf4ETB?= =?us-ascii?q?oZkYMTlg0kDtSCDBjgL+TjfSUSF8VZX1gj9Ha+YgBY?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AoCQBbllhe/4MNJK1mDg4BAQEBAQc?= =?us-ascii?q?BAREBBAQBAYF7gSUvUAVsWCAECyoKhAqDRgOKZYxCiU+EYoJSA1QJAQEBDAE?= =?us-ascii?q?BLQIEAQGEQBmBcSQ4EwIDDQEBBQEBAQIBBQRthTcMhWMBAgEVER0BATcBEQE?= =?us-ascii?q?ZAwECKwIEHxEdCgQBDQUigwQBgX1NAy4Bo1cCgTmIYnWBMoJ/AQEFhQUNC4I?= =?us-ascii?q?MCYE4jCUaggCBEScggwqCG4JQgnEygiyQZYVwigiOTSxECoI8BJIrhDYcgkm?= =?us-ascii?q?IG4ROi3yOcIsqjCGDfAIEAgQFAg4BAQWBaSKBWHAVZQGCQVAYDYEajQMREoN?= =?us-ascii?q?QhFmFPz10AoEnjHsBgQ8BAQ?= X-IronPort-AV: E=Sophos;i="5.70,493,1574121600"; d="scan'208,217";a="735543840" Received: from alln-core-1.cisco.com ([173.36.13.131]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 28 Feb 2020 04:26:50 +0000 Received: from XCH-RCD-005.cisco.com (xch-rcd-005.cisco.com [173.37.102.15]) by alln-core-1.cisco.com (8.15.2/8.15.2) with ESMTPS id 01S4Qo89032210 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 28 Feb 2020 04:26:50 GMT Received: from xhs-rtp-003.cisco.com (64.101.210.230) by XCH-RCD-005.cisco.com (173.37.102.15) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 27 Feb 2020 22:26:49 -0600 Received: from xhs-rcd-002.cisco.com (173.37.227.247) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 27 Feb 2020 23:26:49 -0500 Received: from NAM10-MW2-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Thu, 27 Feb 2020 22:26:48 -0600 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=kvDtm88Atvl+dSHxrEuTf1Bx/3MaXx+mJKWnWqNPRIU9vWu5XH58grNXcMCl1MJ+xIMzis7Dm+oSHjoawFLO3UOQSrTdEc6VpE0yde2+WA9qUc1ohJ8Ph7hrzL1MPQKybEQ0WT9RQ6GI6pmqP6KuX0BFnAdMXypglMxE/oGsvkDOlL2XSMHNqh1lJSb0LlLZjngsp038i0SbgNyZDexJ26ESh0D6aCt4SzySfCE13xrzzfuAwX4EAXQ3xWg5oq7hUaTcpE2Qs9QAPbgA6KRaAdeES0DvL8eqPf6plys3QXDDxSlpGjpBEGAGgC6+vaXXpFcntB6I3dZuMhLkRyrvRw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=+i/O4kzRVqmxTaNxAa0WYPJV6pYKNjMLm/3kMH67PYA=; b=YRObiBN8xb3Ev5rsthuRdNv7mtVQxb/09IuEqB9R+ILodWDymj3IwG1boUZ59agBNbuj6zb9aoBXHqYVjAGeApN2OfGDj6qAUk/+Euo+ztyMbmaW3yuTBOkN60GUn+xsCSe5pHfHw5K81+rN4skfOZtmEmxV8srH5oAO37HMhUz/hX5c2TzawTMXvr+jDvkP9WnZRcy4J0No4J6laN/WYrQnqWKYmWbt5nulnIlqM7lgfDY6yXLyukYsHoWKTKKlTbAWC9XVM85Fsnxdj387xSenUQftHkSg1V7ramkj1lRVZg7SnGY+6USiUOF0ba5cNlQb+l90Yt3sbT+nPZTznw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=+i/O4kzRVqmxTaNxAa0WYPJV6pYKNjMLm/3kMH67PYA=; b=phFel9dnNm/Yb35HB1OMMid7VL5reiyfR6KnEAdUgumhklVvctmsufMzuCyjHzc3Ffb+gOuqNiimphYkv51ZzQachANVicDo7kj2O6ZUPzTlJAl2SN99kyEKZd6GZRX+DvFTFq1lbCMZ0wH0TdVtk4VaQrQAnfGD4zDDlKMl390= Received: from BL0PR11MB3412.namprd11.prod.outlook.com (2603:10b6:208:7c::32) by BL0PR11MB3124.namprd11.prod.outlook.com (2603:10b6:208:30::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2772.15; Fri, 28 Feb 2020 04:26:47 +0000 Received: from BL0PR11MB3412.namprd11.prod.outlook.com ([fe80::29ec:dcc7:ed48:3f7e]) by BL0PR11MB3412.namprd11.prod.outlook.com ([fe80::29ec:dcc7:ed48:3f7e%6]) with mapi id 15.20.2750.021; Fri, 28 Feb 2020 04:26:47 +0000 From: "Kamran Raza (skraza)" To: "Shawn M. Emery" , secdir , "draft-ietf-mpls-ldp-yang.all@ietf.org" Thread-Topic: Updated rev posted [Re: Review of draft-ietf-mpls-ldp-yang-07] Thread-Index: AQHV7e9JI5sjC6LP2EGHwHk11d+oLg== Date: Fri, 28 Feb 2020 04:26:46 +0000 Message-ID: Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.21.0.200113 authentication-results: spf=none (sender IP is ) smtp.mailfrom=skraza@cisco.com; x-originating-ip: [173.38.117.82] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 597107f9-efe1-46b8-4b61-08d7bc066c6a x-ms-traffictypediagnostic: BL0PR11MB3124: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:7219; x-forefront-prvs: 0327618309 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(346002)(376002)(396003)(136003)(366004)(39860400002)(189003)(199004)(4326008)(76116006)(33656002)(2616005)(66946007)(66446008)(64756008)(66556008)(66476007)(8676002)(81156014)(6486002)(26005)(15650500001)(6512007)(2906002)(186003)(81166006)(36756003)(8936002)(478600001)(5660300002)(6506007)(53546011)(86362001)(110136005)(296002)(71200400001)(316002); DIR:OUT; SFP:1101; SCL:1; SRVR:BL0PR11MB3124; H:BL0PR11MB3412.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 4DxE8ZbTytL0zmls/vg1mQ2L+esGKtJpMDRvHT73uqc+X8iYq3G12YvByN5UZnjTIHo636Gx41PjpFk+edZOScQzijIcn1pMrl4lgxNeJ8+zNuBIBFkHvGi1qXzNf3oFrEPxkmUojntHoW2HexrEvvslat+heo/BjUfwgLpv9U+tysNJLYFOuWHyg4QWRMHElob7fkz43CEv0nXBqokmOtHRr5bgx3tWaotfO6a6RR4qoyNEoLreQFsjyD60+3XtR2tBscY4HZeMHLEEg1v1ih6+j4fNXerIp5wQKSPqrywllOnuC0SrYJZhfcoeLzRiE4QmDJGyNeAHVrCR+0BNYVDjjiUaxdwQiH/d5iy79S33uOKkwCrBJx1AIQfn7Dtpk2wdVP5P6fceRzib2b0+AWrNzMK6c3W/V98/UNftDh/fCtb/24M8HinwDH4GUt74 x-ms-exchange-antispam-messagedata: MHw9+PzBjfD6VYEDAYod3SULNwDDz4YAo63RlrhVIWiUMj7+JOxuTuQkOOuALieUKp/HxmUqBnEkZh6IO/B1yV7OlOwgyqGLWJwAjBPLYNGyMX0MkWwXC9zF9bs5MGeuOB/ypBKzV/CfZg973HXw+w== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_F628A40F73B340C5A50BCBC1E8D612F8ciscocom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 597107f9-efe1-46b8-4b61-08d7bc066c6a X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Feb 2020 04:26:46.8746 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: jZMqMsixaeSChRLv3BA+Kg+YiJp5LfuMQx0WZSkKijyKhOn+kPvvDjknR5xcANeBp25uDcpq17SXxvq4vLCc1g== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR11MB3124 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.15, xch-rcd-005.cisco.com X-Outbound-Node: alln-core-1.cisco.com Archived-At: Subject: [secdir] Updated rev posted [Re: Review of draft-ietf-mpls-ldp-yang-07] X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Feb 2020 04:26:57 -0000 --_000_F628A40F73B340C5A50BCBC1E8D612F8ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhbmtzIGZvciB5b3VyIHJldmlldyBhbmQgY29tbWVudHMuDQoNCldlIGhhdmUganVzdCBwb3N0 ZWQgYSBuZXcgcmV2IC0wOCB0aGF0IHRha2VzIGNhcmUgb2YgeW91ciBjb21tZW50cyBhbmQgY29t bWVudHMgZnJvbSBvdGhlciBJRVNHIHJldmlld2Vycy4NCk9uIGJlaGFsZiBvZiBhdXRob3JzLCBw bGVhc2Ugc2VlIGlubGluZSBbc2tyYXphXToNCg0KRnJvbTogIlNoYXduIE0uIEVtZXJ5IiA8c2Vt ZXJ5QHVjY3MuZWR1Pg0KRGF0ZTogTW9uZGF5LCBOb3ZlbWJlciAyNSwgMjAxOSBhdCA1OjM0IFBN DQpUbzogc2VjZGlyIDxzZWNkaXJAaWV0Zi5vcmc+LCAiZHJhZnQtaWV0Zi1tcGxzLWxkcC15YW5n LmFsbEBpZXRmLm9yZyIgPGRyYWZ0LWlldGYtbXBscy1sZHAteWFuZy5hbGxAaWV0Zi5vcmc+DQpD YzogU2hhd24gRW1lcnkgPHNoYXduLmVtZXJ5QGdtYWlsLmNvbT4NClN1YmplY3Q6IFJldmlldyBv ZiBkcmFmdC1pZXRmLW1wbHMtbGRwLXlhbmctMDcNClJlc2VudC1Gcm9tOiA8YWxpYXMtYm91bmNl c0BpZXRmLm9yZz4NClJlc2VudC1UbzogPHNrcmF6YUBjaXNjby5jb20+LCA8cmFqaXZhQGNpc2Nv LmNvbT4sIDx4dWZlbmcubGl1LmlldGZAZ21haWwuY29tPiwgPHNlc2FsZUBqdW5pcGVyLm5ldD4s IDxqZXNjaWEuY2hlbnhpYUBodWF3ZWkuY29tPiwgPGhzaGFoQGNpZW5hLmNvbT4sIDxtYWNoLmNo ZW5AaHVhd2VpLmNvbT4sIDx0c2FhZC5uZXRAZ21haWwuY29tPiwgPG4ubGV5bWFubkB0ZWxla29t LmRlPiwgPGxvYUBwaS5udT4sIDxtYXJ0aW4udmlnb3VyZXV4QG5va2lhLmNvbT4sIDxkYjM1NDZA YXR0LmNvbT4sIDxhcmV0YW5hLmlldGZAZ21haWwuY29tPiwgTmljb2xhaSBMZXltYW5uIDxuLmxl eW1hbm5AdGVsZWtvbS5kZT4sIFRhcmVrIFNhYWQgPHRzYWFkLm5ldEBnbWFpbC5jb20+DQpSZXNl bnQtRGF0ZTogTW9uZGF5LCBOb3ZlbWJlciAyNSwgMjAxOSBhdCA1OjMzIFBNDQoNClJldmlld2Vy OiBTaGF3biBNLiBFbWVyeQ0KUmV2aWV3IHJlc3VsdDogUmVhZHkgd2l0aCBuaXRzDQoNCkkgaGF2 ZSByZXZpZXdlZCB0aGlzIGRvY3VtZW50IGFzIHBhcnQgb2YgdGhlIHNlY3VyaXR5IGRpcmVjdG9y YXRlJ3MNCm9uZ29pbmcgZWZmb3J0IHRvIHJldmlldyBhbGwgSUVURiBkb2N1bWVudHMgYmVpbmcg cHJvY2Vzc2VkIGJ5IHRoZSBJRVNHLg0KVGhlc2UgY29tbWVudHMgd2VyZSB3cml0dGVuIHByaW1h cmlseSBmb3IgdGhlIGJlbmVmaXQgb2YgdGhlIHNlY3VyaXR5DQphcmVhIGRpcmVjdG9ycy4gRG9j dW1lbnQgZWRpdG9ycyBhbmQgV0cgY2hhaXJzIHNob3VsZCB0cmVhdCB0aGVzZQ0KY29tbWVudHMg anVzdCBsaWtlIGFueSBvdGhlciBsYXN0IGNhbGwgY29tbWVudHMuDQoNClRoaXMgZHJhZnQgc3Bl Y2lmaWVzIGEgWUFORyBtb2RlbCBmb3IgdGhlIE11bHRpLVByb3RvY29sIExhYmVsDQpTd2l0Y2hp bmcgKE1QTFMpIExhYmVsIERpc3RyaWJ1dGlvbiBQcm90b2NvbCAoTERQKS4gIE5ldHdvcmsNCkNv bmZpZ3VyYXRpb24gUHJvdG9jb2wgKE5FVENPTkYpIGFuZCBSRVNUQ09ORiBpcyB1c2VkDQp0byBt YW5nZSBuZXR3b3JrIGRldmljZXMgYmFzZWQgb24gdGhpcyBtb2RlbC4NCg0KVGhlIHNlY3VyaXR5 IGNvbnNpZGVyYXRpb25zIHNlY3Rpb24gZG9lcyBleGlzdCBhbmQgZm9yIHNlY3VyaXR5DQphbmQg cHJpdmFjeSBjb25jZXJucywgZGlzY3Vzc2VzIHRoYXQgdGhlIE1USSBmb3IgTkVUQ09ORiBpcw0K U1NIIGFuZCBUTFMgZm9yIFJFU1RDT05GLiAgRm9yIGF1dGhvcml6YXRpb24sIE5FVENPTkYNCmFu ZCBSRVNUQ09ORiB1c2VzIHRoZSBOZXR3b3JrIENvbmZpZ3VyYXRpb24gQWNjZXNzIENvbnRyb2wN Ck1vZGVsIChOQUNNKS4NCg0KVGhlIHNlY3Rpb24gZ29lcyBvbiB0byBzdGF0ZSB0aGF0IHNvbWUg ZGF0YSBub2Rlcw0KYW5kIFJQQyBvcGVyYXRpb25zIGluIHRoZSBZQU5HIG1vZHVsZSBhcmUgY29u c2lkZXJlZCBzZW5zaXRpdmUNCnRvIHZhcmlvdXMgb3BlcmF0aW9ucywgYnV0IGRvZXMgbm90IGdp dmUgZ3VpZGFuY2Ugb24gd2hpY2ggbm9kZXMNCm9yIHN1YnRyZWVzIHRoYXQgd291bGQgYmUgYWZm ZWN0ZWQuICBJbiB0aGUgcGFzdCwgbW9kdWxlIHNwZWNpZmljYXRpb25zDQp0aGF0IEkndmUgcmV2 aWV3ZWQgaGF2ZSBvdXRsaW5lZCBlYWNoIG9mIHRoZXNlIHJlbGV2YW50IGl0ZW1zLg0KDQpbc2ty YXphXTogRW5oYW5jZWQgdGhpcyBzZWN0aW9uIHNpZ25pZmljYW50bHkgYW5kIGhhdmUgYWRkZWQg dGhlIHJlbGV2YW50IGl0ZW1zIHRvIHRoaXMgc2VjdGlvbi4gU2VlIGRyYWZ0IHJldiAtMDguDQoN ClRoZSBzZWN0aW9uIGZpbmlzaGVzIHdpdGggdGhlIHN0YXRlbWVudCB0aGF0IHRoZSBzZWN1cml0 eQ0KcHJvcGVydGllcyBvZiB0aGUgYmFzZSBzcGVjaWZpY2F0aW9ucywgTERQLCBMRFAgSVB2Niwg ZXRjLiwgYWxzbyBhcHBsaWVzDQp0byB0aGlzIGRyYWZ0LiAgSSBhZ3JlZSB3aXRoIHRoZSBhYm92 ZSBhc3NlcnRpb25zLg0KDQpHZW5lcmFsIGNvbW1lbnRzOg0KDQpOb25lLg0KDQpFZGl0b3JpYWwg Y29tbWVudHM6DQpbc2tyYXphXTogRml4ZWQgYWxsIHRoZSBsaXN0ZWQuDQoNCnMvaW50byBmb2xs b3dpbmcvaW50byB0aGUgZm9sbG93aW5nLw0Kcy9tZWFucyBhbmQgYmUgcmVhZC9zaG91bGQgYmUg cmVhZC8NCnMvZmFtaWx5Ii9mYW1pbHkiLi8NCnMvVlBOIEZvcndhcmRpbmcgYW5kIFJvdXRpbmcv VlBOIFJvdXRpbmcgYW5kIEZvcndhcmRpbmcvDQpzL3Byb3ZpZGVzIGEgbWVhbi9wcm92aWRlcyBh IG1lYW5zLw0Kcy9OZWliZ2Jvci9OZWlnaGJvci8NCnMvcGVyZWZlcmVuY2UvcHJlZmVyZW5jZS8N CnMvY3JlYXRhYmxlXC8gZGVsZXRhYmxlL2NyZWF0YWJsZVwvZGVsZXRhYmxlLw0KDQpSRVNUQ09O RiBzaG91bGQgYmUgZXhwYW5kZWQgb24gZmlyc3Qgb2N1cmVuY2UuDQpbc2tyYXphXTogSSBjb3Vs ZCBub3QgZmluZCB0aGUgZXhwYW5zaW9uIOKAkyBldmVuIGluIHRoZSBSRVNUQ09ORiBSRkMgODA0 MCAuDQoNClNoYXduLg0KLS0NCg== --_000_F628A40F73B340C5A50BCBC1E8D612F8ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCnAuTXNvUGxhaW5UZXh0LCBsaS5Nc29QbGFpblRleHQsIGRpdi5Nc29Q bGFpblRleHQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJQbGFp biBUZXh0IENoYXIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZv bnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IkFyaWFsIixzYW5zLXNlcmlmO30NCnNwYW4u UGxhaW5UZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiUGxhaW4gVGV4dCBDaGFyIjsNCgltc28t c3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IlBsYWluIFRleHQiOw0KCWZvbnQt ZmFtaWx5OiJBcmlhbCIsc2Fucy1zZXJpZjt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUt dHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9u MQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDcyLjBwdCA3Mi4wcHQg NzIuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9z dHlsZT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLUNBIiBsaW5rPSIjMDU2M0MxIiB2bGluaz0i Izk1NEY3MiI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPlRoYW5rcyBmb3IgeW91ciByZXZpZXcgYW5k IGNvbW1lbnRzLg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+V2UgaGF2ZSBqdXN0IHBvc3RlZCBhIG5ldyByZXYgLTA4IHRoYXQgdGFrZXMgY2FyZSBvZiB5 b3VyIGNvbW1lbnRzIGFuZCBjb21tZW50cyBmcm9tIG90aGVyIElFU0cgcmV2aWV3ZXJzLg0KPC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPk9uIGJl aGFsZiBvZiBhdXRob3JzLCBwbGVhc2Ugc2VlIGlubGluZQ0KPHNwYW4gc3R5bGU9ImJhY2tncm91 bmQ6eWVsbG93O21zby1oaWdobGlnaHQ6eWVsbG93Ij5bc2tyYXphXTwvc3Bhbj46PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMt c2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpu b25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20g MGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIu MHB0O2NvbG9yOmJsYWNrIj5Gcm9tOiA8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTIuMHB0O2NvbG9yOmJsYWNrIj4mcXVvdDtTaGF3biBNLiBFbWVyeSZxdW90OyAmbHQ7c2VtZXJ5 QHVjY3MuZWR1Jmd0Ozxicj4NCjxiPkRhdGU6IDwvYj5Nb25kYXksIE5vdmVtYmVyIDI1LCAyMDE5 IGF0IDU6MzQgUE08YnI+DQo8Yj5UbzogPC9iPnNlY2RpciAmbHQ7c2VjZGlyQGlldGYub3JnJmd0 OywgJnF1b3Q7ZHJhZnQtaWV0Zi1tcGxzLWxkcC15YW5nLmFsbEBpZXRmLm9yZyZxdW90OyAmbHQ7 ZHJhZnQtaWV0Zi1tcGxzLWxkcC15YW5nLmFsbEBpZXRmLm9yZyZndDs8YnI+DQo8Yj5DYzogPC9i PlNoYXduIEVtZXJ5ICZsdDtzaGF3bi5lbWVyeUBnbWFpbC5jb20mZ3Q7PGJyPg0KPGI+U3ViamVj dDogPC9iPlJldmlldyBvZiBkcmFmdC1pZXRmLW1wbHMtbGRwLXlhbmctMDc8YnI+DQo8Yj5SZXNl bnQtRnJvbTogPC9iPiZsdDthbGlhcy1ib3VuY2VzQGlldGYub3JnJmd0Ozxicj4NCjxiPlJlc2Vu dC1UbzogPC9iPiZsdDtza3JhemFAY2lzY28uY29tJmd0OywgJmx0O3Jhaml2YUBjaXNjby5jb20m Z3Q7LCAmbHQ7eHVmZW5nLmxpdS5pZXRmQGdtYWlsLmNvbSZndDssICZsdDtzZXNhbGVAanVuaXBl ci5uZXQmZ3Q7LCAmbHQ7amVzY2lhLmNoZW54aWFAaHVhd2VpLmNvbSZndDssICZsdDtoc2hhaEBj aWVuYS5jb20mZ3Q7LCAmbHQ7bWFjaC5jaGVuQGh1YXdlaS5jb20mZ3Q7LCAmbHQ7dHNhYWQubmV0 QGdtYWlsLmNvbSZndDssICZsdDtuLmxleW1hbm5AdGVsZWtvbS5kZSZndDssICZsdDtsb2FAcGku bnUmZ3Q7LCAmbHQ7bWFydGluLnZpZ291cmV1eEBub2tpYS5jb20mZ3Q7LA0KICZsdDtkYjM1NDZA YXR0LmNvbSZndDssICZsdDthcmV0YW5hLmlldGZAZ21haWwuY29tJmd0OywgTmljb2xhaSBMZXlt YW5uICZsdDtuLmxleW1hbm5AdGVsZWtvbS5kZSZndDssIFRhcmVrIFNhYWQgJmx0O3RzYWFkLm5l dEBnbWFpbC5jb20mZ3Q7PGJyPg0KPGI+UmVzZW50LURhdGU6IDwvYj5Nb25kYXksIE5vdmVtYmVy IDI1LCAyMDE5IGF0IDU6MzMgUE08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjku NXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPlJldmlld2VyOiBT aGF3biBNLiBFbWVyeTxicj4NClJldmlldyByZXN1bHQ6Jm5ic3A7UmVhZHkgd2l0aCBuaXRzPC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6OS41cHQiPkkgaGF2ZSByZXZpZXdlZCB0aGlzIGRvY3VtZW50IGFz IHBhcnQgb2YgdGhlIHNlY3VyaXR5IGRpcmVjdG9yYXRlJ3M8YnI+DQpvbmdvaW5nIGVmZm9ydCB0 byByZXZpZXcgYWxsJm5ic3A7SUVURiZuYnNwO2RvY3VtZW50cyBiZWluZyBwcm9jZXNzZWQgYnkg dGhlIElFU0cuPGJyPg0KVGhlc2UgY29tbWVudHMgd2VyZSB3cml0dGVuIHByaW1hcmlseSBmb3Ig dGhlIGJlbmVmaXQgb2YgdGhlIHNlY3VyaXR5PGJyPg0KYXJlYSBkaXJlY3RvcnMuIERvY3VtZW50 IGVkaXRvcnMgYW5kIFdHIGNoYWlycyBzaG91bGQgdHJlYXQgdGhlc2U8YnI+DQpjb21tZW50cyBq dXN0IGxpa2UgYW55IG90aGVyIGxhc3QgY2FsbCBjb21tZW50cy48L3NwYW4+PG86cD48L286cD48 L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5 LjVwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS41cHQiPlRoaXMg ZHJhZnQgc3BlY2lmaWVzIGEgWUFORyBtb2RlbCBmb3IgdGhlJm5ic3A7PC9zcGFuPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTIuMHB0Ij5NdWx0aS1Qcm90b2NvbCBMYWJlbDwvc3Bhbj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjkuNXB0Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+ U3dpdGNoaW5nIChNUExTKSBMYWJlbCBEaXN0cmlidXRpb24gUHJvdG9jb2wgKExEUCkuJm5ic3A7 Jm5ic3A7TmV0d29yazwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuNXB0Ij48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+Q29uZmlndXJhdGlvbiBQcm90b2NvbCAoTkVUQ09O RikgYW5kIFJFU1RDT05GIGlzIHVzZWQ8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjVw dCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPnRvIG1hbmdlIG5ldHdvcmsmbmJz cDtkZXZpY2VzIGJhc2VkIG9uIHRoaXMgbW9kZWwuJm5ic3A7Jm5ic3A7PC9zcGFuPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6OS41cHQiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5 LjVwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS41cHQiPlRoZSBz ZWN1cml0eSBjb25zaWRlcmF0aW9ucyBzZWN0aW9uIGRvZXMgZXhpc3QgYW5kIGZvciBzZWN1cml0 eTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS41cHQiPmFuZCBwcml2YWN5IGNvbmNlcm5zLCZu YnNwO2Rpc2N1c3NlcyZuYnNwO3RoYXQgdGhlIE1USSBmb3IgTkVUQ09ORiBpczxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6OS41cHQiPlNTSCBhbmQgVExTJm5ic3A7Zm9yIFJFU1RDT05GLiZuYnNw OyBGb3IgYXV0aG9yaXphdGlvbiwgTkVUQ09ORjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS41 cHQiPmFuZCBSRVNUQ09ORiB1c2VzIHRoZSZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEyLjBwdCI+TmV0d29yayBDb25maWd1cmF0aW9uIEFjY2VzcyBDb250cm9sPC9zcGFuPjxz cGFuIHN0eWxlPSJmb250LXNpemU6OS41cHQiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIu MHB0Ij5Nb2RlbCAoTkFDTSkuPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS41cHQiPjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS41cHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTIuMHB0Ij5UaGUgc2VjdGlvbiBnb2VzIG9uIHRvIHN0YXRlIHRoYXQgc29tZSBkYXRh IG5vZGVzPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS41cHQiPjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTIuMHB0Ij5hbmQgUlBDIG9wZXJhdGlvbnMgaW4gdGhlIFlBTkcgbW9kdWxl IGFyZSBjb25zaWRlcmVkIHNlbnNpdGl2ZTwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjku NXB0Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+dG8gdmFyaW91cyBvcGVyYXRp b25zLCZuYnNwO2J1dCBkb2VzIG5vdCBnaXZlIGd1aWRhbmNlIG9uIHdoaWNoIG5vZGVzPC9zcGFu PjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS41cHQiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTIuMHB0Ij5vciBzdWJ0cmVlcyB0aGF0IHdvdWxkJm5ic3A7YmUgYWZmZWN0ZWQuJm5ic3A7IElu IHRoZSBwYXN0LCBtb2R1bGUgc3BlY2lmaWNhdGlvbnM8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZTo5LjVwdCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPnRoYXQgSSd2ZSBy ZXZpZXdlZCBoYXZlIG91dGxpbmVkIGVhY2ggb2YgdGhlc2UgcmVsZXZhbnQgaXRlbXMuPC9zcGFu PjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS41cHQiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 OS41cHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1 b3Q7LHNhbnMtc2VyaWY7YmFja2dyb3VuZDp5ZWxsb3c7bXNvLWhpZ2hsaWdodDp5ZWxsb3ciPltz a3JhemFdOiBFbmhhbmNlZCB0aGlzIHNlY3Rpb24gc2lnbmlmaWNhbnRseSBhbmQgaGF2ZSBhZGRl ZCB0aGUgcmVsZXZhbnQgaXRlbXMgdG8gdGhpcyBzZWN0aW9uLiBTZWUgZHJhZnQgcmV2IC0wOC48 L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJp YWwmcXVvdDssc2Fucy1zZXJpZiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox Mi4wcHQiPlRoZSBzZWN0aW9uIGZpbmlzaGVzIHdpdGggdGhlIHN0YXRlbWVudCB0aGF0IHRoZSBz ZWN1cml0eTwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuNXB0Ij48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEyLjBwdCI+cHJvcGVydGllcyBvZiB0aGUgYmFzZSBzcGVjaWZpY2F0aW9u cywgTERQLCBMRFAgSVB2NiwgZXRjLiwgYWxzbyBhcHBsaWVzPC9zcGFuPjxzcGFuIHN0eWxlPSJm b250LXNpemU6OS41cHQiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij50byB0aGlz IGRyYWZ0LiZuYnNwOyZuYnNwO0kgYWdyZWUgd2l0aCB0aGUgYWJvdmUgYXNzZXJ0aW9ucy48L3Nw YW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjVwdCI+PG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZTo5LjVwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjVwdCI+R2VuZXJhbCBj b21tZW50czo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuNXB0Ij48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjkuNXB0Ij5Ob25lLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS41 cHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+RWRpdG9yaWFsIGNvbW1lbnRzOjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBw dDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2JhY2tncm91bmQ6eWVs bG93O21zby1oaWdobGlnaHQ6eWVsbG93Ij5bc2tyYXphXTogRml4ZWQgYWxsIHRoZSBsaXN0ZWQu DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+cy9pbnRvIGZvbGxvd2luZy9pbnRvIHRoZSBmb2xsb3dpbmcv PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5zL21l YW5zIGFuZCBiZSByZWFkL3Nob3VsZCBiZSByZWFkLzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+cy9mYW1pbHkmcXVvdDsvZmFtaWx5JnF1b3Q7Li88 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5zL1ZQTiBGb3J3YXJkaW5nIGFuZCBSb3V0aW5nL1ZQTiBSb3V0aW5nIGFuZCBGb3J3YXJkaW5n LzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5zL3Byb3ZpZGVzIGEgbWVhbi9wcm92aWRlcyBhIG1lYW5zLzxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+cy88c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtjb2xvcjpibGFjayI+TmVpYmdib3IvTmVpZ2hib3IvPC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Y29sb3I6YmxhY2siPnMvPC9zcGFuPnBlcmVmZXJlbmNlL3ByZWZl cmVuY2UvPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5zL2NyZWF0YWJsZVwvIGRlbGV0YWJsZS9jcmVhdGFibGVcL2RlbGV0YWJsZS88bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UkVTVENPTkYgc2hv dWxkIGJlIGV4cGFuZGVkIG9uIGZpcnN0IG9jdXJlbmNlLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250 LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2JhY2tncm91bmQ6eWVsbG93O21z by1oaWdobGlnaHQ6eWVsbG93Ij5bc2tyYXphXTogSSBjb3VsZCBub3QgZmluZCB0aGUgZXhwYW5z aW9uIOKAkyBldmVuIGluIHRoZSBSRVNUQ09ORiBSRkMgODA0MCAuDQo8L3NwYW4+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1z ZXJpZiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+U2hhd24uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj4tLTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0K PC9odG1sPg0K --_000_F628A40F73B340C5A50BCBC1E8D612F8ciscocom_-- From nobody Fri Feb 28 07:02:28 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1851F3A194C; Fri, 28 Feb 2020 07:00:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.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 aFdRLzmQA4oS; Fri, 28 Feb 2020 07:00:34 -0800 (PST) Received: from FRA01-MR2-obe.outbound.protection.outlook.com (mail-eopbgr90114.outbound.protection.outlook.com [40.107.9.114]) (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 DE4043A1951; Fri, 28 Feb 2020 07:00:33 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=CEgeYABrUNsOLrrb1agdrLf8gxsASja4tBoSdy8+uzOBm2MGa5WX7OuRpLb8F8qKybTB/0FEHRQ4U7CLwUIrKaUGvTAoMCpItIVRRxZ7qisFggBtaB+jSRplnRdcPhHmz5hdjbjhpwEqdm1H9JywGAtK7c1dNyqwRY9fSK0hhvthNaDivXuV+1XZFy/uySY/eT2h4eua9xDAIZVNOBhZnpvHp5jLB5HKrJE9I9qmCY4FsqqdwaqBSA4FypQeP/Jt+3d1cT7jNU9SXjwKJxVZRbghW9JIv1JMJlkpe2IdKW9uYk1C9eRaroAwtOHztMkAqPd5ssTC2+q/MdjBFp2Olw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=lOeW6q0FtgV0Jyw+9kt5sgBiivow5e5hR3FWakb9NFc=; b=ZQCg4tKyzaMH8EpSU0miiiN41SuGqtbkhNHoB4OOYfwGuwFWOV0Ldo5S+Sn4yeE+dKcfiAObNKsvK+57DMjyVPsBCfjPIcSptGDmK3uZmNyTQbZRZnWspJ3uFuUri2+tA0gmzpd77sKnFlX4xW3k5vxSJ5MVUVICaHN7gvabiYX61Xt6R3LFeDhRJ1mlLKxflHW3/RTeVryJSr+5tXL8AkfgBfkL/M3wn1PDn8l2rChrFZtuSno+6G0q2EzR6nRoiR6BrEoey72UW6TKRt29TAkHbSACRmQXKfO/5KJ35hVZbQUA56eBHIctZFezTKNeQBOpSq9e2cOpquoi8vtG4g== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nokia-bell-labs.com; dmarc=pass action=none header.from=nokia-bell-labs.com; dkim=pass header.d=nokia-bell-labs.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=lOeW6q0FtgV0Jyw+9kt5sgBiivow5e5hR3FWakb9NFc=; b=H8etZ9OUNkbKINzhLtfaDo8yS/HTOnZmTAuNkl2Xzp+TrJQiDDoqaoUxtNNgk6WrDdGZFIcuJM130ZAaiQ9aCl04IrCUbDCWhNmrGj6A2pBTdmfDLiYWFpBGdz/XPFF8Bx0jnwPIvapAVrax5+Pdfjy5GvX3FR05cV+/4c6ltmY= Received: from PR1PR07MB5100.eurprd07.prod.outlook.com (20.177.209.144) by PR1PR07MB5116.eurprd07.prod.outlook.com (20.177.211.24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2772.9; Fri, 28 Feb 2020 15:00:31 +0000 Received: from PR1PR07MB5100.eurprd07.prod.outlook.com ([fe80::8d6a:cf42:5a57:6b77]) by PR1PR07MB5100.eurprd07.prod.outlook.com ([fe80::8d6a:cf42:5a57:6b77%3]) with mapi id 15.20.2772.012; Fri, 28 Feb 2020 15:00:31 +0000 From: "Randriamasy, Sabine (Nokia - FR/Paris-Saclay)" To: The IESG , "secdir@ietf.org" , "ops-dir@ietf.org" CC: IETF ALTO , "draft-ietf-alto-cost-calendar@ietf.org" , "alto-chairs@ietf.org" Thread-Topic: [alto] I-D Action: draft-ietf-alto-cost-calendar-18.txt Thread-Index: AQHV7kWJSZL4nTuZ4Eij3NbOSl7FR6gwsCtA Date: Fri, 28 Feb 2020 15:00:31 +0000 Message-ID: References: <158290102597.22328.2781470606904693361@ietfa.amsl.com> In-Reply-To: <158290102597.22328.2781470606904693361@ietfa.amsl.com> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=sabine.randriamasy@nokia-bell-labs.com; x-originating-ip: [131.228.2.2] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: ea010fd1-ca33-425c-3278-08d7bc5ef4a9 x-ms-traffictypediagnostic: PR1PR07MB5116: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 0327618309 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(4636009)(136003)(376002)(39860400002)(396003)(366004)(346002)(189003)(199004)(52536014)(5660300002)(81156014)(4326008)(110136005)(966005)(186003)(81166006)(26005)(33656002)(478600001)(53546011)(8676002)(450100002)(71200400001)(54906003)(7696005)(6506007)(9686003)(8936002)(66946007)(316002)(66446008)(2906002)(64756008)(66556008)(76116006)(66574012)(86362001)(55016002)(66476007); DIR:OUT; SFP:1102; SCL:1; SRVR:PR1PR07MB5116; H:PR1PR07MB5100.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:0; received-spf: None (protection.outlook.com: nokia-bell-labs.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: mWhgxXK7zzH+6+nkBqnu4Qji4eH0wcYMMjfp0AnN62H3tW0YhlSwefAfb9pzE5uHKD8gmIBKPpNIPJ5/NJW2qxtV/5si+ZlSpp6Yf8kHhywDWCcnJRPjXShhbAZR9usJMv09idUBaYMUXU34sNDOWnZL3GamlD91hWUojfXgnpUz5bObx1oHWjVQkN48ZJ7YNFB8pcBk7ECGlhhh+19cfbKXmtl1lxYOntYdM1jSL+0EkblFSaLalYv98NepYR3FUVBhPZSOTyJVjYRs7POQA8Spdfv6oeN/rs6QJqPR647rU9w9mGFksM2GyXDM2CxHae18IFC4Pblh6Z+P6qILa6IHKqTfd4AGAwyUkWLna9daW30MIUgdpT+ECIP+skdi/aFYiWKPxGydghmYwqBqUBFpknLFXL1+uvyw1rKGBbrKNqfsu+WidBGwr8J2oXiRnKopWo3vWhKbuilorqkaAP7RaP8ytsQj2vXhps4JRc66DInolU9PscS+G2/o08nSKFqIjYGyf66LKJrQshWB3Q== x-ms-exchange-antispam-messagedata: 2T4mwqkZ/h0TCc+2KJsgJaKw2e7i37DUBVtRFThxN7kpZTjw6h7+EHEwMBdh6i7As81T/zx36sDXVRJoYs4x47vlPrMqUoggFAMxdawLmnEuJmVdHcprznE4wblaDmTDdOJBXN32evv8CdruqA7XBg== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nokia-bell-labs.com X-MS-Exchange-CrossTenant-Network-Message-Id: ea010fd1-ca33-425c-3278-08d7bc5ef4a9 X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Feb 2020 15:00:31.3021 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: dt1HSzsVxnUNeoaKL4jSXsaNcoN+HBu5cg1Nz4WaGNeNz9jV1VBj97D5i2uNFFJhO0z3iWSg6QhLgOOWvDLM6eoNL1h0eLPFPyAeXx2KFmQ1FxFBjAr2qlAisigNXi1h X-MS-Exchange-Transport-CrossTenantHeadersStamped: PR1PR07MB5116 Archived-At: Subject: [secdir] FW: [alto] I-D Action: draft-ietf-alto-cost-calendar-18.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Feb 2020 15:00:36 -0000 Dear IESG reviewers, J=FCrgen, Brian, Barry,=20 Thank you very much for your review and suggestions. Upon your feedback, we= have posted a new version 18, that hopefully addresses your comments.=20 Besides, some lower/upper case typo harmonization has been done on expressi= ons such as "Client", "Server", "cost type".=20 We look forward to having your feedback, Best regards, Sabine and co-authors -----Original Message----- From: alto On Behalf Of internet-drafts@ietf.org Sent: Friday, February 28, 2020 3:44 PM To: i-d-announce@ietf.org Cc: alto@ietf.org Subject: [alto] I-D Action: draft-ietf-alto-cost-calendar-18.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Application-Layer Traffic Optimization WG = of the IETF. Title : Application-Layer Traffic Optimization (ALTO) Cos= t Calendar Authors : Sabine Randriamasy Richard Yang Qin Wu Lingli Deng Nico Schwan Filename : draft-ietf-alto-cost-calendar-18.txt Pages : 32 Date : 2020-02-28 Abstract: This document is an extension to the base Application-Layer Traffic Optimization (ALTO) protocol. It extends the ALTO cost information service so that applications decide not only 'where' to connect, but also 'when'. This is useful for applications that need to perform bulk data transfer and would like to schedule these transfers during an off-peak hour, for example. This extension introduces ALTO Cost Calendar, with which an ALTO Server exposes ALTO cost values in JSON arrays where each value corresponds to a given time interval. The time intervals as well as other Calendar attributes, are specified in the Information Resources Directory and ALTO Server responses. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-alto-cost-calendar/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-alto-cost-calendar-18 https://datatracker.ietf.org/doc/html/draft-ietf-alto-cost-calendar-18 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-alto-cost-calendar-18 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ alto mailing list alto@ietf.org https://www.ietf.org/mailman/listinfo/alto From nobody Fri Feb 28 10:18:25 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 519D33A1C74; Fri, 28 Feb 2020 10:18:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=jacobsuniversity.onmicrosoft.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 8aymcrICtmmv; Fri, 28 Feb 2020 10:17:57 -0800 (PST) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-eopbgr150079.outbound.protection.outlook.com [40.107.15.79]) (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 128033A1C6E; Fri, 28 Feb 2020 10:17:55 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=WwmSsEGUXqlHRmW+T1SNR5qnYLEoDYxj0mnvL4ikES7NSiepiYV90mPfGRr8HpA/iyl2fptUXI4zBmUf1rMeBA+9uB8R8Gcc6MPao2FpNlJgcDN5aFL/u1ac1kDHLTWvqdemLf/7GAW3GNcs4tj4wWEaTyfy8AnEKI29hB49PQfOuQG6ywyCxbPhoi1eMaFIpJcqOcKnCm9+DM3IiQIJQG55GX7uYUGr0fadvmNI7MhCTPMl2mIpzVCkIMJ+ui76LXiqVuv7wh41kqy313eT0E68S6dLovjXTeYMKHbUqc+xKUcn5njXVYbykM77ie8fkxzjuLcnRfQ8QzuD9cjgaw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=XpdSaAFwilFRcnJlvy8Gefru26bXBYH63BY1t5pOTGk=; b=KAc9KI9B7ky/8tqpFR5TsODGhQJbM6AF6OsoflTr8JBkGUkdCMzT1MPhLQATAxsIN2dQGmmakUeYo5J5kTG5TuPYt6zQbZJrbDkkUV3IjzdqIVF2I7K4MlyFTQGA4OfL06DDzgepR83M7r0kAXX0MGEdPw7NkUEF4eStRdH7vqeZBjx8cF+0gUtDz9ad+xUINru/4NslSTIAx1/GLOIfwZMO6N7MpS7gk7r/1WXp8iaAdDLLg53mH4Kd+hhGQZnXA7qzhePxFlE61TZyi2+bANgV0Do4VJReeK2PJlV08kyMWAMwh70L+rBsJKAJw/l4ZHwrnYfMoBu053up/LdTeg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=jacobs-university.de; dmarc=pass action=none header.from=jacobs-university.de; dkim=pass header.d=jacobs-university.de; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jacobsuniversity.onmicrosoft.com; s=selector2-jacobsuniversity-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=XpdSaAFwilFRcnJlvy8Gefru26bXBYH63BY1t5pOTGk=; b=q0ySNUcoxK2joe3hBvGlnG4PDg7G8tciPOi8xkw89u1L/CMX4S3zuuIlyeh9zawEAKSAXA9BoPOZspV60dBFT3lT91rAUrkGKcq0UoqgCFRtWDhFPqemVYcGB0yUFKeYqW4PFJ9ZZcPcgEYsWC4viHSXhd/uC6pTDtoh5rWNRu8= Received: from DB6P190MB0006.EURP190.PROD.OUTLOOK.COM (10.172.229.142) by DB6P190MB0104.EURP190.PROD.OUTLOOK.COM (10.172.228.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2772.14; Fri, 28 Feb 2020 18:17:51 +0000 Received: from DB6P190MB0006.EURP190.PROD.OUTLOOK.COM ([fe80::7081:b5ed:c939:60a6]) by DB6P190MB0006.EURP190.PROD.OUTLOOK.COM ([fe80::7081:b5ed:c939:60a6%9]) with mapi id 15.20.2772.012; Fri, 28 Feb 2020 18:17:51 +0000 Received: from localhost (212.201.44.247) by ZR0P278CA0036.CHEP278.PROD.OUTLOOK.COM (2603:10a6:910:1c::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2772.14 via Frontend Transport; Fri, 28 Feb 2020 18:17:50 +0000 From: =?iso-8859-1?Q?Sch=F6nw=E4lder=2C_J=FCrgen?= To: "Randriamasy, Sabine (Nokia - FR/Paris-Saclay)" CC: The IESG , "secdir@ietf.org" , "ops-dir@ietf.org" , "alto-chairs@ietf.org" , "draft-ietf-alto-cost-calendar@ietf.org" , IETF ALTO Thread-Topic: [OPS-DIR] FW: [alto] I-D Action: draft-ietf-alto-cost-calendar-18.txt Thread-Index: AQHV7kWkb6d+ApV9CUmV4N7iECLLGqgwsxiAgAA3IIA= Date: Fri, 28 Feb 2020 18:17:50 +0000 Message-ID: <20200228181749.lvstqfpxwatblmz7@anna.jacobs.jacobs-university.de> References: <158290102597.22328.2781470606904693361@ietfa.amsl.com> In-Reply-To: Reply-To: =?iso-8859-1?Q?Sch=F6nw=E4lder=2C_J=FCrgen?= Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-clientproxiedby: ZR0P278CA0036.CHEP278.PROD.OUTLOOK.COM (2603:10a6:910:1c::23) To DB6P190MB0006.EURP190.PROD.OUTLOOK.COM (2603:10a6:4:89::14) authentication-results: spf=none (sender IP is ) smtp.mailfrom=J.Schoenwaelder@jacobs-university.de; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [212.201.44.247] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 42a62602-8ef5-43a2-9fdb-08d7bc7a8577 x-ms-traffictypediagnostic: DB6P190MB0104: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0327618309 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39850400004)(396003)(376002)(366004)(346002)(136003)(189003)(199004)(186003)(16526019)(1076003)(786003)(54906003)(316002)(26005)(66446008)(64756008)(66556008)(66946007)(956004)(5660300002)(66476007)(52116002)(6496006)(2906002)(71200400001)(86362001)(4326008)(3450700001)(6486002)(478600001)(6916009)(8936002)(81166006)(81156014)(8676002); DIR:OUT; SFP:1101; SCL:1; SRVR:DB6P190MB0104; H:DB6P190MB0006.EURP190.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: jacobs-university.de does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 1QVHCv4EJaQluAZGl/lVLfQLYgMkr+gkT6QO4dVocIa8NkKZYRFvwuUqptfbYoxW1ER8NwbMXKfhOeSHsBuadsU4QMR/u5mOZHGRDKUP53QiB3IEQ5AegIF/1tjlDccn/zY7QrPFEWxPoZQwRzKpJi6HtVgV65du0m1K7dNNI2hgy8toFJr5HrNflKf29BbuF0GzZOb4uPO4liSATDTpRR2ijvbaNYYVS31PP8u+p995QG87MxtoKsLMLsgFodcqrSz+Zc1Jg07kqvSd8GGRbMWQm4EV1lf900znNCYyKzMuYhmJpcIto/FI82iKy4AP+ONitHaozIZaaqywG2sVtgeQf1JjUjoLH+8A01rIUQjPkJbMEnKsiBbL/1o82vYWm20wd/13n4f4kvTHd6ERHNo/59UAo6gd8V4RJYtSZuP3WaWx/dsZY2oSKiM90NvDp0XTtP1kQDcamijkcz5Z0R0MSkxM7ufXksN5ej9B/zmP4jqSrLycON5w7Cl+EbmotpxswhdGL9qFGHziGfjG5A== x-ms-exchange-antispam-messagedata: 6ANw1UeZ7OFzTqZFG6CU4P7BdXiVlF8iZXKyaMu/EZ0fvcpZWkM0COJb6iAaxKAIiNaDUPKCH0dCCi+ZurnzSjhAn4P/nroATyMCMudA/l/NWVge3wjKKXOcz5rC+5PasVatM0+8vIliv3LsFo1VNg== Content-Type: text/plain; charset="iso-8859-1" Content-ID: <44DE18F868E3C0449625EE086C6884B4@EURP190.PROD.OUTLOOK.COM> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: jacobs-university.de X-MS-Exchange-CrossTenant-Network-Message-Id: 42a62602-8ef5-43a2-9fdb-08d7bc7a8577 X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Feb 2020 18:17:51.1084 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f78e973e-5c0b-4ab8-bbd7-9887c95a8ebd X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: SgpSD1ldr3sURxTOuBhLArvjCTA5+lBGjpaHD4VO6veHaxZImC6PpHzBb11oaGneq5Yk2lg0NrzQj4WF40J9/saZvqWMi1S11CYnPvfFOoQ= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6P190MB0104 Archived-At: Subject: Re: [secdir] [OPS-DIR] FW: [alto] I-D Action: draft-ietf-alto-cost-calendar-18.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Feb 2020 18:18:04 -0000 On Fri, Feb 28, 2020 at 03:00:31PM +0000, Randriamasy, Sabine (Nokia - FR/P= aris-Saclay) wrote: > Dear IESG reviewers, J=FCrgen, Brian, Barry,=20 >=20 > Thank you very much for your review and suggestions. Upon your feedback, = we have posted a new version 18, that hopefully addresses your comments.=20 > Besides, some lower/upper case typo harmonization has been done on expres= sions such as "Client", "Server", "cost type".=20 > We look forward to having your feedback, > Thanks for the changes. All looks good but I am still struggling a bit with the type change of the cost field. Revision -18 has this new text: [...] Therefore the implementor of this extension MUST consider that a cost entry is an array of values. I do not really understand what this MUST tries to achieve or what you expect an implementer to do exactly. RFC 7285 section 11.2.3.6 says: [...] An implementation of the protocol in this document SHOULD assume that the cost is a JSONNumber and fail to parse if it is not, unless the implementation is using an extension to this document that indicates when and how costs of other data types are signaled. It may help to spell out 'when and how costs of other data types are signaled' instead of writing "the implementor [...] MUST consider". If the idea is that the usage of an array is signaled by the usage of an array, then say so, if there is some other way to signal this before I try to parse, then say so as well. We should not rely on implementers to consider and find their own solutions. /js PS: I do not know much about ALTO but out of curiosity: has it been considered to allocate new "cost-mode" values "numerical*" and "ordinal*" that signal that the cost field is a vector of numerical/ordinal values and not just a scalar? --=20 Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Fri Feb 28 10:48:58 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACA203A1C8E; Fri, 28 Feb 2020 10:48:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=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 JxEBnnGi3C2q; Fri, 28 Feb 2020 10:48:31 -0800 (PST) Received: from ppa4.dc.icann.org (ppa4.dc.icann.org [192.0.46.77]) (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 AE6773A1C85; Fri, 28 Feb 2020 10:48:31 -0800 (PST) Received: from PFE112-CA-1.pexch112.icann.org (out.west.pexch112.icann.org [64.78.40.7]) by ppa4.dc.icann.org (8.16.0.42/8.16.0.42) with ESMTPS id 01SImPjV003301 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Fri, 28 Feb 2020 18:48:26 GMT Received: from PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) by PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 28 Feb 2020 10:48:23 -0800 Received: from PMBX112-W1-CA-1.pexch112.icann.org ([64.78.40.21]) by PMBX112-W1-CA-1.PEXCH112.ICANN.ORG ([64.78.40.21]) with mapi id 15.00.1497.006; Fri, 28 Feb 2020 10:48:23 -0800 From: Paul Hoffman To: Linda Dunbar CC: secdir , "last-call@ietf.org" , "draft-ietf-dnsop-7706bis.all@ietf.org" , "dnsop@ietf.org" Thread-Topic: [Ext] Secdir last call review of draft-ietf-dnsop-7706bis-07 Thread-Index: AQHV62cOmX4hsSIFCUW9l6yT30xrp6gxfpsA Date: Fri, 28 Feb 2020 18:48:23 +0000 Message-ID: References: <158258558771.24222.13223272462077841258@ietfa.amsl.com> In-Reply-To: <158258558771.24222.13223272462077841258@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [192.0.32.234] x-source-routing-agent: Processed Content-Type: multipart/signed; boundary="Apple-Mail=_41AB472E-1B74-4814-B758-4B4E57D3A287"; protocol="application/pkcs7-signature"; micalg=sha-256 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138, 18.0.572 definitions=2020-02-28_06:2020-02-28, 2020-02-28 signatures=0 Archived-At: Subject: Re: [secdir] [Ext] Secdir last call review of draft-ietf-dnsop-7706bis-07 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Feb 2020 18:48:34 -0000 --Apple-Mail=_41AB472E-1B74-4814-B758-4B4E57D3A287 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Thanks for the review! Answers to your questions here: On Feb 24, 2020, at 3:06 PM, Linda Dunbar via Datatracker = wrote: > - What if > the node is not authorized to have the entire records? It would = desirable for > the Resolvers to have all the records of the root zone. Is there any = scenario > that the Resolvers simply cannot get all the records of the root zone? No, there is no such scenario. Every resolver can always get and cache = any record in the root zone. > - How to detect if any records stored in the Resolver are STALE? Resolvers would treat the records gotten from transferring the root zone = wholesale as if they had requested each one from a root server. Thus, = record staleness is handled for these records exactly as they are for = normal queries. > Page 3, last sentence of the 3rd paragraph: is it a typo? or miss a = verb? > "... it would all responses from a remote root server" Good catch. We'll fix that to "just as it would validate all responses = from a remote root server". --Paul Hoffman= --Apple-Mail=_41AB472E-1B74-4814-B758-4B4E57D3A287 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCC/Qw ggWeMIIEhqADAgECAhAG83jiXlqePPrfwUUEH4ZnMA0GCSqGSIb3DQEBCwUAMGUxCzAJBgNVBAYT AlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAi BgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQTAeFw0xODA2MTMwMDAwMDBaFw0yMTA2 MTMxMjAwMDBaMIG9MQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5pYTEUMBIGA1UEBxML TG9zIEFuZ2VsZXMxPDA6BgNVBAoTM0ludGVybmV0IENvcnBvcmF0aW9uIGZvciBBc3NpZ25lZCBO YW1lcyBhbmQgTnVtYmVyczEeMBwGA1UEAxMVUGF1bCBIb2ZmbWFuIDIwMTgwNjEzMSUwIwYJKoZI hvcNAQkBFhZwYXVsLmhvZmZtYW5AaWNhbm4ub3JnMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB CgKCAQEArTbxBbfxbk1VxDQsOmEm14Yta2AE5cBcJ/ktMkC+aQrTCMSXrQJfjiMUUndnfAT1DWcf jg706vvITa1lkFaLoF9b6cNICMKsibFruFy8ZA2bsIPRXPPzSsY6zibdStNCpruNTQoiL9bIxlQp qRUx/BfvHAhS7g5dAOcRgkpW9Q4Si5bl6A2qS0ImIMzktNcVxrWAn0HsG9u8cKcSCBJxavRAnMt/ XhE7tCICjyoeoprYZ2ztmdZUL6UgMNrDz/KoeNHAWzTAH45hn1Jz1IguGLM/M2Vb8mF8eP3wAh4p MVIi2jCwNqC497R8x0lsNryoG+uy/26nK6fhCTqVfF6hgQIDAQABo4IB7zCCAeswHwYDVR0jBBgw FoAU5wIjgABP2Ne8lAvZP3Q5STI8inkwHQYDVR0OBBYEFD+ST5hEHbTuHJZT9husDN7VLQdgMAwG A1UdEwEB/wQCMAAwIQYDVR0RBBowGIEWcGF1bC5ob2ZmbWFuQGljYW5uLm9yZzAOBgNVHQ8BAf8E BAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMEMGA1UdIAQ8MDowOAYKYIZIAYb9 bAQBAjAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy5kaWdpY2VydC5jb20vQ1BTMIGIBgNVHR8E gYAwfjA9oDugOYY3aHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hBMkFzc3VyZWRJ RENBLWcyLmNybDA9oDugOYY3aHR0cDovL2NybDQuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hBMkFz c3VyZWRJRENBLWcyLmNybDB5BggrBgEFBQcBAQRtMGswJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3Nw LmRpZ2ljZXJ0LmNvbTBDBggrBgEFBQcwAoY3aHR0cDovL2NhY2VydHMuZGlnaWNlcnQuY29tL0Rp Z2lDZXJ0U0hBMkFzc3VyZWRJRENBLmNydDANBgkqhkiG9w0BAQsFAAOCAQEAA7vGiITVJvEIgFN3 UVszD4nyt8ks8d/Ik5Uj1jPuD8+NX4lBpDOIvfYkCn8KYSrx+sMQrpoS2enbOMwekef3tObl2hVK 2Q+tv1GksPq9tQ98Ab1Odv1IM9aYaU1alR5/EEhc0uqs1Ulz2WUc8x/anf3/IpbHyEPdOCLiL9mi b4GDM8z9mqvAE+MtisqRs2+wlMzC/63sNKpA6KdfBNKMLHnyqCAKF7luGWp612yPmGoh63bBLrpR JQorI/fsv5SE2pK3Xf53W/ELf6sxWMsXm9iEgMeoAOtDeJHrv+i+vlldwHHJK6zlXIdVrjxRklyg ISXmlsdHs/sDp1MEqZTOXDCCBk4wggU2oAMCAQICEASueWBmZpAaucV/pmxb3M0wDQYJKoZIhvcN AQELBQAwZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3 LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMB4XDTEz MTEwNTEyMDAwMFoXDTI4MTEwNTEyMDAwMFowZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lD ZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hB MiBBc3N1cmVkIElEIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA3PgRIz9qte/A J3kbLQWHohBDMd8O1BUbT3ekIs4+jHDwvgeO3ScqvAEdtiwKyt1pWB9B7WoFH9pjeFkeIiwr+Lp+ yTU7VvEffEJ+JbAjGcZFONc9RPkgfGCuHLBaGAS+jzv3qfCUmqYMY0m2QRdTQDK9T+ZQelAfJUXo 8Ymvzf9e/1Dz8BcR/73FifW9YrnY+45FBIVtmc3FSE39JqsCNkXqNtdfauIagkEK3OnZ9ZEXjsYh rTg8E+Yef2ac1U3ZRtr2z1KnfTskw7TBUTXGm+vU737kewPhRL16CzfgT8uCig1xGOSm4IksG/Oy czzBsJKeGH29q33FfQihLMKfcwIDAQABo4IC+DCCAvQwEgYDVR0TAQH/BAgwBgEB/wIBADAOBgNV HQ8BAf8EBAMCAYYwNAYIKwYBBQUHAQEEKDAmMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5kaWdp Y2VydC5jb20wgYEGA1UdHwR6MHgwOqA4oDaGNGh0dHA6Ly9jcmw0LmRpZ2ljZXJ0LmNvbS9EaWdp Q2VydEFzc3VyZWRJRFJvb3RDQS5jcmwwOqA4oDaGNGh0dHA6Ly9jcmwzLmRpZ2ljZXJ0LmNvbS9E aWdpQ2VydEFzc3VyZWRJRFJvb3RDQS5jcmwwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwME MIIBswYDVR0gBIIBqjCCAaYwggGiBgpghkgBhv1sAAIEMIIBkjAoBggrBgEFBQcCARYcaHR0cHM6 Ly93d3cuZGlnaWNlcnQuY29tL0NQUzCCAWQGCCsGAQUFBwICMIIBVh6CAVIAQQBuAHkAIAB1AHMA ZQAgAG8AZgAgAHQAaABpAHMAIABDAGUAcgB0AGkAZgBpAGMAYQB0AGUAIABjAG8AbgBzAHQAaQB0 AHUAdABlAHMAIABhAGMAYwBlAHAAdABhAG4AYwBlACAAbwBmACAAdABoAGUAIABEAGkAZwBpAEMA ZQByAHQAIABDAFAALwBDAFAAUwAgAGEAbgBkACAAdABoAGUAIABSAGUAbAB5AGkAbgBnACAAUABh AHIAdAB5ACAAQQBnAHIAZQBlAG0AZQBuAHQAIAB3AGgAaQBjAGgAIABsAGkAbQBpAHQAIABsAGkA YQBiAGkAbABpAHQAeQAgAGEAbgBkACAAYQByAGUAIABpAG4AYwBvAHIAcABvAHIAYQB0AGUAZAAg AGgAZQByAGUAaQBuACAAYgB5ACAAcgBlAGYAZQByAGUAbgBjAGUALjAdBgNVHQ4EFgQU5wIjgABP 2Ne8lAvZP3Q5STI8inkwHwYDVR0jBBgwFoAUReuir/SSy4IxLVGLp6chnfNtyA8wDQYJKoZIhvcN AQELBQADggEBAE7UiSe5/R2Hd34PKAWQ8QovyTs+vZOckMav+pFRhzJUa+jKwXFRXJmOtfrgYhmZ pgeafBMn2+UCooQS2RX2CkRXxDSPbXMfOtagAT3e44LkRWuy6yX9gF4dOZC+W0L2zpFg4/mgVgxI EM4zaHvNk6vwastPWA+5e10bBIGepyLiV0kn7pKTCL5pCFMCOi5dyBn0UIBOAtmwXZG0k4f5lpaB VUCOZu2C2LsoX+1MYe0GWCgZUxFEvEcgKbIEbNiJVJk7ddtneCweknjGVT1YEhEybr1DDE0023vG QtvsvqubYUwGkuOO3yEqUFcEwGCiNdUknmY3CUnP1fhls+DibsIxggMpMIIDJQIBATB5MGUxCzAJ BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5j b20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQQIQBvN44l5anjz638FFBB+G ZzANBglghkgBZQMEAgEFAKCCAYEwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0B CQUxDxcNMjAwMjI4MTg0ODIyWjAvBgkqhkiG9w0BCQQxIgQgvFFFEjlZU8F0kszrUOPtKcgFcGWv z1IlGNrmlpR1NkswgYgGCSsGAQQBgjcQBDF7MHkwZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERp Z2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQg U0hBMiBBc3N1cmVkIElEIENBAhAG83jiXlqePPrfwUUEH4ZnMIGKBgsqhkiG9w0BCRACCzF7oHkw ZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2lj ZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hBMiBBc3N1cmVkIElEIENBAhAG83jiXlqePPrf wUUEH4ZnMA0GCSqGSIb3DQEBAQUABIIBAJ4VHaxRKUd2VG3ACefoqSLzaVkre1BLM1pN1v3Cf0x0 lm3lylu7t0mItTwbrbFbb8+3ftsZLLSxhyExQpZBKwSz0ptOJwAA4SpgU6OM3VDLmRmwWCEIxV6g QGvTGnp/1Rh0dDUrEttnn3/83v6QTEbuzYHfWA+w8NY8VIrxF73NWIs8eL1f6zhWMLm8/0zvFwmm ZavYQMDIis2xqxQHD5vx29y+aUfcCWk7deSlWqfA2S9GasXPgl+NeJZCzWoALxnejnS4szyEYAWx +83peAOHnT+jvpBVnUFPKPYy7/j7ReRG35JywriMZtkIkyTU7/mikc5am1aK3DV4BotmfwIAAAAA AAA= --Apple-Mail=_41AB472E-1B74-4814-B758-4B4E57D3A287-- From nobody Fri Feb 28 12:30:50 2020 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EBDC83A1D73; Fri, 28 Feb 2020 12:30:14 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Nancy Cam-Winget via Datatracker To: Cc: draft-ietf-git-github-wg-configuration.all@ietf.org, last-call@ietf.org, ietf-and-github@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.119.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <158292181485.22384.12881384694322889736@ietfa.amsl.com> Reply-To: Nancy Cam-Winget Date: Fri, 28 Feb 2020 12:30:14 -0800 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-git-github-wg-configuration-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Feb 2020 20:30:15 -0000 Reviewer: Nancy Cam-Winget Review result: Ready SECDIR review of draft-ietf-git-github-wg-configuration-06 Reviewer: Nancy Cam-Winget Review result: Ready with a minor nit and question I have been tracking and actually using the guidelines and tools laid out in this document; as such, it is well written and easy to follow (thank you!). My nits/question are minor: Section 1: - Subjectively, I think the last clause in the last sentence of the 2nd paragraph is superfluous “…using GitHub in a uniform way if desired”. Could be abbreviated to “…using GitHub in a uniform way.” May be sufficient Section 5: There are actually no procedures for the pull requests; admittedly, I don’t know about GitHub’s protective measures….but as I believe anyone can generate a pull request, couldn’t this be an issue from a flood and legitimacy perspective? From nobody Fri Feb 28 13:26:35 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C88023A1E44; Fri, 28 Feb 2020 13:26:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.398 X-Spam-Level: X-Spam-Status: No, score=-1.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, 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 XT39b4lcLt2u; Fri, 28 Feb 2020 13:26:14 -0800 (PST) Received: from mail-vs1-f43.google.com (mail-vs1-f43.google.com [209.85.217.43]) (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 106A83A1E43; Fri, 28 Feb 2020 13:26:14 -0800 (PST) Received: by mail-vs1-f43.google.com with SMTP id t12so2863239vso.13; Fri, 28 Feb 2020 13:26:14 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=TDhb6NhhmPUSYa/SiwFsnrx5RigqbjDZNpkmWDcn4bQ=; b=RC+Q//FjFhxsz4FIthaFtqP6zDJNEyMy0Zco82Ym73xDWxQtKzmW/nhHegbKixKQ9R 2+M48Wqrdtd4gg9Ik4dcTKnXxbm8vNZcnx6qd37qN+MHt3cuvW5Due+68JNVcOsUGkUn d5+Yip+oMkTMrxvsVb+U6x5FBxJ8+A+VAdlO6eRHeTtthiYF7XjcfgjoGpc5geMqWZ5U 25HhBDtgWlPOyXJHU999854z7p0vs7vk/t1tZ61yVdE5s5g1mrdEC2FuLf0FyG7aY1Tl M4PK7Lv2ImDhzZh/LT7YId+GuyLbvDHqhPTZgnRRb+ORgaYEhszeYDngTFTJfUTKpfQ2 o9Gg== X-Gm-Message-State: ANhLgQ1cuc9zmomOqa1OYdxbVvHxpCIdRCZfhjXmifPQmLvuCp1qmlbL gLvQY5za3cvvWr8+sKmBMh8UBHvtiNAmGI9gGd0= X-Google-Smtp-Source: ADFU+vu2l8YWvN+cTbDsYPRFVgT72IDLcjN/CCWzegZ6jv0//yhfKanLq4OlPuFI8Ha6vR2hng+a9LoPLhITYomQ7MI= X-Received: by 2002:a67:2701:: with SMTP id n1mr3702401vsn.103.1582925173037; Fri, 28 Feb 2020 13:26:13 -0800 (PST) MIME-Version: 1.0 References: <158290102597.22328.2781470606904693361@ietfa.amsl.com> <20200228181749.lvstqfpxwatblmz7@anna.jacobs.jacobs-university.de> In-Reply-To: <20200228181749.lvstqfpxwatblmz7@anna.jacobs.jacobs-university.de> From: "Y. Richard Yang" Date: Fri, 28 Feb 2020 16:26:01 -0500 Message-ID: To: =?UTF-8?B?U2Now7Zud8OkbGRlciwgSsO8cmdlbg==?= Cc: "Randriamasy, Sabine (Nokia - FR/Paris-Saclay)" , The IESG , "secdir@ietf.org" , "ops-dir@ietf.org" , "alto-chairs@ietf.org" , "draft-ietf-alto-cost-calendar@ietf.org" , IETF ALTO Content-Type: multipart/alternative; boundary="000000000000a5218c059fa97cea" Archived-At: Subject: Re: [secdir] [OPS-DIR] FW: [alto] I-D Action: draft-ietf-alto-cost-calendar-18.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Feb 2020 21:26:16 -0000 --000000000000a5218c059fa97cea Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Dear J=C3=BCrgen, Always excellent comments. Please see below. On Fri, Feb 28, 2020 at 1:18 PM Sch=C3=B6nw=C3=A4lder, J=C3=BCrgen < J.Schoenwaelder@jacobs-university.de> wrote: > On Fri, Feb 28, 2020 at 03:00:31PM +0000, Randriamasy, Sabine (Nokia - > FR/Paris-Saclay) wrote: > > Dear IESG reviewers, J=C3=BCrgen, Brian, Barry, > > > > Thank you very much for your review and suggestions. Upon your feedback= , > we have posted a new version 18, that hopefully addresses your comments. > > Besides, some lower/upper case typo harmonization has been done on > expressions such as "Client", "Server", "cost type". > > We look forward to having your feedback, > > > > Thanks for the changes. All looks good but I am still struggling a bit > with the type change of the cost field. Revision -18 has this new > text: > > [...] Therefore the implementor of this extension MUST consider > that a cost entry is an array of values. > > I do not really understand what this MUST tries to achieve or what you > expect an implementer to do exactly. > > RFC 7285 section 11.2.3.6 says: > > [...] An implementation of the protocol in this document > SHOULD assume that the cost is a JSONNumber and fail to parse if it > is not, unless the implementation is using an extension to this > document that indicates when and how costs of other data types are > signaled. > > It may help to spell out 'when and how costs of other data types are > signaled' instead of writing "the implementor [...] MUST consider". If > the idea is that the usage of an array is signaled by the usage of an > array, then say so, if there is some other way to signal this before I > try to parse, then say so as well. We should not rely on implementers > to consider and find their own solutions. > > /js > > PS: I do not know much about ALTO but out of curiosity: has it been > considered to allocate new "cost-mode" values "numerical*" and > "ordinal*" that signal that the cost field is a vector of > numerical/ordinal values and not just a scalar? > > It indeed can help a lot if we could introduce a new cost mode, but the change would be more substantial. Looking at your proposal on spelling out "when and how costs of other data types are signaled," which is an excellent suggestion. How does the following look: "... Therefore the implementor of this extension MUST consider that a cost entry is an array of values. Specifically, an implementation of this extension MUST parse the "number-of-intervals" attribute of the "calendar-attributes" in an IRD entry announcing a service providing Cost Calendar. The implementation then will know that a cost entry of the service will be an array of values, and the expected size of the array is that specified by the "number-of-intervals" attribute. Richard > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 > --000000000000a5218c059fa97cea Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear=C2=A0J=C3=BCrgen,

Always excellent comments. Please see below.

On Fri, Feb 28, 2020 at = 1:18 PM Sch=C3=B6nw=C3=A4lder, J=C3=BCrgen <J.Schoenwaelder@jacobs-university.de> wr= ote:
On Fri, Feb= 28, 2020 at 03:00:31PM +0000, Randriamasy, Sabine (Nokia - FR/Paris-Saclay= ) wrote:
> Dear IESG reviewers, J=C3=BCrgen, Brian, Barry,
>
> Thank you very much for your review and suggestions. Upon your feedbac= k, we have posted a new version 18, that hopefully addresses your comments.=
> Besides, some lower/upper case typo harmonization has been done on exp= ressions such as "Client", "Server", "cost type&qu= ot;.
> We look forward to having your feedback,
>

Thanks for the changes. All looks good but I am still struggling a bit
with the type change of the cost field. Revision -18 has this new
text:

=C2=A0 =C2=A0[...] Therefore the implementor of this extension MUST conside= r
=C2=A0 =C2=A0that a cost entry is an array of values.

I do not really understand what this MUST tries to achieve or what you
expect an implementer to do exactly.

RFC 7285 section 11.2.3.6 says:

=C2=A0 =C2=A0[...] An implementation of the protocol in this document
=C2=A0 =C2=A0SHOULD assume that the cost is a JSONNumber and fail to parse = if it
=C2=A0 =C2=A0is not, unless the implementation is using an extension to thi= s
=C2=A0 =C2=A0document that indicates when and how costs of other data types= are
=C2=A0 =C2=A0signaled.

It may help to spell out 'when and how costs of other data types are signaled' instead of writing "the implementor [...] MUST consider&= quot;. If
the idea is that the usage of an array is signaled by the usage of an
array, then say so, if there is some other way to signal this before I
try to parse, then say so as well. We should not rely on implementers
to consider and find their own solutions.

/js

PS: I do not know much about ALTO but out of curiosity: has it been
=C2=A0 =C2=A0 considered to allocate new "cost-mode" values "= ;numerical*" and
=C2=A0 =C2=A0 "ordinal*" that signal that the cost field is a vec= tor of
=C2=A0 =C2=A0 numerical/ordinal values and not just a scalar?


It indeed can help a lot if we could i= ntroduce a new cost mode, but the change would be
more substantial.

Looking at your proposal on spelling out "when a= nd how costs of other data types are
signaled," which is an excel= lent suggestion. How does the following look:

"... Therefore th= e implementor of this extension MUST consider that a cost entry is an
ar= ray of values. Specifically, an implementation of this extension MUST parse=
the "number-of-intervals" attribute of the "calendar-att= ributes" in an IRD entry
announcing a service providing Cost Calend= ar. The implementation then will
know that = a cost entry of the service will be an array of values, and the expectedsize of the array is that specified by the "number-of-intervals"= attribute.

Richard






=C2=A0
421 200 3587=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Campus= Ring 1 | 28759 Bremen | Germany
Fax:=C2=A0 =C2=A0+49 421 200 3103=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0<https://www.jacobs-university.de/>

--000000000000a5218c059fa97cea-- From nobody Sat Feb 29 00:22:04 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF99E3A0C17; Sat, 29 Feb 2020 00:21:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=jacobsuniversity.onmicrosoft.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 7k03zJ9D5H3Z; Sat, 29 Feb 2020 00:21:46 -0800 (PST) Received: from EUR03-VE1-obe.outbound.protection.outlook.com (mail-eopbgr50080.outbound.protection.outlook.com [40.107.5.80]) (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 AAF2C3A0C10; Sat, 29 Feb 2020 00:21:45 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=MHNjxm3OGmLTYMGAC08amoixQC+MRfYmM2fRjYKqHphOpiJExxlnbOZTvP1fA3s/SnujG/RMoHfwDFgSZ+ZEsNFNsjwWIHa33+bEd38cpRH8uDZ5aBrqiBv5+1Fn6M3gEM8Cei/8oUaNv23ef4t9JE4PTzXSBDErccymeQU/tNoov2b/cu/53rJyt9URTGM54TbAZhghMwQomxXzbY5VNNkNRY8l7YUA6T2Q6KL3rFY/smmcg2AlUHaD5ELSOcU6o2Pk5nqDF1epzEGCHCFIqXpEbvtIQ+cxL7WPkobAbrgAMyFTnraq0DDVrMVG9mEGO2KDf2nFvhsNRWpAXaH9QA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=3vljNeg4XpKIY8og8a2nUcpRIL6+6eka8O7o50LI7z4=; b=Buj7Mbd0GRC7Wkn+OWDlBcgIniaR8sKXgXnUBh0Ve5i9AaQxBHJi2aNyW4Qtn3GC9Bym8K+8yEjzohWbZ5Ao0zBYP+rm/ZU0YRLX6+paGRcVSxD56JTBuAmV8llqW6bi575lYD4lt8+1r83Amwd5XwAvALxdAnxuJG6of2nU5iugrZNo72HVqa8rDl7Uh9I8FQD23r9A2z73DEZ6ZIzHjgn6aBHt/y0jM9fL1r6bXQE9Bbdwl0tDU0GkbNqbGxAhJR7zrgvm4JPsN6LQQzWUGdFq36U0PlM2v7VdjyKXfCxIdO/0m1HumFFhpcg+JQdfVMXxcK04Iy+Np8tDfs+4WQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=jacobs-university.de; dmarc=pass action=none header.from=jacobs-university.de; dkim=pass header.d=jacobs-university.de; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jacobsuniversity.onmicrosoft.com; s=selector2-jacobsuniversity-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=3vljNeg4XpKIY8og8a2nUcpRIL6+6eka8O7o50LI7z4=; b=OevHl27Awvpnz1jVcmWSwZULqK6n0/SKsPTczDLqYiEkE4iu7jP9u1wEYxh2Oen92yTfeIx6nQEX4W3GaeqQlJTG1I1NDhoSAwPENAwbz+LLn2r4BbT2qGc1FvNU5WNYbmHRtUv8FAy0cQpkQHoB/EfQFBitiUfunxRDAiGZoVw= Received: from AM4P190MB0004.EURP190.PROD.OUTLOOK.COM (10.172.221.19) by AM4P190MB0100.EURP190.PROD.OUTLOOK.COM (10.172.219.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2772.16; Sat, 29 Feb 2020 08:21:40 +0000 Received: from AM4P190MB0004.EURP190.PROD.OUTLOOK.COM ([fe80::b931:fce:e8b5:ec62]) by AM4P190MB0004.EURP190.PROD.OUTLOOK.COM ([fe80::b931:fce:e8b5:ec62%10]) with mapi id 15.20.2772.018; Sat, 29 Feb 2020 08:21:40 +0000 Received: from localhost (212.201.44.247) by FRYP281CA0013.DEUP281.PROD.OUTLOOK.COM (2603:10a6:d10::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2772.14 via Frontend Transport; Sat, 29 Feb 2020 08:21:40 +0000 From: =?iso-8859-1?Q?Sch=F6nw=E4lder=2C_J=FCrgen?= To: "Y. Richard Yang" CC: "Randriamasy, Sabine (Nokia - FR/Paris-Saclay)" , The IESG , "secdir@ietf.org" , "ops-dir@ietf.org" , "alto-chairs@ietf.org" , "draft-ietf-alto-cost-calendar@ietf.org" , IETF ALTO Thread-Topic: [OPS-DIR] FW: [alto] I-D Action: draft-ietf-alto-cost-calendar-18.txt Thread-Index: AQHV7kWkb6d+ApV9CUmV4N7iECLLGqgwsxiAgAA3IICAADSVgIAAty+A Date: Sat, 29 Feb 2020 08:21:40 +0000 Message-ID: <20200229082139.5js3fxcmfrj4wo6m@anna.jacobs.jacobs-university.de> References: <158290102597.22328.2781470606904693361@ietfa.amsl.com> <20200228181749.lvstqfpxwatblmz7@anna.jacobs.jacobs-university.de> In-Reply-To: Reply-To: =?iso-8859-1?Q?Sch=F6nw=E4lder=2C_J=FCrgen?= Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-clientproxiedby: FRYP281CA0013.DEUP281.PROD.OUTLOOK.COM (2603:10a6:d10::23) To AM4P190MB0004.EURP190.PROD.OUTLOOK.COM (2603:10a6:200:65::19) authentication-results: spf=none (sender IP is ) smtp.mailfrom=J.Schoenwaelder@jacobs-university.de; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [212.201.44.247] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 2bf68bd0-2f92-4e3c-c357-08d7bcf066f3 x-ms-traffictypediagnostic: AM4P190MB0100: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 03283976A6 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(136003)(39850400004)(366004)(346002)(396003)(376002)(199004)(189003)(4326008)(54906003)(66476007)(478600001)(66556008)(6486002)(956004)(64756008)(66946007)(86362001)(1076003)(71200400001)(66446008)(296002)(5660300002)(786003)(26005)(16526019)(186003)(316002)(3450700001)(52116002)(6496006)(8936002)(53546011)(2906002)(81156014)(81166006)(6916009)(8676002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM4P190MB0100; H:AM4P190MB0004.EURP190.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: jacobs-university.de does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: a9i448wF1gQAlpqTKs2ARFnGnBFw+jStTKNpBA4k1IVc72i+cps3S94o7dhbOJnaf+qmrX5+s6TnVOWZQqHTTwEdKVrMFB3yFTE1KENE3LjhbNlb30fCS445+OmmTp9c39Pirm5Bv1LyypSc6IWrSqd6A9LNh2JVCmr6myLfEmPBBK4HKfWwN5A/xAJWtPUpADI5B3RuQbbMAcHv3h4+x6UuzxMU7Xt72jvSE/LEcjUfnb2cMvuBZoKaSrsVtQomz9CEAaZYX5tA4mxZKg7UYOhHBVZyYPU+RvMYZNUCh/JAmSUOFS10WSCc/by8vmWezU0j7netvxIWUHGkwmWPbj1HKZICvnD8/DNcPNqW54Xu/pJ9RmCKpaaBA+7yo2W6xw4hRkz9/Pp6GMwy6JURXYsvx+igxV40XqZFfUpTpJ5iDeQlDUUqC75la5aNPgvRQIjeqOLFvmU2Pj+TkD6uMsYv3osgNh0bBDJov6+TpezBnXxLQFdMs/1rE602qxMm6RYt82TlzYM26qBtoLa8WQ== x-ms-exchange-antispam-messagedata: Gw/3ytOTcEL/dSpzW5fv2mXFgNRGV8VoqovaxDRI++tTnCmosu47+qauTaC0n7D2SLXYMuZq68B7Z/kqIKOQNmHTBscwp/ndk/yVyH4zm2QzFKgBC6e1ZYY4+aHxOBlJ4cozvHkLGhNmpGNjFIzRQw== Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: jacobs-university.de X-MS-Exchange-CrossTenant-Network-Message-Id: 2bf68bd0-2f92-4e3c-c357-08d7bcf066f3 X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Feb 2020 08:21:40.3697 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f78e973e-5c0b-4ab8-bbd7-9887c95a8ebd X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: jwa3vf40G77pdCiUuvT00aR3/SM4lbDu+RVqZJb5qdaMrP4HjhKsmunNRo9ah7YITXcwKHRQ6w+moxn5ff6KCkOSnCZKSpY1ORw4LDWVS9o= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4P190MB0100 Archived-At: Subject: Re: [secdir] [OPS-DIR] FW: [alto] I-D Action: draft-ietf-alto-cost-calendar-18.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Feb 2020 08:21:48 -0000 On Fri, Feb 28, 2020 at 04:26:01PM -0500, Y. Richard Yang wrote: > Dear J=FCrgen, >=20 > Always excellent comments. Please see below. >=20 > On Fri, Feb 28, 2020 at 1:18 PM Sch=F6nw=E4lder, J=FCrgen < > J.Schoenwaelder@jacobs-university.de> wrote: >=20 > > On Fri, Feb 28, 2020 at 03:00:31PM +0000, Randriamasy, Sabine (Nokia - > > FR/Paris-Saclay) wrote: > > > Dear IESG reviewers, J=FCrgen, Brian, Barry, > > > > > > Thank you very much for your review and suggestions. Upon your feedba= ck, > > we have posted a new version 18, that hopefully addresses your comments= . > > > Besides, some lower/upper case typo harmonization has been done on > > expressions such as "Client", "Server", "cost type". > > > We look forward to having your feedback, > > > > > > > Thanks for the changes. All looks good but I am still struggling a bit > > with the type change of the cost field. Revision -18 has this new > > text: > > > > [...] Therefore the implementor of this extension MUST consider > > that a cost entry is an array of values. > > > > I do not really understand what this MUST tries to achieve or what you > > expect an implementer to do exactly. > > > > RFC 7285 section 11.2.3.6 says: > > > > [...] An implementation of the protocol in this document > > SHOULD assume that the cost is a JSONNumber and fail to parse if it > > is not, unless the implementation is using an extension to this > > document that indicates when and how costs of other data types are > > signaled. > > > > It may help to spell out 'when and how costs of other data types are > > signaled' instead of writing "the implementor [...] MUST consider". If > > the idea is that the usage of an array is signaled by the usage of an > > array, then say so, if there is some other way to signal this before I > > try to parse, then say so as well. We should not rely on implementers > > to consider and find their own solutions. > > > > /js > > > > PS: I do not know much about ALTO but out of curiosity: has it been > > considered to allocate new "cost-mode" values "numerical*" and > > "ordinal*" that signal that the cost field is a vector of > > numerical/ordinal values and not just a scalar? > > > > > It indeed can help a lot if we could introduce a new cost mode, but the > change would be > more substantial. >=20 > Looking at your proposal on spelling out "when and how costs of other dat= a > types are > signaled," which is an excellent suggestion. How does the following look: >=20 > "... Therefore the implementor of this extension MUST consider that a cos= t > entry is an > array of values. Specifically, an implementation of this extension MUST > parse > the "number-of-intervals" attribute of the "calendar-attributes" in an IR= D > entry > announcing a service providing Cost Calendar. The implementation then wil= l > know that a cost entry of the service will be an array of values, and the > expected > size of the array is that specified by the "number-of-intervals" attribut= e. >=20 So the signal is the "number-of-intervals" attribute, this works for me. I think it helps to spell this out. /js --=20 Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Sat Feb 29 04:37:53 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 778AD3A09B4; Sat, 29 Feb 2020 04:37:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.398 X-Spam-Level: X-Spam-Status: No, score=-1.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, 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 MH4VU0MeKyRO; Sat, 29 Feb 2020 04:37:34 -0800 (PST) Received: from mail-ua1-f41.google.com (mail-ua1-f41.google.com [209.85.222.41]) (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 902E63A09B5; Sat, 29 Feb 2020 04:37:34 -0800 (PST) Received: by mail-ua1-f41.google.com with SMTP id c7so1988758uaf.5; Sat, 29 Feb 2020 04:37:34 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=CGHxwca6JhKOyGTJicUcy6RVBgpTp/YGtehXJT/4Dq8=; b=lyOql8zV5sOxl7PJx3CJ95ufF35eu2FLAloF+iuvXKYmRCN5hKbXsgjH9O2+kQWj7Q hw8HV5cimtCdLh5+BvGzO2rP2NR4JW40rdzbc2Blfhicz7CzoSb2oegcsK+PQwjS3tAR 6zq08gGr+cb0QZ9zNlO1oNH70ZefZRxbeviSSHzyPzo/K8Y3dQlnjVjq2+GJ5kNYzvoZ f6rxm+4J713CDJ9RTBDmJLpD8UD6IEvjILlPQ41l1SV1/htIZ2yIiu/iHFRrNdhwdIkm Gvfn1G5D7U0uLdkCUDvQRUsmg34q8HWs7fwHOMNFn4U2W/NK4nBzKWcMYp3uPv/XoLLr AXDA== X-Gm-Message-State: ANhLgQ1/8qGc0jIdWcPMY+S0/NzmcjMac+FLdKa1GriDj/TLoSW/M876 5KpP8dkNUhFwfww6M/FoC+gNsB+Bl7KEQoEoW44= X-Google-Smtp-Source: ADFU+vv1KuAa0xBt1lHOSUl4q1JU1IlWHZBoJ+N8KiAVbDBu5XVw7aqt2aRK/H0LgcgAH/dMS29MZnWVJqROilbucI8= X-Received: by 2002:a9f:23ca:: with SMTP id 68mr4194146uao.128.1582979853539; Sat, 29 Feb 2020 04:37:33 -0800 (PST) MIME-Version: 1.0 References: <158290102597.22328.2781470606904693361@ietfa.amsl.com> <20200228181749.lvstqfpxwatblmz7@anna.jacobs.jacobs-university.de> <20200229082139.5js3fxcmfrj4wo6m@anna.jacobs.jacobs-university.de> In-Reply-To: <20200229082139.5js3fxcmfrj4wo6m@anna.jacobs.jacobs-university.de> From: "Y. Richard Yang" Date: Sat, 29 Feb 2020 07:37:22 -0500 Message-ID: To: =?UTF-8?B?U2Now7Zud8OkbGRlciwgSsO8cmdlbg==?= Cc: IETF ALTO , "Randriamasy, Sabine (Nokia - FR/Paris-Saclay)" , The IESG , "alto-chairs@ietf.org" , "draft-ietf-alto-cost-calendar@ietf.org" , "ops-dir@ietf.org" , "secdir@ietf.org" Content-Type: multipart/alternative; boundary="000000000000db5d8b059fb63785" Archived-At: Subject: Re: [secdir] [OPS-DIR] FW: [alto] I-D Action: draft-ietf-alto-cost-calendar-18.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Feb 2020 12:37:37 -0000 --000000000000db5d8b059fb63785 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sat, Feb 29, 2020 at 3:21 AM Sch=C3=B6nw=C3=A4lder, J=C3=BCrgen < J.Schoenwaelder@jacobs-university.de> wrote: > On Fri, Feb 28, 2020 at 04:26:01PM -0500, Y. Richard Yang wrote: > > Dear J=C3=BCrgen, > > > > Always excellent comments. Please see below. > > > > On Fri, Feb 28, 2020 at 1:18 PM Sch=C3=B6nw=C3=A4lder, J=C3=BCrgen < > > J.Schoenwaelder@jacobs-university.de> wrote: > > > > > On Fri, Feb 28, 2020 at 03:00:31PM +0000, Randriamasy, Sabine (Nokia = - > > > FR/Paris-Saclay) wrote: > > > > Dear IESG reviewers, J=C3=BCrgen, Brian, Barry, > > > > > > > > Thank you very much for your review and suggestions. Upon your > feedback, > > > we have posted a new version 18, that hopefully addresses your > comments. > > > > Besides, some lower/upper case typo harmonization has been done on > > > expressions such as "Client", "Server", "cost type". > > > > We look forward to having your feedback, > > > > > > > > > > Thanks for the changes. All looks good but I am still struggling a bi= t > > > with the type change of the cost field. Revision -18 has this new > > > text: > > > > > > [...] Therefore the implementor of this extension MUST consider > > > that a cost entry is an array of values. > > > > > > I do not really understand what this MUST tries to achieve or what yo= u > > > expect an implementer to do exactly. > > > > > > RFC 7285 section 11.2.3.6 says: > > > > > > [...] An implementation of the protocol in this document > > > SHOULD assume that the cost is a JSONNumber and fail to parse if i= t > > > is not, unless the implementation is using an extension to this > > > document that indicates when and how costs of other data types are > > > signaled. > > > > > > It may help to spell out 'when and how costs of other data types are > > > signaled' instead of writing "the implementor [...] MUST consider". I= f > > > the idea is that the usage of an array is signaled by the usage of an > > > array, then say so, if there is some other way to signal this before = I > > > try to parse, then say so as well. We should not rely on implementers > > > to consider and find their own solutions. > > > > > > /js > > > > > > PS: I do not know much about ALTO but out of curiosity: has it been > > > considered to allocate new "cost-mode" values "numerical*" and > > > "ordinal*" that signal that the cost field is a vector of > > > numerical/ordinal values and not just a scalar? > > > > > > > > It indeed can help a lot if we could introduce a new cost mode, but the > > change would be > > more substantial. > > > > Looking at your proposal on spelling out "when and how costs of other > data > > types are > > signaled," which is an excellent suggestion. How does the following loo= k: > > > > "... Therefore the implementor of this extension MUST consider that a > cost > > entry is an > > array of values. Specifically, an implementation of this extension MUST > > parse > > the "number-of-intervals" attribute of the "calendar-attributes" in an > IRD > > entry > > announcing a service providing Cost Calendar. The implementation then > will > > know that a cost entry of the service will be an array of values, and t= he > > expected > > size of the array is that specified by the "number-of-intervals" > attribute. > > > > So the signal is the "number-of-intervals" attribute, this works for > me. I think it helps to spell this out. > Yes. Exactly. Thanks a lot for the help! Richard > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 > --=20 Richard --000000000000db5d8b059fb63785 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Sat, Feb 29, 2020 at 3:21 AM Sch=C3=B6nw=C3=A4lder, J=C3= =BCrgen <J.Schoe= nwaelder@jacobs-university.de> wrote:
On Fri, Feb 28, 2020 at 04:26:01PM -0500, Y. Richard Yang wrote:<= br> > Dear J=C3=BCrgen,
>
> Always excellent comments. Please see below.
>
> On Fri, Feb 28, 2020 at 1:18 PM Sch=C3=B6nw=C3=A4lder, J=C3=BCrgen <= ;
> J.Schoenwaelder@jacobs-university.de> wrote:
>
> > On Fri, Feb 28, 2020 at 03:00:31PM +0000, Randriamasy, Sabine (No= kia -
> > FR/Paris-Saclay) wrote:
> > > Dear IESG reviewers, J=C3=BCrgen, Brian, Barry,
> > >
> > > Thank you very much for your review and suggestions. Upon yo= ur feedback,
> > we have posted a new version 18, that hopefully addresses your co= mments.
> > > Besides, some lower/upper case typo harmonization has been d= one on
> > expressions such as "Client", "Server", "= ;cost type".
> > > We look forward to having your feedback,
> > >
> >
> > Thanks for the changes. All looks good but I am still struggling = a bit
> > with the type change of the cost field. Revision -18 has this new=
> > text:
> >
> >=C2=A0 =C2=A0 [...] Therefore the implementor of this extension MU= ST consider
> >=C2=A0 =C2=A0 that a cost entry is an array of values.
> >
> > I do not really understand what this MUST tries to achieve or wha= t you
> > expect an implementer to do exactly.
> >
> > RFC 7285 section 11.2.3.6 says:
> >
> >=C2=A0 =C2=A0 [...] An implementation of the protocol in this docu= ment
> >=C2=A0 =C2=A0 SHOULD assume that the cost is a JSONNumber and fail= to parse if it
> >=C2=A0 =C2=A0 is not, unless the implementation is using an extens= ion to this
> >=C2=A0 =C2=A0 document that indicates when and how costs of other = data types are
> >=C2=A0 =C2=A0 signaled.
> >
> > It may help to spell out 'when and how costs of other data ty= pes are
> > signaled' instead of writing "the implementor [...] MUST= consider". If
> > the idea is that the usage of an array is signaled by the usage o= f an
> > array, then say so, if there is some other way to signal this bef= ore I
> > try to parse, then say so as well. We should not rely on implemen= ters
> > to consider and find their own solutions.
> >
> > /js
> >
> > PS: I do not know much about ALTO but out of curiosity: has it be= en
> >=C2=A0 =C2=A0 =C2=A0considered to allocate new "cost-mode&quo= t; values "numerical*" and
> >=C2=A0 =C2=A0 =C2=A0"ordinal*" that signal that the cost= field is a vector of
> >=C2=A0 =C2=A0 =C2=A0numerical/ordinal values and not just a scalar= ?
> >
> >
> It indeed can help a lot if we could introduce a new cost mode, but th= e
> change would be
> more substantial.
>
> Looking at your proposal on spelling out "when and how costs of o= ther data
> types are
> signaled," which is an excellent suggestion. How does the followi= ng look:
>
> "... Therefore the implementor of this extension MUST consider th= at a cost
> entry is an
> array of values. Specifically, an implementation of this extension MUS= T
> parse
> the "number-of-intervals" attribute of the "calendar-at= tributes" in an IRD
> entry
> announcing a service providing Cost Calendar. The implementation then = will
> know that a cost entry of the service will be an array of values, and = the
> expected
> size of the array is that specified by the "number-of-intervals&q= uot; attribute.
>

So the signal is the "number-of-intervals" attribute, this works = for
me. I think it helps to spell this out.

Yes. Exactly. Th= anks a lot for the help!

Richard=C2=A0


/js

--
Juergen Schoenwaelder=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Jacobs Univer= sity Bremen gGmbH
Phone: +49 421 200 3587=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Campus Ring 1 | 28= 759 Bremen | Germany
Fax:=C2=A0 =C2=A0+49 421 200 3103=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<https://www.jacobs-university.de/>
--
Richard
--000000000000db5d8b059fb63785-- From nobody Sat Feb 29 14:57:26 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCC293A153E; Sat, 29 Feb 2020 14:57:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.612 X-Spam-Level: X-Spam-Status: No, score=-1.612 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.276, T_SPF_PERMERROR=0.01, 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 dvEzWFSz5rMF; Sat, 29 Feb 2020 14:57:15 -0800 (PST) Received: from exchange.uccs.edu (uccs-ex1.uccs.edu [128.198.1.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8447B3A153D; Sat, 29 Feb 2020 14:57:12 -0800 (PST) Received: from mail-ed1-f46.google.com (209.85.208.46) by UCCS-EX1.uccs.edu (128.198.1.101) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Sat, 29 Feb 2020 15:57:10 -0700 Received: by mail-ed1-f46.google.com with SMTP id y3so1624145edj.13; Sat, 29 Feb 2020 14:57:10 -0800 (PST) X-Gm-Message-State: APjAAAVnr0ZrUZYRCYC0G5GmYfJHIwuv1lylYril4MExuSvcBYzhuiqc vYUrmYK3j44FX2j+jPVbkyZCOPi0hFaPJ/kEyLo= X-Google-Smtp-Source: APXvYqyGyIIeHYuC/if5PP85UYU0bssR1RyFysdn0ZNAqzy2XDKUIvOgEyi1Ps5Sb/2sztIqxyx/JDInLVfgnS6Wnrs= X-Received: by 2002:a17:906:7c9:: with SMTP id m9mr9527376ejc.243.1583017028791; Sat, 29 Feb 2020 14:57:08 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: "Shawn M. Emery" Date: Sat, 29 Feb 2020 17:56:56 -0500 X-Gmail-Original-Message-ID: Message-ID: To: "Kamran Raza (skraza)" CC: secdir , "draft-ietf-mpls-ldp-yang.all@ietf.org" Content-Type: multipart/alternative; boundary="000000000000acb56e059fbedf45" X-Originating-IP: [209.85.208.46] X-ClientProxiedBy: UCCS-EX4.uccs.edu (128.198.1.104) To UCCS-EX1.uccs.edu (128.198.1.101) Archived-At: Subject: Re: [secdir] Updated rev posted [Re: Review of draft-ietf-mpls-ldp-yang-07] X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Feb 2020 22:57:20 -0000 --000000000000acb56e059fbedf45 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thank you for the major update, the Security Consideration section looks much better. Here are my comments with rev 08: 1. In section 10.1.2, it states that LDP peer authentication can be augmented via a key generated with an algorithm such as MD5. I know it may be out of scope from this document, but why is MD5 given as an example rather than scrypt or is the assumption that the keys are based on high entropy? 2. In section 10.1.3, it states: These are the operations and their sensitivity/vulnerability: ... but the vulnerabilities were listed before this statement. Should reorder. Regards, Shawn. -- On Thu, Feb 27, 2020 at 11:26 PM Kamran Raza (skraza) wrote: > Thanks for your review and comments. > > We have just posted a new rev -08 that takes care of your comments and > comments from other IESG reviewers. > > On behalf of authors, please see inline [skraza]: > > > > *From: *"Shawn M. Emery" > *Date: *Monday, November 25, 2019 at 5:34 PM > *To: *secdir , "draft-ietf-mpls-ldp-yang.all@ietf.org" < > draft-ietf-mpls-ldp-yang.all@ietf.org> > *Cc: *Shawn Emery > *Subject: *Review of draft-ietf-mpls-ldp-yang-07 > *Resent-From: * > *Resent-To: *, , < > xufeng.liu.ietf@gmail.com>, , < > jescia.chenxia@huawei.com>, , , < > tsaad.net@gmail.com>, , , < > martin.vigoureux@nokia.com>, , , > Nicolai Leymann , Tarek Saad > *Resent-Date: *Monday, November 25, 2019 at 5:33 PM > > > > Reviewer: Shawn M. Emery > Review result: Ready with nits > > > > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the IESG. > These comments were written primarily for the benefit of the security > area directors. Document editors and WG chairs should treat these > comments just like any other last call comments. > > > > This draft specifies a YANG model for the Multi-Protocol Label > > Switching (MPLS) Label Distribution Protocol (LDP). Network > > Configuration Protocol (NETCONF) and RESTCONF is used > > to mange network devices based on this model. > > > > The security considerations section does exist and for security > > and privacy concerns, discusses that the MTI for NETCONF is > > SSH and TLS for RESTCONF. For authorization, NETCONF > > and RESTCONF uses the Network Configuration Access Control > > Model (NACM). > > > > The section goes on to state that some data nodes > > and RPC operations in the YANG module are considered sensitive > > to various operations, but does not give guidance on which nodes > > or subtrees that would be affected. In the past, module specifications > > that I've reviewed have outlined each of these relevant items. > > > > [skraza]: Enhanced this section significantly and have added the relevant > items to this section. See draft rev -08. > > > > The section finishes with the statement that the security > > properties of the base specifications, LDP, LDP IPv6, etc., also applies > > to this draft. I agree with the above assertions. > > > > General comments: > > > > None. > > > > Editorial comments: > > [skraza]: Fixed all the listed. > > > > s/into following/into the following/ > > s/means and be read/should be read/ > > s/family"/family"./ > > s/VPN Forwarding and Routing/VPN Routing and Forwarding/ > > s/provides a mean/provides a means/ > > s/Neibgbor/Neighbor/ > > s/pereference/preference/ > > s/creatable\/ deletable/creatable\/deletable/ > > > > RESTCONF should be expanded on first ocurence. > > [skraza]: I could not find the expansion =E2=80=93 even in the RESTCONF R= FC 8040 . > > > > Shawn. > > -- > --000000000000acb56e059fbedf45 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thank you for the major update, the Security Consideration= section looks much better.=C2=A0 Here are my comments with rev 08:
1. In section 10.1.2, it states that LDP peer authentication ca= n be augmented via a key generated with an algorithm such as MD5.=C2=A0 I k= now it may be out of scope from this document, but why is MD5 given as an e= xample rather than scrypt or is the assumption that the keys are based on h= igh entropy?

2. In section 10.1.3, it states:<= br>
These are the operations and their sensitivity/vulnerabil= ity:
...

but the vulnerabilities were li= sted before this statement.=C2=A0 Should reorder.=C2=A0

=
Regards,

Shawn.
--
<= /div>

On Thu, Feb 27, 2020 at 11:26 PM Kamran Raza (skraza) <skraza@cisco.com> wrote:

Thanks for your review and comments.

We have just posted a= new rev -08 that takes care of your comments and comments from other IESG = reviewers.

On behalf of authors, please see inline [skraza]:

=C2=A0

From: = "Shawn M. Emery&= quot; <semery@uccs.= edu>
Date: Monday, November 25, 2019 at 5:34 PM
To: secdir <= secdir@ietf.org>, "draft-ietf-mpls-ldp-yang.all@ietf.org&qu= ot; <draft-ietf-mpls-ldp-yang.all@ietf.org>
Cc: Shawn Emery <shawn.emery@gmail.com>
Subject: Review of draft-ietf-mpls-ldp-yang-07
Resent-From: <alias-bounces@ietf.org>
Resent-To: <skraza@cisco.com>, <rajiva@cisco.com>, <xufeng.liu.ietf@gmail.com>, <sesale@juniper.net>= ;, <jesci= a.chenxia@huawei.com>, <hshah@ciena.com>, <mach.chen@huawei.com>, <tsaad.net@gmail.com>, <n.leymann@telekom.d= e>, <loa@pi.nu= >, <m= artin.vigoureux@nokia.com>, <db3546@att.com= >, <areta= na.ietf@gmail.com>, Nicolai Leymann <n.leymann@telekom.de>, Tarek Saad <= tsaad.net@gmail.co= m>
Resent-Date: Monday, November 25, 2019 at 5:33 PM

=C2=A0

Reviewer: Shawn M. Emery
Review result:=C2=A0Ready with nits

=C2=A0

I have reviewed this= document as part of the security directorate's
ongoing effort to review all=C2=A0IETF=C2=A0documents being processed by th= e IESG.
These comments were written primarily for the benefit of the security
area directors. Document editors and WG chairs should treat these
comments just like any other last call comments.

=C2=A0=

This draft specifies= a YANG model for the=C2=A0Multi-Prot= ocol Label

Switching (MPLS) Labe= l Distribution Protocol (LDP).=C2=A0=C2=A0Network

Configuration Protoco= l (NETCONF) and RESTCONF is used<= /u>

to mange network=C2= =A0devices based on this model.=C2=A0=C2=A0

=C2=A0=

The security conside= rations section does exist and for security

and privacy concerns= ,=C2=A0discusses=C2=A0that the MTI for NETCONF is

SSH and TLS=C2=A0for= RESTCONF.=C2=A0 For authorization, NETCONF

and RESTCONF uses th= e=C2=A0Network Configuration Access C= ontrol

Model (NACM).<= span style=3D"font-size:9.5pt">

=C2=A0=

The section goes on t= o state that some data nodes<= u>

and RPC operations in= the YANG module are considered sensitive

to various operations= ,=C2=A0but does not give guidance on which nodes

or subtrees that woul= d=C2=A0be affected.=C2=A0 In the past, module specifications

that I've reviewe= d have outlined each of these relevant items.

=C2=A0=

[skraza]: Enhanced this section significantly and= have added the relevant items to this section. See draft rev -08.

=C2=A0

The section finishes = with the statement that the security=

properties of the bas= e specifications, LDP, LDP IPv6, etc., also applies

to this draft.=C2=A0= =C2=A0I agree with the above assertions.

=C2=A0=

General comments:=

=C2=A0=

None.<= /span>

=C2=A0=

Editorial comments:

[skraza]: Fixed all the listed. <= u>

=C2=A0

s/into following/into the following/

s/means and be read/should be read/

s/family"/family"./

s/VPN Forwarding and Routing/VPN Routing and Forward= ing/

s/provides a mean/provides a means/

s/Neibgbo= r/Neighbor/

s/= pereference/preference/

s/creatable\/ deletable/creatable\/deletable/=

=C2=A0

RESTCONF should be expanded on first ocurence.

[skraza]: I could not find the expansion =E2=80= =93 even in the RESTCONF RFC 8040 . <= u>

=C2=A0

Shawn.

--

--000000000000acb56e059fbedf45--