From nobody Tue Jul 14 08:13:31 2015 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 882D51ACE9F for ; Tue, 14 Jul 2015 08:13:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.341 X-Spam-Level: X-Spam-Status: No, score=0.341 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b2OSrFHHeOxd for ; Tue, 14 Jul 2015 08:13:28 -0700 (PDT) Received: from COL004-OMC2S5.hotmail.com (col004-omc2s5.hotmail.com [65.55.34.79]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 327441ACEB7 for ; Tue, 14 Jul 2015 08:13:22 -0700 (PDT) Received: from COL125-W13 ([65.55.34.71]) by COL004-OMC2S5.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.23008); Tue, 14 Jul 2015 08:13:21 -0700 X-TMN: [7oSv53NaiCyZhrtZVk0Ea8GN8wOzlTSW] X-Originating-Email: [denghui02@hotmail.com] Message-ID: Content-Type: multipart/alternative; boundary="_9a24f634-5b58-4b7e-aa68-a179ebddce23_" From: Hui Deng To: "mif@ietf.org" , Margaret Date: Tue, 14 Jul 2015 23:13:21 +0800 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 14 Jul 2015 15:13:21.0639 (UTC) FILETIME=[9F2F7F70:01D0BE47] Archived-At: Subject: [mif] WGLC for draft-ietf-mif-mpvd-ndp-support X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jul 2015 15:13:30 -0000 --_9a24f634-5b58-4b7e-aa68-a179ebddce23_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGVsbG8gYWxsDQogDQpUaGlzIGVtYWlsIGluaXRpYXRlcyAzIHdlZWtzIFdHTEMgZm9yIHRoZSBk b2N1bWVudCBiZWxvdzoNCmh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0 Zi1taWYtbXB2ZC1uZHAtc3VwcG9ydC8NCiANCkFjY29yZGluZyB0byBvdXIgd29ya2luZyBncm91 cCBkaXNjdXNzaW9uLCB3ZSBuZWVkIDQtNSBzdWJzdGFudGl2ZSByZXZpZXdzIGZvciB0aGlzIGRv Y3VtZW50IA0KYmVmb3JlIHdlIG1vdmUgZm9yd2FyZCB0aGlzIGRvY3VtZW50IHRvIElFU0cuDQog DQpUaGlzIFdHTEMgd2lsbCBlbmQgb24gQXVnLiA1dGgNCiANClRoYW5rcyBhIGxvdCBmb3IgeW91 ciBraW5kIHJldmlldw0KIA0KREVORyBIdWkNCiAJCSAJICAgCQkgIA== --_9a24f634-5b58-4b7e-aa68-a179ebddce23_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxzdHlsZT48IS0tDQouaG1tZXNzYWdlIFANCnsNCm1hcmdpbjowcHg7 DQpwYWRkaW5nOjBweA0KfQ0KYm9keS5obW1lc3NhZ2UNCnsNCmZvbnQtc2l6ZTogMTJwdDsNCmZv bnQtZmFtaWx5OkNhbGlicmkNCn0NCi0tPjwvc3R5bGU+PC9oZWFkPg0KPGJvZHkgY2xhc3M9J2ht bWVzc2FnZSc+PGRpdiBkaXI9J2x0cic+SGVsbG8gYWxsPEJSPiZuYnNwOzxCUj5UaGlzJm5ic3A7 ZW1haWwgaW5pdGlhdGVzIDMgd2Vla3MgV0dMQyBmb3IgdGhlIGRvY3VtZW50IGJlbG93OjxCUj48 YSBocmVmPSJodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtbWlmLW1w dmQtbmRwLXN1cHBvcnQvIj5odHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWll dGYtbWlmLW1wdmQtbmRwLXN1cHBvcnQvPC9hPjxCUj4mbmJzcDs8QlI+QWNjb3JkaW5nIHRvIG91 ciB3b3JraW5nIGdyb3VwIGRpc2N1c3Npb24sIHdlIG5lZWQgNC01Jm5ic3A7c3Vic3RhbnRpdmUg cmV2aWV3cyBmb3IgdGhpcyBkb2N1bWVudCA8QlI+YmVmb3JlIHdlIG1vdmUgZm9yd2FyZCB0aGlz IGRvY3VtZW50IHRvIElFU0cuPEJSPiZuYnNwOzxCUj5UaGlzIFdHTEMgd2lsbCBlbmQgb24gQXVn LiA1dGg8QlI+Jm5ic3A7PEJSPlRoYW5rcyBhIGxvdCBmb3IgeW91ciBraW5kIHJldmlldzxCUj4m bmJzcDs8QlI+REVORyBIdWk8QlI+IAkJIAkgICAJCSAgPC9kaXY+PC9ib2R5Pg0KPC9odG1sPg== --_9a24f634-5b58-4b7e-aa68-a179ebddce23_-- From nobody Tue Jul 14 08:16:08 2015 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C02AF1ACEC8 for ; Tue, 14 Jul 2015 08:16:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.359 X-Spam-Level: X-Spam-Status: No, score=-2.359 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sBpwQamwv8a7 for ; Tue, 14 Jul 2015 08:16:06 -0700 (PDT) Received: from COL004-OMC2S16.hotmail.com (col004-omc2s16.hotmail.com [65.55.34.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 299001ACEBB for ; Tue, 14 Jul 2015 08:16:06 -0700 (PDT) Received: from COL125-W23 ([65.55.34.72]) by COL004-OMC2S16.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.23008); Tue, 14 Jul 2015 08:16:05 -0700 X-TMN: [P5KTHtw5I77wusUqGZVk52lNJM/YZ7na] X-Originating-Email: [denghui02@hotmail.com] Message-ID: Content-Type: multipart/alternative; boundary="_c94dfd92-4882-4c03-a836-9f029d5007ae_" From: Hui Deng To: "mif@ietf.org" , Margaret Date: Tue, 14 Jul 2015 23:16:05 +0800 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 14 Jul 2015 15:16:05.0254 (UTC) FILETIME=[00B52A60:01D0BE48] Archived-At: Subject: [mif] WGLC for draft-ietf-mif-mpvd-dhcp-support X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jul 2015 15:16:07 -0000 --_c94dfd92-4882-4c03-a836-9f029d5007ae_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGVsbG8gYWxsDQogDQpUaGlzIGVtYWlsIGluaXRpYXRlcyAzIHdlZWtzIFdHTEMgZm9yIGJlbG93 IGRvY3VtZW50Og0KaHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLW1p Zi1tcHZkLWRoY3Atc3VwcG9ydC8NCiANCkFjY29yZGluZyB0byBvdXIgd29ya2luZyBncm91cCBk aXNjdXNzaW9uLCB3ZSBuZWVkIDQtNSBzdWJzdGFudGl2ZSByZXZpZXdzIGZvciB0aGlzIGRvY3Vt ZW50IGJlZm9yZSB3ZSBtb3ZlIGl0IHRvIHRoZSBJRVNHDQogDQpUaGlzIFdHTEMgd2lsbCBlbmQg b24gQXVnLiA1dGguDQogDQpUaGFua3MgZm9yIHlvdXIgcmV2aWV3Lg0KIA0KREVORyBIdWkNCiAJ CSAJICAgCQkgIA== --_c94dfd92-4882-4c03-a836-9f029d5007ae_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxzdHlsZT48IS0tDQouaG1tZXNzYWdlIFANCnsNCm1hcmdpbjowcHg7 DQpwYWRkaW5nOjBweA0KfQ0KYm9keS5obW1lc3NhZ2UNCnsNCmZvbnQtc2l6ZTogMTJwdDsNCmZv bnQtZmFtaWx5OkNhbGlicmkNCn0NCi0tPjwvc3R5bGU+PC9oZWFkPg0KPGJvZHkgY2xhc3M9J2ht bWVzc2FnZSc+PGRpdiBkaXI9J2x0cic+SGVsbG8gYWxsPEJSPiZuYnNwOzxCUj5UaGlzIGVtYWls IGluaXRpYXRlcyAzIHdlZWtzIFdHTEMgZm9yIGJlbG93IGRvY3VtZW50OjxCUj48YSBocmVmPSJo dHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtbWlmLW1wdmQtZGhjcC1z dXBwb3J0LyI+aHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLW1pZi1t cHZkLWRoY3Atc3VwcG9ydC88L2E+PEJSPiZuYnNwOzxCUj5BY2NvcmRpbmcgdG8gb3VyIHdvcmtp bmcgZ3JvdXAgZGlzY3Vzc2lvbiwgd2UgbmVlZCA0LTUgc3Vic3RhbnRpdmUgcmV2aWV3cyBmb3Ig dGhpcyBkb2N1bWVudCBiZWZvcmUgd2UgbW92ZSBpdCB0byB0aGUgSUVTRzxCUj4mbmJzcDs8QlI+ VGhpcyBXR0xDIHdpbGwgZW5kIG9uIEF1Zy4gNXRoLjxCUj4mbmJzcDs8QlI+VGhhbmtzIGZvciB5 b3VyIHJldmlldy48QlI+Jm5ic3A7PEJSPkRFTkcgSHVpPEJSPiAJCSAJICAgCQkgIDwvZGl2Pjwv Ym9keT4NCjwvaHRtbD4= --_c94dfd92-4882-4c03-a836-9f029d5007ae_-- From nobody Tue Jul 14 08:18:51 2015 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 767B91ACED1 for ; Tue, 14 Jul 2015 08:18:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.359 X-Spam-Level: X-Spam-Status: No, score=-2.359 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tAL6jE0CvJLZ for ; Tue, 14 Jul 2015 08:18:48 -0700 (PDT) Received: from COL004-OMC2S11.hotmail.com (col004-omc2s11.hotmail.com [65.55.34.85]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 70B961ACED0 for ; Tue, 14 Jul 2015 08:18:48 -0700 (PDT) Received: from COL125-W41 ([65.55.34.72]) by COL004-OMC2S11.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.23008); Tue, 14 Jul 2015 08:18:47 -0700 X-TMN: [QA4RlJz5T1yU7QUD2/M7SweOVl09cK8P] X-Originating-Email: [denghui02@hotmail.com] Message-ID: Content-Type: multipart/alternative; boundary="_42e8b7d8-2807-4adf-bc37-c997ec0e7da4_" From: Hui Deng To: "mif@ietf.org" , Margaret Date: Tue, 14 Jul 2015 23:18:47 +0800 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 14 Jul 2015 15:18:47.0671 (UTC) FILETIME=[61840870:01D0BE48] Archived-At: Subject: [mif] WGLC for draft-ietf-mif-mpvd-id X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jul 2015 15:18:50 -0000 --_42e8b7d8-2807-4adf-bc37-c997ec0e7da4_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGVsbG8gYWxsLA0KIA0KV2Ugd291bGQgbGlrZSB0byBoYXZlIGEgMyB3ZWVrcyBXR0xDIGZvciB0 aGUgYmVsb3cgZG9jdW1lbnQ6DQpodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0 LWlldGYtbWlmLW1wdmQtaWQvDQogDQpQbGVhc2UgaGVscCB0byBzZW5kIHlvdXIgY29tbWVudHMg dG8gdGhpcyB0aHJlYWQuDQpUaGlzIFdHTEMgd2lsbCBlbmQgb24gQXVnLiA1dGguDQogDQpNYW55 IHRoYW5rcw0KIA0KREVORyBIdWkNCiAJCSAJICAgCQkgIA== --_42e8b7d8-2807-4adf-bc37-c997ec0e7da4_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxzdHlsZT48IS0tDQouaG1tZXNzYWdlIFANCnsNCm1hcmdpbjowcHg7 DQpwYWRkaW5nOjBweA0KfQ0KYm9keS5obW1lc3NhZ2UNCnsNCmZvbnQtc2l6ZTogMTJwdDsNCmZv bnQtZmFtaWx5OkNhbGlicmkNCn0NCi0tPjwvc3R5bGU+PC9oZWFkPg0KPGJvZHkgY2xhc3M9J2ht bWVzc2FnZSc+PGRpdiBkaXI9J2x0cic+SGVsbG8gYWxsLDxCUj4mbmJzcDs8QlI+V2Ugd291bGQg bGlrZSB0byBoYXZlIGEgMyB3ZWVrcyBXR0xDIGZvciB0aGUgYmVsb3cgZG9jdW1lbnQ6PEJSPjxh IGhyZWY9Imh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1taWYtbXB2 ZC1pZC8iPmh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1taWYtbXB2 ZC1pZC88L2E+PEJSPiZuYnNwOzxCUj5QbGVhc2UgaGVscCB0byBzZW5kIHlvdXIgY29tbWVudHMg dG8gdGhpcyB0aHJlYWQuPEJSPlRoaXMgV0dMQyB3aWxsIGVuZCBvbiBBdWcuIDV0aC48QlI+Jm5i c3A7PEJSPk1hbnkgdGhhbmtzPEJSPiZuYnNwOzxCUj5ERU5HIEh1aTxCUj4gCQkgCSAgIAkJICA8 L2Rpdj48L2JvZHk+DQo8L2h0bWw+ --_42e8b7d8-2807-4adf-bc37-c997ec0e7da4_-- From nobody Sat Jul 18 03:48:26 2015 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32CEF1B2AC2 for ; Sat, 18 Jul 2015 03:48:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.959 X-Spam-Level: X-Spam-Status: No, score=-0.959 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4fVZigvo1sCM for ; Sat, 18 Jul 2015 03:48:23 -0700 (PDT) Received: from COL004-OMC2S1.hotmail.com (col004-omc2s1.hotmail.com [65.55.34.75]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B17961B2AC0 for ; Sat, 18 Jul 2015 03:48:23 -0700 (PDT) Received: from COL125-W16 ([65.55.34.73]) by COL004-OMC2S1.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.23008); Sat, 18 Jul 2015 03:48:23 -0700 X-TMN: [r84flNhFqXxOKISNju94T13p0sORbj+d] X-Originating-Email: [denghui02@hotmail.com] Message-ID: Content-Type: multipart/alternative; boundary="_66223288-b889-4d20-8e49-b3806d6fd71f_" From: Hui Deng To: "mif@ietf.org" , Margaret Date: Sat, 18 Jul 2015 18:48:22 +0800 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 18 Jul 2015 10:48:23.0098 (UTC) FILETIME=[4491A9A0:01D0C147] Archived-At: Subject: [mif] draft mif agenda X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Jul 2015 10:48:25 -0000 --_66223288-b889-4d20-8e49-b3806d6fd71f_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGVsbG8gYWxsDQpQbGVhc2UgZmVlbCBmcmVlIHRvIGxldCB1cyBrbm93IHdoZXRoZXIgeW91IGhh dmUgYW55IGNvbW1lbnRzIG9uIG1pZiBhZ2VuZGEuaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcHJvY2Vl ZGluZ3MvOTMvYWdlbmRhL2FnZW5kYS05My1taWYNCnRoYW5rcyAgYSBsb3QNCkRFTkcgSHVpIAkJ IAkgICAJCSAg --_66223288-b889-4d20-8e49-b3806d6fd71f_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxzdHlsZT48IS0tDQouaG1tZXNzYWdlIFANCnsNCm1hcmdpbjowcHg7 DQpwYWRkaW5nOjBweA0KfQ0KYm9keS5obW1lc3NhZ2UNCnsNCmZvbnQtc2l6ZTogMTJwdDsNCmZv bnQtZmFtaWx5OkNhbGlicmkNCn0NCi0tPjwvc3R5bGU+PC9oZWFkPg0KPGJvZHkgY2xhc3M9J2ht bWVzc2FnZSc+PGRpdiBkaXI9J2x0cic+SGVsbG8gYWxsPGRpdj48YnI+PC9kaXY+PGRpdj5QbGVh c2UgZmVlbCBmcmVlIHRvIGxldCB1cyBrbm93IHdoZXRoZXIgeW91IGhhdmUgYW55IGNvbW1lbnRz IG9uIG1pZiBhZ2VuZGEuPC9kaXY+PGRpdj48YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9w cm9jZWVkaW5ncy85My9hZ2VuZGEvYWdlbmRhLTkzLW1pZiIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBz Oi8vd3d3LmlldGYub3JnL3Byb2NlZWRpbmdzLzkzL2FnZW5kYS9hZ2VuZGEtOTMtbWlmPC9hPjwv ZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+dGhhbmtzICZuYnNwO2EgbG90PC9kaXY+PGRpdj48YnI+ PC9kaXY+PGRpdj5ERU5HIEh1aTwvZGl2PiAJCSAJICAgCQkgIDwvZGl2PjwvYm9keT4NCjwvaHRt bD4= --_66223288-b889-4d20-8e49-b3806d6fd71f_-- From nobody Sat Jul 18 12:54:29 2015 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B02281B2C7A; Sat, 18 Jul 2015 06:24:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WU2-j7vYsWEC; Sat, 18 Jul 2015 06:24:04 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0ED531B2C78; Sat, 18 Jul 2015 06:24:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2435; q=dns/txt; s=iport; t=1437225844; x=1438435444; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=0x2mYmy4XM2JJfrWtSI09SY9Zc+F596O/IFuyZogDZg=; b=ioVXTPojYn3+GzJztRQIzMhYOus0X27RHEkUMKCqQ+qtFooZLBw4MF2J vCyb9lJVjaprtZXlH7Zztpt96YukLRhpCTgbghfVAd0eHbeV76pQmIRDB emFvVyZtCvzK5u0yzO6yF6+YMgcSYvufUWxOHBmeqdkhWV9MWsIjuH2rV 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BCAwCUUqpV/4wNJK1bgxNUaQasIo83CYFrCoRpgQoCAgKBJjgUAQEBAQEBAYEKhCMBAQEEAQEBNzQLDAQCAQgRAwEBAQsUCQchBgsUCQgCBAENBQiIEQMSDcZsDYUuAQEBAQEBAQEBAQEBAQEBAQEBAQEBF4tMgk2BVhEBIDEHBoMRgRQFkVuCdwGEboJggmoBgypGg1SMAoNHg2EmY4MZb4ENOoEEAQEB X-IronPort-AV: E=Sophos;i="5.15,499,1432598400"; d="scan'208";a="169966707" Received: from alln-core-7.cisco.com ([173.36.13.140]) by alln-iport-4.cisco.com with ESMTP; 18 Jul 2015 13:24:03 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id t6IDO3E6014538 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 18 Jul 2015 13:24:03 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.177]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.03.0195.001; Sat, 18 Jul 2015 08:24:02 -0500 From: "Bernie Volz (volz)" To: dhcwg , "mif@ietf.org" Thread-Topic: [dhcwg] WGLC in MIF WG for draft-ietf-mif-mpvd-dhcp-support Thread-Index: AQHQvuUdhpnPUl2xEEWJbRw61Eu0oZ3hOZPg Date: Sat, 18 Jul 2015 13:24:01 +0000 Message-ID: <489D13FBFA9B3E41812EA89F188F018E1CB7D9AF@xmb-rcd-x04.cisco.com> References: <55A62F35.4000001@gmail.com> In-Reply-To: <55A62F35.4000001@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.240.87] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: X-Mailman-Approved-At: Sat, 18 Jul 2015 12:54:28 -0700 Cc: "draft-ietf-mif-mpvd-dhcp-support@tools.ietf.org" Subject: Re: [mif] [dhcwg] WGLC in MIF WG for draft-ietf-mif-mpvd-dhcp-support X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Jul 2015 13:24:05 -0000 Hi: A few items regarding this draft: 1. There is still "[TODO: Should we add any other exclusions?]" in section = 6. Shouldn't this be resolved before sending this draft on? 2. RFC 7227 and general DHCPv6 options handling has avoided explicit orderi= ng of options (or encapsulated options). So, why specify: "The OPTION_PVD_A= UTH option MUST be the last option inside the OPTION_PVD option" in section= 5? I presume (though it is not explicitly stated) that this is because this op= tion contains the signature and obviously one can't generate the signature = of the signature. But given how the signature is calculated, why is this ev= en an issue? Can we avoid enforcing the order here? I cannot see how this matters and wh= at the benefit is? If there is a reason for this ordering, please explain. Perhaps this comes from SEND document, but even then there is the question = as to why this is needed. Anyway, these are some initial comments.=20 - Bernie -----Original Message----- From: dhcwg [mailto:dhcwg-bounces@ietf.org] On Behalf Of Tomek Mrugalski Sent: Wednesday, July 15, 2015 6:00 AM To: dhcwg Cc: mif-chairs@ietf.org Subject: [dhcwg] WGLC in MIF WG for draft-ietf-mif-mpvd-dhcp-support Gentlepeople, There's working group last call going in the mif working group for the mult= iple provisioning domains proposal. One of those drafts (draft-ietf-mif-mpvd-dhcp-support) defines DHCPv6 options. I'd appreciate a= ny comments you may have on this. Make sure you post your comments in a way= that will reach the draft authors - either cc them directly or perhaps sen= d to both dhc and mif. They may not be subscribed to the dhc list. Tomek -------- Forwarded Message -------- Subject: [mif] WGLC for draft-ietf-mif-mpvd-dhcp-support Date: Tue, 14 Jul 2015 23:16:05 +0800 From: Hui Deng To: mif@ietf.org , Margaret Hello all This email initiates 3 weeks WGLC for below document: http://datatracker.ietf.org/doc/draft-ietf-mif-mpvd-dhcp-support/ According to our working group discussion, we need 4-5 substantive reviews = for this document before we move it to the IESG This WGLC will end on Aug. 5th. Thanks for your review. DENG Hui _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From nobody Mon Jul 20 04:39:32 2015 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1DD71A21B9 for ; Mon, 20 Jul 2015 04:39:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.389 X-Spam-Level: X-Spam-Status: No, score=-1.389 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6DsZoaktaMDk for ; Mon, 20 Jul 2015 04:39:30 -0700 (PDT) Received: from mail-ie0-x231.google.com (mail-ie0-x231.google.com [IPv6:2607:f8b0:4001:c03::231]) (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 7AEA61A21B6 for ; Mon, 20 Jul 2015 04:39:27 -0700 (PDT) Received: by iecri3 with SMTP id ri3so20263800iec.2 for ; Mon, 20 Jul 2015 04:39:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=ezn1F7sRbaCXFGnGi/xaf8ShJCtvIC8WBVgdJ2FhMVc=; b=U+Kk9zlo9aALMRrhBiO+INbNr/X8Wmm0+HvrWx95dYJQV7KcQ249BOq2TdkPIsKyLl rWYTrqdULIR5dztUPAkq5BR9BROMQHVl+30xAs46RMHwt0nzH0O+pCtlmBSOe7DjlI7f l3lIOBdfs4zekziLBY6VV3+jGZj9+imJZDTXcooltMNDbyy6DadyuG3Tq1rYNvJBofMY 2ecH5opjKDWHFC/4r+zhqFrX8JDiCW38QwM8ANsTzarL6gXzbidZ2CobHEr2BOtYjkOl mfic94F0y4uQXbqzwVKL1rNT92a2JtCCM5z0pwgX3vHWs2bQnKMzaa3hJGiRQSDCKqvx 0fTQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=ezn1F7sRbaCXFGnGi/xaf8ShJCtvIC8WBVgdJ2FhMVc=; b=VdpUJbeZRBmK5GFxoSei3GujJ06QBJ5OEhemZ6VUfQ36GAcTF/t48HjYMdzjecrc1n HugoPwiIBheCtCHnsaiSkxp52Y99C1ykqhs19aObJD5qnOR+IfijrIgBRw/DSl4tDcEt oOCWl6qrV24lk7fgDVetHQg442NWMegLA38gu7Zkp/efr5DtxFkNMNoWH79fvtKX4rwU 6sgOSIX8xuHwKOcTxUsHfCv40BUlcuno/3fHoO+BIFEkd0jxP/njrno6epz9+pplLel+ 1WSDgDZ7t20AleXBaLjGmKXrJtCu2rm5RxpMoXDhuUedgV9eNdORz7Xgsyzx7s+U9Lw+ WSFQ== X-Gm-Message-State: ALoCoQnlhwh6TwOYtmP8vFIgl3OYDy+55W3Gv/DgQxIzfOD5+fwBOMcnxm+WYJ1ZGM0wAz0prQn/ X-Received: by 10.107.16.223 with SMTP id 92mr39389113ioq.14.1437392366813; Mon, 20 Jul 2015 04:39:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.138.203 with HTTP; Mon, 20 Jul 2015 04:39:04 -0700 (PDT) In-Reply-To: <489D13FBFA9B3E41812EA89F188F018E1CB7D9AF@xmb-rcd-x04.cisco.com> References: <55A62F35.4000001@gmail.com> <489D13FBFA9B3E41812EA89F188F018E1CB7D9AF@xmb-rcd-x04.cisco.com> From: Erik Kline Date: Mon, 20 Jul 2015 13:39:04 +0200 Message-ID: To: "Bernie Volz (volz)" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: dhcwg , "mif@ietf.org" , "draft-ietf-mif-mpvd-dhcp-support@tools.ietf.org" Subject: Re: [mif] [dhcwg] WGLC in MIF WG for draft-ietf-mif-mpvd-dhcp-support X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jul 2015 11:39:31 -0000 I think the encapsulation matters so that you can have data for PVD1 and data for PVD2 clearly and correctly associated in one logical response. On 18 July 2015 at 15:24, Bernie Volz (volz) wrote: > Hi: > > A few items regarding this draft: > > 1. There is still "[TODO: Should we add any other exclusions?]" in sectio= n 6. Shouldn't this be resolved before sending this draft on? > > 2. RFC 7227 and general DHCPv6 options handling has avoided explicit orde= ring of options (or encapsulated options). So, why specify: "The OPTION_PVD= _AUTH option MUST be the last option inside the OPTION_PVD option" in secti= on 5? > > I presume (though it is not explicitly stated) that this is because this = option contains the signature and obviously one can't generate the signatur= e of the signature. But given how the signature is calculated, why is this = even an issue? > > Can we avoid enforcing the order here? I cannot see how this matters and = what the benefit is? > > If there is a reason for this ordering, please explain. > > Perhaps this comes from SEND document, but even then there is the questio= n as to why this is needed. > > > Anyway, these are some initial comments. > > - Bernie > > -----Original Message----- > From: dhcwg [mailto:dhcwg-bounces@ietf.org] On Behalf Of Tomek Mrugalski > Sent: Wednesday, July 15, 2015 6:00 AM > To: dhcwg > Cc: mif-chairs@ietf.org > Subject: [dhcwg] WGLC in MIF WG for draft-ietf-mif-mpvd-dhcp-support > > Gentlepeople, > > There's working group last call going in the mif working group for the mu= ltiple provisioning domains proposal. One of those drafts > (draft-ietf-mif-mpvd-dhcp-support) defines DHCPv6 options. I'd appreciate= any comments you may have on this. Make sure you post your comments in a w= ay that will reach the draft authors - either cc them directly or perhaps s= end to both dhc and mif. They may not be subscribed to the dhc list. > > Tomek > > -------- Forwarded Message -------- > Subject: [mif] WGLC for draft-ietf-mif-mpvd-dhcp-support > Date: Tue, 14 Jul 2015 23:16:05 +0800 > From: Hui Deng > To: mif@ietf.org , Margaret > > Hello all > > This email initiates 3 weeks WGLC for below document: > http://datatracker.ietf.org/doc/draft-ietf-mif-mpvd-dhcp-support/ > > According to our working group discussion, we need 4-5 substantive review= s for this document before we move it to the IESG > > This WGLC will end on Aug. 5th. > > Thanks for your review. > > DENG Hui > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg From nobody Mon Jul 20 04:47:42 2015 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61B751A6FEC; Mon, 20 Jul 2015 04:47:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e0ZTyzzM9sSh; Mon, 20 Jul 2015 04:47:30 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 23CF71A6F34; Mon, 20 Jul 2015 04:47:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3305; q=dns/txt; s=iport; t=1437392846; x=1438602446; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=5rjyP4VdAgc/du0twsPTunlmW9TYRkdgvRO4ApWlJsI=; b=AdWb/0ZZVmEhukPBlWKhBL1VRrRVj8A54iqZtLqNqacPS2o56Hfcly/g Yg/XESaZkK3UZjKkI6ZVQRFxSYLLuNxdAKPzko3NX5ebZjrPnBV2v8k5d xKzucf4fLYkt4yWXC7VZJe9voEZIFgXYi+NRHyEinFCfwG+kX1HIZEd08 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BPAwAb36xV/5xdJa1cgxNUaawzjzcJgWsKhGmBDgKBKDgUAQEBAQEBAYEKhCMBAQEDAQEBATc0CwUHBAIBCA4DAwEBAQEeCQchBgsUCQgCBA4FiBkDCggNv38NhS4BAQEBAQEBAQEBAQEBAQEBAQEBAQEXi0yCTYFWEQEeMwcGgxGBFAWUUgGEboJggmoBgWeBQ0aDVIwCg0eDYSZjgxlvgQ2BPgEBAQ X-IronPort-AV: E=Sophos;i="5.15,507,1432598400"; d="scan'208";a="13255329" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-4.cisco.com with ESMTP; 20 Jul 2015 11:47:25 +0000 Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id t6KBlOir029292 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 20 Jul 2015 11:47:25 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.177]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.03.0195.001; Mon, 20 Jul 2015 06:47:24 -0500 From: "Bernie Volz (volz)" To: Erik Kline Thread-Topic: [dhcwg] WGLC in MIF WG for draft-ietf-mif-mpvd-dhcp-support Thread-Index: AQHQvuUdhpnPUl2xEEWJbRw61Eu0oZ3hOZPggANd0AD//66Cdw== Date: Mon, 20 Jul 2015 11:47:23 +0000 Message-ID: <41023767-2645-45A7-826A-250FD74DCBD7@cisco.com> References: <55A62F35.4000001@gmail.com> <489D13FBFA9B3E41812EA89F188F018E1CB7D9AF@xmb-rcd-x04.cisco.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: dhcwg , "mif@ietf.org" , "draft-ietf-mif-mpvd-dhcp-support@tools.ietf.org" Subject: Re: [mif] [dhcwg] WGLC in MIF WG for draft-ietf-mif-mpvd-dhcp-support X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jul 2015 11:47:32 -0000 I don't think that applies as each PVD is a separate option with encapsulat= ions, including the OPTION_PVD_AUTH option. This PVD_AUTH option covers eac= h PVD. - Bernie (from iPad) > On Jul 20, 2015, at 7:39 AM, Erik Kline wrote: >=20 > I think the encapsulation matters so that you can have data for PVD1 > and data for PVD2 clearly and correctly associated in one logical > response. >=20 >> On 18 July 2015 at 15:24, Bernie Volz (volz) wrote: >> Hi: >>=20 >> A few items regarding this draft: >>=20 >> 1. There is still "[TODO: Should we add any other exclusions?]" in secti= on 6. Shouldn't this be resolved before sending this draft on? >>=20 >> 2. RFC 7227 and general DHCPv6 options handling has avoided explicit ord= ering of options (or encapsulated options). So, why specify: "The OPTION_PV= D_AUTH option MUST be the last option inside the OPTION_PVD option" in sect= ion 5? >>=20 >> I presume (though it is not explicitly stated) that this is because this= option contains the signature and obviously one can't generate the signatu= re of the signature. But given how the signature is calculated, why is this= even an issue? >>=20 >> Can we avoid enforcing the order here? I cannot see how this matters and= what the benefit is? >>=20 >> If there is a reason for this ordering, please explain. >>=20 >> Perhaps this comes from SEND document, but even then there is the questi= on as to why this is needed. >>=20 >>=20 >> Anyway, these are some initial comments. >>=20 >> - Bernie >>=20 >> -----Original Message----- >> From: dhcwg [mailto:dhcwg-bounces@ietf.org] On Behalf Of Tomek Mrugalski >> Sent: Wednesday, July 15, 2015 6:00 AM >> To: dhcwg >> Cc: mif-chairs@ietf.org >> Subject: [dhcwg] WGLC in MIF WG for draft-ietf-mif-mpvd-dhcp-support >>=20 >> Gentlepeople, >>=20 >> There's working group last call going in the mif working group for the m= ultiple provisioning domains proposal. One of those drafts >> (draft-ietf-mif-mpvd-dhcp-support) defines DHCPv6 options. I'd appreciat= e any comments you may have on this. Make sure you post your comments in a = way that will reach the draft authors - either cc them directly or perhaps = send to both dhc and mif. They may not be subscribed to the dhc list. >>=20 >> Tomek >>=20 >> -------- Forwarded Message -------- >> Subject: [mif] WGLC for draft-ietf-mif-mpvd-dhcp-support >> Date: Tue, 14 Jul 2015 23:16:05 +0800 >> From: Hui Deng >> To: mif@ietf.org , Margaret >>=20 >> Hello all >>=20 >> This email initiates 3 weeks WGLC for below document: >> http://datatracker.ietf.org/doc/draft-ietf-mif-mpvd-dhcp-support/ >>=20 >> According to our working group discussion, we need 4-5 substantive revie= ws for this document before we move it to the IESG >>=20 >> This WGLC will end on Aug. 5th. >>=20 >> Thanks for your review. >>=20 >> DENG Hui >>=20 >> _______________________________________________ >> dhcwg mailing list >> dhcwg@ietf.org >> https://www.ietf.org/mailman/listinfo/dhcwg >>=20 >> _______________________________________________ >> dhcwg mailing list >> dhcwg@ietf.org >> https://www.ietf.org/mailman/listinfo/dhcwg From nobody Mon Jul 20 05:07:03 2015 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D12C61A6F7C for ; Mon, 20 Jul 2015 05:07:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.389 X-Spam-Level: X-Spam-Status: No, score=-1.389 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X6DANUQo91LJ for ; Mon, 20 Jul 2015 05:07:00 -0700 (PDT) Received: from mail-ie0-x230.google.com (mail-ie0-x230.google.com [IPv6:2607:f8b0:4001:c03::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8EA131A3BA4 for ; Mon, 20 Jul 2015 05:06:59 -0700 (PDT) Received: by ietj16 with SMTP id j16so116019410iet.0 for ; Mon, 20 Jul 2015 05:06:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=O/G3IK6S4ClV+Vttg80EfP3mUHkgW+SEvdUYBS23ELs=; b=VCTua9LdajvE8ar6LGYHJ8GFVghjcpzjCOtfeaon530z+PIScfJ8K/Hc2uIv4mkaae 1uqW1gkAutnQuT5OZbMaIR6vFjKM/5ciS0dfHW5Ko3cNqHT+bV93U2edYFThUHzJ5hRS 0uxaJ+bTB7Km4lHW4LJo93F3i/GjIqjhGPKoXoQatJdTg1akaxSzCXiwL+UeyineWjJT g2Q7jmA9N1O0lAPg4WKtx4kP+n+z08ACU9hYGLZkLaOmWELAaLNJGVjlPV5CBQ3pmQLq 3SK0e2PpsN1aGX2o58/gkgc2pypqZqlu66sJE/CMR3t8fZsqKk5O/RWIYHETYPl/dvMQ Gsvg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=O/G3IK6S4ClV+Vttg80EfP3mUHkgW+SEvdUYBS23ELs=; b=AeUtD9rLSgGfOrXoGzxTDQnlyiDfW7j4T0Gs4tYdWRnSzzto4Z7lN3idbxh6icwc11 wahyiL49ihuQ6vztFKaAvZbRxhbZ9/vOqbRgPdVj5/R2QwvE5oxdac455z/TwBcHGH7R 8vF8kGla+gAuBwbZXSj52yo8d+F2DrAuTre+HVVJRF1MBuVH+46GE2WiaPiQ3LvNXdcF 69ouEQ/HO8vdLiuPGUwPNcYPt2/yTOUY1CkTpHHdvQ/FxQC2ZKHIPzESGUMOEJqI6imd +QBRCU24rfwo51tfcZNgcbZObequjHK08Rwo271BgbrdFfbLtDn5jObAyfq+92Wd1SBf 3FfQ== X-Gm-Message-State: ALoCoQlcvxfhD6/Il1a/NTuWDKteEA3omNQmuCDgf2azxw+QIFyuD7bbpMVuKBkhhrrYtTD2OLxR X-Received: by 10.50.110.3 with SMTP id hw3mr4509378igb.20.1437394018960; Mon, 20 Jul 2015 05:06:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.10.71 with HTTP; Mon, 20 Jul 2015 05:06:39 -0700 (PDT) In-Reply-To: <41023767-2645-45A7-826A-250FD74DCBD7@cisco.com> References: <55A62F35.4000001@gmail.com> <489D13FBFA9B3E41812EA89F188F018E1CB7D9AF@xmb-rcd-x04.cisco.com> <41023767-2645-45A7-826A-250FD74DCBD7@cisco.com> From: Erik Kline Date: Mon, 20 Jul 2015 14:06:39 +0200 Message-ID: To: "Bernie Volz (volz)" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: dhcwg , "mif@ietf.org" , "draft-ietf-mif-mpvd-dhcp-support@tools.ietf.org" Subject: Re: [mif] [dhcwg] WGLC in MIF WG for draft-ietf-mif-mpvd-dhcp-support X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jul 2015 12:07:02 -0000 I misunderstood your comment: you referred to avoiding ordering but I misread as "avoiding encapsulated options". Apologies. On 20 July 2015 at 13:47, Bernie Volz (volz) wrote: > I don't think that applies as each PVD is a separate option with encapsul= ations, including the OPTION_PVD_AUTH option. This PVD_AUTH option covers e= ach PVD. > > - Bernie (from iPad) > >> On Jul 20, 2015, at 7:39 AM, Erik Kline wrote: >> >> I think the encapsulation matters so that you can have data for PVD1 >> and data for PVD2 clearly and correctly associated in one logical >> response. >> >>> On 18 July 2015 at 15:24, Bernie Volz (volz) wrote: >>> Hi: >>> >>> A few items regarding this draft: >>> >>> 1. There is still "[TODO: Should we add any other exclusions?]" in sect= ion 6. Shouldn't this be resolved before sending this draft on? >>> >>> 2. RFC 7227 and general DHCPv6 options handling has avoided explicit or= dering of options (or encapsulated options). So, why specify: "The OPTION_P= VD_AUTH option MUST be the last option inside the OPTION_PVD option" in sec= tion 5? >>> >>> I presume (though it is not explicitly stated) that this is because thi= s option contains the signature and obviously one can't generate the signat= ure of the signature. But given how the signature is calculated, why is thi= s even an issue? >>> >>> Can we avoid enforcing the order here? I cannot see how this matters an= d what the benefit is? >>> >>> If there is a reason for this ordering, please explain. >>> >>> Perhaps this comes from SEND document, but even then there is the quest= ion as to why this is needed. >>> >>> >>> Anyway, these are some initial comments. >>> >>> - Bernie >>> >>> -----Original Message----- >>> From: dhcwg [mailto:dhcwg-bounces@ietf.org] On Behalf Of Tomek Mrugalsk= i >>> Sent: Wednesday, July 15, 2015 6:00 AM >>> To: dhcwg >>> Cc: mif-chairs@ietf.org >>> Subject: [dhcwg] WGLC in MIF WG for draft-ietf-mif-mpvd-dhcp-support >>> >>> Gentlepeople, >>> >>> There's working group last call going in the mif working group for the = multiple provisioning domains proposal. One of those drafts >>> (draft-ietf-mif-mpvd-dhcp-support) defines DHCPv6 options. I'd apprecia= te any comments you may have on this. Make sure you post your comments in a= way that will reach the draft authors - either cc them directly or perhaps= send to both dhc and mif. They may not be subscribed to the dhc list. >>> >>> Tomek >>> >>> -------- Forwarded Message -------- >>> Subject: [mif] WGLC for draft-ietf-mif-mpvd-dhcp-support >>> Date: Tue, 14 Jul 2015 23:16:05 +0800 >>> From: Hui Deng >>> To: mif@ietf.org , Margaret >>> >>> Hello all >>> >>> This email initiates 3 weeks WGLC for below document: >>> http://datatracker.ietf.org/doc/draft-ietf-mif-mpvd-dhcp-support/ >>> >>> According to our working group discussion, we need 4-5 substantive revi= ews for this document before we move it to the IESG >>> >>> This WGLC will end on Aug. 5th. >>> >>> Thanks for your review. >>> >>> DENG Hui >>> >>> _______________________________________________ >>> dhcwg mailing list >>> dhcwg@ietf.org >>> https://www.ietf.org/mailman/listinfo/dhcwg >>> >>> _______________________________________________ >>> dhcwg mailing list >>> dhcwg@ietf.org >>> https://www.ietf.org/mailman/listinfo/dhcwg From nobody Mon Jul 20 07:33:43 2015 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE5881A890D for ; Mon, 20 Jul 2015 07:33:41 -0700 (PDT) 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T1SDFoXN_cVK for ; Mon, 20 Jul 2015 07:33:40 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DEE431A88F2 for ; Mon, 20 Jul 2015 07:33:39 -0700 (PDT) Received: from dhcp-b16c.meeting.ietf.org ([31.133.177.108]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0M5cpk-1Z21jm1hHM-00xbtv; Mon, 20 Jul 2015 16:33:38 +0200 Content-Type: multipart/alternative; boundary="Apple-Mail=_419455A9-804E-4FF1-BA29-25F761202944" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) From: Ian Farrer In-Reply-To: Date: Mon, 20 Jul 2015 16:33:37 +0200 Message-Id: <79C18793-758C-421A-A0C6-2F5625F1E17E@gmx.com> References: To: Hui Deng X-Mailer: Apple Mail (2.2102) X-Provags-ID: V03:K0:qYthxkCLFG8Wi0FTHYhCew+LHuUXIFLdKjAFEtXg4WyGg9mVYfa Ys7LEAM3f34guF+B+01ZcEkWYgl5M3Lrxy02sURGf1rxMpXn8AYnvShkHVAtJyXc7gyY6CC eGa1TaKXwJNS18lFgLNs46mRqy5vO/L5Bj2wm7zSmdPXUbNyu+fT+W5A4Rudn9gwsdX3dX+ YIYRDUnZIDEhBjhuiUf+w== X-UI-Out-Filterresults: notjunk:1;V01:K0:u/kASnwLtJo=:ofORxz5p8uoPS5HsV5UqAU 9jeLWzf70sMqBmfGhnjVk2tmGyDVcg1WQipdml55nk2M+ooAPUR0Ms1A4WL1uZx4IQta2Wv36 2KyWBkDZQspXej8RAzRfyo057ni+cmbBniC/IXB1gmwXaAunso1bepXOesTyaWL+opQF3tgcw 4CxenURaOxC5cDTRtsLFeyh11ZEH7Gi8QjZp4Bmkb1t3XEEo00cn5XCQ8v15acCd4PAo0bGiL MGfqx5puNmKUzovb09FwpwnUuVApn2bufVe69JK+3BO78y9Ov12noItxMqcjQlsBOtuU6tnub t6dVzqAzE6aNv1p7BfVqh0MqAyYwTvLLOLg3eFu/Ym4XEug96TzTEcmYgcUCDNclxexY5ywpc 0cKZ6wf7O3+H1rkXz6/oNMu0cIbW8E6OdkAardHUtLoXYKqOtrJKSvqSFFw5fvlqaGtUSSUWM 7EnrkMCFShpXQeXVHdZ9wIXCo1WO6nB03enQ6nR4uTVjRbBNMnKY4wSoSAi4G2V0BPIB6hQsb YPHfD+AHOT8+NlNs8DuyOP4Lmh8RxVp8XyMO7zlvTzXrCjMUKCDBlzi34//gU8at7NSMSMpLB +69yVXBso08SVhvPSHZjLUn2mojy8l6DoB9hyVIScNTg0c97g0oXI1PuEQ0X1yLMU9YVSEeC3 UQH5K02jz5JRNR1s0dqhiV/cWOb+Mxtq/rEymF5QZHIoAlPpm1urOCuz9rURZ054b39c= Archived-At: Cc: "mif@ietf.org" Subject: Re: [mif] WGLC for draft-ietf-mif-mpvd-id X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jul 2015 14:33:42 -0000 --Apple-Mail=_419455A9-804E-4FF1-BA29-25F761202944 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, Before this document can proceed, I think that there is still a = significant open point. Multiple or single PVD ID formats? This question has been raised a few times at WG meetings, but there is = no reflection in the draft as it stands. This is an excerpt from the = IETF91 minutes: Margaret: 2 changes proposed: move to single unique short ID (UUID)=20 and allow for additional info to be a part of the ID. So can we=20 try to reach consensus on each? Who thinks we should move to one unique format?=20 (a couple of hands; 2nd time asking had about 10 hands) Who thinks we should not use a single unique format?=20 (no hands) OK. Single unique. So, I would like to see this discussion take place before the document = progresses. Thanks, Ian > On 14 Jul 2015, at 17:18, Hui Deng wrote: >=20 > Hello all, > =20 > We would like to have a 3 weeks WGLC for the below document: > http://datatracker.ietf.org/doc/draft-ietf-mif-mpvd-id/ = > =20 > Please help to send your comments to this thread. > This WGLC will end on Aug. 5th. > =20 > Many thanks > =20 > DENG Hui > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif = --Apple-Mail=_419455A9-804E-4FF1-BA29-25F761202944 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Hi,

Before this document can proceed, I = think that there is still a significant open point. Multiple or single = PVD ID formats?

This question has been raised a few times at WG meetings, but = there is no reflection in the draft as it stands. This is an excerpt = from the IETF91 minutes:

Margaret: 2 changes proposed: move to single unique short ID =
(UUID)=20
  and allow for additional info to be a part of the ID. So can we=20
  try to reach consensus on each?

Who thinks we should move to one unique format?=20
 (a couple of hands; 2nd time asking had about 10 hands)
Who thinks we should not use a single unique format?=20
 (no hands)
 OK. Single unique.
So, I would like to see this = discussion take place before the document progresses.

Thanks,
Ian



On 14 Jul 2015, at 17:18, Hui = Deng <denghui02@hotmail.com> wrote:

Hello all,
 
We would like to have a 3 weeks WGLC for = the below document:
http://datatracker.ietf.org/doc/draft-ietf-mif-mpvd-id/
 
Please help to send your comments to = this thread.
This WGLC will end on Aug. 5th.
 
Many thanks
 
DENG Hui
_______________________________________________
mif mailing list
mif@ietf.org
https://www.ietf.org/mailman/listinfo/mif

= --Apple-Mail=_419455A9-804E-4FF1-BA29-25F761202944-- From nobody Mon Jul 20 11:08:41 2015 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBC8C1B2A6F for ; Mon, 20 Jul 2015 11:08:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1 X-Spam-Level: X-Spam-Status: No, score=-1 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, FREEMAIL_REPLY=1, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PWeGeo57jQTk for ; Mon, 20 Jul 2015 11:08:39 -0700 (PDT) Received: from mail-wg0-x229.google.com (mail-wg0-x229.google.com [IPv6:2a00:1450:400c:c00::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 576FB1B2A6E for ; Mon, 20 Jul 2015 11:08:39 -0700 (PDT) Received: by wgbcc4 with SMTP id cc4so43815597wgb.3 for ; Mon, 20 Jul 2015 11:08:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=8TsPhxOmRMVL5uhmJobdveLjIEs66NbK2t7rKtvm0DI=; b=opOseqh8xf7YqH9jf/9fUfv8iWYGBEtTXX0phVkbnSSLdH+qYcalZ7L663SYx0MpQJ BSZzrqBue3P4Vxbd/0A+HYQDDorrwP1KVQzw+2sedkjM1XUji41Fg4eBV7dlTD1Kj3ao beZeLsPr3M9yqx3VUl+FqMRUs/uJfJ2ju5Qc6UsrJAu5Hx1BYc1ADdgkn6rt5HoB+FEI 4hhLHEomCOKAz1kGhRvXdpfW0HmvWv3+JDsUv+/pKqXKVyzNOYfY164nNIW1hIL+Dm0+ bTWgJjvGayZ4dj7csjJoVu5l8Bj5AlUqCE6FSnNimOru3pbgkQJOFf4sRFrE/1o3iAoM fSOQ== X-Received: by 10.194.5.103 with SMTP id r7mr57645485wjr.47.1437415718069; Mon, 20 Jul 2015 11:08:38 -0700 (PDT) Received: from ?IPv6:2001:67c:370:136:e497:a2ce:99fb:df9a? ([2001:67c:370:136:e497:a2ce:99fb:df9a]) by smtp.googlemail.com with ESMTPSA id r8sm7653873wiz.5.2015.07.20.11.08.36 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 20 Jul 2015 11:08:37 -0700 (PDT) To: Ian Farrer , Hui Deng References: <79C18793-758C-421A-A0C6-2F5625F1E17E@gmx.com> From: Jouni Korhonen Message-ID: <55AD3922.8090009@gmail.com> Date: Mon, 20 Jul 2015 11:08:34 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: <79C18793-758C-421A-A0C6-2F5625F1E17E@gmx.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "mif@ietf.org" Subject: Re: [mif] WGLC for draft-ietf-mif-mpvd-id X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jul 2015 18:08:41 -0000 Ian, So would UUID be adequate PVD-ID format as suggested below? What about the additonal information part? Not needed? - Jouni 7/20/2015, 7:33 AM, Ian Farrer kirjoitti: > Hi, > > Before this document can proceed, I think that there is still a > significant open point. Multiple or single PVD ID formats? > > This question has been raised a few times at WG meetings, but there is > no reflection in the draft as it stands. This is an excerpt from the > IETF91 minutes: > > Margaret: 2 changes proposed: move to single unique short ID (UUID) > and allow for additional info to be a part of the ID. So can we > try to reach consensus on each? > > Who thinks we should move to one unique format? > (a couple of hands; 2nd time asking had about 10 hands) > Who thinks we should not use a single unique format? > (no hands) > OK. Single unique. > > So, I would like to see this discussion take place before the document > progresses. > > Thanks, > Ian > > > >> On 14 Jul 2015, at 17:18, Hui Deng > > wrote: >> >> Hello all, >> >> We would like to have a 3 weeks WGLC for the below document: >> http://datatracker.ietf.org/doc/draft-ietf-mif-mpvd-id/ >> >> Please help to send your comments to this thread. >> This WGLC will end on Aug. 5th. >> >> Many thanks >> >> DENG Hui >> _______________________________________________ >> mif mailing list >> mif@ietf.org >> https://www.ietf.org/mailman/listinfo/mif > > > > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif > From nobody Tue Jul 21 02:02:48 2015 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E9F01B2C31 for ; Tue, 21 Jul 2015 02:02:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.899 X-Spam-Level: X-Spam-Status: No, score=-0.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UdQEWyGK4nsp for ; Tue, 21 Jul 2015 02:02:44 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BDE301B2BDE for ; Tue, 21 Jul 2015 02:02:43 -0700 (PDT) Received: from dhcp-b16c.meeting.ietf.org ([31.133.177.108]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0LsUDg-1Yp6in2HqS-011yqq; Tue, 21 Jul 2015 11:02:41 +0200 Content-Type: multipart/alternative; boundary="Apple-Mail=_1A9A0DF0-AA97-484A-A040-EEC4FA47EC7B" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) From: Ian Farrer In-Reply-To: <55AD3922.8090009@gmail.com> Date: Tue, 21 Jul 2015 11:02:40 +0200 Message-Id: <69E5A45D-C11A-4383-A4EE-AEF05675E718@gmx.com> References: <79C18793-758C-421A-A0C6-2F5625F1E17E@gmx.com> <55AD3922.8090009@gmail.com> To: Jouni Korhonen X-Mailer: Apple Mail (2.2102) X-Provags-ID: V03:K0:FpFIUekJ7+J0cKVtsy3BFNV7PDmbsrY9vU2hMTLHpQJbDFq1bTL AL5TeHygfiMTUbgMs2fZw6dPbNEfAQvEi//+pOx8Dznts0THU3Jd0iTYZTSPv52Mlwl1pJC hJWmCAHQD2Mftw/2vtDX3KD0yoWezC1RT10MO9OveJ3dGnwWKYtIYRqWNKZ77DVEwOwS4Al vyX3nbDkcz/1AKgkP67yA== X-UI-Out-Filterresults: notjunk:1;V01:K0:GSTuAuShzDA=:x84lNsyhVALY9WKgTfobuG eVXB1M/pnzf2uKnUzko6eYHcj4WRQic4pmkzwMB0dRtsOone+V0xbio71kZyAEuUby2fCKO6N 4mS4ntBz2Z5WhMb813x+icNOQlVK97JjGRY/bBwMHJ5R1p+cwkabgLdWaqJqWjJGIHnE9IOK2 N1lPS3hXSj+mV4Ipkb4p3S7XIGXAw8LArjhvBhlXErCjJQPFl00wUPZZJepuzh8p5TluvPylE 5mdQqWHSianuAmyodAMozgJnzD7EiJS/yIUJmrIlD0JFmkJNiIVVrUnaoWuGwu4CZX123yntF qB29Ubtz8cuuLNtgVSwBbGzg6Ljk90IfNeYDk/U9y+ZoTND+FYMKNgx/lFVUJkq+1j/oQ4pcd ipaX7rtr60zSuvUvaMvW66V73NGUIj1pHmFsRRFA08O35vtaAh07EMopJ4yv6WX0Sr3dPq48k 8Mp8BrHobKyXn0RQgXw1yBse8Ta0FrQIaY9u3xyr/RE5CoLBkq2Ledf4OLRHqV4RA4p5JO9r/ HRU0c+muh75Vz7nHRDAr0nes2Ybluva6eB2sBHSik76cC4vjwAgAB1HCzAn7G/9nZuzjzZrqb 7BLR1mscDqlld+CK3wh+N5WeXFe8Rx6DUlZHU6DShXQuHgMIhfD0zGUQzXB897vtFhZGuwaYx C6YG664da5t4RyT5u/RelsUsnAQF91bVA8Dc9bIBTaYt7EMyTqg/U2zNnHskiz5N8CN4= Archived-At: Cc: "mif@ietf.org" , Hui Deng Subject: Re: [mif] WGLC for draft-ietf-mif-mpvd-id X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2015 09:02:46 -0000 --Apple-Mail=_1A9A0DF0-AA97-484A-A040-EEC4FA47EC7B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi Jouni, The specific things that I think need to be addressed here are: 1, Removing the decision making process for an operator looking to = choose the right format to use. This needs to be common across the whole = of an operator=92s network and so needs to be supported by all devices = and advertising/provisioning protocols present and future. Once deployed = at any scale, changing this will be non-trivial. 2, At this stage in the development of the PvD architecture, it is very = difficult to know how this will need to evolve and be extended in the = future, so it is almost impossible to make an informed decision about = what the best PvD format to choose is. So, this is why I think that choosing a single format with a high = probability of uniqueness and a small, defined size. But this needs to = be combined with extensibility for adding meta-data to take advantage of = the capabilities of less constrained devices and advertising protocols = so that additional information can be supplied to allow clients / = applications / users to make an informed decision about the PvD. How I would see this working is that the PvD-ID itself would be a single = format - e.g. UUID. This must be advertised in all provisioning = messages. An additional DHCPv6/PIO option would then be defined that = allows an operator to add additional meta-data options which are = associated with the PVD-ID according to their needs / the capabilities = of the device/protocols etc (i.e. the other PvD-ID formats that have = been described in the draft).=20 This allows for the mechanism to be extended as needed without the need = to change the PvD-ID formats that are in use in existing devices. If you = want to extend your PvD architecture so that new devices have new logic = for selecting the correct PvD based on new logic, then you can add a new = PvD-ID meta-data option linked to an existing PvD-ID without needing to = change the underlying PvD architecture or devices that you have = deployed. With the current mechanism as described, to make any changes to your PvD = architecture to support new client PvD selection logic requires = deploying another PvD format in parallel to the existing one. This is, = by the PvD architecture a new PvD, even if the service properties are = identical to an existing PvD which you have already deployed. Then, your = provisioning protocols need to advertise duplicate configuration for = both of the PvDs, even thought that configuration is the same, with the = exception of the PvD-ID. So, the short answer to your question is: Single PvD-ID format (I like = UUID) + extensible associated meta-data. Cheers, Ian > On 20 Jul 2015, at 20:08, Jouni Korhonen = wrote: >=20 > Ian, >=20 > So would UUID be adequate PVD-ID format as suggested below? >=20 > What about the additonal information part? Not needed? >=20 > - Jouni >=20 >=20 > 7/20/2015, 7:33 AM, Ian Farrer kirjoitti: >> Hi, >>=20 >> Before this document can proceed, I think that there is still a >> significant open point. Multiple or single PVD ID formats? >>=20 >> This question has been raised a few times at WG meetings, but there = is >> no reflection in the draft as it stands. This is an excerpt from the >> IETF91 minutes: >>=20 >> Margaret: 2 changes proposed: move to single unique short ID (UUID) >> and allow for additional info to be a part of the ID. So can we >> try to reach consensus on each? >>=20 >> Who thinks we should move to one unique format? >> (a couple of hands; 2nd time asking had about 10 hands) >> Who thinks we should not use a single unique format? >> (no hands) >> OK. Single unique. >>=20 >> So, I would like to see this discussion take place before the = document >> progresses. >>=20 >> Thanks, >> Ian >>=20 >>=20 >>=20 >>> On 14 Jul 2015, at 17:18, Hui Deng >> >> = wrote: >>>=20 >>> Hello all, >>>=20 >>> We would like to have a 3 weeks WGLC for the below document: >>> http://datatracker.ietf.org/doc/draft-ietf-mif-mpvd-id/ = >>>=20 >>> Please help to send your comments to this thread. >>> This WGLC will end on Aug. 5th. >>>=20 >>> Many thanks >>>=20 >>> DENG Hui >>> _______________________________________________ >>> mif mailing list >>> mif@ietf.org > >>> https://www.ietf.org/mailman/listinfo/mif = >>=20 >>=20 >>=20 >> _______________________________________________ >> mif mailing list >> mif@ietf.org >> https://www.ietf.org/mailman/listinfo/mif = --Apple-Mail=_1A9A0DF0-AA97-484A-A040-EEC4FA47EC7B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Hi Jouni,

The specific things that I think need to be addressed here = are:

1, = Removing the decision making process for an operator looking to choose = the right format to use. This needs to be common across the whole of an = operator=92s network and so needs to be supported by all devices and = advertising/provisioning protocols present and future. Once deployed at = any scale, changing this will be non-trivial.

2, At this stage in the development of = the PvD architecture, it is very difficult to know how this will need to = evolve and be extended in the future, so it is almost impossible to make = an informed decision about what the best PvD format to choose = is.

So, this = is why I think that choosing a single format with a high probability of = uniqueness and a small, defined size. But this needs to be combined with = extensibility for adding meta-data to take advantage of the capabilities = of less constrained devices and advertising protocols so that additional = information can be supplied to allow clients / applications / users to = make an informed decision about the PvD.

How I would see this working is that = the PvD-ID itself would be a single format - e.g. UUID. This must be = advertised in all provisioning messages. An additional DHCPv6/PIO option = would then be defined that allows an operator to add additional = meta-data options which are associated with the PVD-ID according to = their needs / the capabilities of the device/protocols etc (i.e. the = other PvD-ID formats that have been described in the = draft). 

This allows for the mechanism to be extended as needed = without the need to change the PvD-ID formats that are in use in = existing devices. If you want to extend your PvD architecture so that = new devices have new logic for selecting the correct PvD based on new = logic, then you can add a new PvD-ID meta-data option linked to an = existing PvD-ID without needing to change the underlying PvD = architecture or devices that you have deployed.

With the current mechanism as = described, to make any changes to your PvD architecture to support new = client PvD selection logic requires deploying another PvD format in = parallel to the existing one. This is, by the PvD architecture a new = PvD, even if the service properties are identical to an existing PvD = which you have already deployed. Then, your provisioning protocols need = to advertise duplicate configuration for both of the PvDs, even thought = that configuration is the same, with the exception of the = PvD-ID.

So, = the short answer to your question is: Single PvD-ID format (I like UUID) = + extensible associated meta-data.

Cheers,
Ian


On 20 Jul 2015, at 20:08, Jouni Korhonen <jouni.nospam@gmail.com> wrote:

Ian,

So would UUID be adequate = PVD-ID format as suggested below?

What about the additonal information part? Not = needed?

- Jouni


7/20/2015, 7:33 AM, Ian Farrer = kirjoitti:
Hi,

Before this document = can proceed, I think that there is still a
significant = open point. Multiple or single PVD ID formats?

This question has been raised a few times at WG meetings, but = there is
no reflection in the draft as it stands. This is = an excerpt from the
IETF91 minutes:

Margaret: 2 changes proposed: move to single unique short ID = (UUID)
  and allow for additional info to be a = part of the ID. So can we
  try to reach = consensus on each?

Who thinks we should = move to one unique format?
 (a couple of hands; 2nd = time asking had about 10 hands)
Who thinks we should not = use a single unique format?
 (no hands)
 OK. Single unique.

So, I = would like to see this discussion take place before the document
progresses.

Thanks,
Ian



On 14 Jul 2015, at = 17:18, Hui Deng <denghui02@hotmail.com
<mailto:denghui02@hotmail.com>> wrote:

Hello all,

We = would like to have a 3 weeks WGLC for the below document:
http://datatracker.ietf.org/doc/draft-ietf-mif-mpvd-id/

Please help to send your comments to this = thread.
This WGLC will end on Aug. 5th.

Many thanks

DENG Hui
_______________________________________________
mif mailing list
mif@ietf.org <mailto:mif@ietf.org>
https://www.ietf.org/mailman/listinfo/mif



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

= --Apple-Mail=_1A9A0DF0-AA97-484A-A040-EEC4FA47EC7B-- From nobody Tue Jul 21 03:44:30 2015 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58F151A000B for ; Tue, 21 Jul 2015 03:44:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1 X-Spam-Level: X-Spam-Status: No, score=-1 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, FREEMAIL_REPLY=1, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BDz-wd-ooJWJ for ; Tue, 21 Jul 2015 03:44:27 -0700 (PDT) Received: from mail-wi0-x22f.google.com (mail-wi0-x22f.google.com [IPv6:2a00:1450:400c:c05::22f]) (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 1AD841A000F for ; Tue, 21 Jul 2015 03:44:27 -0700 (PDT) Received: by wibud3 with SMTP id ud3so123151683wib.0 for ; Tue, 21 Jul 2015 03:44:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=OX/cfjlTeOHUJR6pOdr5ji+vwB+SrETqoalMGRggBCk=; b=rMkd4/D9hr92b5nkFsJpQJpCMo4iIoM1fScnwsrt+C5AGaysg3Mtzxs+We9QpX51EI eBMwdESd8OvgrbxFlLbAkxszYYRXYjMWThq1+acnn6MWhxiPWiA0JtOyFWrWREC/9gS1 H/TcPUxmY0FfVeq8t6+3elxY5eEGwS47vVTp6gqafQ+QgNKpouCk+rK9TlwxI08A7FLC v6OkzYH8/3S4lvrKWVJ75ujiqWUW2TXhi+ldQJC/rBgvjy+6FBDcbe74WOFY0cbVnvTG 0L/3RI1qQQrHG4JPkQtfF/dDhASDhrGvo9lsF/T2muHHuapiSIT8h4YvHfJQu6ERdCT5 PSpA== X-Received: by 10.194.178.201 with SMTP id da9mr64118006wjc.139.1437475465864; Tue, 21 Jul 2015 03:44:25 -0700 (PDT) Received: from ?IPv6:2001:67c:370:136:3c8e:6c6c:4dcc:f560? ([2001:67c:370:136:3c8e:6c6c:4dcc:f560]) by smtp.googlemail.com with ESMTPSA id ny7sm16169860wic.11.2015.07.21.03.44.24 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 21 Jul 2015 03:44:25 -0700 (PDT) To: Ian Farrer References: <79C18793-758C-421A-A0C6-2F5625F1E17E@gmx.com> <55AD3922.8090009@gmail.com> <69E5A45D-C11A-4383-A4EE-AEF05675E718@gmx.com> From: Jouni Korhonen Message-ID: <55AE2288.5070509@gmail.com> Date: Tue, 21 Jul 2015 03:44:24 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: <69E5A45D-C11A-4383-A4EE-AEF05675E718@gmx.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "mif@ietf.org" , Hui Deng Subject: Re: [mif] WGLC for draft-ietf-mif-mpvd-id X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2015 10:44:29 -0000 Thanks Ian, And the metadata is just a binary blob only understood by the PVD-ID "owner"? - Jouni 7/21/2015, 2:02 AM, Ian Farrer kirjoitti: > Hi Jouni, > > The specific things that I think need to be addressed here are: > > 1, Removing the decision making process for an operator looking to > choose the right format to use. This needs to be common across the whole > of an operator’s network and so needs to be supported by all devices and > advertising/provisioning protocols present and future. Once deployed at > any scale, changing this will be non-trivial. > > 2, At this stage in the development of the PvD architecture, it is very > difficult to know how this will need to evolve and be extended in the > future, so it is almost impossible to make an informed decision about > what the best PvD format to choose is. > > So, this is why I think that choosing a single format with a high > probability of uniqueness and a small, defined size. But this needs to > be combined with extensibility for adding meta-data to take advantage of > the capabilities of less constrained devices and advertising protocols > so that additional information can be supplied to allow clients / > applications / users to make an informed decision about the PvD. > > How I would see this working is that the PvD-ID itself would be a single > format - e.g. UUID. This must be advertised in all provisioning > messages. An additional DHCPv6/PIO option would then be defined that > allows an operator to add additional meta-data options which are > associated with the PVD-ID according to their needs / the capabilities > of the device/protocols etc (i.e. the other PvD-ID formats that have > been described in the draft). > > This allows for the mechanism to be extended as needed without the need > to change the PvD-ID formats that are in use in existing devices. If you > want to extend your PvD architecture so that new devices have new logic > for selecting the correct PvD based on new logic, then you can add a new > PvD-ID meta-data option linked to an existing PvD-ID without needing to > change the underlying PvD architecture or devices that you have deployed. > > With the current mechanism as described, to make any changes to your PvD > architecture to support new client PvD selection logic requires > deploying another PvD format in parallel to the existing one. This is, > by the PvD architecture a new PvD, even if the service properties are > identical to an existing PvD which you have already deployed. Then, your > provisioning protocols need to advertise duplicate configuration for > both of the PvDs, even thought that configuration is the same, with the > exception of the PvD-ID. > > So, the short answer to your question is: Single PvD-ID format (I like > UUID) + extensible associated meta-data. > > Cheers, > Ian > > >> On 20 Jul 2015, at 20:08, Jouni Korhonen > > wrote: >> >> Ian, >> >> So would UUID be adequate PVD-ID format as suggested below? >> >> What about the additonal information part? Not needed? >> >> - Jouni >> >> >> 7/20/2015, 7:33 AM, Ian Farrer kirjoitti: >>> Hi, >>> >>> Before this document can proceed, I think that there is still a >>> significant open point. Multiple or single PVD ID formats? >>> >>> This question has been raised a few times at WG meetings, but there is >>> no reflection in the draft as it stands. This is an excerpt from the >>> IETF91 minutes: >>> >>> Margaret: 2 changes proposed: move to single unique short ID (UUID) >>> and allow for additional info to be a part of the ID. So can we >>> try to reach consensus on each? >>> >>> Who thinks we should move to one unique format? >>> (a couple of hands; 2nd time asking had about 10 hands) >>> Who thinks we should not use a single unique format? >>> (no hands) >>> OK. Single unique. >>> >>> So, I would like to see this discussion take place before the document >>> progresses. >>> >>> Thanks, >>> Ian >>> >>> >>> >>>> On 14 Jul 2015, at 17:18, Hui Deng >>> >>>> > wrote: >>>> >>>> Hello all, >>>> >>>> We would like to have a 3 weeks WGLC for the below document: >>>> http://datatracker.ietf.org/doc/draft-ietf-mif-mpvd-id/ >>>> >>>> Please help to send your comments to this thread. >>>> This WGLC will end on Aug. 5th. >>>> >>>> Many thanks >>>> >>>> DENG Hui >>>> _______________________________________________ >>>> mif mailing list >>>> mif@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mif >>> >>> >>> >>> _______________________________________________ >>> mif mailing list >>> mif@ietf.org >>> https://www.ietf.org/mailman/listinfo/mif > From nobody Tue Jul 21 04:17:53 2015 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79ABF1A00B2 for ; Tue, 21 Jul 2015 04:17:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.599 X-Spam-Level: X-Spam-Status: No, score=-1.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ypCILb5RKIYG for ; Tue, 21 Jul 2015 04:17:49 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D0CA71A0099 for ; Tue, 21 Jul 2015 04:17:48 -0700 (PDT) Received: from dhcp-b35a.meeting.ietf.org ([31.133.179.90]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0Ld3t6-1YZcAC4132-00iFfZ; Tue, 21 Jul 2015 13:17:45 +0200 Content-Type: multipart/alternative; boundary="Apple-Mail=_027FCD19-2DDD-4DC0-B838-18CDE837C3AF" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) From: Ian Farrer In-Reply-To: <55AE2288.5070509@gmail.com> Date: Tue, 21 Jul 2015 13:17:44 +0200 Message-Id: <74F2D07D-4FB2-4FB6-B482-EF202B4D533F@gmx.com> References: <79C18793-758C-421A-A0C6-2F5625F1E17E@gmx.com> <55AD3922.8090009@gmail.com> <69E5A45D-C11A-4383-A4EE-AEF05675E718@gmx.com> <55AE2288.5070509@gmail.com> To: Jouni Korhonen X-Mailer: Apple Mail (2.2102) X-Provags-ID: V03:K0:FlSfnx/UD5LelPBIoWLiCzcGrbk5jN+qVRtcIp75dx77soQO49B kLfaecXeUoObIjPreAUsC+wBNRRiJyDHLGaaHmrdO3SNIquHio+taXJsysw7nSmPop/H092 C4OBmsVdw4PSxaVnPnxncL6TTe6/1tf9x2IPsasJmZTzJ5RBBLvSWSivesly/kcywUXWxNQ pxEE/IBJbHpoOAuDsUJbg== X-UI-Out-Filterresults: notjunk:1;V01:K0:7qUZtb5YrvA=:EulBKNXnOmFVGevpvG25jP Fb8gTxZzesLFA85TsaHhnGBtfLCpVnOL5VFveLrcKOvpJ6dHos3bisOMz+a/Wc2lMPkX1ZzHn PJtclo4M65V0fT1HZRIxmGZh2h23nqXjxstDWkWZmt4jOOgwO72E8Q/vcNZj+KPvfsz6daNsG GkV2xkJg4KX2HFGyE3Cch3zSmuZcsAtvoYtJRS+kSv/n+K3EvIPpLxRJ0Qmc5or38XoGf0SjV 4zvbR6NOXtzFG5FO2tY+j0HrnowOD/CHYKsiP97FaKLNzSyt+LTF2Mzf6LFqkR3Hv4yzgHpcN HW83o0wM963J8/EobNp2+lDyj23O4j2CVmItpoUvgMG2FJw/PMj05Np0j0nLkejrpjYDV2QSO dJDsCHg8MM6W5fxEh88yFu4LIIEjzq+rbOqX96kM9ANx7CKlzt98VT0JzUHPhp/7kziFxmYKP RRpXlRJHZJoNh2jAjZtgeyIBffTxi7hI6eiDhJL3EgrR6RiDxukBDNxu48sCczkT4uEAp3YJA HHmB54o1uy9WiCbkw5l4K0lpKqxYi3Pvi+oh9iyRURgfDB9o8kEPXOtuDu0bcmxf5wdkdIJ23 suotM2CoSkhhGL01CYLaz3XBX4mjq16AWqgcoKruRAVLkhWQQW2j+1+FQFlzEOwHpQ2YdJ4Xf /xazx3odrnT1tNegmUdzk+FQSN3NytjP3uTU3Upz+xZp34moqVzCIr32T2hGUG1ZYgRQ= Archived-At: Cc: "mif@ietf.org" , Hui Deng Subject: Re: [mif] WGLC for draft-ietf-mif-mpvd-id X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2015 11:17:51 -0000 --Apple-Mail=_027FCD19-2DDD-4DC0-B838-18CDE837C3AF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 The meta-data formats would be standardised formats as well so that they = can potentially be universally understood. i.e. the id-formats that are enumerated in section 3 of the pad-id = document (with the exception of the format which is chosen as the single = unique Identifier) would form the initial set of PVD-ID meta data. However, on thinking about this, maybe defining an additional type for = 'PVD-ID owner binary blob=92 could be an idea if people see a need for = it. Cheers, Ian =20 > On 21 Jul 2015, at 12:44, Jouni Korhonen = wrote: >=20 > Thanks Ian, >=20 > And the metadata is just a binary blob only understood by the PVD-ID = "owner"? >=20 > - Jouni >=20 > 7/21/2015, 2:02 AM, Ian Farrer kirjoitti: >> Hi Jouni, >>=20 >> The specific things that I think need to be addressed here are: >>=20 >> 1, Removing the decision making process for an operator looking to >> choose the right format to use. This needs to be common across the = whole >> of an operator=92s network and so needs to be supported by all = devices and >> advertising/provisioning protocols present and future. Once deployed = at >> any scale, changing this will be non-trivial. >>=20 >> 2, At this stage in the development of the PvD architecture, it is = very >> difficult to know how this will need to evolve and be extended in the >> future, so it is almost impossible to make an informed decision about >> what the best PvD format to choose is. >>=20 >> So, this is why I think that choosing a single format with a high >> probability of uniqueness and a small, defined size. But this needs = to >> be combined with extensibility for adding meta-data to take advantage = of >> the capabilities of less constrained devices and advertising = protocols >> so that additional information can be supplied to allow clients / >> applications / users to make an informed decision about the PvD. >>=20 >> How I would see this working is that the PvD-ID itself would be a = single >> format - e.g. UUID. This must be advertised in all provisioning >> messages. An additional DHCPv6/PIO option would then be defined that >> allows an operator to add additional meta-data options which are >> associated with the PVD-ID according to their needs / the = capabilities >> of the device/protocols etc (i.e. the other PvD-ID formats that have >> been described in the draft). >>=20 >> This allows for the mechanism to be extended as needed without the = need >> to change the PvD-ID formats that are in use in existing devices. If = you >> want to extend your PvD architecture so that new devices have new = logic >> for selecting the correct PvD based on new logic, then you can add a = new >> PvD-ID meta-data option linked to an existing PvD-ID without needing = to >> change the underlying PvD architecture or devices that you have = deployed. >>=20 >> With the current mechanism as described, to make any changes to your = PvD >> architecture to support new client PvD selection logic requires >> deploying another PvD format in parallel to the existing one. This = is, >> by the PvD architecture a new PvD, even if the service properties are >> identical to an existing PvD which you have already deployed. Then, = your >> provisioning protocols need to advertise duplicate configuration for >> both of the PvDs, even thought that configuration is the same, with = the >> exception of the PvD-ID. >>=20 >> So, the short answer to your question is: Single PvD-ID format (I = like >> UUID) + extensible associated meta-data. >>=20 >> Cheers, >> Ian >>=20 >>=20 >>> On 20 Jul 2015, at 20:08, Jouni Korhonen >> >> = wrote: >>>=20 >>> Ian, >>>=20 >>> So would UUID be adequate PVD-ID format as suggested below? >>>=20 >>> What about the additonal information part? Not needed? >>>=20 >>> - Jouni >>>=20 >>>=20 >>> 7/20/2015, 7:33 AM, Ian Farrer kirjoitti: >>>> Hi, >>>>=20 >>>> Before this document can proceed, I think that there is still a >>>> significant open point. Multiple or single PVD ID formats? >>>>=20 >>>> This question has been raised a few times at WG meetings, but there = is >>>> no reflection in the draft as it stands. This is an excerpt from = the >>>> IETF91 minutes: >>>>=20 >>>> Margaret: 2 changes proposed: move to single unique short ID (UUID) >>>> and allow for additional info to be a part of the ID. So can we >>>> try to reach consensus on each? >>>>=20 >>>> Who thinks we should move to one unique format? >>>> (a couple of hands; 2nd time asking had about 10 hands) >>>> Who thinks we should not use a single unique format? >>>> (no hands) >>>> OK. Single unique. >>>>=20 >>>> So, I would like to see this discussion take place before the = document >>>> progresses. >>>>=20 >>>> Thanks, >>>> Ian >>>>=20 >>>>=20 >>>>=20 >>>>> On 14 Jul 2015, at 17:18, Hui Deng >>>>> > >>>>> >> = wrote: >>>>>=20 >>>>> Hello all, >>>>>=20 >>>>> We would like to have a 3 weeks WGLC for the below document: >>>>> http://datatracker.ietf.org/doc/draft-ietf-mif-mpvd-id/ = >>>>>=20 >>>>> Please help to send your comments to this thread. >>>>> This WGLC will end on Aug. 5th. >>>>>=20 >>>>> Many thanks >>>>>=20 >>>>> DENG Hui >>>>> _______________________________________________ >>>>> mif mailing list >>>>> mif@ietf.org >> >>>>> https://www.ietf.org/mailman/listinfo/mif = >>>>=20 >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> mif mailing list >>>> mif@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/mif = --Apple-Mail=_027FCD19-2DDD-4DC0-B838-18CDE837C3AF Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 The meta-data formats would be standardised formats as well = so that they can potentially be universally understood.
i.e. the id-formats that are = enumerated in section 3 of the pad-id document (with the exception of = the format which is chosen as the single unique Identifier) would form = the initial set of PVD-ID meta data.

However, on thinking about this, maybe = defining an additional type for 'PVD-ID owner binary blob=92 could be an = idea if people see a need for it.

Cheers,
Ian
 

On 21 Jul 2015, at 12:44, Jouni Korhonen = <jouni.nospam@gmail.com> wrote:

Thanks Ian,

And the metadata is just a binary blob only = understood by the PVD-ID "owner"?

- Jouni

7/21/2015, 2:02 AM, Ian Farrer = kirjoitti:
Hi Jouni,

The specific = things that I think need to be addressed here are:

1, Removing the decision making process for an operator = looking to
choose the right format to use. This needs to = be common across the whole
of an operator=92s network and = so needs to be supported by all devices and
advertising/provisioning protocols present and future. Once = deployed at
any scale, changing this will be = non-trivial.

2, At this stage in the = development of the PvD architecture, it is very
difficult = to know how this will need to evolve and be extended in the
future, so it is almost impossible to make an informed = decision about
what the best PvD format to choose is.

So, this is why I think that choosing a single = format with a high
probability of uniqueness and a small, = defined size. But this needs to
be combined with = extensibility for adding meta-data to take advantage of
the = capabilities of less constrained devices and advertising protocols
so that additional information can be supplied to allow = clients /
applications / users to make an informed = decision about the PvD.

How I would see = this working is that the PvD-ID itself would be a single
format - e.g. UUID. This must be advertised in all = provisioning
messages. An additional DHCPv6/PIO option = would then be defined that
allows an operator to add = additional meta-data options which are
associated with the = PVD-ID according to their needs / the capabilities
of the = device/protocols etc (i.e. the other PvD-ID formats that have
been described in the draft).

This= allows for the mechanism to be extended as needed without the need
to change the PvD-ID formats that are in use in existing = devices. If you
want to extend your PvD architecture so = that new devices have new logic
for selecting the correct = PvD based on new logic, then you can add a new
PvD-ID = meta-data option linked to an existing PvD-ID without needing to
change the underlying PvD architecture or devices that you = have deployed.

With the current mechanism = as described, to make any changes to your PvD
architecture = to support new client PvD selection logic requires
deploying= another PvD format in parallel to the existing one. This is,
by the PvD architecture a new PvD, even if the service = properties are
identical to an existing PvD which you have = already deployed. Then, your
provisioning protocols need = to advertise duplicate configuration for
both of the PvDs, = even thought that configuration is the same, with the
exception of the PvD-ID.

So, the = short answer to your question is: Single PvD-ID format (I like
UUID) + extensible associated meta-data.

Cheers,
Ian


On 20 Jul 2015, at = 20:08, Jouni Korhonen <jouni.nospam@gmail.com
<mailto:jouni.nospam@gmail.com>> wrote:

Ian,

So would = UUID be adequate PVD-ID format as suggested below?

What about the additonal information part? Not needed?

- Jouni


7/20/2015, 7:33 AM, Ian Farrer kirjoitti:
Hi,

Before this document can proceed, I think that there is still = a
significant open point. Multiple or single PVD ID = formats?

This question has been raised a = few times at WG meetings, but there is
no reflection in = the draft as it stands. This is an excerpt from the
IETF91 = minutes:

Margaret: 2 changes proposed: move = to single unique short ID (UUID)
 and allow for = additional info to be a part of the ID. So can we
 try = to reach consensus on each?

Who thinks we = should move to one unique format?
(a couple of hands; 2nd = time asking had about 10 hands)
Who thinks we should not = use a single unique format?
(no hands)
OK. = Single unique.

So, I would like to see this = discussion take place before the document
progresses.

Thanks,
Ian



On 14 Jul 2015, at 17:18, Hui Deng <denghui02@hotmail.com
<mailto:denghui02@hotmail.com>
<mailto:denghui02@hotmail.com>> wrote:

Hello all,

We = would like to have a 3 weeks WGLC for the below document:
http://datatracker.ietf.org/doc/draft-ietf-mif-mpvd-id/

Please help to send your comments to this = thread.
This WGLC will end on Aug. 5th.

Many thanks

DENG Hui
_______________________________________________
mif mailing list
mif@ietf.org <mailto:mif@ietf.org><mailto:mif@ietf.org>
https://www.ietf.org/mailman/listinfo/mif



_______________________________________________
mif mailing list
mif@ietf.org <mailto:mif@ietf.org>
https://www.ietf.org/mailman/listinfo/mif

= --Apple-Mail=_027FCD19-2DDD-4DC0-B838-18CDE837C3AF-- From nobody Tue Jul 21 12:57:04 2015 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD2D51B2CC7 for ; Tue, 21 Jul 2015 12:57:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.55 X-Spam-Level: X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 31KBffkMdXQG for ; Tue, 21 Jul 2015 12:57:01 -0700 (PDT) Received: from mail.core-networks.de (mail.core-networks.de [IPv6:2001:1bc0:d::4:9]) (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 C1BA71B2B75 for ; Tue, 21 Jul 2015 12:57:01 -0700 (PDT) Received: from localhost ([127.0.0.1]) by mail.core-networks.de id 1ZHdeu-0000oG-8y with ESMTPSA (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) for mif@ietf.org; Tue, 21 Jul 2015 21:57:00 +0200 From: Steven Barth To: mif@ietf.org Message-ID: <55AEA40C.4090909@openwrt.org> Date: Tue, 21 Jul 2015 21:57:00 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: [mif] Comments on draft-ietf-mif-mpvd-dhcp-support-01 X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2015 19:57:03 -0000 Hi everyone, as promised few comments on the DHCPv6 support draft. This is based on roughly reading it 1-2 times and not meant to be conclusive in any way. Also I'm not a dhc expert, though I have implemented a DHCPv6 client, server and relay myself. 3 SHOULD contain exactly one still allows more than one PVD_AUTH vs. "MUST be the last option inside PVD" in 5 5 refers to RFC3791 in key-hash and digital-signature options but 3791 is not part of references. 6 specifies that ANY options may be encapsulated. This is awkward, e.g., what would be the meaning of e.g. a Status or a Reconfigure-Accept option within that container, more general what happens to options explicitly defined to be on some level and / or having a specific meaning there? Also where may your container option be present? Only on the top-level? Also inside IA_NA/IA_PD? Inside IAAddr / IAPrefix? Also in which DHCPv6 messages may your container appear? 7.1 merely specifies to send ORO etc. in SOLICIT, but not in REQUEST, RENEW etc. whereas 7.3 says OPTION_PVD must not be sent if ORO is absent in request 8 mentions the use of timestamps to avoid replay attacks, though DHCPv6 is usually used to bootstrap network connectivity and thus at this point devices (especially embedded ones) may not have an accurate wallclock yet. This is especially interesting since DHCPv6 itself may carry NTP server addresses to use. Some additional stuff related to routers forwarding this kind of information from to clients (e.g. your coffee shop example in 8). In general this should applies to CPEs, as specified in RFC 7084, especially if they themselves got the information using DHCPv6 from an ISP, but not necessarily. Again disclaimer: this list is not conclusive: Since you don't restrict options inside your container, it may originally contain options e.g. FQDN which may only be directed at the specific receiving router but not hosts behind it (e.g. the hotspot got the PVD TLVs via DHCPV6 itself). Furthermore the container may contain options which are specified to not be sent to clients unless explicitly asked for in an ORO. In both instances the "coffee shop router" would need to dynamically remove options from the container which will inevitably invalidate the signature of the container. Also given the "coffee shop router" is supposed to hand out addresses from different PVDs and "tag" them appropriately: How is it supposed to do that with just a container which SHOULD contain a signature? It certainly cannot place IAAddrs or IAPrefixes inside containers since it doesn't have the key (there are more and even more severe issues with trying to use containers for IA_Xs or IAAdress / IAPrefix but I will skip them for the sake of simplicity for now). Also, if a hotspot / CER / etc. asks (e.g. an ISP) for PVD information that does not necessarily mean that all the hosts behind said router will understand PVD information so that router requires that it also gets "legacy" information for "legacy" hosts being not PVD-aware OR it needs some guidance to construct that information from data within the PVD containers it got. Cheers, Steven From nobody Wed Jul 22 00:11:40 2015 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 101D11ACE2E for ; Wed, 22 Jul 2015 00:11:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.55 X-Spam-Level: X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AaaorOewsPqU for ; Wed, 22 Jul 2015 00:11:37 -0700 (PDT) Received: from mail.core-networks.de (mail.core-networks.de [IPv6:2001:1bc0:d::4:9]) (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 74C921ACE26 for ; Wed, 22 Jul 2015 00:11:37 -0700 (PDT) Received: from localhost ([127.0.0.1]) by mail.core-networks.de id 1ZHoBj-0000So-9i with ESMTPSA (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) for mif@ietf.org; Wed, 22 Jul 2015 09:11:35 +0200 From: Steven Barth To: mif@ietf.org Message-ID: <55AF4226.8010803@openwrt.org> Date: Wed, 22 Jul 2015 09:11:34 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: [mif] Comments on draft-ietf-mif-mpvd-id-01 X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2015 07:11:39 -0000 Hello everyone, below a few comments for the MPVD ID draft. 3 I'm unsure about the id-length field. It seems entirely redundant for e.g. DHCP(v6) purposes and even considering e.g. RAs it is redundant for half of the given id-types. Should this be type-specfic instead? 3 I'm unsure if cross references to the draft that in turn references this one are wise, also wrt. informative / normative reference sections. 3 id-type Encoding and / or allowed lengths are entirely unclear for most types you declare. Are they supposed to be strings, BE integers, ...? How big are they supposed to be? Shall I be able to use 16, 32 or maybe even 24bit numbers for representing the OID? 0x04: RFC 4282 specifies the assignment of NAI Realms to be tied to domain names, so this type seems mostly redundant since you alreay have FQDN. 0x06: This looks overly specific to me. Why not have a generic (unicast) prefix type, so people could also use their RIPE / ARIN / ... assigned UC addresses? E.g. prefix length followed by arbitrary length ipv6 prefix. 4 What if I want to use this outside a configuration protocol? 4 Undefined reference to "PVD container option" In general 4 seems awkward / misplaced here, since you are defining an abstract identifier. Cheers, Steven From nobody Wed Jul 22 00:13:45 2015 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CC931ACE2A for ; Wed, 22 Jul 2015 00:13:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.841 X-Spam-Level: * X-Spam-Status: No, score=1.841 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_37=0.6, J_CHICKENPOX_42=0.6, J_CHICKENPOX_54=0.6, J_CHICKENPOX_81=0.6, J_CHICKENPOX_82=0.6, J_CHICKENPOX_84=0.6, J_CHICKENPOX_92=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c8y1rL2AfJnu for ; Wed, 22 Jul 2015 00:13:42 -0700 (PDT) Received: from COL004-OMC2S17.hotmail.com (col004-omc2s17.hotmail.com [65.55.34.91]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 31FBF1ACE25 for ; Wed, 22 Jul 2015 00:13:42 -0700 (PDT) Received: from COL125-W43 ([65.55.34.72]) by COL004-OMC2S17.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.23008); Wed, 22 Jul 2015 00:13:41 -0700 X-TMN: [PfSkjsoDDNchnwpniLroux/mdVwerPiJ] X-Originating-Email: [denghui02@hotmail.com] Message-ID: Content-Type: multipart/alternative; boundary="_2957eb25-9117-4ce1-a405-b65e9e159b19_" From: Hui Deng To: "mif@ietf.org" , "cyrus@openwrt.org" Date: Wed, 22 Jul 2015 15:13:41 +0800 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 22 Jul 2015 07:13:41.0472 (UTC) FILETIME=[F02C8600:01D0C44D] Archived-At: Subject: [mif] Subject: Comments on draft-ietf-mif-mpvd-dhcp-support-01 X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2015 07:13:44 -0000 --_2957eb25-9117-4ce1-a405-b65e9e159b19_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGVsbG8gYWxsLCANCiANClN0ZXZlbiBzZW50IHRoaXMsIGJ5IHNvbWUgY2hhbmNlLCBpdCB3YXMg bm90IHNob3duIHVwIGluIG91ciBsaXN0LCBzbyBJIGNjIGhlcmUNCiANCkZyb206IFN0ZXZlbiBC YXJ0aCA8Y3lydXNAb3BlbndydC5vcmc+VG86IG1pZkBpZXRmLm9yZ0NjOiBEYXRlOiBUdWUsIDIx IEp1bCAyMDE1IDIxOjU1OjQ5ICswMjAwU3ViamVjdDogQ29tbWVudHMgb24gZHJhZnQtaWV0Zi1t aWYtbXB2ZC1kaGNwLXN1cHBvcnQtMDFIaSBldmVyeW9uZSxhcyBwcm9taXNlZCBmZXcgY29tbWVu dHMgb24gdGhlIERIQ1B2NiBzdXBwb3J0IGRyYWZ0LiBUaGlzIGlzIGJhc2VkIG9uIHJvdWdobHly ZWFkaW5nIGl0IDEtMiB0aW1lcyBhbmQgbm90IG1lYW50IHRvIGJlIGNvbmNsdXNpdmUgaW4gYW55 IHdheS4gQWxzbyBJJ20gbm90IGFkaGMgZXhwZXJ0LCB0aG91Z2ggSSBoYXZlIGltcGxlbWVudGVk IGEgREhDUHY2IGNsaWVudCwgc2VydmVyIGFuZCByZWxheSBteXNlbGYuMyBTSE9VTEQgY29udGFp biBleGFjdGx5IG9uZSBzdGlsbCBhbGxvd3MgbW9yZSB0aGFuIG9uZSBQVkRfQVVUSCB2cy4iTVVT VCBiZSB0aGUgbGFzdCBvcHRpb24gaW5zaWRlIFBWRCIgaW4gNTUgcmVmZXJzIHRvIFJGQzM3OTEg aW4ga2V5LWhhc2ggYW5kIGRpZ2l0YWwtc2lnbmF0dXJlIG9wdGlvbnMgYnV0IDM3OTEgaXNub3Qg cGFydCBvZiByZWZlcmVuY2VzLjYgc3BlY2lmaWVzIHRoYXQgQU5ZIG9wdGlvbnMgbWF5IGJlIGVu Y2Fwc3VsYXRlZC4gVGhpcyBpcyBhd2t3YXJkLCBlLmcuLCB3aGF0d291bGQgYmUgdGhlIG1lYW5p bmcgb2YgZS5nLiBhIFN0YXR1cyBvciBhIFJlY29uZmlndXJlLUFjY2VwdCBvcHRpb24gd2l0aGlu dGhhdCBjb250YWluZXIsIG1vcmUgZ2VuZXJhbCB3aGF0IGhhcHBlbnMgdG8gb3B0aW9ucyBleHBs aWNpdGx5IGRlZmluZWQgdG8gYmVvbiBzb21lIGxldmVsIGFuZCAvIG9yIGhhdmluZyBhIHNwZWNp ZmljIG1lYW5pbmcgdGhlcmU/QWxzbyB3aGVyZSBtYXkgeW91ciBjb250YWluZXIgb3B0aW9uIGJl IHByZXNlbnQ/IE9ubHkgb24gdGhlIHRvcC1sZXZlbD9BbHNvIGluc2lkZSBJQV9OQS9JQV9QRD8g SW5zaWRlIElBQWRkciAvIElBUHJlZml4P0Fsc28gaW4gd2hpY2ggREhDUHY2IG1lc3NhZ2VzIG1h eSB5b3VyIGNvbnRhaW5lciBhcHBlYXI/Ny4xIG1lcmVseSBzcGVjaWZpZXMgdG8gc2VuZCBPUk8g ZXRjLiBpbiBTT0xJQ0lULCBidXQgbm90IGluIFJFUVVFU1QsIFJFTkVXIGV0Yy53aGVyZWFzIDcu MyBzYXlzIE9QVElPTl9QVkQgbXVzdCBub3QgYmUgc2VudCBpZiBPUk8gaXMgYWJzZW50IGluIHJl cXVlc3Q4IG1lbnRpb25zIHRoZSB1c2Ugb2YgdGltZXN0YW1wcyB0byBhdm9pZCByZXBsYXkgYXR0 YWNrcywgdGhvdWdoIERIQ1B2NiBpcyB1c3VhbGx5dXNlZCB0byBib290c3RyYXAgbmV0d29yayBj b25uZWN0aXZpdHkgYW5kIHRodXMgYXQgdGhpcyBwb2ludCBkZXZpY2VzIChlc3BlY2lhbGx5ZW1i ZWRkZWQgb25lcykgbWF5IG5vdCBoYXZlIGFuIGFjY3VyYXRlIHdhbGxjbG9jayB5ZXQuIFRoaXMg aXMgZXNwZWNpYWxseSBpbnRlcmVzdGluZ3NpbmNlIERIQ1B2NiBpdHNlbGYgbWF5IGNhcnJ5IE5U UCBzZXJ2ZXIgYWRkcmVzc2VzIHRvIHVzZS5Tb21lIGFkZGl0aW9uYWwgc3R1ZmYgcmVsYXRlZCB0 byByb3V0ZXJzIGZvcndhcmRpbmcgdGhpcyBraW5kIG9mIGluZm9ybWF0aW9uIGZyb210byBjbGll bnRzIChlLmcuIHlvdXIgY29mZmVlIHNob3AgZXhhbXBsZSBpbiA4KS4gSW4gZ2VuZXJhbCB0aGlz IHNob3VsZCBhcHBsaWVzIHRvIENQRXMsYXMgc3BlY2lmaWVkIGluIFJGQyA3MDg0LCBlc3BlY2lh bGx5IGlmIHRoZXkgdGhlbXNlbHZlcyBnb3QgdGhlIGluZm9ybWF0aW9uIHVzaW5nREhDUHY2IGZy b20gYW4gSVNQLCBidXQgbm90IG5lY2Vzc2FyaWx5LiBBZ2FpbiBkaXNjbGFpbWVyOiB0aGlzIGxp c3QgaXMgbm90IGNvbmNsdXNpdmU6U2luY2UgeW91IGRvbid0IHJlc3RyaWN0IG9wdGlvbnMgaW5z aWRlIHlvdXIgY29udGFpbmVyLCBpdCBtYXkgb3JpZ2luYWxseSBjb250YWluIG9wdGlvbnNlLmcu IEZRRE4gd2hpY2ggbWF5IG9ubHkgYmUgZGlyZWN0ZWQgYXQgdGhlIHNwZWNpZmljIHJlY2Vpdmlu ZyByb3V0ZXIgYnV0IG5vdCBob3N0cyBiZWhpbmRpdCAoZS5nLiB0aGUgaG90c3BvdCBnb3QgdGhl IFBWRCBUTFZzIHZpYSBESENQVjYgaXRzZWxmKS4gRnVydGhlcm1vcmUgdGhlIGNvbnRhaW5lciBt YXljb250YWluIG9wdGlvbnMgd2hpY2ggYXJlIHNwZWNpZmllZCB0byBub3QgYmUgc2VudCB0byBj bGllbnRzIHVubGVzcyBleHBsaWNpdGx5IGFza2VkIGZvcmluIGFuIE9STy4gSW4gYm90aCBpbnN0 YW5jZXMgdGhlICJjb2ZmZWUgc2hvcCByb3V0ZXIiIHdvdWxkIG5lZWQgdG8gZHluYW1pY2FsbHkg cmVtb3Zlb3B0aW9ucyBmcm9tIHRoZSBjb250YWluZXIgd2hpY2ggd2lsbCBpbmV2aXRhYmx5IGlu dmFsaWRhdGUgdGhlIHNpZ25hdHVyZSBvZiB0aGUgY29udGFpbmVyLkFsc28gZ2l2ZW4gdGhlICJj b2ZmZWUgc2hvcCByb3V0ZXIiIGlzIHN1cHBvc2VkIHRvIGhhbmQgb3V0IGFkZHJlc3NlcyBmcm9t IGRpZmZlcmVudCBQVkRzYW5kICJ0YWciIHRoZW0gYXBwcm9wcmlhdGVseTogSG93IGlzIGl0IHN1 cHBvc2VkIHRvIGRvIHRoYXQgd2l0aCBqdXN0IGEgY29udGFpbmVyIHdoaWNoU0hPVUxEIGNvbnRh aW4gYSBzaWduYXR1cmU/SXQgY2VydGFpbmx5IGNhbm5vdCBwbGFjZSBJQUFkZHJzIG9yIElBUHJl Zml4ZXMgaW5zaWRlIGNvbnRhaW5lcnMgc2luY2UgaXQgZG9lc24ndCBoYXZldGhlIGtleSAodGhl cmUgYXJlIG1vcmUgYW5kIGV2ZW4gbW9yZSBzZXZlcmUgaXNzdWVzIHdpdGggdHJ5aW5nIHRvIHVz ZSBjb250YWluZXJzIGZvciBJQV9Yc29yIElBQWRyZXNzIC8gSUFQcmVmaXggYnV0IEkgd2lsbCBz a2lwIHRoZW0gZm9yIHRoZSBzYWtlIG9mIHNpbXBsaWNpdHkgZm9yIG5vdykuQWxzbywgaWYgYSBo b3RzcG90IC8gQ0VSIC8gZXRjLiBhc2tzIChlLmcuIGFuIElTUCkgZm9yIFBWRCBpbmZvcm1hdGlv biB0aGF0IGRvZXNub3QgbmVjZXNzYXJpbHkgbWVhbiB0aGF0IGFsbCB0aGUgaG9zdHMgYmVoaW5k IHNhaWQgcm91dGVyIHdpbGwgdW5kZXJzdGFuZCBQVkQgaW5mb3JtYXRpb25zbyB0aGF0IHJvdXRl ciByZXF1aXJlcyB0aGF0IGl0IGFsc28gZ2V0cyAibGVnYWN5IiBpbmZvcm1hdGlvbiBmb3IgImxl Z2FjeSIgaG9zdHMgYmVpbmdub3QgUFZELWF3YXJlIE9SIGl0IG5lZWRzIHNvbWUgZ3VpZGFuY2Ug dG8gY29uc3RydWN0IHRoYXQgaW5mb3JtYXRpb24gZnJvbSBkYXRhIHdpdGhpbnRoZSBQVkQgY29u dGFpbmVycyBpdCBnb3QuQ2hlZXJzLFN0ZXZlbg0KIAkJIAkgICAJCSAg --_2957eb25-9117-4ce1-a405-b65e9e159b19_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxzdHlsZT48IS0tDQouaG1tZXNzYWdlIFANCnsNCm1hcmdpbjowcHg7 DQpwYWRkaW5nOjBweA0KfQ0KYm9keS5obW1lc3NhZ2UNCnsNCmZvbnQtc2l6ZTogMTJwdDsNCmZv bnQtZmFtaWx5OkNhbGlicmkNCn0NCi0tPjwvc3R5bGU+PC9oZWFkPg0KPGJvZHkgY2xhc3M9J2ht bWVzc2FnZSc+PGRpdiBkaXI9J2x0cic+SGVsbG8gYWxsLCA8QlI+Jm5ic3A7PEJSPlN0ZXZlbiBz ZW50IHRoaXMsIGJ5IHNvbWUgY2hhbmNlLCBpdCB3YXMgbm90IHNob3duIHVwIGluIG91ciBsaXN0 LCBzbyBJIGNjIGhlcmU8QlI+Jm5ic3A7PEJSPjxzcGFuIHN0eWxlPSJmb250OiAxNHB4L25vcm1h bCBhcmlhbCwgc2Fucy1zZXJpZjsgY29sb3I6IHJnYigzNCwgMzQsIDM0KTsgdGV4dC10cmFuc2Zv cm06IG5vbmU7IHRleHQtaW5kZW50OiAwcHg7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IHdvcmQt c3BhY2luZzogMHB4OyBmbG9hdDogbm9uZTsgZGlzcGxheTogaW5saW5lICFpbXBvcnRhbnQ7IHdo aXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogMTsgYmFja2dyb3VuZC1jb2xvcjogcmdiKDI1NSwg MjU1LCAyNTUpOyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7Ij5Gcm9tOiZuYnNwO1N0 ZXZlbiBCYXJ0aCAmbHQ7Y3lydXNAb3BlbndydC5vcmcmZ3Q7PC9zcGFuPjxiciBzdHlsZT0iZm9u dDogMTRweC9ub3JtYWwgYXJpYWwsIHNhbnMtc2VyaWY7IGNvbG9yOiByZ2IoMzQsIDM0LCAzNCk7 IHRleHQtdHJhbnNmb3JtOiBub25lOyB0ZXh0LWluZGVudDogMHB4OyBsZXR0ZXItc3BhY2luZzog bm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiAx OyBiYWNrZ3JvdW5kLWNvbG9yOiByZ2IoMjU1LCAyNTUsIDI1NSk7IC13ZWJraXQtdGV4dC1zdHJv a2Utd2lkdGg6IDBweDsiPjxzcGFuIHN0eWxlPSJmb250OiAxNHB4L25vcm1hbCBhcmlhbCwgc2Fu cy1zZXJpZjsgY29sb3I6IHJnYigzNCwgMzQsIDM0KTsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHRl eHQtaW5kZW50OiAwcHg7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4 OyBmbG9hdDogbm9uZTsgZGlzcGxheTogaW5saW5lICFpbXBvcnRhbnQ7IHdoaXRlLXNwYWNlOiBu b3JtYWw7IHdpZG93czogMTsgYmFja2dyb3VuZC1jb2xvcjogcmdiKDI1NSwgMjU1LCAyNTUpOyAt d2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7Ij5UbzombmJzcDttaWZAaWV0Zi5vcmc8L3Nw YW4+PGJyIHN0eWxlPSJmb250OiAxNHB4L25vcm1hbCBhcmlhbCwgc2Fucy1zZXJpZjsgY29sb3I6 IHJnYigzNCwgMzQsIDM0KTsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHRleHQtaW5kZW50OiAwcHg7 IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyB3aGl0ZS1zcGFjZTog bm9ybWFsOyB3aWRvd3M6IDE7IGJhY2tncm91bmQtY29sb3I6IHJnYigyNTUsIDI1NSwgMjU1KTsg LXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyI+PHNwYW4gc3R5bGU9ImZvbnQ6IDE0cHgv bm9ybWFsIGFyaWFsLCBzYW5zLXNlcmlmOyBjb2xvcjogcmdiKDM0LCAzNCwgMzQpOyB0ZXh0LXRy YW5zZm9ybTogbm9uZTsgdGV4dC1pbmRlbnQ6IDBweDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsg d29yZC1zcGFjaW5nOiAwcHg7IGZsb2F0OiBub25lOyBkaXNwbGF5OiBpbmxpbmUgIWltcG9ydGFu dDsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiAxOyBiYWNrZ3JvdW5kLWNvbG9yOiByZ2Io MjU1LCAyNTUsIDI1NSk7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsiPkNjOiZuYnNw Ozwvc3Bhbj48YnIgc3R5bGU9ImZvbnQ6IDE0cHgvbm9ybWFsIGFyaWFsLCBzYW5zLXNlcmlmOyBj b2xvcjogcmdiKDM0LCAzNCwgMzQpOyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgdGV4dC1pbmRlbnQ6 IDBweDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IHdoaXRlLXNw YWNlOiBub3JtYWw7IHdpZG93czogMTsgYmFja2dyb3VuZC1jb2xvcjogcmdiKDI1NSwgMjU1LCAy NTUpOyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7Ij48c3BhbiBzdHlsZT0iZm9udDog MTRweC9ub3JtYWwgYXJpYWwsIHNhbnMtc2VyaWY7IGNvbG9yOiByZ2IoMzQsIDM0LCAzNCk7IHRl eHQtdHJhbnNmb3JtOiBub25lOyB0ZXh0LWluZGVudDogMHB4OyBsZXR0ZXItc3BhY2luZzogbm9y bWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgZmxvYXQ6IG5vbmU7IGRpc3BsYXk6IGlubGluZSAhaW1w b3J0YW50OyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IDE7IGJhY2tncm91bmQtY29sb3I6 IHJnYigyNTUsIDI1NSwgMjU1KTsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyI+RGF0 ZTombmJzcDtUdWUsIDIxIEp1bCAyMDE1IDIxOjU1OjQ5ICswMjAwPC9zcGFuPjxiciBzdHlsZT0i Zm9udDogMTRweC9ub3JtYWwgYXJpYWwsIHNhbnMtc2VyaWY7IGNvbG9yOiByZ2IoMzQsIDM0LCAz NCk7IHRleHQtdHJhbnNmb3JtOiBub25lOyB0ZXh0LWluZGVudDogMHB4OyBsZXR0ZXItc3BhY2lu Zzogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dz OiAxOyBiYWNrZ3JvdW5kLWNvbG9yOiByZ2IoMjU1LCAyNTUsIDI1NSk7IC13ZWJraXQtdGV4dC1z dHJva2Utd2lkdGg6IDBweDsiPjxzcGFuIHN0eWxlPSJmb250OiAxNHB4L25vcm1hbCBhcmlhbCwg c2Fucy1zZXJpZjsgY29sb3I6IHJnYigzNCwgMzQsIDM0KTsgdGV4dC10cmFuc2Zvcm06IG5vbmU7 IHRleHQtaW5kZW50OiAwcHg7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IHdvcmQtc3BhY2luZzog MHB4OyBmbG9hdDogbm9uZTsgZGlzcGxheTogaW5saW5lICFpbXBvcnRhbnQ7IHdoaXRlLXNwYWNl OiBub3JtYWw7IHdpZG93czogMTsgYmFja2dyb3VuZC1jb2xvcjogcmdiKDI1NSwgMjU1LCAyNTUp OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7Ij5TdWJqZWN0OiZuYnNwO0NvbW1lbnRz IG9uIGRyYWZ0LWlldGYtbWlmLW1wdmQtZGhjcC1zdXBwb3J0LTAxPC9zcGFuPjxiciBzdHlsZT0i Zm9udDogMTRweC9ub3JtYWwgYXJpYWwsIHNhbnMtc2VyaWY7IGNvbG9yOiByZ2IoMzQsIDM0LCAz NCk7IHRleHQtdHJhbnNmb3JtOiBub25lOyB0ZXh0LWluZGVudDogMHB4OyBsZXR0ZXItc3BhY2lu Zzogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dz OiAxOyBiYWNrZ3JvdW5kLWNvbG9yOiByZ2IoMjU1LCAyNTUsIDI1NSk7IC13ZWJraXQtdGV4dC1z dHJva2Utd2lkdGg6IDBweDsiPjxzcGFuIHN0eWxlPSJmb250OiAxNHB4L25vcm1hbCBhcmlhbCwg c2Fucy1zZXJpZjsgY29sb3I6IHJnYigzNCwgMzQsIDM0KTsgdGV4dC10cmFuc2Zvcm06IG5vbmU7 IHRleHQtaW5kZW50OiAwcHg7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IHdvcmQtc3BhY2luZzog MHB4OyBmbG9hdDogbm9uZTsgZGlzcGxheTogaW5saW5lICFpbXBvcnRhbnQ7IHdoaXRlLXNwYWNl OiBub3JtYWw7IHdpZG93czogMTsgYmFja2dyb3VuZC1jb2xvcjogcmdiKDI1NSwgMjU1LCAyNTUp OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7Ij5IaSBldmVyeW9uZSw8L3NwYW4+PGJy IHN0eWxlPSJmb250OiAxNHB4L25vcm1hbCBhcmlhbCwgc2Fucy1zZXJpZjsgY29sb3I6IHJnYigz NCwgMzQsIDM0KTsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHRleHQtaW5kZW50OiAwcHg7IGxldHRl ci1zcGFjaW5nOiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyB3aGl0ZS1zcGFjZTogbm9ybWFs OyB3aWRvd3M6IDE7IGJhY2tncm91bmQtY29sb3I6IHJnYigyNTUsIDI1NSwgMjU1KTsgLXdlYmtp dC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyI+PGJyIHN0eWxlPSJmb250OiAxNHB4L25vcm1hbCBh cmlhbCwgc2Fucy1zZXJpZjsgY29sb3I6IHJnYigzNCwgMzQsIDM0KTsgdGV4dC10cmFuc2Zvcm06 IG5vbmU7IHRleHQtaW5kZW50OiAwcHg7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IHdvcmQtc3Bh Y2luZzogMHB4OyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IDE7IGJhY2tncm91bmQtY29s b3I6IHJnYigyNTUsIDI1NSwgMjU1KTsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyI+ PHNwYW4gc3R5bGU9ImZvbnQ6IDE0cHgvbm9ybWFsIGFyaWFsLCBzYW5zLXNlcmlmOyBjb2xvcjog cmdiKDM0LCAzNCwgMzQpOyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgdGV4dC1pbmRlbnQ6IDBweDsg bGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IGZsb2F0OiBub25lOyBk aXNwbGF5OiBpbmxpbmUgIWltcG9ydGFudDsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiAx OyBiYWNrZ3JvdW5kLWNvbG9yOiByZ2IoMjU1LCAyNTUsIDI1NSk7IC13ZWJraXQtdGV4dC1zdHJv a2Utd2lkdGg6IDBweDsiPmFzIHByb21pc2VkIGZldyBjb21tZW50cyBvbiB0aGUgREhDUHY2IHN1 cHBvcnQgZHJhZnQuIFRoaXMgaXMgYmFzZWQgb24gcm91Z2hseTwvc3Bhbj48YnIgc3R5bGU9ImZv bnQ6IDE0cHgvbm9ybWFsIGFyaWFsLCBzYW5zLXNlcmlmOyBjb2xvcjogcmdiKDM0LCAzNCwgMzQp OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgdGV4dC1pbmRlbnQ6IDBweDsgbGV0dGVyLXNwYWNpbmc6 IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czog MTsgYmFja2dyb3VuZC1jb2xvcjogcmdiKDI1NSwgMjU1LCAyNTUpOyAtd2Via2l0LXRleHQtc3Ry b2tlLXdpZHRoOiAwcHg7Ij48c3BhbiBzdHlsZT0iZm9udDogMTRweC9ub3JtYWwgYXJpYWwsIHNh bnMtc2VyaWY7IGNvbG9yOiByZ2IoMzQsIDM0LCAzNCk7IHRleHQtdHJhbnNmb3JtOiBub25lOyB0 ZXh0LWluZGVudDogMHB4OyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBw eDsgZmxvYXQ6IG5vbmU7IGRpc3BsYXk6IGlubGluZSAhaW1wb3J0YW50OyB3aGl0ZS1zcGFjZTog bm9ybWFsOyB3aWRvd3M6IDE7IGJhY2tncm91bmQtY29sb3I6IHJnYigyNTUsIDI1NSwgMjU1KTsg LXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyI+cmVhZGluZyBpdCAxLTIgdGltZXMgYW5k IG5vdCBtZWFudCB0byBiZSBjb25jbHVzaXZlIGluIGFueSB3YXkuIEFsc28gSSdtIG5vdCBhPC9z cGFuPjxiciBzdHlsZT0iZm9udDogMTRweC9ub3JtYWwgYXJpYWwsIHNhbnMtc2VyaWY7IGNvbG9y OiByZ2IoMzQsIDM0LCAzNCk7IHRleHQtdHJhbnNmb3JtOiBub25lOyB0ZXh0LWluZGVudDogMHB4 OyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgd2hpdGUtc3BhY2U6 IG5vcm1hbDsgd2lkb3dzOiAxOyBiYWNrZ3JvdW5kLWNvbG9yOiByZ2IoMjU1LCAyNTUsIDI1NSk7 IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsiPjxzcGFuIHN0eWxlPSJmb250OiAxNHB4 L25vcm1hbCBhcmlhbCwgc2Fucy1zZXJpZjsgY29sb3I6IHJnYigzNCwgMzQsIDM0KTsgdGV4dC10 cmFuc2Zvcm06IG5vbmU7IHRleHQtaW5kZW50OiAwcHg7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7 IHdvcmQtc3BhY2luZzogMHB4OyBmbG9hdDogbm9uZTsgZGlzcGxheTogaW5saW5lICFpbXBvcnRh bnQ7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogMTsgYmFja2dyb3VuZC1jb2xvcjogcmdi KDI1NSwgMjU1LCAyNTUpOyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7Ij5kaGMgZXhw ZXJ0LCB0aG91Z2ggSSBoYXZlIGltcGxlbWVudGVkIGEgREhDUHY2IGNsaWVudCwgc2VydmVyIGFu ZCByZWxheSBteXNlbGYuPC9zcGFuPjxiciBzdHlsZT0iZm9udDogMTRweC9ub3JtYWwgYXJpYWws IHNhbnMtc2VyaWY7IGNvbG9yOiByZ2IoMzQsIDM0LCAzNCk7IHRleHQtdHJhbnNmb3JtOiBub25l OyB0ZXh0LWluZGVudDogMHB4OyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB3b3JkLXNwYWNpbmc6 IDBweDsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiAxOyBiYWNrZ3JvdW5kLWNvbG9yOiBy Z2IoMjU1LCAyNTUsIDI1NSk7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsiPjxiciBz dHlsZT0iZm9udDogMTRweC9ub3JtYWwgYXJpYWwsIHNhbnMtc2VyaWY7IGNvbG9yOiByZ2IoMzQs IDM0LCAzNCk7IHRleHQtdHJhbnNmb3JtOiBub25lOyB0ZXh0LWluZGVudDogMHB4OyBsZXR0ZXIt c3BhY2luZzogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgd2hpdGUtc3BhY2U6IG5vcm1hbDsg d2lkb3dzOiAxOyBiYWNrZ3JvdW5kLWNvbG9yOiByZ2IoMjU1LCAyNTUsIDI1NSk7IC13ZWJraXQt dGV4dC1zdHJva2Utd2lkdGg6IDBweDsiPjxzcGFuIHN0eWxlPSJmb250OiAxNHB4L25vcm1hbCBh cmlhbCwgc2Fucy1zZXJpZjsgY29sb3I6IHJnYigzNCwgMzQsIDM0KTsgdGV4dC10cmFuc2Zvcm06 IG5vbmU7IHRleHQtaW5kZW50OiAwcHg7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IHdvcmQtc3Bh Y2luZzogMHB4OyBmbG9hdDogbm9uZTsgZGlzcGxheTogaW5saW5lICFpbXBvcnRhbnQ7IHdoaXRl LXNwYWNlOiBub3JtYWw7IHdpZG93czogMTsgYmFja2dyb3VuZC1jb2xvcjogcmdiKDI1NSwgMjU1 LCAyNTUpOyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7Ij4zIFNIT1VMRCBjb250YWlu IGV4YWN0bHkgb25lIHN0aWxsIGFsbG93cyBtb3JlIHRoYW4gb25lIFBWRF9BVVRIIHZzLjwvc3Bh bj48YnIgc3R5bGU9ImZvbnQ6IDE0cHgvbm9ybWFsIGFyaWFsLCBzYW5zLXNlcmlmOyBjb2xvcjog cmdiKDM0LCAzNCwgMzQpOyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgdGV4dC1pbmRlbnQ6IDBweDsg bGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IHdoaXRlLXNwYWNlOiBu b3JtYWw7IHdpZG93czogMTsgYmFja2dyb3VuZC1jb2xvcjogcmdiKDI1NSwgMjU1LCAyNTUpOyAt d2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7Ij48c3BhbiBzdHlsZT0iZm9udDogMTRweC9u b3JtYWwgYXJpYWwsIHNhbnMtc2VyaWY7IGNvbG9yOiByZ2IoMzQsIDM0LCAzNCk7IHRleHQtdHJh bnNmb3JtOiBub25lOyB0ZXh0LWluZGVudDogMHB4OyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB3 b3JkLXNwYWNpbmc6IDBweDsgZmxvYXQ6IG5vbmU7IGRpc3BsYXk6IGlubGluZSAhaW1wb3J0YW50 OyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IDE7IGJhY2tncm91bmQtY29sb3I6IHJnYigy NTUsIDI1NSwgMjU1KTsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyI+Ik1VU1QgYmUg dGhlIGxhc3Qgb3B0aW9uIGluc2lkZSBQVkQiIGluIDU8L3NwYW4+PGJyIHN0eWxlPSJmb250OiAx NHB4L25vcm1hbCBhcmlhbCwgc2Fucy1zZXJpZjsgY29sb3I6IHJnYigzNCwgMzQsIDM0KTsgdGV4 dC10cmFuc2Zvcm06IG5vbmU7IHRleHQtaW5kZW50OiAwcHg7IGxldHRlci1zcGFjaW5nOiBub3Jt YWw7IHdvcmQtc3BhY2luZzogMHB4OyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IDE7IGJh Y2tncm91bmQtY29sb3I6IHJnYigyNTUsIDI1NSwgMjU1KTsgLXdlYmtpdC10ZXh0LXN0cm9rZS13 aWR0aDogMHB4OyI+PGJyIHN0eWxlPSJmb250OiAxNHB4L25vcm1hbCBhcmlhbCwgc2Fucy1zZXJp ZjsgY29sb3I6IHJnYigzNCwgMzQsIDM0KTsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHRleHQtaW5k ZW50OiAwcHg7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyB3aGl0 ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IDE7IGJhY2tncm91bmQtY29sb3I6IHJnYigyNTUsIDI1 NSwgMjU1KTsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyI+PHNwYW4gc3R5bGU9ImZv bnQ6IDE0cHgvbm9ybWFsIGFyaWFsLCBzYW5zLXNlcmlmOyBjb2xvcjogcmdiKDM0LCAzNCwgMzQp OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgdGV4dC1pbmRlbnQ6IDBweDsgbGV0dGVyLXNwYWNpbmc6 IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IGZsb2F0OiBub25lOyBkaXNwbGF5OiBpbmxpbmUg IWltcG9ydGFudDsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiAxOyBiYWNrZ3JvdW5kLWNv bG9yOiByZ2IoMjU1LCAyNTUsIDI1NSk7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsi PjUgcmVmZXJzIHRvIFJGQzM3OTEgaW4ga2V5LWhhc2ggYW5kIGRpZ2l0YWwtc2lnbmF0dXJlIG9w dGlvbnMgYnV0IDM3OTEgaXM8L3NwYW4+PGJyIHN0eWxlPSJmb250OiAxNHB4L25vcm1hbCBhcmlh bCwgc2Fucy1zZXJpZjsgY29sb3I6IHJnYigzNCwgMzQsIDM0KTsgdGV4dC10cmFuc2Zvcm06IG5v bmU7IHRleHQtaW5kZW50OiAwcHg7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IHdvcmQtc3BhY2lu ZzogMHB4OyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IDE7IGJhY2tncm91bmQtY29sb3I6 IHJnYigyNTUsIDI1NSwgMjU1KTsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyI+PHNw YW4gc3R5bGU9ImZvbnQ6IDE0cHgvbm9ybWFsIGFyaWFsLCBzYW5zLXNlcmlmOyBjb2xvcjogcmdi KDM0LCAzNCwgMzQpOyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgdGV4dC1pbmRlbnQ6IDBweDsgbGV0 dGVyLXNwYWNpbmc6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IGZsb2F0OiBub25lOyBkaXNw bGF5OiBpbmxpbmUgIWltcG9ydGFudDsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiAxOyBi YWNrZ3JvdW5kLWNvbG9yOiByZ2IoMjU1LCAyNTUsIDI1NSk7IC13ZWJraXQtdGV4dC1zdHJva2Ut d2lkdGg6IDBweDsiPm5vdCBwYXJ0IG9mIHJlZmVyZW5jZXMuPC9zcGFuPjxiciBzdHlsZT0iZm9u dDogMTRweC9ub3JtYWwgYXJpYWwsIHNhbnMtc2VyaWY7IGNvbG9yOiByZ2IoMzQsIDM0LCAzNCk7 IHRleHQtdHJhbnNmb3JtOiBub25lOyB0ZXh0LWluZGVudDogMHB4OyBsZXR0ZXItc3BhY2luZzog bm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiAx OyBiYWNrZ3JvdW5kLWNvbG9yOiByZ2IoMjU1LCAyNTUsIDI1NSk7IC13ZWJraXQtdGV4dC1zdHJv a2Utd2lkdGg6IDBweDsiPjxiciBzdHlsZT0iZm9udDogMTRweC9ub3JtYWwgYXJpYWwsIHNhbnMt c2VyaWY7IGNvbG9yOiByZ2IoMzQsIDM0LCAzNCk7IHRleHQtdHJhbnNmb3JtOiBub25lOyB0ZXh0 LWluZGVudDogMHB4OyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsg d2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiAxOyBiYWNrZ3JvdW5kLWNvbG9yOiByZ2IoMjU1 LCAyNTUsIDI1NSk7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsiPjxzcGFuIHN0eWxl PSJmb250OiAxNHB4L25vcm1hbCBhcmlhbCwgc2Fucy1zZXJpZjsgY29sb3I6IHJnYigzNCwgMzQs IDM0KTsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHRleHQtaW5kZW50OiAwcHg7IGxldHRlci1zcGFj aW5nOiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyBmbG9hdDogbm9uZTsgZGlzcGxheTogaW5s aW5lICFpbXBvcnRhbnQ7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogMTsgYmFja2dyb3Vu ZC1jb2xvcjogcmdiKDI1NSwgMjU1LCAyNTUpOyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAw cHg7Ij42IHNwZWNpZmllcyB0aGF0IEFOWSBvcHRpb25zIG1heSBiZSBlbmNhcHN1bGF0ZWQuIFRo aXMgaXMgYXdrd2FyZCwgZS5nLiwgd2hhdDwvc3Bhbj48YnIgc3R5bGU9ImZvbnQ6IDE0cHgvbm9y bWFsIGFyaWFsLCBzYW5zLXNlcmlmOyBjb2xvcjogcmdiKDM0LCAzNCwgMzQpOyB0ZXh0LXRyYW5z Zm9ybTogbm9uZTsgdGV4dC1pbmRlbnQ6IDBweDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgd29y ZC1zcGFjaW5nOiAwcHg7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogMTsgYmFja2dyb3Vu ZC1jb2xvcjogcmdiKDI1NSwgMjU1LCAyNTUpOyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAw cHg7Ij48c3BhbiBzdHlsZT0iZm9udDogMTRweC9ub3JtYWwgYXJpYWwsIHNhbnMtc2VyaWY7IGNv bG9yOiByZ2IoMzQsIDM0LCAzNCk7IHRleHQtdHJhbnNmb3JtOiBub25lOyB0ZXh0LWluZGVudDog MHB4OyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgZmxvYXQ6IG5v bmU7IGRpc3BsYXk6IGlubGluZSAhaW1wb3J0YW50OyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRv d3M6IDE7IGJhY2tncm91bmQtY29sb3I6IHJnYigyNTUsIDI1NSwgMjU1KTsgLXdlYmtpdC10ZXh0 LXN0cm9rZS13aWR0aDogMHB4OyI+d291bGQgYmUgdGhlIG1lYW5pbmcgb2YgZS5nLiBhIFN0YXR1 cyBvciBhIFJlY29uZmlndXJlLUFjY2VwdCBvcHRpb24gd2l0aGluPC9zcGFuPjxiciBzdHlsZT0i Zm9udDogMTRweC9ub3JtYWwgYXJpYWwsIHNhbnMtc2VyaWY7IGNvbG9yOiByZ2IoMzQsIDM0LCAz NCk7IHRleHQtdHJhbnNmb3JtOiBub25lOyB0ZXh0LWluZGVudDogMHB4OyBsZXR0ZXItc3BhY2lu Zzogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dz OiAxOyBiYWNrZ3JvdW5kLWNvbG9yOiByZ2IoMjU1LCAyNTUsIDI1NSk7IC13ZWJraXQtdGV4dC1z dHJva2Utd2lkdGg6IDBweDsiPjxzcGFuIHN0eWxlPSJmb250OiAxNHB4L25vcm1hbCBhcmlhbCwg c2Fucy1zZXJpZjsgY29sb3I6IHJnYigzNCwgMzQsIDM0KTsgdGV4dC10cmFuc2Zvcm06IG5vbmU7 IHRleHQtaW5kZW50OiAwcHg7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IHdvcmQtc3BhY2luZzog MHB4OyBmbG9hdDogbm9uZTsgZGlzcGxheTogaW5saW5lICFpbXBvcnRhbnQ7IHdoaXRlLXNwYWNl OiBub3JtYWw7IHdpZG93czogMTsgYmFja2dyb3VuZC1jb2xvcjogcmdiKDI1NSwgMjU1LCAyNTUp OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7Ij50aGF0IGNvbnRhaW5lciwgbW9yZSBn ZW5lcmFsIHdoYXQgaGFwcGVucyB0byBvcHRpb25zIGV4cGxpY2l0bHkgZGVmaW5lZCB0byBiZTwv c3Bhbj48YnIgc3R5bGU9ImZvbnQ6IDE0cHgvbm9ybWFsIGFyaWFsLCBzYW5zLXNlcmlmOyBjb2xv cjogcmdiKDM0LCAzNCwgMzQpOyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgdGV4dC1pbmRlbnQ6IDBw eDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IHdoaXRlLXNwYWNl OiBub3JtYWw7IHdpZG93czogMTsgYmFja2dyb3VuZC1jb2xvcjogcmdiKDI1NSwgMjU1LCAyNTUp OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7Ij48c3BhbiBzdHlsZT0iZm9udDogMTRw eC9ub3JtYWwgYXJpYWwsIHNhbnMtc2VyaWY7IGNvbG9yOiByZ2IoMzQsIDM0LCAzNCk7IHRleHQt dHJhbnNmb3JtOiBub25lOyB0ZXh0LWluZGVudDogMHB4OyBsZXR0ZXItc3BhY2luZzogbm9ybWFs OyB3b3JkLXNwYWNpbmc6IDBweDsgZmxvYXQ6IG5vbmU7IGRpc3BsYXk6IGlubGluZSAhaW1wb3J0 YW50OyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IDE7IGJhY2tncm91bmQtY29sb3I6IHJn YigyNTUsIDI1NSwgMjU1KTsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyI+b24gc29t ZSBsZXZlbCBhbmQgLyBvciBoYXZpbmcgYSBzcGVjaWZpYyBtZWFuaW5nIHRoZXJlPzwvc3Bhbj48 YnIgc3R5bGU9ImZvbnQ6IDE0cHgvbm9ybWFsIGFyaWFsLCBzYW5zLXNlcmlmOyBjb2xvcjogcmdi KDM0LCAzNCwgMzQpOyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgdGV4dC1pbmRlbnQ6IDBweDsgbGV0 dGVyLXNwYWNpbmc6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IHdoaXRlLXNwYWNlOiBub3Jt YWw7IHdpZG93czogMTsgYmFja2dyb3VuZC1jb2xvcjogcmdiKDI1NSwgMjU1LCAyNTUpOyAtd2Vi a2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7Ij48YnIgc3R5bGU9ImZvbnQ6IDE0cHgvbm9ybWFs IGFyaWFsLCBzYW5zLXNlcmlmOyBjb2xvcjogcmdiKDM0LCAzNCwgMzQpOyB0ZXh0LXRyYW5zZm9y bTogbm9uZTsgdGV4dC1pbmRlbnQ6IDBweDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgd29yZC1z cGFjaW5nOiAwcHg7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogMTsgYmFja2dyb3VuZC1j b2xvcjogcmdiKDI1NSwgMjU1LCAyNTUpOyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7 Ij48c3BhbiBzdHlsZT0iZm9udDogMTRweC9ub3JtYWwgYXJpYWwsIHNhbnMtc2VyaWY7IGNvbG9y OiByZ2IoMzQsIDM0LCAzNCk7IHRleHQtdHJhbnNmb3JtOiBub25lOyB0ZXh0LWluZGVudDogMHB4 OyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgZmxvYXQ6IG5vbmU7 IGRpc3BsYXk6IGlubGluZSAhaW1wb3J0YW50OyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6 IDE7IGJhY2tncm91bmQtY29sb3I6IHJnYigyNTUsIDI1NSwgMjU1KTsgLXdlYmtpdC10ZXh0LXN0 cm9rZS13aWR0aDogMHB4OyI+QWxzbyB3aGVyZSBtYXkgeW91ciBjb250YWluZXIgb3B0aW9uIGJl IHByZXNlbnQ/IE9ubHkgb24gdGhlIHRvcC1sZXZlbD88L3NwYW4+PGJyIHN0eWxlPSJmb250OiAx NHB4L25vcm1hbCBhcmlhbCwgc2Fucy1zZXJpZjsgY29sb3I6IHJnYigzNCwgMzQsIDM0KTsgdGV4 dC10cmFuc2Zvcm06IG5vbmU7IHRleHQtaW5kZW50OiAwcHg7IGxldHRlci1zcGFjaW5nOiBub3Jt YWw7IHdvcmQtc3BhY2luZzogMHB4OyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IDE7IGJh Y2tncm91bmQtY29sb3I6IHJnYigyNTUsIDI1NSwgMjU1KTsgLXdlYmtpdC10ZXh0LXN0cm9rZS13 aWR0aDogMHB4OyI+PHNwYW4gc3R5bGU9ImZvbnQ6IDE0cHgvbm9ybWFsIGFyaWFsLCBzYW5zLXNl cmlmOyBjb2xvcjogcmdiKDM0LCAzNCwgMzQpOyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgdGV4dC1p bmRlbnQ6IDBweDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IGZs b2F0OiBub25lOyBkaXNwbGF5OiBpbmxpbmUgIWltcG9ydGFudDsgd2hpdGUtc3BhY2U6IG5vcm1h bDsgd2lkb3dzOiAxOyBiYWNrZ3JvdW5kLWNvbG9yOiByZ2IoMjU1LCAyNTUsIDI1NSk7IC13ZWJr aXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsiPkFsc28gaW5zaWRlIElBX05BL0lBX1BEPyBJbnNp ZGUgSUFBZGRyIC8gSUFQcmVmaXg/PC9zcGFuPjxiciBzdHlsZT0iZm9udDogMTRweC9ub3JtYWwg YXJpYWwsIHNhbnMtc2VyaWY7IGNvbG9yOiByZ2IoMzQsIDM0LCAzNCk7IHRleHQtdHJhbnNmb3Jt OiBub25lOyB0ZXh0LWluZGVudDogMHB4OyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB3b3JkLXNw YWNpbmc6IDBweDsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiAxOyBiYWNrZ3JvdW5kLWNv bG9yOiByZ2IoMjU1LCAyNTUsIDI1NSk7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsi PjxiciBzdHlsZT0iZm9udDogMTRweC9ub3JtYWwgYXJpYWwsIHNhbnMtc2VyaWY7IGNvbG9yOiBy Z2IoMzQsIDM0LCAzNCk7IHRleHQtdHJhbnNmb3JtOiBub25lOyB0ZXh0LWluZGVudDogMHB4OyBs ZXR0ZXItc3BhY2luZzogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgd2hpdGUtc3BhY2U6IG5v cm1hbDsgd2lkb3dzOiAxOyBiYWNrZ3JvdW5kLWNvbG9yOiByZ2IoMjU1LCAyNTUsIDI1NSk7IC13 ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsiPjxzcGFuIHN0eWxlPSJmb250OiAxNHB4L25v cm1hbCBhcmlhbCwgc2Fucy1zZXJpZjsgY29sb3I6IHJnYigzNCwgMzQsIDM0KTsgdGV4dC10cmFu c2Zvcm06IG5vbmU7IHRleHQtaW5kZW50OiAwcHg7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IHdv cmQtc3BhY2luZzogMHB4OyBmbG9hdDogbm9uZTsgZGlzcGxheTogaW5saW5lICFpbXBvcnRhbnQ7 IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogMTsgYmFja2dyb3VuZC1jb2xvcjogcmdiKDI1 NSwgMjU1LCAyNTUpOyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7Ij5BbHNvIGluIHdo aWNoIERIQ1B2NiBtZXNzYWdlcyBtYXkgeW91ciBjb250YWluZXIgYXBwZWFyPzwvc3Bhbj48YnIg c3R5bGU9ImZvbnQ6IDE0cHgvbm9ybWFsIGFyaWFsLCBzYW5zLXNlcmlmOyBjb2xvcjogcmdiKDM0 LCAzNCwgMzQpOyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgdGV4dC1pbmRlbnQ6IDBweDsgbGV0dGVy LXNwYWNpbmc6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IHdoaXRlLXNwYWNlOiBub3JtYWw7 IHdpZG93czogMTsgYmFja2dyb3VuZC1jb2xvcjogcmdiKDI1NSwgMjU1LCAyNTUpOyAtd2Via2l0 LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7Ij48YnIgc3R5bGU9ImZvbnQ6IDE0cHgvbm9ybWFsIGFy aWFsLCBzYW5zLXNlcmlmOyBjb2xvcjogcmdiKDM0LCAzNCwgMzQpOyB0ZXh0LXRyYW5zZm9ybTog bm9uZTsgdGV4dC1pbmRlbnQ6IDBweDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgd29yZC1zcGFj aW5nOiAwcHg7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogMTsgYmFja2dyb3VuZC1jb2xv cjogcmdiKDI1NSwgMjU1LCAyNTUpOyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7Ij48 c3BhbiBzdHlsZT0iZm9udDogMTRweC9ub3JtYWwgYXJpYWwsIHNhbnMtc2VyaWY7IGNvbG9yOiBy Z2IoMzQsIDM0LCAzNCk7IHRleHQtdHJhbnNmb3JtOiBub25lOyB0ZXh0LWluZGVudDogMHB4OyBs ZXR0ZXItc3BhY2luZzogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgZmxvYXQ6IG5vbmU7IGRp c3BsYXk6IGlubGluZSAhaW1wb3J0YW50OyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IDE7 IGJhY2tncm91bmQtY29sb3I6IHJnYigyNTUsIDI1NSwgMjU1KTsgLXdlYmtpdC10ZXh0LXN0cm9r ZS13aWR0aDogMHB4OyI+Ny4xIG1lcmVseSBzcGVjaWZpZXMgdG8gc2VuZCBPUk8gZXRjLiBpbiBT T0xJQ0lULCBidXQgbm90IGluIFJFUVVFU1QsIFJFTkVXIGV0Yy48L3NwYW4+PGJyIHN0eWxlPSJm b250OiAxNHB4L25vcm1hbCBhcmlhbCwgc2Fucy1zZXJpZjsgY29sb3I6IHJnYigzNCwgMzQsIDM0 KTsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHRleHQtaW5kZW50OiAwcHg7IGxldHRlci1zcGFjaW5n OiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6 IDE7IGJhY2tncm91bmQtY29sb3I6IHJnYigyNTUsIDI1NSwgMjU1KTsgLXdlYmtpdC10ZXh0LXN0 cm9rZS13aWR0aDogMHB4OyI+PHNwYW4gc3R5bGU9ImZvbnQ6IDE0cHgvbm9ybWFsIGFyaWFsLCBz YW5zLXNlcmlmOyBjb2xvcjogcmdiKDM0LCAzNCwgMzQpOyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsg dGV4dC1pbmRlbnQ6IDBweDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAw cHg7IGZsb2F0OiBub25lOyBkaXNwbGF5OiBpbmxpbmUgIWltcG9ydGFudDsgd2hpdGUtc3BhY2U6 IG5vcm1hbDsgd2lkb3dzOiAxOyBiYWNrZ3JvdW5kLWNvbG9yOiByZ2IoMjU1LCAyNTUsIDI1NSk7 IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsiPndoZXJlYXMgNy4zIHNheXMgT1BUSU9O X1BWRCBtdXN0IG5vdCBiZSBzZW50IGlmIE9STyBpcyBhYnNlbnQgaW4gcmVxdWVzdDwvc3Bhbj48 YnIgc3R5bGU9ImZvbnQ6IDE0cHgvbm9ybWFsIGFyaWFsLCBzYW5zLXNlcmlmOyBjb2xvcjogcmdi KDM0LCAzNCwgMzQpOyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgdGV4dC1pbmRlbnQ6IDBweDsgbGV0 dGVyLXNwYWNpbmc6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IHdoaXRlLXNwYWNlOiBub3Jt YWw7IHdpZG93czogMTsgYmFja2dyb3VuZC1jb2xvcjogcmdiKDI1NSwgMjU1LCAyNTUpOyAtd2Vi a2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7Ij48YnIgc3R5bGU9ImZvbnQ6IDE0cHgvbm9ybWFs IGFyaWFsLCBzYW5zLXNlcmlmOyBjb2xvcjogcmdiKDM0LCAzNCwgMzQpOyB0ZXh0LXRyYW5zZm9y bTogbm9uZTsgdGV4dC1pbmRlbnQ6IDBweDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgd29yZC1z cGFjaW5nOiAwcHg7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogMTsgYmFja2dyb3VuZC1j b2xvcjogcmdiKDI1NSwgMjU1LCAyNTUpOyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7 Ij48c3BhbiBzdHlsZT0iZm9udDogMTRweC9ub3JtYWwgYXJpYWwsIHNhbnMtc2VyaWY7IGNvbG9y OiByZ2IoMzQsIDM0LCAzNCk7IHRleHQtdHJhbnNmb3JtOiBub25lOyB0ZXh0LWluZGVudDogMHB4 OyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgZmxvYXQ6IG5vbmU7 IGRpc3BsYXk6IGlubGluZSAhaW1wb3J0YW50OyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6 IDE7IGJhY2tncm91bmQtY29sb3I6IHJnYigyNTUsIDI1NSwgMjU1KTsgLXdlYmtpdC10ZXh0LXN0 cm9rZS13aWR0aDogMHB4OyI+OCBtZW50aW9ucyB0aGUgdXNlIG9mIHRpbWVzdGFtcHMgdG8gYXZv aWQgcmVwbGF5IGF0dGFja3MsIHRob3VnaCBESENQdjYgaXMgdXN1YWxseTwvc3Bhbj48YnIgc3R5 bGU9ImZvbnQ6IDE0cHgvbm9ybWFsIGFyaWFsLCBzYW5zLXNlcmlmOyBjb2xvcjogcmdiKDM0LCAz NCwgMzQpOyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgdGV4dC1pbmRlbnQ6IDBweDsgbGV0dGVyLXNw YWNpbmc6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdp ZG93czogMTsgYmFja2dyb3VuZC1jb2xvcjogcmdiKDI1NSwgMjU1LCAyNTUpOyAtd2Via2l0LXRl eHQtc3Ryb2tlLXdpZHRoOiAwcHg7Ij48c3BhbiBzdHlsZT0iZm9udDogMTRweC9ub3JtYWwgYXJp YWwsIHNhbnMtc2VyaWY7IGNvbG9yOiByZ2IoMzQsIDM0LCAzNCk7IHRleHQtdHJhbnNmb3JtOiBu b25lOyB0ZXh0LWluZGVudDogMHB4OyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB3b3JkLXNwYWNp bmc6IDBweDsgZmxvYXQ6IG5vbmU7IGRpc3BsYXk6IGlubGluZSAhaW1wb3J0YW50OyB3aGl0ZS1z cGFjZTogbm9ybWFsOyB3aWRvd3M6IDE7IGJhY2tncm91bmQtY29sb3I6IHJnYigyNTUsIDI1NSwg MjU1KTsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyI+dXNlZCB0byBib290c3RyYXAg bmV0d29yayBjb25uZWN0aXZpdHkgYW5kIHRodXMgYXQgdGhpcyBwb2ludCBkZXZpY2VzIChlc3Bl Y2lhbGx5PC9zcGFuPjxiciBzdHlsZT0iZm9udDogMTRweC9ub3JtYWwgYXJpYWwsIHNhbnMtc2Vy aWY7IGNvbG9yOiByZ2IoMzQsIDM0LCAzNCk7IHRleHQtdHJhbnNmb3JtOiBub25lOyB0ZXh0LWlu ZGVudDogMHB4OyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgd2hp dGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiAxOyBiYWNrZ3JvdW5kLWNvbG9yOiByZ2IoMjU1LCAy NTUsIDI1NSk7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsiPjxzcGFuIHN0eWxlPSJm b250OiAxNHB4L25vcm1hbCBhcmlhbCwgc2Fucy1zZXJpZjsgY29sb3I6IHJnYigzNCwgMzQsIDM0 KTsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHRleHQtaW5kZW50OiAwcHg7IGxldHRlci1zcGFjaW5n OiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyBmbG9hdDogbm9uZTsgZGlzcGxheTogaW5saW5l ICFpbXBvcnRhbnQ7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogMTsgYmFja2dyb3VuZC1j b2xvcjogcmdiKDI1NSwgMjU1LCAyNTUpOyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7 Ij5lbWJlZGRlZCBvbmVzKSBtYXkgbm90IGhhdmUgYW4gYWNjdXJhdGUgd2FsbGNsb2NrIHlldC4g VGhpcyBpcyBlc3BlY2lhbGx5IGludGVyZXN0aW5nPC9zcGFuPjxiciBzdHlsZT0iZm9udDogMTRw eC9ub3JtYWwgYXJpYWwsIHNhbnMtc2VyaWY7IGNvbG9yOiByZ2IoMzQsIDM0LCAzNCk7IHRleHQt dHJhbnNmb3JtOiBub25lOyB0ZXh0LWluZGVudDogMHB4OyBsZXR0ZXItc3BhY2luZzogbm9ybWFs OyB3b3JkLXNwYWNpbmc6IDBweDsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiAxOyBiYWNr Z3JvdW5kLWNvbG9yOiByZ2IoMjU1LCAyNTUsIDI1NSk7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lk dGg6IDBweDsiPjxzcGFuIHN0eWxlPSJmb250OiAxNHB4L25vcm1hbCBhcmlhbCwgc2Fucy1zZXJp ZjsgY29sb3I6IHJnYigzNCwgMzQsIDM0KTsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHRleHQtaW5k ZW50OiAwcHg7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyBmbG9h dDogbm9uZTsgZGlzcGxheTogaW5saW5lICFpbXBvcnRhbnQ7IHdoaXRlLXNwYWNlOiBub3JtYWw7 IHdpZG93czogMTsgYmFja2dyb3VuZC1jb2xvcjogcmdiKDI1NSwgMjU1LCAyNTUpOyAtd2Via2l0 LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7Ij5zaW5jZSBESENQdjYgaXRzZWxmIG1heSBjYXJyeSBO VFAgc2VydmVyIGFkZHJlc3NlcyB0byB1c2UuPC9zcGFuPjxiciBzdHlsZT0iZm9udDogMTRweC9u b3JtYWwgYXJpYWwsIHNhbnMtc2VyaWY7IGNvbG9yOiByZ2IoMzQsIDM0LCAzNCk7IHRleHQtdHJh bnNmb3JtOiBub25lOyB0ZXh0LWluZGVudDogMHB4OyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB3 b3JkLXNwYWNpbmc6IDBweDsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiAxOyBiYWNrZ3Jv dW5kLWNvbG9yOiByZ2IoMjU1LCAyNTUsIDI1NSk7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6 IDBweDsiPjxiciBzdHlsZT0iZm9udDogMTRweC9ub3JtYWwgYXJpYWwsIHNhbnMtc2VyaWY7IGNv bG9yOiByZ2IoMzQsIDM0LCAzNCk7IHRleHQtdHJhbnNmb3JtOiBub25lOyB0ZXh0LWluZGVudDog MHB4OyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgd2hpdGUtc3Bh Y2U6IG5vcm1hbDsgd2lkb3dzOiAxOyBiYWNrZ3JvdW5kLWNvbG9yOiByZ2IoMjU1LCAyNTUsIDI1 NSk7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsiPjxzcGFuIHN0eWxlPSJmb250OiAx NHB4L25vcm1hbCBhcmlhbCwgc2Fucy1zZXJpZjsgY29sb3I6IHJnYigzNCwgMzQsIDM0KTsgdGV4 dC10cmFuc2Zvcm06IG5vbmU7IHRleHQtaW5kZW50OiAwcHg7IGxldHRlci1zcGFjaW5nOiBub3Jt YWw7IHdvcmQtc3BhY2luZzogMHB4OyBmbG9hdDogbm9uZTsgZGlzcGxheTogaW5saW5lICFpbXBv cnRhbnQ7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogMTsgYmFja2dyb3VuZC1jb2xvcjog cmdiKDI1NSwgMjU1LCAyNTUpOyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7Ij5Tb21l IGFkZGl0aW9uYWwgc3R1ZmYgcmVsYXRlZCB0byByb3V0ZXJzIGZvcndhcmRpbmcgdGhpcyBraW5k IG9mIGluZm9ybWF0aW9uIGZyb208L3NwYW4+PGJyIHN0eWxlPSJmb250OiAxNHB4L25vcm1hbCBh cmlhbCwgc2Fucy1zZXJpZjsgY29sb3I6IHJnYigzNCwgMzQsIDM0KTsgdGV4dC10cmFuc2Zvcm06 IG5vbmU7IHRleHQtaW5kZW50OiAwcHg7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IHdvcmQtc3Bh Y2luZzogMHB4OyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IDE7IGJhY2tncm91bmQtY29s b3I6IHJnYigyNTUsIDI1NSwgMjU1KTsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyI+ PHNwYW4gc3R5bGU9ImZvbnQ6IDE0cHgvbm9ybWFsIGFyaWFsLCBzYW5zLXNlcmlmOyBjb2xvcjog cmdiKDM0LCAzNCwgMzQpOyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgdGV4dC1pbmRlbnQ6IDBweDsg bGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IGZsb2F0OiBub25lOyBk aXNwbGF5OiBpbmxpbmUgIWltcG9ydGFudDsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiAx OyBiYWNrZ3JvdW5kLWNvbG9yOiByZ2IoMjU1LCAyNTUsIDI1NSk7IC13ZWJraXQtdGV4dC1zdHJv a2Utd2lkdGg6IDBweDsiPnRvIGNsaWVudHMgKGUuZy4geW91ciBjb2ZmZWUgc2hvcCBleGFtcGxl IGluIDgpLiBJbiBnZW5lcmFsIHRoaXMgc2hvdWxkIGFwcGxpZXMgdG8gQ1BFcyw8L3NwYW4+PGJy IHN0eWxlPSJmb250OiAxNHB4L25vcm1hbCBhcmlhbCwgc2Fucy1zZXJpZjsgY29sb3I6IHJnYigz NCwgMzQsIDM0KTsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHRleHQtaW5kZW50OiAwcHg7IGxldHRl ci1zcGFjaW5nOiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyB3aGl0ZS1zcGFjZTogbm9ybWFs OyB3aWRvd3M6IDE7IGJhY2tncm91bmQtY29sb3I6IHJnYigyNTUsIDI1NSwgMjU1KTsgLXdlYmtp dC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyI+PHNwYW4gc3R5bGU9ImZvbnQ6IDE0cHgvbm9ybWFs IGFyaWFsLCBzYW5zLXNlcmlmOyBjb2xvcjogcmdiKDM0LCAzNCwgMzQpOyB0ZXh0LXRyYW5zZm9y bTogbm9uZTsgdGV4dC1pbmRlbnQ6IDBweDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgd29yZC1z cGFjaW5nOiAwcHg7IGZsb2F0OiBub25lOyBkaXNwbGF5OiBpbmxpbmUgIWltcG9ydGFudDsgd2hp dGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiAxOyBiYWNrZ3JvdW5kLWNvbG9yOiByZ2IoMjU1LCAy NTUsIDI1NSk7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsiPmFzIHNwZWNpZmllZCBp biBSRkMgNzA4NCwgZXNwZWNpYWxseSBpZiB0aGV5IHRoZW1zZWx2ZXMgZ290IHRoZSBpbmZvcm1h dGlvbiB1c2luZzwvc3Bhbj48YnIgc3R5bGU9ImZvbnQ6IDE0cHgvbm9ybWFsIGFyaWFsLCBzYW5z LXNlcmlmOyBjb2xvcjogcmdiKDM0LCAzNCwgMzQpOyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgdGV4 dC1pbmRlbnQ6IDBweDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7 IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogMTsgYmFja2dyb3VuZC1jb2xvcjogcmdiKDI1 NSwgMjU1LCAyNTUpOyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7Ij48c3BhbiBzdHls ZT0iZm9udDogMTRweC9ub3JtYWwgYXJpYWwsIHNhbnMtc2VyaWY7IGNvbG9yOiByZ2IoMzQsIDM0 LCAzNCk7IHRleHQtdHJhbnNmb3JtOiBub25lOyB0ZXh0LWluZGVudDogMHB4OyBsZXR0ZXItc3Bh Y2luZzogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgZmxvYXQ6IG5vbmU7IGRpc3BsYXk6IGlu bGluZSAhaW1wb3J0YW50OyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IDE7IGJhY2tncm91 bmQtY29sb3I6IHJnYigyNTUsIDI1NSwgMjU1KTsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDog MHB4OyI+REhDUHY2IGZyb20gYW4gSVNQLCBidXQgbm90IG5lY2Vzc2FyaWx5LiBBZ2FpbiBkaXNj bGFpbWVyOiB0aGlzIGxpc3QgaXMgbm90IGNvbmNsdXNpdmU6PC9zcGFuPjxiciBzdHlsZT0iZm9u dDogMTRweC9ub3JtYWwgYXJpYWwsIHNhbnMtc2VyaWY7IGNvbG9yOiByZ2IoMzQsIDM0LCAzNCk7 IHRleHQtdHJhbnNmb3JtOiBub25lOyB0ZXh0LWluZGVudDogMHB4OyBsZXR0ZXItc3BhY2luZzog bm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiAx OyBiYWNrZ3JvdW5kLWNvbG9yOiByZ2IoMjU1LCAyNTUsIDI1NSk7IC13ZWJraXQtdGV4dC1zdHJv a2Utd2lkdGg6IDBweDsiPjxiciBzdHlsZT0iZm9udDogMTRweC9ub3JtYWwgYXJpYWwsIHNhbnMt c2VyaWY7IGNvbG9yOiByZ2IoMzQsIDM0LCAzNCk7IHRleHQtdHJhbnNmb3JtOiBub25lOyB0ZXh0 LWluZGVudDogMHB4OyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsg d2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiAxOyBiYWNrZ3JvdW5kLWNvbG9yOiByZ2IoMjU1 LCAyNTUsIDI1NSk7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsiPjxzcGFuIHN0eWxl PSJmb250OiAxNHB4L25vcm1hbCBhcmlhbCwgc2Fucy1zZXJpZjsgY29sb3I6IHJnYigzNCwgMzQs IDM0KTsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHRleHQtaW5kZW50OiAwcHg7IGxldHRlci1zcGFj aW5nOiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyBmbG9hdDogbm9uZTsgZGlzcGxheTogaW5s aW5lICFpbXBvcnRhbnQ7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogMTsgYmFja2dyb3Vu ZC1jb2xvcjogcmdiKDI1NSwgMjU1LCAyNTUpOyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAw cHg7Ij5TaW5jZSB5b3UgZG9uJ3QgcmVzdHJpY3Qgb3B0aW9ucyBpbnNpZGUgeW91ciBjb250YWlu ZXIsIGl0IG1heSBvcmlnaW5hbGx5IGNvbnRhaW4gb3B0aW9uczwvc3Bhbj48YnIgc3R5bGU9ImZv bnQ6IDE0cHgvbm9ybWFsIGFyaWFsLCBzYW5zLXNlcmlmOyBjb2xvcjogcmdiKDM0LCAzNCwgMzQp OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgdGV4dC1pbmRlbnQ6IDBweDsgbGV0dGVyLXNwYWNpbmc6 IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czog MTsgYmFja2dyb3VuZC1jb2xvcjogcmdiKDI1NSwgMjU1LCAyNTUpOyAtd2Via2l0LXRleHQtc3Ry b2tlLXdpZHRoOiAwcHg7Ij48c3BhbiBzdHlsZT0iZm9udDogMTRweC9ub3JtYWwgYXJpYWwsIHNh bnMtc2VyaWY7IGNvbG9yOiByZ2IoMzQsIDM0LCAzNCk7IHRleHQtdHJhbnNmb3JtOiBub25lOyB0 ZXh0LWluZGVudDogMHB4OyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBw eDsgZmxvYXQ6IG5vbmU7IGRpc3BsYXk6IGlubGluZSAhaW1wb3J0YW50OyB3aGl0ZS1zcGFjZTog bm9ybWFsOyB3aWRvd3M6IDE7IGJhY2tncm91bmQtY29sb3I6IHJnYigyNTUsIDI1NSwgMjU1KTsg LXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyI+ZS5nLiBGUUROIHdoaWNoIG1heSBvbmx5 IGJlIGRpcmVjdGVkIGF0IHRoZSBzcGVjaWZpYyByZWNlaXZpbmcgcm91dGVyIGJ1dCBub3QgaG9z dHMgYmVoaW5kPC9zcGFuPjxiciBzdHlsZT0iZm9udDogMTRweC9ub3JtYWwgYXJpYWwsIHNhbnMt c2VyaWY7IGNvbG9yOiByZ2IoMzQsIDM0LCAzNCk7IHRleHQtdHJhbnNmb3JtOiBub25lOyB0ZXh0 LWluZGVudDogMHB4OyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsg d2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiAxOyBiYWNrZ3JvdW5kLWNvbG9yOiByZ2IoMjU1 LCAyNTUsIDI1NSk7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsiPjxzcGFuIHN0eWxl PSJmb250OiAxNHB4L25vcm1hbCBhcmlhbCwgc2Fucy1zZXJpZjsgY29sb3I6IHJnYigzNCwgMzQs IDM0KTsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHRleHQtaW5kZW50OiAwcHg7IGxldHRlci1zcGFj aW5nOiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyBmbG9hdDogbm9uZTsgZGlzcGxheTogaW5s aW5lICFpbXBvcnRhbnQ7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogMTsgYmFja2dyb3Vu ZC1jb2xvcjogcmdiKDI1NSwgMjU1LCAyNTUpOyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAw cHg7Ij5pdCAoZS5nLiB0aGUgaG90c3BvdCBnb3QgdGhlIFBWRCBUTFZzIHZpYSBESENQVjYgaXRz ZWxmKS4gRnVydGhlcm1vcmUgdGhlIGNvbnRhaW5lciBtYXk8L3NwYW4+PGJyIHN0eWxlPSJmb250 OiAxNHB4L25vcm1hbCBhcmlhbCwgc2Fucy1zZXJpZjsgY29sb3I6IHJnYigzNCwgMzQsIDM0KTsg dGV4dC10cmFuc2Zvcm06IG5vbmU7IHRleHQtaW5kZW50OiAwcHg7IGxldHRlci1zcGFjaW5nOiBu b3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IDE7 IGJhY2tncm91bmQtY29sb3I6IHJnYigyNTUsIDI1NSwgMjU1KTsgLXdlYmtpdC10ZXh0LXN0cm9r ZS13aWR0aDogMHB4OyI+PHNwYW4gc3R5bGU9ImZvbnQ6IDE0cHgvbm9ybWFsIGFyaWFsLCBzYW5z LXNlcmlmOyBjb2xvcjogcmdiKDM0LCAzNCwgMzQpOyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgdGV4 dC1pbmRlbnQ6IDBweDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7 IGZsb2F0OiBub25lOyBkaXNwbGF5OiBpbmxpbmUgIWltcG9ydGFudDsgd2hpdGUtc3BhY2U6IG5v cm1hbDsgd2lkb3dzOiAxOyBiYWNrZ3JvdW5kLWNvbG9yOiByZ2IoMjU1LCAyNTUsIDI1NSk7IC13 ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsiPmNvbnRhaW4gb3B0aW9ucyB3aGljaCBhcmUg c3BlY2lmaWVkIHRvIG5vdCBiZSBzZW50IHRvIGNsaWVudHMgdW5sZXNzIGV4cGxpY2l0bHkgYXNr ZWQgZm9yPC9zcGFuPjxiciBzdHlsZT0iZm9udDogMTRweC9ub3JtYWwgYXJpYWwsIHNhbnMtc2Vy aWY7IGNvbG9yOiByZ2IoMzQsIDM0LCAzNCk7IHRleHQtdHJhbnNmb3JtOiBub25lOyB0ZXh0LWlu ZGVudDogMHB4OyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgd2hp dGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiAxOyBiYWNrZ3JvdW5kLWNvbG9yOiByZ2IoMjU1LCAy NTUsIDI1NSk7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsiPjxzcGFuIHN0eWxlPSJm b250OiAxNHB4L25vcm1hbCBhcmlhbCwgc2Fucy1zZXJpZjsgY29sb3I6IHJnYigzNCwgMzQsIDM0 KTsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHRleHQtaW5kZW50OiAwcHg7IGxldHRlci1zcGFjaW5n OiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyBmbG9hdDogbm9uZTsgZGlzcGxheTogaW5saW5l ICFpbXBvcnRhbnQ7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogMTsgYmFja2dyb3VuZC1j b2xvcjogcmdiKDI1NSwgMjU1LCAyNTUpOyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7 Ij5pbiBhbiBPUk8uIEluIGJvdGggaW5zdGFuY2VzIHRoZSAiY29mZmVlIHNob3Agcm91dGVyIiB3 b3VsZCBuZWVkIHRvIGR5bmFtaWNhbGx5IHJlbW92ZTwvc3Bhbj48YnIgc3R5bGU9ImZvbnQ6IDE0 cHgvbm9ybWFsIGFyaWFsLCBzYW5zLXNlcmlmOyBjb2xvcjogcmdiKDM0LCAzNCwgMzQpOyB0ZXh0 LXRyYW5zZm9ybTogbm9uZTsgdGV4dC1pbmRlbnQ6IDBweDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1h bDsgd29yZC1zcGFjaW5nOiAwcHg7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogMTsgYmFj a2dyb3VuZC1jb2xvcjogcmdiKDI1NSwgMjU1LCAyNTUpOyAtd2Via2l0LXRleHQtc3Ryb2tlLXdp ZHRoOiAwcHg7Ij48c3BhbiBzdHlsZT0iZm9udDogMTRweC9ub3JtYWwgYXJpYWwsIHNhbnMtc2Vy aWY7IGNvbG9yOiByZ2IoMzQsIDM0LCAzNCk7IHRleHQtdHJhbnNmb3JtOiBub25lOyB0ZXh0LWlu ZGVudDogMHB4OyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgZmxv YXQ6IG5vbmU7IGRpc3BsYXk6IGlubGluZSAhaW1wb3J0YW50OyB3aGl0ZS1zcGFjZTogbm9ybWFs OyB3aWRvd3M6IDE7IGJhY2tncm91bmQtY29sb3I6IHJnYigyNTUsIDI1NSwgMjU1KTsgLXdlYmtp dC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyI+b3B0aW9ucyBmcm9tIHRoZSBjb250YWluZXIgd2hp Y2ggd2lsbCBpbmV2aXRhYmx5IGludmFsaWRhdGUgdGhlIHNpZ25hdHVyZSBvZiB0aGUgY29udGFp bmVyLjwvc3Bhbj48YnIgc3R5bGU9ImZvbnQ6IDE0cHgvbm9ybWFsIGFyaWFsLCBzYW5zLXNlcmlm OyBjb2xvcjogcmdiKDM0LCAzNCwgMzQpOyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgdGV4dC1pbmRl bnQ6IDBweDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IHdoaXRl LXNwYWNlOiBub3JtYWw7IHdpZG93czogMTsgYmFja2dyb3VuZC1jb2xvcjogcmdiKDI1NSwgMjU1 LCAyNTUpOyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7Ij48YnIgc3R5bGU9ImZvbnQ6 IDE0cHgvbm9ybWFsIGFyaWFsLCBzYW5zLXNlcmlmOyBjb2xvcjogcmdiKDM0LCAzNCwgMzQpOyB0 ZXh0LXRyYW5zZm9ybTogbm9uZTsgdGV4dC1pbmRlbnQ6IDBweDsgbGV0dGVyLXNwYWNpbmc6IG5v cm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogMTsg YmFja2dyb3VuZC1jb2xvcjogcmdiKDI1NSwgMjU1LCAyNTUpOyAtd2Via2l0LXRleHQtc3Ryb2tl LXdpZHRoOiAwcHg7Ij48c3BhbiBzdHlsZT0iZm9udDogMTRweC9ub3JtYWwgYXJpYWwsIHNhbnMt c2VyaWY7IGNvbG9yOiByZ2IoMzQsIDM0LCAzNCk7IHRleHQtdHJhbnNmb3JtOiBub25lOyB0ZXh0 LWluZGVudDogMHB4OyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsg ZmxvYXQ6IG5vbmU7IGRpc3BsYXk6IGlubGluZSAhaW1wb3J0YW50OyB3aGl0ZS1zcGFjZTogbm9y bWFsOyB3aWRvd3M6IDE7IGJhY2tncm91bmQtY29sb3I6IHJnYigyNTUsIDI1NSwgMjU1KTsgLXdl YmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyI+QWxzbyBnaXZlbiB0aGUgImNvZmZlZSBzaG9w IHJvdXRlciIgaXMgc3VwcG9zZWQgdG8gaGFuZCBvdXQgYWRkcmVzc2VzIGZyb20gZGlmZmVyZW50 IFBWRHM8L3NwYW4+PGJyIHN0eWxlPSJmb250OiAxNHB4L25vcm1hbCBhcmlhbCwgc2Fucy1zZXJp ZjsgY29sb3I6IHJnYigzNCwgMzQsIDM0KTsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHRleHQtaW5k ZW50OiAwcHg7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyB3aGl0 ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IDE7IGJhY2tncm91bmQtY29sb3I6IHJnYigyNTUsIDI1 NSwgMjU1KTsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyI+PHNwYW4gc3R5bGU9ImZv bnQ6IDE0cHgvbm9ybWFsIGFyaWFsLCBzYW5zLXNlcmlmOyBjb2xvcjogcmdiKDM0LCAzNCwgMzQp OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgdGV4dC1pbmRlbnQ6IDBweDsgbGV0dGVyLXNwYWNpbmc6 IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IGZsb2F0OiBub25lOyBkaXNwbGF5OiBpbmxpbmUg IWltcG9ydGFudDsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiAxOyBiYWNrZ3JvdW5kLWNv bG9yOiByZ2IoMjU1LCAyNTUsIDI1NSk7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsi PmFuZCAidGFnIiB0aGVtIGFwcHJvcHJpYXRlbHk6IEhvdyBpcyBpdCBzdXBwb3NlZCB0byBkbyB0 aGF0IHdpdGgganVzdCBhIGNvbnRhaW5lciB3aGljaDwvc3Bhbj48YnIgc3R5bGU9ImZvbnQ6IDE0 cHgvbm9ybWFsIGFyaWFsLCBzYW5zLXNlcmlmOyBjb2xvcjogcmdiKDM0LCAzNCwgMzQpOyB0ZXh0 LXRyYW5zZm9ybTogbm9uZTsgdGV4dC1pbmRlbnQ6IDBweDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1h bDsgd29yZC1zcGFjaW5nOiAwcHg7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogMTsgYmFj a2dyb3VuZC1jb2xvcjogcmdiKDI1NSwgMjU1LCAyNTUpOyAtd2Via2l0LXRleHQtc3Ryb2tlLXdp ZHRoOiAwcHg7Ij48c3BhbiBzdHlsZT0iZm9udDogMTRweC9ub3JtYWwgYXJpYWwsIHNhbnMtc2Vy aWY7IGNvbG9yOiByZ2IoMzQsIDM0LCAzNCk7IHRleHQtdHJhbnNmb3JtOiBub25lOyB0ZXh0LWlu ZGVudDogMHB4OyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgZmxv YXQ6IG5vbmU7IGRpc3BsYXk6IGlubGluZSAhaW1wb3J0YW50OyB3aGl0ZS1zcGFjZTogbm9ybWFs OyB3aWRvd3M6IDE7IGJhY2tncm91bmQtY29sb3I6IHJnYigyNTUsIDI1NSwgMjU1KTsgLXdlYmtp dC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyI+U0hPVUxEIGNvbnRhaW4gYSBzaWduYXR1cmU/PC9z cGFuPjxiciBzdHlsZT0iZm9udDogMTRweC9ub3JtYWwgYXJpYWwsIHNhbnMtc2VyaWY7IGNvbG9y OiByZ2IoMzQsIDM0LCAzNCk7IHRleHQtdHJhbnNmb3JtOiBub25lOyB0ZXh0LWluZGVudDogMHB4 OyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgd2hpdGUtc3BhY2U6 IG5vcm1hbDsgd2lkb3dzOiAxOyBiYWNrZ3JvdW5kLWNvbG9yOiByZ2IoMjU1LCAyNTUsIDI1NSk7 IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsiPjxzcGFuIHN0eWxlPSJmb250OiAxNHB4 L25vcm1hbCBhcmlhbCwgc2Fucy1zZXJpZjsgY29sb3I6IHJnYigzNCwgMzQsIDM0KTsgdGV4dC10 cmFuc2Zvcm06IG5vbmU7IHRleHQtaW5kZW50OiAwcHg7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7 IHdvcmQtc3BhY2luZzogMHB4OyBmbG9hdDogbm9uZTsgZGlzcGxheTogaW5saW5lICFpbXBvcnRh bnQ7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogMTsgYmFja2dyb3VuZC1jb2xvcjogcmdi KDI1NSwgMjU1LCAyNTUpOyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7Ij5JdCBjZXJ0 YWlubHkgY2Fubm90IHBsYWNlIElBQWRkcnMgb3IgSUFQcmVmaXhlcyBpbnNpZGUgY29udGFpbmVy cyBzaW5jZSBpdCBkb2Vzbid0IGhhdmU8L3NwYW4+PGJyIHN0eWxlPSJmb250OiAxNHB4L25vcm1h bCBhcmlhbCwgc2Fucy1zZXJpZjsgY29sb3I6IHJnYigzNCwgMzQsIDM0KTsgdGV4dC10cmFuc2Zv cm06IG5vbmU7IHRleHQtaW5kZW50OiAwcHg7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IHdvcmQt c3BhY2luZzogMHB4OyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IDE7IGJhY2tncm91bmQt Y29sb3I6IHJnYigyNTUsIDI1NSwgMjU1KTsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4 OyI+PHNwYW4gc3R5bGU9ImZvbnQ6IDE0cHgvbm9ybWFsIGFyaWFsLCBzYW5zLXNlcmlmOyBjb2xv cjogcmdiKDM0LCAzNCwgMzQpOyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgdGV4dC1pbmRlbnQ6IDBw eDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IGZsb2F0OiBub25l OyBkaXNwbGF5OiBpbmxpbmUgIWltcG9ydGFudDsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dz OiAxOyBiYWNrZ3JvdW5kLWNvbG9yOiByZ2IoMjU1LCAyNTUsIDI1NSk7IC13ZWJraXQtdGV4dC1z dHJva2Utd2lkdGg6IDBweDsiPnRoZSBrZXkgKHRoZXJlIGFyZSBtb3JlIGFuZCBldmVuIG1vcmUg c2V2ZXJlIGlzc3VlcyB3aXRoIHRyeWluZyB0byB1c2UgY29udGFpbmVycyBmb3IgSUFfWHM8L3Nw YW4+PGJyIHN0eWxlPSJmb250OiAxNHB4L25vcm1hbCBhcmlhbCwgc2Fucy1zZXJpZjsgY29sb3I6 IHJnYigzNCwgMzQsIDM0KTsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHRleHQtaW5kZW50OiAwcHg7 IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyB3aGl0ZS1zcGFjZTog bm9ybWFsOyB3aWRvd3M6IDE7IGJhY2tncm91bmQtY29sb3I6IHJnYigyNTUsIDI1NSwgMjU1KTsg LXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyI+PHNwYW4gc3R5bGU9ImZvbnQ6IDE0cHgv bm9ybWFsIGFyaWFsLCBzYW5zLXNlcmlmOyBjb2xvcjogcmdiKDM0LCAzNCwgMzQpOyB0ZXh0LXRy YW5zZm9ybTogbm9uZTsgdGV4dC1pbmRlbnQ6IDBweDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsg d29yZC1zcGFjaW5nOiAwcHg7IGZsb2F0OiBub25lOyBkaXNwbGF5OiBpbmxpbmUgIWltcG9ydGFu dDsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiAxOyBiYWNrZ3JvdW5kLWNvbG9yOiByZ2Io MjU1LCAyNTUsIDI1NSk7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsiPm9yIElBQWRy ZXNzIC8gSUFQcmVmaXggYnV0IEkgd2lsbCBza2lwIHRoZW0gZm9yIHRoZSBzYWtlIG9mIHNpbXBs aWNpdHkgZm9yIG5vdykuPC9zcGFuPjxiciBzdHlsZT0iZm9udDogMTRweC9ub3JtYWwgYXJpYWws IHNhbnMtc2VyaWY7IGNvbG9yOiByZ2IoMzQsIDM0LCAzNCk7IHRleHQtdHJhbnNmb3JtOiBub25l OyB0ZXh0LWluZGVudDogMHB4OyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB3b3JkLXNwYWNpbmc6 IDBweDsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiAxOyBiYWNrZ3JvdW5kLWNvbG9yOiBy Z2IoMjU1LCAyNTUsIDI1NSk7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsiPjxiciBz dHlsZT0iZm9udDogMTRweC9ub3JtYWwgYXJpYWwsIHNhbnMtc2VyaWY7IGNvbG9yOiByZ2IoMzQs IDM0LCAzNCk7IHRleHQtdHJhbnNmb3JtOiBub25lOyB0ZXh0LWluZGVudDogMHB4OyBsZXR0ZXIt c3BhY2luZzogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgd2hpdGUtc3BhY2U6IG5vcm1hbDsg d2lkb3dzOiAxOyBiYWNrZ3JvdW5kLWNvbG9yOiByZ2IoMjU1LCAyNTUsIDI1NSk7IC13ZWJraXQt dGV4dC1zdHJva2Utd2lkdGg6IDBweDsiPjxzcGFuIHN0eWxlPSJmb250OiAxNHB4L25vcm1hbCBh cmlhbCwgc2Fucy1zZXJpZjsgY29sb3I6IHJnYigzNCwgMzQsIDM0KTsgdGV4dC10cmFuc2Zvcm06 IG5vbmU7IHRleHQtaW5kZW50OiAwcHg7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IHdvcmQtc3Bh Y2luZzogMHB4OyBmbG9hdDogbm9uZTsgZGlzcGxheTogaW5saW5lICFpbXBvcnRhbnQ7IHdoaXRl LXNwYWNlOiBub3JtYWw7IHdpZG93czogMTsgYmFja2dyb3VuZC1jb2xvcjogcmdiKDI1NSwgMjU1 LCAyNTUpOyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7Ij5BbHNvLCBpZiBhIGhvdHNw b3QgLyBDRVIgLyBldGMuIGFza3MgKGUuZy4gYW4gSVNQKSBmb3IgUFZEIGluZm9ybWF0aW9uIHRo YXQgZG9lczwvc3Bhbj48YnIgc3R5bGU9ImZvbnQ6IDE0cHgvbm9ybWFsIGFyaWFsLCBzYW5zLXNl cmlmOyBjb2xvcjogcmdiKDM0LCAzNCwgMzQpOyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgdGV4dC1p bmRlbnQ6IDBweDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IHdo aXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogMTsgYmFja2dyb3VuZC1jb2xvcjogcmdiKDI1NSwg MjU1LCAyNTUpOyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7Ij48c3BhbiBzdHlsZT0i Zm9udDogMTRweC9ub3JtYWwgYXJpYWwsIHNhbnMtc2VyaWY7IGNvbG9yOiByZ2IoMzQsIDM0LCAz NCk7IHRleHQtdHJhbnNmb3JtOiBub25lOyB0ZXh0LWluZGVudDogMHB4OyBsZXR0ZXItc3BhY2lu Zzogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgZmxvYXQ6IG5vbmU7IGRpc3BsYXk6IGlubGlu ZSAhaW1wb3J0YW50OyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IDE7IGJhY2tncm91bmQt Y29sb3I6IHJnYigyNTUsIDI1NSwgMjU1KTsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4 OyI+bm90IG5lY2Vzc2FyaWx5IG1lYW4gdGhhdCBhbGwgdGhlIGhvc3RzIGJlaGluZCBzYWlkIHJv dXRlciB3aWxsIHVuZGVyc3RhbmQgUFZEIGluZm9ybWF0aW9uPC9zcGFuPjxiciBzdHlsZT0iZm9u dDogMTRweC9ub3JtYWwgYXJpYWwsIHNhbnMtc2VyaWY7IGNvbG9yOiByZ2IoMzQsIDM0LCAzNCk7 IHRleHQtdHJhbnNmb3JtOiBub25lOyB0ZXh0LWluZGVudDogMHB4OyBsZXR0ZXItc3BhY2luZzog bm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiAx OyBiYWNrZ3JvdW5kLWNvbG9yOiByZ2IoMjU1LCAyNTUsIDI1NSk7IC13ZWJraXQtdGV4dC1zdHJv a2Utd2lkdGg6IDBweDsiPjxzcGFuIHN0eWxlPSJmb250OiAxNHB4L25vcm1hbCBhcmlhbCwgc2Fu cy1zZXJpZjsgY29sb3I6IHJnYigzNCwgMzQsIDM0KTsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHRl eHQtaW5kZW50OiAwcHg7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4 OyBmbG9hdDogbm9uZTsgZGlzcGxheTogaW5saW5lICFpbXBvcnRhbnQ7IHdoaXRlLXNwYWNlOiBu b3JtYWw7IHdpZG93czogMTsgYmFja2dyb3VuZC1jb2xvcjogcmdiKDI1NSwgMjU1LCAyNTUpOyAt d2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7Ij5zbyB0aGF0IHJvdXRlciByZXF1aXJlcyB0 aGF0IGl0IGFsc28gZ2V0cyAibGVnYWN5IiBpbmZvcm1hdGlvbiBmb3IgImxlZ2FjeSIgaG9zdHMg YmVpbmc8L3NwYW4+PGJyIHN0eWxlPSJmb250OiAxNHB4L25vcm1hbCBhcmlhbCwgc2Fucy1zZXJp ZjsgY29sb3I6IHJnYigzNCwgMzQsIDM0KTsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHRleHQtaW5k ZW50OiAwcHg7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyB3aGl0 ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IDE7IGJhY2tncm91bmQtY29sb3I6IHJnYigyNTUsIDI1 NSwgMjU1KTsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyI+PHNwYW4gc3R5bGU9ImZv bnQ6IDE0cHgvbm9ybWFsIGFyaWFsLCBzYW5zLXNlcmlmOyBjb2xvcjogcmdiKDM0LCAzNCwgMzQp OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgdGV4dC1pbmRlbnQ6IDBweDsgbGV0dGVyLXNwYWNpbmc6 IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IGZsb2F0OiBub25lOyBkaXNwbGF5OiBpbmxpbmUg IWltcG9ydGFudDsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiAxOyBiYWNrZ3JvdW5kLWNv bG9yOiByZ2IoMjU1LCAyNTUsIDI1NSk7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsi Pm5vdCBQVkQtYXdhcmUgT1IgaXQgbmVlZHMgc29tZSBndWlkYW5jZSB0byBjb25zdHJ1Y3QgdGhh dCBpbmZvcm1hdGlvbiBmcm9tIGRhdGEgd2l0aGluPC9zcGFuPjxiciBzdHlsZT0iZm9udDogMTRw eC9ub3JtYWwgYXJpYWwsIHNhbnMtc2VyaWY7IGNvbG9yOiByZ2IoMzQsIDM0LCAzNCk7IHRleHQt dHJhbnNmb3JtOiBub25lOyB0ZXh0LWluZGVudDogMHB4OyBsZXR0ZXItc3BhY2luZzogbm9ybWFs OyB3b3JkLXNwYWNpbmc6IDBweDsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiAxOyBiYWNr Z3JvdW5kLWNvbG9yOiByZ2IoMjU1LCAyNTUsIDI1NSk7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lk dGg6IDBweDsiPjxzcGFuIHN0eWxlPSJmb250OiAxNHB4L25vcm1hbCBhcmlhbCwgc2Fucy1zZXJp ZjsgY29sb3I6IHJnYigzNCwgMzQsIDM0KTsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHRleHQtaW5k ZW50OiAwcHg7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyBmbG9h dDogbm9uZTsgZGlzcGxheTogaW5saW5lICFpbXBvcnRhbnQ7IHdoaXRlLXNwYWNlOiBub3JtYWw7 IHdpZG93czogMTsgYmFja2dyb3VuZC1jb2xvcjogcmdiKDI1NSwgMjU1LCAyNTUpOyAtd2Via2l0 LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7Ij50aGUgUFZEIGNvbnRhaW5lcnMgaXQgZ290Ljwvc3Bh bj48YnIgc3R5bGU9ImZvbnQ6IDE0cHgvbm9ybWFsIGFyaWFsLCBzYW5zLXNlcmlmOyBjb2xvcjog cmdiKDM0LCAzNCwgMzQpOyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgdGV4dC1pbmRlbnQ6IDBweDsg bGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IHdoaXRlLXNwYWNlOiBu b3JtYWw7IHdpZG93czogMTsgYmFja2dyb3VuZC1jb2xvcjogcmdiKDI1NSwgMjU1LCAyNTUpOyAt d2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7Ij48YnIgc3R5bGU9ImZvbnQ6IDE0cHgvbm9y bWFsIGFyaWFsLCBzYW5zLXNlcmlmOyBjb2xvcjogcmdiKDM0LCAzNCwgMzQpOyB0ZXh0LXRyYW5z Zm9ybTogbm9uZTsgdGV4dC1pbmRlbnQ6IDBweDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgd29y ZC1zcGFjaW5nOiAwcHg7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogMTsgYmFja2dyb3Vu ZC1jb2xvcjogcmdiKDI1NSwgMjU1LCAyNTUpOyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAw cHg7Ij48c3BhbiBzdHlsZT0iZm9udDogMTRweC9ub3JtYWwgYXJpYWwsIHNhbnMtc2VyaWY7IGNv bG9yOiByZ2IoMzQsIDM0LCAzNCk7IHRleHQtdHJhbnNmb3JtOiBub25lOyB0ZXh0LWluZGVudDog MHB4OyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgZmxvYXQ6IG5v bmU7IGRpc3BsYXk6IGlubGluZSAhaW1wb3J0YW50OyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRv d3M6IDE7IGJhY2tncm91bmQtY29sb3I6IHJnYigyNTUsIDI1NSwgMjU1KTsgLXdlYmtpdC10ZXh0 LXN0cm9rZS13aWR0aDogMHB4OyI+Q2hlZXJzLDwvc3Bhbj48YnIgc3R5bGU9ImZvbnQ6IDE0cHgv bm9ybWFsIGFyaWFsLCBzYW5zLXNlcmlmOyBjb2xvcjogcmdiKDM0LCAzNCwgMzQpOyB0ZXh0LXRy YW5zZm9ybTogbm9uZTsgdGV4dC1pbmRlbnQ6IDBweDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsg d29yZC1zcGFjaW5nOiAwcHg7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogMTsgYmFja2dy b3VuZC1jb2xvcjogcmdiKDI1NSwgMjU1LCAyNTUpOyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRo OiAwcHg7Ij48YnIgc3R5bGU9ImZvbnQ6IDE0cHgvbm9ybWFsIGFyaWFsLCBzYW5zLXNlcmlmOyBj b2xvcjogcmdiKDM0LCAzNCwgMzQpOyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgdGV4dC1pbmRlbnQ6 IDBweDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IHdoaXRlLXNw YWNlOiBub3JtYWw7IHdpZG93czogMTsgYmFja2dyb3VuZC1jb2xvcjogcmdiKDI1NSwgMjU1LCAy NTUpOyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7Ij48c3BhbiBzdHlsZT0iZm9udDog MTRweC9ub3JtYWwgYXJpYWwsIHNhbnMtc2VyaWY7IGNvbG9yOiByZ2IoMzQsIDM0LCAzNCk7IHRl eHQtdHJhbnNmb3JtOiBub25lOyB0ZXh0LWluZGVudDogMHB4OyBsZXR0ZXItc3BhY2luZzogbm9y bWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgZmxvYXQ6IG5vbmU7IGRpc3BsYXk6IGlubGluZSAhaW1w b3J0YW50OyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IDE7IGJhY2tncm91bmQtY29sb3I6 IHJnYigyNTUsIDI1NSwgMjU1KTsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyI+U3Rl dmVuPC9zcGFuPjxCUj4gCQkgCSAgIAkJICA8L2Rpdj48L2JvZHk+DQo8L2h0bWw+ --_2957eb25-9117-4ce1-a405-b65e9e159b19_-- From nobody Wed Jul 22 00:21:20 2015 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A929B1ACDF0 for ; Wed, 22 Jul 2015 00:21:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.549 X-Spam-Level: X-Spam-Status: No, score=-1.549 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yTCASnMOTWNL for ; Wed, 22 Jul 2015 00:21:16 -0700 (PDT) Received: from mail.core-networks.de (mail.core-networks.de [IPv6:2001:1bc0:d::4:9]) (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 272681B2AAE for ; Wed, 22 Jul 2015 00:21:16 -0700 (PDT) Received: from localhost ([127.0.0.1]) by mail.core-networks.de id 1ZHoL4-0000mo-Bv with ESMTPSA (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) for ; Wed, 22 Jul 2015 09:21:14 +0200 To: Hui Deng , "mif@ietf.org" References: From: Steven Barth Message-ID: <55AF4469.50308@openwrt.org> Date: Wed, 22 Jul 2015 09:21:13 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------070707070207090606030506" Archived-At: Subject: Re: [mif] Subject: Comments on draft-ietf-mif-mpvd-dhcp-support-01 X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2015 07:21:18 -0000 This is a multi-part message in MIME format. --------------070707070207090606030506 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit I resent it and it went through. See https://mailarchive.ietf.org/arch/msg/mif/bcfrumt2vd-YU2lUL-IKSWSqt0c It seems my subscription wasn't 100% through the first time I sent, sorry about that. Am 22.07.2015 um 09:13 schrieb Hui Deng: > Hello all, > > Steven sent this, by some chance, it was not shown up in our list, so I cc here > > From: Steven Barth > To: mif@ietf.org > Cc: > Date: Tue, 21 Jul 2015 21:55:49 +0200 > Subject: Comments on draft-ietf-mif-mpvd-dhcp-support-01 > Hi everyone, > > as promised few comments on the DHCPv6 support draft. This is based on roughly > reading it 1-2 times and not meant to be conclusive in any way. Also I'm not a > dhc expert, though I have implemented a DHCPv6 client, server and relay myself. > > 3 SHOULD contain exactly one still allows more than one PVD_AUTH vs. > "MUST be the last option inside PVD" in 5 > > 5 refers to RFC3791 in key-hash and digital-signature options but 3791 is > not part of references. > > 6 specifies that ANY options may be encapsulated. This is awkward, e.g., what > would be the meaning of e.g. a Status or a Reconfigure-Accept option within > that container, more general what happens to options explicitly defined to be > on some level and / or having a specific meaning there? > > Also where may your container option be present? Only on the top-level? > Also inside IA_NA/IA_PD? Inside IAAddr / IAPrefix? > > Also in which DHCPv6 messages may your container appear? > > 7.1 merely specifies to send ORO etc. in SOLICIT, but not in REQUEST, RENEW etc. > whereas 7.3 says OPTION_PVD must not be sent if ORO is absent in request > > 8 mentions the use of timestamps to avoid replay attacks, though DHCPv6 is usually > used to bootstrap network connectivity and thus at this point devices (especially > embedded ones) may not have an accurate wallclock yet. This is especially interesting > since DHCPv6 itself may carry NTP server addresses to use. > > Some additional stuff related to routers forwarding this kind of information from > to clients (e.g. your coffee shop example in 8). In general this should applies to CPEs, > as specified in RFC 7084, especially if they themselves got the information using > DHCPv6 from an ISP, but not necessarily. Again disclaimer: this list is not conclusive: > > Since you don't restrict options inside your container, it may originally contain options > e.g. FQDN which may only be directed at the specific receiving router but not hosts behind > it (e.g. the hotspot got the PVD TLVs via DHCPV6 itself). Furthermore the container may > contain options which are specified to not be sent to clients unless explicitly asked for > in an ORO. In both instances the "coffee shop router" would need to dynamically remove > options from the container which will inevitably invalidate the signature of the container. > > Also given the "coffee shop router" is supposed to hand out addresses from different PVDs > and "tag" them appropriately: How is it supposed to do that with just a container which > SHOULD contain a signature? > It certainly cannot place IAAddrs or IAPrefixes inside containers since it doesn't have > the key (there are more and even more severe issues with trying to use containers for IA_Xs > or IAAdress / IAPrefix but I will skip them for the sake of simplicity for now). > > Also, if a hotspot / CER / etc. asks (e.g. an ISP) for PVD information that does > not necessarily mean that all the hosts behind said router will understand PVD information > so that router requires that it also gets "legacy" information for "legacy" hosts being > not PVD-aware OR it needs some guidance to construct that information from data within > the PVD containers it got. > > Cheers, > > Steven --------------070707070207090606030506 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit I resent it and it went through. See https://mailarchive.ietf.org/arch/msg/mif/bcfrumt2vd-YU2lUL-IKSWSqt0c
It seems my subscription wasn't 100% through the first time I sent, sorry about that.


Am 22.07.2015 um 09:13 schrieb Hui Deng:
Hello all,
 
Steven sent this, by some chance, it was not shown up in our list, so I cc here
 
From: Steven Barth <cyrus@openwrt.org>
To: mif@ietf.org
Cc: 
Date: Tue, 21 Jul 2015 21:55:49 +0200
Subject: Comments on draft-ietf-mif-mpvd-dhcp-support-01
Hi everyone,

as promised few comments on the DHCPv6 support draft. This is based on roughly
reading it 1-2 times and not meant to be conclusive in any way. Also I'm not a
dhc expert, though I have implemented a DHCPv6 client, server and relay myself.

3 SHOULD contain exactly one still allows more than one PVD_AUTH vs.
"MUST be the last option inside PVD" in 5

5 refers to RFC3791 in key-hash and digital-signature options but 3791 is
not part of references.

6 specifies that ANY options may be encapsulated. This is awkward, e.g., what
would be the meaning of e.g. a Status or a Reconfigure-Accept option within
that container, more general what happens to options explicitly defined to be
on some level and / or having a specific meaning there?

Also where may your container option be present? Only on the top-level?
Also inside IA_NA/IA_PD? Inside IAAddr / IAPrefix?

Also in which DHCPv6 messages may your container appear?

7.1 merely specifies to send ORO etc. in SOLICIT, but not in REQUEST, RENEW etc.
whereas 7.3 says OPTION_PVD must not be sent if ORO is absent in request

8 mentions the use of timestamps to avoid replay attacks, though DHCPv6 is usually
used to bootstrap network connectivity and thus at this point devices (especially
embedded ones) may not have an accurate wallclock yet. This is especially interesting
since DHCPv6 itself may carry NTP server addresses to use.

Some additional stuff related to routers forwarding this kind of information from
to clients (e.g. your coffee shop example in 8). In general this should applies to CPEs,
as specified in RFC 7084, especially if they themselves got the information using
DHCPv6 from an ISP, but not necessarily. Again disclaimer: this list is not conclusive:

Since you don't restrict options inside your container, it may originally contain options
e.g. FQDN which may only be directed at the specific receiving router but not hosts behind
it (e.g. the hotspot got the PVD TLVs via DHCPV6 itself). Furthermore the container may
contain options which are specified to not be sent to clients unless explicitly asked for
in an ORO. In both instances the "coffee shop router" would need to dynamically remove
options from the container which will inevitably invalidate the signature of the container.

Also given the "coffee shop router" is supposed to hand out addresses from different PVDs
and "tag" them appropriately: How is it supposed to do that with just a container which
SHOULD contain a signature?
It certainly cannot place IAAddrs or IAPrefixes inside containers since it doesn't have
the key (there are more and even more severe issues with trying to use containers for IA_Xs
or IAAdress / IAPrefix but I will skip them for the sake of simplicity for now).

Also, if a hotspot / CER / etc. asks (e.g. an ISP) for PVD information that does
not necessarily mean that all the hosts behind said router will understand PVD information
so that router requires that it also gets "legacy" information for "legacy" hosts being
not PVD-aware OR it needs some guidance to construct that information from data within
the PVD containers it got.

Cheers,

Steven

--------------070707070207090606030506-- From nobody Wed Jul 22 00:45:04 2015 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 484E21AD0B1 for ; Wed, 22 Jul 2015 00:45:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.55 X-Spam-Level: X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m4I-WJqXIrk0 for ; Wed, 22 Jul 2015 00:45:01 -0700 (PDT) Received: from mail.core-networks.de (mail.core-networks.de [IPv6:2001:1bc0:d::4:9]) (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 7BB761ACE2C for ; Wed, 22 Jul 2015 00:45:01 -0700 (PDT) Received: from localhost ([127.0.0.1]) by mail.core-networks.de id 1ZHoi3-0001aP-49 with ESMTPSA (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) for mif@ietf.org; Wed, 22 Jul 2015 09:44:59 +0200 To: mif@ietf.org References: <55AF4226.8010803@openwrt.org> From: Steven Barth Message-ID: <55AF49FA.4020605@openwrt.org> Date: Wed, 22 Jul 2015 09:44:58 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: <55AF4226.8010803@openwrt.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [mif] Comments on draft-ietf-mif-mpvd-id-01 X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2015 07:45:03 -0000 > 3 I'm unsure about the id-length field. It seems entirely redundant for e.g. > DHCP(v6) purposes and even considering e.g. RAs it is redundant for half of > the given id-types. Should this be type-specfic instead? Actually strike that, I should not review this early in the morning. Anyway it makes sense to allow for future id-types to be skippable, still may be debatable whether it should be depending on if the configuration or whatever protocol actually requires it. From nobody Wed Jul 22 01:23:20 2015 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 358571A036C for ; Wed, 22 Jul 2015 01:23:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.55 X-Spam-Level: X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CdkvU-eTaEdl for ; Wed, 22 Jul 2015 01:23:17 -0700 (PDT) Received: from mail.core-networks.de (mail.core-networks.de [IPv6:2001:1bc0:d::4:9]) (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 BEF7A1A0267 for ; Wed, 22 Jul 2015 01:23:17 -0700 (PDT) Received: from localhost ([127.0.0.1]) by mail.core-networks.de id 1ZHpJ5-0002xh-RA with ESMTPSA (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) for mif@ietf.org; Wed, 22 Jul 2015 10:23:16 +0200 To: "mif@ietf.org" From: Steven Barth Message-ID: <55AF52F1.2040802@openwrt.org> Date: Wed, 22 Jul 2015 10:23:13 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: [mif] Comments on draft-ietf-mif-mpvd-ndp-support X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2015 08:23:19 -0000 Hello everyone, some probably non-conclusive comments on the NDP-support draft. 3 "However, including a PVD container or identity options inside a Router Solicitation (RS) NDP messages is also possible (actually, in this way a host can solicit for information from a specific provisioning domain)." This is awkward. Foremost, hosts only send RSs when they change links and also replies to RS may be multicasted to all hosts on the links (and often in practice still are). In any case I don't see the point of adding the container to the RS and / or maybe the Identity. This is just plain ambiguous. 3 "The PVD container MUST NOT be fragmented i.e., should the IPv6 packet be fragmented, the PVD container and the accompanying PVD identity MUST both be inside the same fragment." The i.e. makes it ambiguous. Now MUST the whole container NOT be fragmented or MUST every fragment have a PVD Identity or only the first one? 3 S-bit: Could this not just be encoded as "Name Type" = 0? 3 "Name Type": I find it peculiar that the name type is selectable but not the signature algorithm (at least to my understanding). 3 "Key Hash": Since this doesn't have a length field a client not understanding the name type cannot interpret anything in the container even if it does not want to check the signature. I'm not sure if this is intended. 3 "This MAY imply adding padding zero octets to the tail of the PVD container option until the alignment requirement has been met" A MAY padding seems awkward and actually ambiguous. (This also applies to 4 to a lesser degree) 4 Is it useful that PVD ID is a separate TLV if a container MUST have exactly 1 in it and the stand-alone use (e.g. in RS) is probably questionable? 6 Again as for dhcpv6, timestamps may not be ready for checking at the point where RAs are evaluated since these are essentially bootstrap protocol and not all devices do have RTCs or unauthenticated NTP server options may be used to tamper with wallclock settings. 9 RFC 3971 is in informative references but since you use it as source for your signature algorithm should it not be normative? Cheers, Steven From nobody Wed Jul 22 02:29:06 2015 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D65EC1ACEBF for ; Wed, 22 Jul 2015 02:29:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1 X-Spam-Level: X-Spam-Status: No, score=-1 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, FREEMAIL_REPLY=1, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bTSu2fi0UZA9 for ; Wed, 22 Jul 2015 02:29:03 -0700 (PDT) Received: from mail-wi0-x235.google.com (mail-wi0-x235.google.com [IPv6:2a00:1450:400c:c05::235]) (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 C0D301AD06E for ; Wed, 22 Jul 2015 02:29:02 -0700 (PDT) Received: by wibxm9 with SMTP id xm9so154482077wib.0 for ; Wed, 22 Jul 2015 02:29:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=u8DazJVUy4cE+xkJOICAAFkcVIhHKBZK89xZ2cku7Ig=; b=AAzC+oDthHEeat10BtEQIquezRWlPXX0hIXTXnyCdKvzUQGTytnEMSouq6+3pajk33 2jc4EJy6iCLlb1TIr8UMwwvvXyVHcbWnyqhWLTjfaSnU2Np8qfgr8DE9yxCppa1+ayqy GBysHXb4R+MmRablK3CdtnBR0njCQuF4wgdlLLZfqg7tEexq6cW0xgWMOAAUmhfC3ILY DYHNecZbgryLUA1QI6YPXoHOXlr9MC0W5RsBFasKsHQhHOfueym6kByfk22TsOS37/ZC iO4Cd76K9Wpfk2TaQ5CCf+QTC3o2gTsJztV4XpSOeWHi5ZCqnFNl5gqEkXrmo0FAgBpP T4YA== X-Received: by 10.180.101.138 with SMTP id fg10mr4799408wib.46.1437557341533; Wed, 22 Jul 2015 02:29:01 -0700 (PDT) Received: from ?IPv6:2001:67c:370:160:e513:b48:e684:212f? ([2001:67c:370:160:e513:b48:e684:212f]) by smtp.googlemail.com with ESMTPSA id v9sm1380218wjq.41.2015.07.22.02.29.00 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 22 Jul 2015 02:29:00 -0700 (PDT) To: Ian Farrer References: <79C18793-758C-421A-A0C6-2F5625F1E17E@gmx.com> <55AD3922.8090009@gmail.com> <69E5A45D-C11A-4383-A4EE-AEF05675E718@gmx.com> <55AE2288.5070509@gmail.com> <74F2D07D-4FB2-4FB6-B482-EF202B4D533F@gmx.com> From: Jouni Korhonen Message-ID: <55AF625B.5040506@gmail.com> Date: Wed, 22 Jul 2015 02:28:59 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: <74F2D07D-4FB2-4FB6-B482-EF202B4D533F@gmx.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "mif@ietf.org" , Hui Deng Subject: Re: [mif] WGLC for draft-ietf-mif-mpvd-id X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2015 09:29:05 -0000 Now I do not really understand the desire for standardized format for metadata. You basically move to burden of multiple, some more descriptive IDs, to fully flexible/standardized metadata. Does not seem to improve the situation. - Jouni 7/21/2015, 4:17 AM, Ian Farrer kirjoitti: > The meta-data formats would be standardised formats as well so that they > can potentially be universally understood. > > i.e. the id-formats that are enumerated in section 3 of the pad-id > document (with the exception of the format which is chosen as the single > unique Identifier) would form the initial set of PVD-ID meta data. > > However, on thinking about this, maybe defining an additional type for > 'PVD-ID owner binary blob’ could be an idea if people see a need for it. > > Cheers, > Ian > > >> On 21 Jul 2015, at 12:44, Jouni Korhonen > > wrote: >> >> Thanks Ian, >> >> And the metadata is just a binary blob only understood by the PVD-ID >> "owner"? >> >> - Jouni >> >> 7/21/2015, 2:02 AM, Ian Farrer kirjoitti: >>> Hi Jouni, >>> >>> The specific things that I think need to be addressed here are: >>> >>> 1, Removing the decision making process for an operator looking to >>> choose the right format to use. This needs to be common across the whole >>> of an operator’s network and so needs to be supported by all devices and >>> advertising/provisioning protocols present and future. Once deployed at >>> any scale, changing this will be non-trivial. >>> >>> 2, At this stage in the development of the PvD architecture, it is very >>> difficult to know how this will need to evolve and be extended in the >>> future, so it is almost impossible to make an informed decision about >>> what the best PvD format to choose is. >>> >>> So, this is why I think that choosing a single format with a high >>> probability of uniqueness and a small, defined size. But this needs to >>> be combined with extensibility for adding meta-data to take advantage of >>> the capabilities of less constrained devices and advertising protocols >>> so that additional information can be supplied to allow clients / >>> applications / users to make an informed decision about the PvD. >>> >>> How I would see this working is that the PvD-ID itself would be a single >>> format - e.g. UUID. This must be advertised in all provisioning >>> messages. An additional DHCPv6/PIO option would then be defined that >>> allows an operator to add additional meta-data options which are >>> associated with the PVD-ID according to their needs / the capabilities >>> of the device/protocols etc (i.e. the other PvD-ID formats that have >>> been described in the draft). >>> >>> This allows for the mechanism to be extended as needed without the need >>> to change the PvD-ID formats that are in use in existing devices. If you >>> want to extend your PvD architecture so that new devices have new logic >>> for selecting the correct PvD based on new logic, then you can add a new >>> PvD-ID meta-data option linked to an existing PvD-ID without needing to >>> change the underlying PvD architecture or devices that you have deployed. >>> >>> With the current mechanism as described, to make any changes to your PvD >>> architecture to support new client PvD selection logic requires >>> deploying another PvD format in parallel to the existing one. This is, >>> by the PvD architecture a new PvD, even if the service properties are >>> identical to an existing PvD which you have already deployed. Then, your >>> provisioning protocols need to advertise duplicate configuration for >>> both of the PvDs, even thought that configuration is the same, with the >>> exception of the PvD-ID. >>> >>> So, the short answer to your question is: Single PvD-ID format (I like >>> UUID) + extensible associated meta-data. >>> >>> Cheers, >>> Ian >>> >>> >>>> On 20 Jul 2015, at 20:08, Jouni Korhonen >>> >>>> > wrote: >>>> >>>> Ian, >>>> >>>> So would UUID be adequate PVD-ID format as suggested below? >>>> >>>> What about the additonal information part? Not needed? >>>> >>>> - Jouni >>>> >>>> >>>> 7/20/2015, 7:33 AM, Ian Farrer kirjoitti: >>>>> Hi, >>>>> >>>>> Before this document can proceed, I think that there is still a >>>>> significant open point. Multiple or single PVD ID formats? >>>>> >>>>> This question has been raised a few times at WG meetings, but there is >>>>> no reflection in the draft as it stands. This is an excerpt from the >>>>> IETF91 minutes: >>>>> >>>>> Margaret: 2 changes proposed: move to single unique short ID (UUID) >>>>> and allow for additional info to be a part of the ID. So can we >>>>> try to reach consensus on each? >>>>> >>>>> Who thinks we should move to one unique format? >>>>> (a couple of hands; 2nd time asking had about 10 hands) >>>>> Who thinks we should not use a single unique format? >>>>> (no hands) >>>>> OK. Single unique. >>>>> >>>>> So, I would like to see this discussion take place before the document >>>>> progresses. >>>>> >>>>> Thanks, >>>>> Ian >>>>> >>>>> >>>>> >>>>>> On 14 Jul 2015, at 17:18, Hui Deng >>>>> >>>>>> >>>>>> > wrote: >>>>>> >>>>>> Hello all, >>>>>> >>>>>> We would like to have a 3 weeks WGLC for the below document: >>>>>> http://datatracker.ietf.org/doc/draft-ietf-mif-mpvd-id/ >>>>>> >>>>>> Please help to send your comments to this thread. >>>>>> This WGLC will end on Aug. 5th. >>>>>> >>>>>> Many thanks >>>>>> >>>>>> DENG Hui >>>>>> _______________________________________________ >>>>>> mif mailing list >>>>>> mif@ietf.org >>>>>> >>>>>> https://www.ietf.org/mailman/listinfo/mif >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> mif mailing list >>>>> mif@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/mif > From nobody Wed Jul 22 06:14:05 2015 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C55951A1AE6 for ; Wed, 22 Jul 2015 06:14:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bPC12LBbOlMK for ; Wed, 22 Jul 2015 06:14:02 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1243E1A1AA6 for ; Wed, 22 Jul 2015 06:13:50 -0700 (PDT) X-AuditID: c6180641-f794d6d000001dfb-d4-55af2f01a637 Received: from EUSAAHC001.ericsson.se (Unknown_Domain [147.117.188.75]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id B0.A2.07675.10F2FA55; Wed, 22 Jul 2015 07:49:54 +0200 (CEST) Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC001.ericsson.se ([147.117.188.75]) with mapi id 14.03.0210.002; Wed, 22 Jul 2015 09:13:48 -0400 From: Suresh Krishnan To: Steven Barth , "mif@ietf.org" Thread-Topic: [mif] Comments on draft-ietf-mif-mpvd-dhcp-support-01 Thread-Index: AQHQw+9tYbI6movB7kuuOxc8D/a1sg== Date: Wed, 22 Jul 2015 13:13:48 +0000 Message-ID: References: <55AEA40C.4090909@openwrt.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.11] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrGLMWRmVeSWpSXmKPExsUyuXSPty6T/vpQg75zPBbnDm9isujac4PJ gcljyZKfTB5bFmcEMEVx2aSk5mSWpRbp2yVwZdybfYO5oMu4oul5VAPjb40uRk4OCQETiRUH jjJD2GISF+6tZ+ti5OIQEjjKKHHj4VQWCGc5o8TcK0dZQKrYgDo27PzMBGKLCDhLXP1/CMwW FnCSeHbqFztMfP+nDVC2nsSKDZvBelkEVCWWbFwMFucV8JU4tfEjUC8H0AItiePL/EDCjEBH fD+1Bmwks4C4xK0n85kgjhOQWLLnPNShohIvH/9jhbCVJD7+ns8OUa8jsWD3JzYIW1ti2cLX zBCrBCVOznzCMoFRZBaSsbOQtMxC0jILScsCRpZVjBylxalluelGhpsYgQF/TILNcQfjgk+W hxgFOBiVeHgXdKwLFWJNLCuuzD3EKM3BoiTOK+2XFyokkJ5YkpqdmlqQWhRfVJqTWnyIkYmD U6qBUfEXP7fjktWLTd/VHa8K2lqqU/tmrjeb5tOGv1a/n3ory6yeoqq2vZG9lFtQ7VCb0rMv y6rurtT7t9H1G9e790mpEuYP27/WPBWqEV34aEv9zW7eu38WXC0vPWJ+wjDg+bYZZx8v+/u8 xWHuzTQdPYd1qk5liWkTeL/ccHlUdv0Ng/nM2M7Ge0osxRmJhlrMRcWJAP3y/L9ZAgAA Archived-At: Subject: Re: [mif] Comments on draft-ietf-mif-mpvd-dhcp-support-01 X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2015 13:14:03 -0000 Hi Steven,=0A= Thanks a lot for your comments. Please find responses inline.=0A= =0A= On 07/21/2015 03:57 PM, Steven Barth wrote:=0A= > Hi everyone,=0A= >=0A= > as promised few comments on the DHCPv6 support draft. This is based on ro= ughly=0A= > reading it 1-2 times and not meant to be conclusive in any way. Also I'm = not a=0A= > dhc expert, though I have implemented a DHCPv6 client, server and relay m= yself.=0A= >=0A= >=0A= >=0A= > 3 SHOULD contain exactly one still allows more than one PVD_AUTH vs.=0A= > "MUST be the last option inside PVD" in 5=0A= =0A= =0A= It does not allow more than one. The options are 1 or 0 depending on =0A= whether the option was requested in the ORO. If it occurs, it needs to =0A= be the last option inside the PVD.=0A= =0A= >=0A= >=0A= > 5 refers to RFC3791 in key-hash and digital-signature options but 3791 is= =0A= > not part of references.=0A= =0A= Will add the reference.=0A= =0A= >=0A= >=0A= > 6 specifies that ANY options may be encapsulated. This is awkward, e.g., = what=0A= > would be the meaning of e.g. a Status or a Reconfigure-Accept option with= in=0A= > that container, more general what happens to options explicitly defined t= o be=0A= > on some level and / or having a specific meaning there?=0A= =0A= I think it is very difficult to find a good answer here. At the other =0A= end of the spectrum we can list the options that are allowed. This has a = =0A= different set of isues. As I see it, there are three possible options=0A= =0A= a) Allow all legal DHCPv6 options to be inside the PVD. Expect =0A= reasonable use of options by admins.=0A= =0A= b) List all the allowed options in the document.=0A= =0A= c) Maintain an extensible (e.g. IANA) registry of the options allowed =0A= inside the PVD container=0A= =0A= Each of these comes with a different set of pros and cons. We can pick a = =0A= direction based on what the wg thinks.=0A= =0A= >=0A= > Also where may your container option be present? Only on the top-level?= =0A= > Also inside IA_NA/IA_PD? Inside IAAddr / IAPrefix?=0A= >=0A= > Also in which DHCPv6 messages may your container appear?=0A= ...=0A= > 7.1 merely specifies to send ORO etc. in SOLICIT, but not in REQUEST, REN= EW etc.=0A= > whereas 7.3 says OPTION_PVD must not be sent if ORO is absent in request= =0A= =0A= Will add text about the messages that can carry this option.=0A= =0A= >=0A= >=0A= > 8 mentions the use of timestamps to avoid replay attacks, though DHCPv6 i= s usually=0A= > used to bootstrap network connectivity and thus at this point devices (es= pecially=0A= > embedded ones) may not have an accurate wallclock yet. This is especially= interesting=0A= > since DHCPv6 itself may carry NTP server addresses to use.=0A= =0A= Right. This is a real issue that is not specific to mif. The same =0A= problem occurs when we need to do DNSSEC validation for the NTP servers =0A= provided (as DNSSEC validation requires clock sync).=0A= =0A= > Some additional stuff related to routers forwarding this kind of informat= ion from=0A= > to clients (e.g. your coffee shop example in 8). In general this should a= pplies to CPEs,=0A= > as specified in RFC 7084, especially if they themselves got the informati= on using=0A= > DHCPv6 from an ISP, but not necessarily. Again disclaimer: this list is n= ot conclusive:=0A= >=0A= > Since you don't restrict options inside your container, it may originally= contain options=0A= > e.g. FQDN which may only be directed at the specific receiving router but= not hosts behind=0A= > it (e.g. the hotspot got the PVD TLVs via DHCPV6 itself). Furthermore the= container may=0A= > contain options which are specified to not be sent to clients unless expl= icitly asked for=0A= > in an ORO. In both instances the "coffee shop router" would need to dynam= ically remove=0A= > options from the container which will inevitably invalidate the signature= of the container.=0A= >=0A= > Also given the "coffee shop router" is supposed to hand out addresses fro= m different PVDs=0A= > and "tag" them appropriately: How is it supposed to do that with just a c= ontainer which=0A= > SHOULD contain a signature?=0A= =0A= Let me clarify something before we go further. The OPTION_PVD_AUTH will =0A= be sent only if it is in the ORO. If the CPE does not request this, it =0A= will not get a signed PVD option. It is free to split up the contained =0A= options however it wishes. For the homenet use case, I think it would be = =0A= best not to request the OPTION_PVD_AUTH as it is likely that there is no = =0A= need to ensure the integrity of the container.=0A= =0A= =0A= > It certainly cannot place IAAddrs or IAPrefixes inside containers since i= t doesn't have=0A= > the key (there are more and even more severe issues with trying to use co= ntainers for IA_Xs=0A= > or IAAdress / IAPrefix but I will skip them for the sake of simplicity fo= r now).=0A= >=0A= > Also, if a hotspot / CER / etc. asks (e.g. an ISP) for PVD information th= at does=0A= > not necessarily mean that all the hosts behind said router will understan= d PVD information=0A= > so that router requires that it also gets "legacy" information for "legac= y" hosts being=0A= > not PVD-aware OR it needs some guidance to construct that information fro= m data within=0A= > the PVD containers it got.=0A= =0A= Yes. This is a tough cookie. In the NDP based solution we had a much =0A= easier way to do this. We created the option so that legacy clients will = =0A= just skip over the PVD "container" and look at the options they understand.= =0A= =0A= A good way to solve this would be for the DHCPv6 server to send the =0A= configuration info outside the container for further distribution to =0A= legacy clients along with the info inside the container for the PVD =0A= aware clients. Unfortunately, there is no way to request the server to =0A= do this with the current ORO mechanism=0A= =0A= Would some guidance of this form be useful?=0A= =0A= "Clients that request the OPTION_PVD with the intention of =0A= redistributing configuration information to other clients (e.g. CPE =0A= routers) SHOULD NOT request the OPTION_PVD_AUTH in the ORO. This allows =0A= them to send out a subset of the received options to their clients and =0A= also allows them to support PVD unaware clients by sending out the =0A= options without PVD information."=0A= =0A= Thanks=0A= Suresh=0A= =0A= From nobody Wed Jul 22 08:21:42 2015 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 999481A0113 for ; Wed, 22 Jul 2015 08:21:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.599 X-Spam-Level: X-Spam-Status: No, score=-1.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id al26LM1HsNHs for ; Wed, 22 Jul 2015 08:21:37 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 58BB91A0439 for ; Wed, 22 Jul 2015 08:21:36 -0700 (PDT) Received: from dhcp-a15f.meeting.ietf.org ([31.133.161.95]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0MMoU7-1ZICHL0ssp-008XEa; Wed, 22 Jul 2015 17:21:32 +0200 Content-Type: multipart/alternative; boundary="Apple-Mail=_F671A12C-A84E-4A53-8A0E-B58F36CDC8DF" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) From: Ian Farrer In-Reply-To: <55AF625B.5040506@gmail.com> Date: Wed, 22 Jul 2015 17:21:31 +0200 Message-Id: <352EAA2D-0D69-40F6-8C6B-8980DD780AEA@gmx.com> References: <79C18793-758C-421A-A0C6-2F5625F1E17E@gmx.com> <55AD3922.8090009@gmail.com> <69E5A45D-C11A-4383-A4EE-AEF05675E718@gmx.com> <55AE2288.5070509@gmail.com> <74F2D07D-4FB2-4FB6-B482-EF202B4D533F@gmx.com> <55AF625B.5040506@gmail.com> To: Jouni Korhonen X-Mailer: Apple Mail (2.2102) X-Provags-ID: V03:K0:GejJxLJuZ8H3UpZDKRg8ufeNQCBdh4RD27SekTb3MD1ZEEnHh13 IxD0wbnZ6g9+X0/C5VPEHfeCFRGYCWeLuiO7Khmtx76GpXeBwkHxJKTofypaHZugRJ39sZL 2DqAzTS7JuhGhlcR6htPJp2tipUAdcOUASEWHkv74LzmKuMRfgm7EGGIMMGbITVobG8JIcH XoH0zXdW3NtmuYyHPbVkw== X-UI-Out-Filterresults: notjunk:1;V01:K0:ZnJhZZybIDY=:5Sc/8bJMW87Vx6kgNPY5ss L72Gs48xUUm0VJP3exvkYUfjljT/6wkcsEyqns+3Cww94x5Ng4sTGlrcOHLJPujd7ekygpzyT k4ReCAPQaeFErGc13BH4OBX3opdsKzzHS5J7/ZJCfhwk6ma8lFa44RN42EmZ4FKimEsUlFFF0 DjplDIOfmaTKeDJvjKEZQuYLOJGZyDmhgjQblam+KXTTGNCcOUvvEj6hKchldXmXY4DCryGP/ 7WddzDk5cfFMS33Qv17zKq4m4fKKrHtArUm+Ve8uxvGQ4OtqTKhPrsvOKvKAxFB6NYaNFx87x gwY3NY5HIu89zuBu24Z1G3V4O5s+oVMcSqo9h32SAd5QfGHTLJflWp4Tq1YJj7S5Kt8AWzJdJ DnKOr4cXmvT+zS1K3xXkiSddXzdDAzSIJ/yIWqKhBdy5XXZ3ppUYevR34JdQYgYu/kspab5yb JOLnVe/NT78PbEEjgscDYG5TeFmfvJo1wszwP8iyJAYUD03ax13T93FjOXXtazKjtUNJyEy6t Nu+UODHhIlk9juawug/SvWx1iGRMaXiTqHlNWKuJPwwp0OY50+WpLivKlu84R/2hvmcrTFVIH kA06MTzOFAIVFxPGAju05oy7AyJYHPtdAhMZahV6vx+vonPNY/lLGzZ5TmVJ5hjoSILwJhnHG 986xJJe0OLG8OVlbJ5UnI0jUAUrWhtt3B2JDDrqfLmEZpkIQyrB3Zn1+vcVjVLFMppUQ= Archived-At: Cc: "mif@ietf.org" , Hui Deng Subject: Re: [mif] WGLC for draft-ietf-mif-mpvd-id X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2015 15:21:40 -0000 --Apple-Mail=_F671A12C-A84E-4A53-8A0E-B58F36CDC8DF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi Jouni, A set top box supplied by an operator could ship pre-configured to look = for the PvD based on the UUID (if this is the chosen single unique = identifier format). This UUID is advertised in RAs to the STB, so it can = select it. It=92s a closed system, so it=92s achievable. But the user may want to access the same content over the same PvD, but = this time with a 3rd party streaming client on their laptop. Now there=92s= no pre-configured PvD to look for, so it would be useful to present = something descriptive and human readable to the user to give them a = chance of being able to select the right PvD for their app (e.g. you add = the meta-data, associated with the same UUID as above, say the FQDN = format =92streamingtv.bigtelco.com=92). The FQDN format is standard, so = the app without any knowledge of the operator=92s network can interpret = this and offer it to the user as a choice. Once the app is configured, = it=92s looking for the associated UUID as the unique identifier for the = streaming PvD (i.e., if the laptop was moved to another subnet in the = house that was running PvDs over RAs without the FQDN meta-data option, = it would still be able to identify the right one to use). Maybe you also want to attach an additional meta-data message in the = DHCPv6 provisioning containing a URL for a page telling the user how to = configure their client correctly. The URL is also associated with the = PvD-ID (alongside the FQDN meta-data). Again, the URL would need to be a = standard format. And so on... So, the extensible format allows for the mechanism to be augmented in = the future (within the limits of what is implementable in a client / = provisioning protocol). Several of these in different formats may be = used and associated with a single PvD. Clients can ignore meta-data that = they don=92t understand, or a not configured to parse. Standard formats = mean that devices/applications can interpret offered meta-data without = having to be pre-configured (somehow) to run within a specific operators = PvD architecture.=20 Cheers, Ian > On 22 Jul 2015, at 11:28, Jouni Korhonen = wrote: >=20 > Now I do not really understand the desire for standardized format for = metadata. You basically move to burden of multiple, some more = descriptive IDs, to fully flexible/standardized metadata. Does not seem = to improve the situation. >=20 > - Jouni >=20 > 7/21/2015, 4:17 AM, Ian Farrer kirjoitti: >> The meta-data formats would be standardised formats as well so that = they >> can potentially be universally understood. >>=20 >> i.e. the id-formats that are enumerated in section 3 of the pad-id >> document (with the exception of the format which is chosen as the = single >> unique Identifier) would form the initial set of PVD-ID meta data. >>=20 >> However, on thinking about this, maybe defining an additional type = for >> 'PVD-ID owner binary blob=92 could be an idea if people see a need = for it. >>=20 >> Cheers, >> Ian >>=20 >>=20 >>> On 21 Jul 2015, at 12:44, Jouni Korhonen >> >> = wrote: >>>=20 >>> Thanks Ian, >>>=20 >>> And the metadata is just a binary blob only understood by the PVD-ID >>> "owner"? >>>=20 >>> - Jouni >>>=20 >>> 7/21/2015, 2:02 AM, Ian Farrer kirjoitti: >>>> Hi Jouni, >>>>=20 >>>> The specific things that I think need to be addressed here are: >>>>=20 >>>> 1, Removing the decision making process for an operator looking to >>>> choose the right format to use. This needs to be common across the = whole >>>> of an operator=92s network and so needs to be supported by all = devices and >>>> advertising/provisioning protocols present and future. Once = deployed at >>>> any scale, changing this will be non-trivial. >>>>=20 >>>> 2, At this stage in the development of the PvD architecture, it is = very >>>> difficult to know how this will need to evolve and be extended in = the >>>> future, so it is almost impossible to make an informed decision = about >>>> what the best PvD format to choose is. >>>>=20 >>>> So, this is why I think that choosing a single format with a high >>>> probability of uniqueness and a small, defined size. But this needs = to >>>> be combined with extensibility for adding meta-data to take = advantage of >>>> the capabilities of less constrained devices and advertising = protocols >>>> so that additional information can be supplied to allow clients / >>>> applications / users to make an informed decision about the PvD. >>>>=20 >>>> How I would see this working is that the PvD-ID itself would be a = single >>>> format - e.g. UUID. This must be advertised in all provisioning >>>> messages. An additional DHCPv6/PIO option would then be defined = that >>>> allows an operator to add additional meta-data options which are >>>> associated with the PVD-ID according to their needs / the = capabilities >>>> of the device/protocols etc (i.e. the other PvD-ID formats that = have >>>> been described in the draft). >>>>=20 >>>> This allows for the mechanism to be extended as needed without the = need >>>> to change the PvD-ID formats that are in use in existing devices. = If you >>>> want to extend your PvD architecture so that new devices have new = logic >>>> for selecting the correct PvD based on new logic, then you can add = a new >>>> PvD-ID meta-data option linked to an existing PvD-ID without = needing to >>>> change the underlying PvD architecture or devices that you have = deployed. >>>>=20 >>>> With the current mechanism as described, to make any changes to = your PvD >>>> architecture to support new client PvD selection logic requires >>>> deploying another PvD format in parallel to the existing one. This = is, >>>> by the PvD architecture a new PvD, even if the service properties = are >>>> identical to an existing PvD which you have already deployed. Then, = your >>>> provisioning protocols need to advertise duplicate configuration = for >>>> both of the PvDs, even thought that configuration is the same, with = the >>>> exception of the PvD-ID. >>>>=20 >>>> So, the short answer to your question is: Single PvD-ID format (I = like >>>> UUID) + extensible associated meta-data. >>>>=20 >>>> Cheers, >>>> Ian >>>>=20 >>>>=20 >>>>> On 20 Jul 2015, at 20:08, Jouni Korhonen >>>>> > >>>>> >> = wrote: >>>>>=20 >>>>> Ian, >>>>>=20 >>>>> So would UUID be adequate PVD-ID format as suggested below? >>>>>=20 >>>>> What about the additonal information part? Not needed? >>>>>=20 >>>>> - Jouni >>>>>=20 >>>>>=20 >>>>> 7/20/2015, 7:33 AM, Ian Farrer kirjoitti: >>>>>> Hi, >>>>>>=20 >>>>>> Before this document can proceed, I think that there is still a >>>>>> significant open point. Multiple or single PVD ID formats? >>>>>>=20 >>>>>> This question has been raised a few times at WG meetings, but = there is >>>>>> no reflection in the draft as it stands. This is an excerpt from = the >>>>>> IETF91 minutes: >>>>>>=20 >>>>>> Margaret: 2 changes proposed: move to single unique short ID = (UUID) >>>>>> and allow for additional info to be a part of the ID. So can we >>>>>> try to reach consensus on each? >>>>>>=20 >>>>>> Who thinks we should move to one unique format? >>>>>> (a couple of hands; 2nd time asking had about 10 hands) >>>>>> Who thinks we should not use a single unique format? >>>>>> (no hands) >>>>>> OK. Single unique. >>>>>>=20 >>>>>> So, I would like to see this discussion take place before the = document >>>>>> progresses. >>>>>>=20 >>>>>> Thanks, >>>>>> Ian >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>> On 14 Jul 2015, at 17:18, Hui Deng >>>>>>> > >>>>>>> > >>>>>>> >> = wrote: >>>>>>>=20 >>>>>>> Hello all, >>>>>>>=20 >>>>>>> We would like to have a 3 weeks WGLC for the below document: >>>>>>> http://datatracker.ietf.org/doc/draft-ietf-mif-mpvd-id/ = >>>>>>>=20 >>>>>>> Please help to send your comments to this thread. >>>>>>> This WGLC will end on Aug. 5th. >>>>>>>=20 >>>>>>> Many thanks >>>>>>>=20 >>>>>>> DENG Hui >>>>>>> _______________________________________________ >>>>>>> mif mailing list >>>>>>> mif@ietf.org >>>>>>> >>> >>>>>>> https://www.ietf.org/mailman/listinfo/mif = >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> _______________________________________________ >>>>>> mif mailing list >>>>>> mif@ietf.org >> >>>>>> https://www.ietf.org/mailman/listinfo/mif = --Apple-Mail=_F671A12C-A84E-4A53-8A0E-B58F36CDC8DF Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
Hi Jouni,

A set top box supplied by an operator = could ship pre-configured to look for the PvD based on the UUID (if this = is the chosen single unique identifier format). This UUID is advertised = in RAs to the STB, so it can select it. It=92s a closed system, so it=92s = achievable.

But = the user may want to access the same content over the same PvD, but this = time with a 3rd party streaming client on their laptop. Now there=92s no = pre-configured PvD to look for, so it would be useful to present = something descriptive and human readable to the user to give them a = chance of being able to select the right PvD for their app (e.g. you add = the meta-data, associated with the same UUID as above, say the FQDN = format =92streamingtv.bigtelco.com=92). The FQDN format is = standard, so the app without any knowledge of the operator=92s network = can interpret this and offer it to the user as a choice. Once the app is = configured, it=92s looking for the associated UUID as the unique = identifier for the streaming PvD (i.e., if the laptop was moved to = another subnet in the house that was running PvDs over RAs without the = FQDN meta-data option, it would still be able to identify the right one = to use).

Maybe = you also want to attach an additional meta-data message in the DHCPv6 = provisioning containing a URL for a page telling the user how to = configure their client correctly. The URL is also associated with the = PvD-ID (alongside the FQDN meta-data). Again, the URL would need to be a = standard format.

And so on...

So, the extensible format allows for the mechanism to be = augmented in the future (within the limits of what is implementable in a = client / provisioning protocol). Several of these in different formats = may be used and associated with a single PvD. Clients can ignore = meta-data that they don=92t understand, or a not configured to parse. = Standard formats mean that devices/applications can interpret offered = meta-data without having to be pre-configured (somehow) to run within a = specific operators PvD architecture. 

Cheers,
Ian


On = 22 Jul 2015, at 11:28, Jouni Korhonen <jouni.nospam@gmail.com> wrote:

Now I do not really understand the desire for = standardized format for metadata. You basically move to burden of = multiple, some more descriptive IDs, to fully flexible/standardized = metadata. Does not seem to improve the situation.

- Jouni

7/21/2015, 4:17 AM, Ian Farrer = kirjoitti:
The meta-data formats would be standardised formats as = well so that they
can potentially be universally = understood.

i.e. the id-formats that are = enumerated in section 3 of the pad-id
document (with the = exception of the format which is chosen as the single
unique= Identifier) would form the initial set of PVD-ID meta data.

However, on thinking about this, maybe = defining an additional type for
'PVD-ID owner binary blob=92= could be an idea if people see a need for it.

Cheers,
Ian


On 21 Jul 2015, at = 12:44, Jouni Korhonen <jouni.nospam@gmail.com
<mailto:jouni.nospam@gmail.com>> wrote:

Thanks Ian,

And = the metadata is just a binary blob only understood by the PVD-ID
"owner"?

- Jouni
7/21/2015, 2:02 AM, Ian Farrer kirjoitti:
Hi Jouni,

The specific things that I think need to be = addressed here are:

1, Removing the = decision making process for an operator looking to
choose = the right format to use. This needs to be common across the whole
of an operator=92s network and so needs to be supported by = all devices and
advertising/provisioning protocols present = and future. Once deployed at
any scale, changing this will = be non-trivial.

2, At this stage in the = development of the PvD architecture, it is very
difficult = to know how this will need to evolve and be extended in the
future, so it is almost impossible to make an informed = decision about
what the best PvD format to choose is.

So, this is why I think that choosing a single = format with a high
probability of uniqueness and a small, = defined size. But this needs to
be combined with = extensibility for adding meta-data to take advantage of
the = capabilities of less constrained devices and advertising protocols
so that additional information can be supplied to allow = clients /
applications / users to make an informed = decision about the PvD.

How I would see = this working is that the PvD-ID itself would be a single
format - e.g. UUID. This must be advertised in all = provisioning
messages. An additional DHCPv6/PIO option = would then be defined that
allows an operator to add = additional meta-data options which are
associated with the = PVD-ID according to their needs / the capabilities
of the = device/protocols etc (i.e. the other PvD-ID formats that have
been described in the draft).

This= allows for the mechanism to be extended as needed without the need
to change the PvD-ID formats that are in use in existing = devices. If you
want to extend your PvD architecture so = that new devices have new logic
for selecting the correct = PvD based on new logic, then you can add a new
PvD-ID = meta-data option linked to an existing PvD-ID without needing to
change the underlying PvD architecture or devices that you = have deployed.

With the current mechanism = as described, to make any changes to your PvD
architecture = to support new client PvD selection logic requires
deploying= another PvD format in parallel to the existing one. This is,
by the PvD architecture a new PvD, even if the service = properties are
identical to an existing PvD which you have = already deployed. Then, your
provisioning protocols need = to advertise duplicate configuration for
both of the PvDs, = even thought that configuration is the same, with the
exception of the PvD-ID.

So, the = short answer to your question is: Single PvD-ID format (I like
UUID) + extensible associated meta-data.

Cheers,
Ian


On 20 Jul 2015, at = 20:08, Jouni Korhonen <jouni.nospam@gmail.com
<mailto:jouni.nospam@gmail.com>
<mailto:jouni.nospam@gmail.com>> wrote:

Ian,

So would = UUID be adequate PVD-ID format as suggested below?

What about the additonal information part? Not needed?

- Jouni


7/20/2015, 7:33 AM, Ian Farrer kirjoitti:
Hi,

Before this document can proceed, I think that there is still = a
significant open point. Multiple or single PVD ID = formats?

This question has been raised a = few times at WG meetings, but there is
no reflection in = the draft as it stands. This is an excerpt from the
IETF91 = minutes:

Margaret: 2 changes proposed: move = to single unique short ID (UUID)
and allow for additional = info to be a part of the ID. So can we
try to reach = consensus on each?

Who thinks we should = move to one unique format?
(a couple of hands; 2nd time = asking had about 10 hands)
Who thinks we should not use a = single unique format?
(no hands)
OK. Single = unique.

So, I would like to see this = discussion take place before the document
progresses.

Thanks,
Ian



On 14 Jul 2015, at 17:18, Hui Deng <denghui02@hotmail.com
<mailto:denghui02@hotmail.com>
<mailto:denghui02@hotmail.com>
<mailto:denghui02@hotmail.com>> wrote:

Hello all,

We = would like to have a 3 weeks WGLC for the below document:
http://datatracker.ietf.org/doc/draft-ietf-mif-mpvd-id/

Please help to send your comments to this = thread.
This WGLC will end on Aug. 5th.

Many thanks

DENG Hui
_______________________________________________
mif mailing list
mif@ietf.org
<mailto:mif@ietf.org><mailto:mif@ietf.org><mailto:mif@ietf.org>
https://www.ietf.org/mailman/listinfo/mif



_______________________________________________
mif mailing list
mif@ietf.org <mailto:mif@ietf.org><mailto:mif@ietf.org>
https://www.ietf.org/mailman/listinfo/mif
= --Apple-Mail=_F671A12C-A84E-4A53-8A0E-B58F36CDC8DF-- From nobody Wed Jul 22 09:41:30 2015 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEE0C1B2A88 for ; Wed, 22 Jul 2015 09:41:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.02 X-Spam-Level: X-Spam-Status: No, score=-0.02 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lS0WKOY8S2iF for ; Wed, 22 Jul 2015 09:41:28 -0700 (PDT) Received: from smtpcmd02111.aruba.it (smtpcmd02111.aruba.it [62.149.158.111]) by ietfa.amsl.com (Postfix) with ESMTP id 1D6BE1B2A8F for ; Wed, 22 Jul 2015 09:40:23 -0700 (PDT) Received: from dell-tcastaldi ([31.130.224.109]) by smtpcmd02.ad.aruba.it with bizsmtp id vUgN1q01h2NEPrz01UgPXc; Wed, 22 Jul 2015 18:40:23 +0200 Date: Wed, 22 Jul 2015 18:40:24 +0200 (CEST) From: Meetecho Team To: mif@ietf.org Message-ID: <520615538.19.1437583224523.JavaMail.tcastaldi@dell-tcastaldi> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_18_825317873.1437583224522" Archived-At: Subject: [mif] Meetecho recordings of MIF WG session X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2015 16:41:30 -0000 ------=_Part_18_825317873.1437583224522 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Dear all, the full recording (synchronized video, audio, slides and jabber room) of the MIF WG session at IETF 93 is available at the following URL: http://ietf93.conf.meetecho.com/index.php/Recorded_Sessions#MIF In case of problems with the playout, just drop an e-mail to ietf-support@meetecho.com. For the chair(s): please feel free to put the link to the recording in the minutes, if you think this might be useful. Cheers, the Meetecho Team ------=_Part_18_825317873.1437583224522-- From nobody Wed Jul 22 14:09:13 2015 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 308441B2E8E for ; Wed, 22 Jul 2015 14:09:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.95 X-Spam-Level: X-Spam-Status: No, score=-0.95 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, J_CHICKENPOX_62=0.6] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cxedv48MUKfm for ; Wed, 22 Jul 2015 14:09:10 -0700 (PDT) Received: from mail.core-networks.de (mx1.core-networks.de [IPv6:2001:1bc0:d::4:8]) (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 076291B2E8C for ; Wed, 22 Jul 2015 14:09:10 -0700 (PDT) Received: from localhost ([127.0.0.1]) by mail.core-networks.de id 1ZI1GE-0005Ms-92 with ESMTPSA (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) for ; Wed, 22 Jul 2015 23:09:06 +0200 To: Suresh Krishnan , "mif@ietf.org" References: <55AEA40C.4090909@openwrt.org> From: Steven Barth Message-ID: <55B0066B.3080909@openwrt.org> Date: Wed, 22 Jul 2015 23:08:59 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [mif] Comments on draft-ietf-mif-mpvd-dhcp-support-01 X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2015 21:09:12 -0000 > >> 3 SHOULD contain exactly one still allows more than one PVD_AUTH vs. >> "MUST be the last option inside PVD" in 5 > > It does not allow more than one. The options are 1 or 0 depending on > whether the option was requested in the ORO. If it occurs, it needs to > be the last option inside the PVD. No, it does not say that, there are 3 locations where it says something about it. One is in 3 which says "SHOULD contain exactly one" and in 5 it says "SHOULD contain at most one" and then again in the next sentence it says "PVD_AUTH option MUST be the last option". So you actually managed to contradict yourself 2 times about the same thing. >> 6 specifies that ANY options may be encapsulated. This is awkward, e.g., what >> would be the meaning of e.g. a Status or a Reconfigure-Accept option within >> that container, more general what happens to options explicitly defined to be >> on some level and / or having a specific meaning there? > I think it is very difficult to find a good answer here. At the other > end of the spectrum we can list the options that are allowed. This has a > different set of isues. As I see it, there are three possible options > > a) Allow all legal DHCPv6 options to be inside the PVD. Expect > reasonable use of options by admins. > > b) List all the allowed options in the document. > > c) Maintain an extensible (e.g. IANA) registry of the options allowed > inside the PVD container > > Each of these comes with a different set of pros and cons. We can pick a > direction based on what the wg thinks. There are certainly more options, you could also blacklist options or describe characteristics of TLVs you want / don't want to be encaps'ed (e.g. ones that authenticate the DHCPv6 packet). dhc might want to provide guidance here? > >> 8 mentions the use of timestamps to avoid replay attacks, though DHCPv6 is usually >> used to bootstrap network connectivity and thus at this point devices (especially >> embedded ones) may not have an accurate wallclock yet. This is especially interesting >> since DHCPv6 itself may carry NTP server addresses to use. > Right. This is a real issue that is not specific to mif. The same > problem occurs when we need to do DNSSEC validation for the NTP servers > provided (as DNSSEC validation requires clock sync). As far as I know NTP does not depend on DNS at all, you can use it just over IP and RFC 4075 specifies exactly that for DHCPv6. > Let me clarify something before we go further. The OPTION_PVD_AUTH will > be sent only if it is in the ORO.If the CPE does not request this, it > will not get a signed PVD option. It is free to split up the contained > options however it wishes. For the homenet use case, I think it would be > best not to request the OPTION_PVD_AUTH as it is likely that there is no > need to ensure the integrity of the container I couldn't find that mentioned in the draft. In any case there is also another big issue here: A client usually makes one IA_NA request and expects to get all addresses (from all PVDs?) in that single IA. So you have a severe scoping issue: You only have one PVD container per PVD-ID, so you need to duplicate the IA_NA (header) across multiple containers. This is bad because now you have IA_NAs with duplicate IDs, duplicate T1 and T2 values and the client must "reassemble" them from different PVD containers. > Yes. This is a tough cookie. In the NDP based solution we had a much > easier way to do this. We created the option so that legacy clients will > just skip over the PVD "container" and look at the options they understand. It doesn't save you the duplication though, it just makes it explicit that in the RA case you always have to provide legacy in addition. > A good way to solve this would be for the DHCPv6 server to send the > configuration info outside the container for further distribution to > legacy clients along with the info inside the container for the PVD > aware clients. Unfortunately, there is no way to request the server to > do this with the current ORO mechanism It might not cover 100% of cases but the presence of an IA_PD request might be an indicator here that you are dealing with a router which has clients behind it. > > Would some guidance of this form be useful? > > "Clients that request the OPTION_PVD with the intention of > redistributing configuration information to other clients (e.g. CPE > routers) SHOULD NOT request the OPTION_PVD_AUTH in the ORO. This allows > them to send out a subset of the received options to their clients and > also allows them to support PVD unaware clients by sending out the > options without PVD information." I don't see how the PVD_AUTH plays into the legacy clients, since you are not encrypting a router can always take out options from the PVDs and put them into top-level, however there should be guidance as to when and how that results in useful output, i.e. if I just take out a random PVDs RDNSS which might only resolve a certain set of zones and a legacy client tries to use it for internet connectivity bad things happen. Cheers, Steven From nobody Wed Jul 22 21:54:04 2015 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 061171A1A9F for ; Wed, 22 Jul 2015 21:54:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WDf8NhWY371b for ; Wed, 22 Jul 2015 21:54:01 -0700 (PDT) Received: from mail-wi0-x22e.google.com (mail-wi0-x22e.google.com [IPv6:2a00:1450:400c:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2EE401A00E1 for ; Wed, 22 Jul 2015 21:54:01 -0700 (PDT) Received: by wibud3 with SMTP id ud3so6935035wib.1 for ; Wed, 22 Jul 2015 21:54:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-type:content-transfer-encoding; bh=H6gM/RT5xCAUgI2OE6yaWXExMl5sZqS2b+KOAirET1A=; b=zXiipKKDvNcbfWJ7uEYf2vapSyKiiMjafC+uhCWsdCzUe5FwToAyYm5+FIND+Erpsr IFmD2nPEQ7W6UWbzm+Ck1DIGgS3T0zk8hZ60RpWiBGCLQnDAFOQiM5lvmJJIlOD349Xi Z90P4205mbRiaM1+TlWFA5orYU1IXmzb6M6VegV8nuLJCO+VIvNlcQ5w680oFHTgmK74 mMPfhYcvs+9wsiLsgDOKuQDzsOD4VGXWy39lNvI2Dklw/6N3aLxHhy5w3wIcguxtlyFn LP5V86WW2FUcxf92c5+LdVt8z1szdho4Ojn1/jqEdEnvz5Sfz1CtsPSqwPobAOx2pnjD 2hog== X-Received: by 10.180.79.10 with SMTP id f10mr48055045wix.1.1437627240013; Wed, 22 Jul 2015 21:54:00 -0700 (PDT) Received: from ?IPv6:2001:67c:370:136:85e5:7d83:1632:2e30? ([2001:67c:370:136:85e5:7d83:1632:2e30]) by smtp.googlemail.com with ESMTPSA id iy4sm6533429wic.24.2015.07.22.21.53.58 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 22 Jul 2015 21:53:59 -0700 (PDT) To: Steven Barth , mif@ietf.org References: <55AF4226.8010803@openwrt.org> From: Jouni Korhonen Message-ID: <55B07365.8080201@gmail.com> Date: Wed, 22 Jul 2015 21:53:57 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: <55AF4226.8010803@openwrt.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [mif] Comments on draft-ietf-mif-mpvd-id-01 X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jul 2015 04:54:03 -0000 Steven, Thanks for the review. See my initial comments inline. 7/22/2015, 12:11 AM, Steven Barth kirjoitti: > Hello everyone, > > below a few comments for the MPVD ID draft. > > > 3 I'm unsure about the id-length field. It seems entirely redundant for e.g. > DHCP(v6) purposes and even considering e.g. RAs it is redundant for half of > the given id-types. Should this be type-specfic instead? We need the length information for NDP case where the option carrying the ID has the length expressed in the units of 8. I do not like the idea of having different encodings based on the type. The "optimization" would be not be big enough to justivy that imho. > 3 I'm unsure if cross references to the draft that in turn references this > one are wise, also wrt. informative / normative reference sections. Referencing will explain the context better. Informative reference ensures that the document won't be blocked if the two referenced documents are not ready yet.. > > > 3 id-type > Encoding and / or allowed lengths are entirely unclear for most types you declare. > Are they supposed to be strings, BE integers, ...? How big are they supposed to be? > Shall I be able to use 16, 32 or maybe even 24bit numbers for representing the OID? Will check the OID case. Most of the identifier formats have their "natural" encoding explained in their respective RFCs but having exact text here regarding coding would be good to avoid confussion. Thanks for pointing it. > > 0x04: RFC 4282 specifies the assignment of NAI Realms to be tied to domain names, > so this type seems mostly redundant since you alreay have FQDN. NAIs are different to FQDNs. Tieing NAIs to DNS administration is an "easy" way to guarantee they come from a managed nameespace. This is typical for example with AAA protocols. > > 0x06: This looks overly specific to me. Why not have a generic (unicast) prefix type, > so people could also use their RIPE / ARIN / ... assigned UC addresses? E.g. prefix > length followed by arbitrary length ipv6 prefix. Good point. Will consider that. > > 4 What if I want to use this outside a configuration protocol? You just do it. The PVD-ID is not explicitly tied to MPVD configuration protocols (two of those at the moment). > > 4 Undefined reference to "PVD container option" What do you mean? > > In general 4 seems awkward / misplaced here, since you are defining an abstract identifier. 4 meaning option type 0x04? - Jouni > > > > Cheers, > > Steven > > > > > > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif > From nobody Thu Jul 23 00:43:40 2015 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 513831A8892 for ; Thu, 23 Jul 2015 00:43:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.55 X-Spam-Level: X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GOKRCSjXOo4k for ; Thu, 23 Jul 2015 00:43:36 -0700 (PDT) Received: from mail.core-networks.de (mx1.core-networks.de [IPv6:2001:1bc0:d::4:8]) (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 7EAE21A8903 for ; Thu, 23 Jul 2015 00:43:36 -0700 (PDT) Received: from localhost ([127.0.0.1]) by mail.core-networks.de id 1ZIBAE-00046d-9Q with ESMTPSA (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) for ; Thu, 23 Jul 2015 09:43:34 +0200 To: Jouni Korhonen , mif@ietf.org References: <55AF4226.8010803@openwrt.org> <55B07365.8080201@gmail.com> From: Steven Barth Message-ID: <55B09B1F.1030108@openwrt.org> Date: Thu, 23 Jul 2015 09:43:27 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: <55B07365.8080201@gmail.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [mif] Comments on draft-ietf-mif-mpvd-id-01 X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jul 2015 07:43:38 -0000 > We need the length information for NDP case where the option carrying the ID has the length expressed in the units of 8. I do not like the idea of having different encodings based on the type. The "optimization" would be not be big enough to justivy that imho. Yes, understood, makes sense. > >> 3 I'm unsure if cross references to the draft that in turn references this >> one are wise, also wrt. informative / normative reference sections. > > Referencing will explain the context better. Informative reference ensures that the document won't be blocked if the two referenced documents are not ready yet.. Okay, not that important I suppose, personal feelings is just that circular references are bit uncomfortable, but feel free to ignore. > >> >> >> 3 id-type >> Encoding and / or allowed lengths are entirely unclear for most types you declare. >> Are they supposed to be strings, BE integers, ...? How big are they supposed to be? >> Shall I be able to use 16, 32 or maybe even 24bit numbers for representing the OID? > > Will check the OID case. Most of the identifier formats have their "natural" encoding explained in their respective RFCs but having exact text here regarding coding would be good to avoid confussion. Thanks for pointing it. Yeah, e.g. for UUID it wasn't clear to me if it refers to binary or string notation. FQDN basically the same and it didn't even reference any RFCs. I suppose RFC 1035 without "compression" was your intention here? > > >> >> 0x04: RFC 4282 specifies the assignment of NAI Realms to be tied to domain names, >> so this type seems mostly redundant since you alreay have FQDN. > > NAIs are different to FQDNs. Tieing NAIs to DNS administration is an "easy" way to guarantee they come from a managed nameespace. This is typical for example with AAA protocols. I was mostly basing this comment on the IANA Considerations Section in RFC 4282, but if there is legitimate reason I guess its fine. > >> 4 What if I want to use this outside a configuration protocol? > > You just do it. The PVD-ID is not explicitly tied to MPVD configuration protocols (two of those at the moment). > >> >> 4 Undefined reference to "PVD container option" > > What do you mean? > >> >> In general 4 seems awkward / misplaced here, since you are defining an abstract identifier. > > 4 meaning option type 0x04? The 3 comments above were all intended to refer to Security Considerations (= Section 4). Maybe to elaborate a bit more: You are only talking about Security Considerations in connection with configuration protocols, therefore my first question. You also mention the "container option" the first and only time in that section and it seems to be not really obvious what you are referring to. All in all (comment 3) I think since this is just an abstract ID format that should be used in many different usecases, maybe just mentioning that instead of a security considerations which applies to some example usecases like NDP and DHCPv6. Cheers, Steven From nobody Thu Jul 23 01:55:16 2015 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DEE71AC417 for ; Thu, 23 Jul 2015 01:55:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.15 X-Spam-Level: X-Spam-Status: No, score=-1.15 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, J_CHICKENPOX_62=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0P6AMbg5Jj6N for ; Thu, 23 Jul 2015 01:55:13 -0700 (PDT) Received: from mail-lb0-x230.google.com (mail-lb0-x230.google.com [IPv6:2a00:1450:4010:c04::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E1B1E1AC408 for ; Thu, 23 Jul 2015 01:54:36 -0700 (PDT) Received: by lbbzr7 with SMTP id zr7so153057595lbb.1 for ; Thu, 23 Jul 2015 01:54:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=RB8LwtiMYQ3vVbTtwx+xVL4DMn4/P4NMsLG/h73IEGw=; b=0jC03w533VODPCOskSZyaWVfVGPRJbT/8qGZ/4E9UCKrFVaRTpcTcvJQCrz8SSnBTF GRVkKewKRohOJxtxw/GQZWA2JinYdh6b4NaoqOcuEsXTPRlsxoM0tqYjHm17Oe4UQ6gK qZjmaSyxB/cWTCG74+Wc3IHr9Lbxg/nAskkqzR00mNim8EX+o2SVpvZ8FCD4mkXKwQDb 80XQ0Guhi8pYzroO1Se+P570eBfoyxh2jqR63vM5OC1wD/OlbGxaVIj+VMJw/A4x9cNW X2Qst/OOYj0bYYuquoAaM/nQlwKMeUOg1lHdKOMwYFpEb4a9l/znfzfQy+V4jWlW2LJK eFjQ== MIME-Version: 1.0 X-Received: by 10.112.126.42 with SMTP id mv10mr6741826lbb.58.1437641675350; Thu, 23 Jul 2015 01:54:35 -0700 (PDT) Received: by 10.114.12.68 with HTTP; Thu, 23 Jul 2015 01:54:35 -0700 (PDT) In-Reply-To: <55B0066B.3080909@openwrt.org> References: <55AEA40C.4090909@openwrt.org> <55B0066B.3080909@openwrt.org> Date: Thu, 23 Jul 2015 03:54:35 -0500 Message-ID: From: Behcet Sarikaya To: Steven Barth Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "mif@ietf.org" Subject: Re: [mif] Comments on draft-ietf-mif-mpvd-dhcp-support-01 X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: sarikaya@ieee.org List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jul 2015 08:55:15 -0000 I did not see any comments on -ndp-support draft. Maybe it should have been named ra-support. Behcet On Wed, Jul 22, 2015 at 4:08 PM, Steven Barth wrote: > > >> >>> 3 SHOULD contain exactly one still allows more than one PVD_AUTH vs. >>> "MUST be the last option inside PVD" in 5 >> >> It does not allow more than one. The options are 1 or 0 depending on >> whether the option was requested in the ORO. If it occurs, it needs to >> be the last option inside the PVD. > No, it does not say that, there are 3 locations where it says something > about it. One is in 3 which says "SHOULD contain exactly one" and in 5 > it says "SHOULD contain at most one" and then again in the next sentence > it says "PVD_AUTH option MUST be the last option". So you actually > managed to contradict yourself 2 times about the same thing. > >>> 6 specifies that ANY options may be encapsulated. This is awkward, e.g., what >>> would be the meaning of e.g. a Status or a Reconfigure-Accept option within >>> that container, more general what happens to options explicitly defined to be >>> on some level and / or having a specific meaning there? >> I think it is very difficult to find a good answer here. At the other >> end of the spectrum we can list the options that are allowed. This has a >> different set of isues. As I see it, there are three possible options >> >> a) Allow all legal DHCPv6 options to be inside the PVD. Expect >> reasonable use of options by admins. >> >> b) List all the allowed options in the document. >> >> c) Maintain an extensible (e.g. IANA) registry of the options allowed >> inside the PVD container >> >> Each of these comes with a different set of pros and cons. We can pick a >> direction based on what the wg thinks. > There are certainly more options, you could also blacklist options > or describe characteristics of TLVs you want / don't want to be > encaps'ed (e.g. ones that authenticate the DHCPv6 packet). > dhc might want to provide guidance here? > >> >>> 8 mentions the use of timestamps to avoid replay attacks, though DHCPv6 is usually >>> used to bootstrap network connectivity and thus at this point devices (especially >>> embedded ones) may not have an accurate wallclock yet. This is especially interesting >>> since DHCPv6 itself may carry NTP server addresses to use. >> Right. This is a real issue that is not specific to mif. The same >> problem occurs when we need to do DNSSEC validation for the NTP servers >> provided (as DNSSEC validation requires clock sync). > As far as I know NTP does not depend on DNS at all, you can use it just over IP > and RFC 4075 specifies exactly that for DHCPv6. > > >> Let me clarify something before we go further. The OPTION_PVD_AUTH will >> be sent only if it is in the ORO.If the CPE does not request this, it >> will not get a signed PVD option. It is free to split up the contained >> options however it wishes. For the homenet use case, I think it would be >> best not to request the OPTION_PVD_AUTH as it is likely that there is no >> need to ensure the integrity of the container > I couldn't find that mentioned in the draft. > > > In any case there is also another big issue here: > A client usually makes one IA_NA request and expects to get > all addresses (from all PVDs?) in that single IA. So you have a severe > scoping issue: You only have one PVD container per PVD-ID, so you need > to duplicate the IA_NA (header) across multiple containers. This is > bad because now you have IA_NAs with duplicate IDs, duplicate > T1 and T2 values and the client must "reassemble" them from different > PVD containers. > > >> Yes. This is a tough cookie. In the NDP based solution we had a much >> easier way to do this. We created the option so that legacy clients will >> just skip over the PVD "container" and look at the options they understand. > It doesn't save you the duplication though, it just makes it explicit > that in the RA case you always have to provide legacy in addition. > > >> A good way to solve this would be for the DHCPv6 server to send the >> configuration info outside the container for further distribution to >> legacy clients along with the info inside the container for the PVD >> aware clients. Unfortunately, there is no way to request the server to >> do this with the current ORO mechanism > It might not cover 100% of cases but the presence of an IA_PD > request might be an indicator here that you are dealing with > a router which has clients behind it. > > >> >> Would some guidance of this form be useful? >> >> "Clients that request the OPTION_PVD with the intention of >> redistributing configuration information to other clients (e.g. CPE >> routers) SHOULD NOT request the OPTION_PVD_AUTH in the ORO. This allows >> them to send out a subset of the received options to their clients and >> also allows them to support PVD unaware clients by sending out the >> options without PVD information." > I don't see how the PVD_AUTH plays into the legacy clients, since > you are not encrypting a router can always take out options from > the PVDs and put them into top-level, however there should be > guidance as to when and how that results in useful output, i.e. > if I just take out a random PVDs RDNSS which might only resolve > a certain set of zones and a legacy client tries to use it for internet > connectivity bad things happen. > > > > Cheers, > > Steven > > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif From nobody Thu Jul 23 04:08:04 2015 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD4011A89FF for ; Thu, 23 Jul 2015 04:08:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WWL8ElHJvDre for ; Thu, 23 Jul 2015 04:07:59 -0700 (PDT) Received: from mail-wi0-x230.google.com (mail-wi0-x230.google.com [IPv6:2a00:1450:400c:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 611AE1A89B1 for ; Thu, 23 Jul 2015 04:07:59 -0700 (PDT) Received: by wicmv11 with SMTP id mv11so18858751wic.0 for ; Thu, 23 Jul 2015 04:07:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-type:content-transfer-encoding; bh=+DVbSyb80tkVCf8ECTKU5QGg5yp0Wm7m25+8cjL53O4=; b=g/APW+8/EO0vZiva8f7kbGmab7LXEHPScOvl2DF5TuNkDR8V3ZT603I456Utxc9bMT UDOGgE81OedyKarRK4PP9s+HBSTFQnqC8qlvNpvnJIkULxyT3JJZ7uCQbhN27o9TEz/+ B1Gsk57y/gKhv7VV9WCpoGAHpasve6VpV2ENm8+hfPTkagssqcnEylBL5UFttMbY93Ea LyAmdlVrU2RwCTujNAIQw4+mpnYxpZE/Uu9ufUFyAkHhGpvQB/x4IfX7+2W2QWn3XgT4 eo5YkjeXixkWdpq6vAU78FELjdLPWZy7J7KkfgjtLLi7aLYKTDziI1T72pcrnnFGtIZC mOPg== X-Received: by 10.194.83.70 with SMTP id o6mr14555593wjy.44.1437649678144; Thu, 23 Jul 2015 04:07:58 -0700 (PDT) Received: from ?IPv6:2001:67c:370:136:688d:6fe9:d384:b1f6? ([2001:67c:370:136:688d:6fe9:d384:b1f6]) by smtp.googlemail.com with ESMTPSA id gw7sm26624596wib.15.2015.07.23.04.07.56 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 23 Jul 2015 04:07:57 -0700 (PDT) To: Steven Barth , "mif@ietf.org" References: <55AF52F1.2040802@openwrt.org> From: Jouni Korhonen Message-ID: <55B0CB0C.1010301@gmail.com> Date: Thu, 23 Jul 2015 04:07:56 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: <55AF52F1.2040802@openwrt.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [mif] Comments on draft-ietf-mif-mpvd-ndp-support X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jul 2015 11:08:03 -0000 Hi Steve, Thanks for the review. See my intial comments inline: 7/22/2015, 1:23 AM, Steven Barth kirjoitti: > Hello everyone, > > some probably non-conclusive comments on the NDP-support draft. > > 3 "However, including a PVD container or identity > options inside a Router Solicitation (RS) NDP messages is also > possible (actually, in this way a host can solicit for information > from a specific provisioning domain)." > > This is awkward. Foremost, hosts only send RSs when they change links > and also replies to RS may be multicasted to all hosts on the links > (and often in practice still are). And what is the issue in that case if all others on the same link see what you are asking for? > In any case I don't see the point of adding the container to the RS and / or > maybe the Identity. This is just plain ambiguous. Could you open more the "plain ambiguous" part? Ambiguous how to implement or how/when to use? If you have a better wording in mind I am happy to see it & incorporate it. > 3 "The PVD container MUST NOT be fragmented i.e., should the > IPv6 packet be fragmented, the PVD container and the accompanying PVD > identity MUST both be inside the same fragment." > > The i.e. makes it ambiguous. Now MUST the whole container NOT be fragmented or > MUST every fragment have a PVD Identity or only the first one? Again, what is ambiguous here? The container must not be fragmented. If the ipv6 packet itself is fragmented the container has to be as a whole in one of those fragment. If you have a better wording in mind I am happy to see it & incorporate it. > > > 3 S-bit: Could this not just be encoded as "Name Type" = 0? It could. The reason why that is not the case now is that we use RFC6487 name type registry here are currently value 0 is reserved and therefore overloading its meaning in this I-D could be a bit risky. > 3 "Name Type": I find it peculiar that the name type is selectable but not > the signature algorithm (at least to my understanding). Algorithms that are directly mapped to name types are listed in RFC6487. > > 3 "Key Hash": Since this doesn't have a length field a client not understanding > the name type cannot interpret anything in the container even if it does not > want to check the signature. I'm not sure if this is intended. Ok. This is a good point. I'll look into this. My earlier assumption was that if security is in place and the host does not understand the name type -> skip the entire container. But I think we may need to address the case where the end host just does not care i.e. "approve exception" that is very typical when surfing web and ignoring expired certificates.. > 3 "This MAY imply adding > padding zero octets to the tail of the PVD container option until the > alignment requirement has been met" > > A MAY padding seems awkward and actually ambiguous. (This also applies to > 4 to a lesser degree) Care to explain more what is ambiguous? You may end up doing padding but not in all cases. If you have a better wording in mind I am happy to see it & incorporate it. > 4 Is it useful that PVD ID is a separate TLV if a container MUST have exactly 1 in it > and the stand-alone use (e.g. in RS) is probably questionable? Until the RS piece is resolved a separate option is imho justified. > 6 Again as for dhcpv6, timestamps may not be ready for checking at the point > where RAs are evaluated since these are essentially bootstrap protocol and > not all devices do have RTCs or unauthenticated NTP server options may be used > to tamper with wallclock settings. I assume you are now in Section 6? It says "..some replay protection mechanism such as a.. This specification does not define a replay protection solution.." I understand the point that timestamp may not answer the replay protection issue but this I-D is not also relying on it either. I am happy to remove the "..such as.." part if that is contentious. > > 9 RFC 3971 is in informative references but since you use it as source for > your signature algorithm should it not be normative? Hmm.. good point. However, we do not want to mandate entire RFC3971 but only parts of it. I wonder how to express that in the normative/informative references. - Jouni > > > > > Cheers, > > Steven > > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif > From nobody Thu Jul 23 04:31:39 2015 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20A001AC419 for ; Thu, 23 Jul 2015 04:31:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wb50Kos7SCQY for ; Thu, 23 Jul 2015 04:31:35 -0700 (PDT) Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450:400c:c05::22d]) (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 3A8FD1A8A3C for ; Thu, 23 Jul 2015 04:31:34 -0700 (PDT) Received: by wibud3 with SMTP id ud3so19743993wib.1 for ; Thu, 23 Jul 2015 04:31:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-type:content-transfer-encoding; bh=rp9MGqUq58wTGl8qx8xQpfBWyf9Yr0/gH+2XJekVnIU=; b=cFpPzAJhZssoDnTxOD2tx4CRrTDQRFiGAnev+sjCveQSKwqh7szteaETXAvchcYuL5 AzaZ2u1fJJf0e99NTwV3YNC1+RYFLZHciRp1w1Yat4bTHWTbcxvXIJSRB2AhRhZ3MpFm dqCmnn5Pymp7Ra3SVpKeIwwLn9DmkT1rpTiqvtoddxYy/ZnJTIRcpWMD5f/tnI2/EqBw 89E+L1O+WKZh4HBVlPFZ2wJeOTXVedAh+b3kNZ1be0rbcN5Uq9hmTsVtDYbpC4EL81kn CeD5R6RCA58HuKRs6igQQmBePIeOlrEHV/d/66pTeowLJoGWRBaPqcLh7sviQKfV8p/C wozA== X-Received: by 10.194.120.230 with SMTP id lf6mr16436423wjb.41.1437651092976; Thu, 23 Jul 2015 04:31:32 -0700 (PDT) Received: from [31.133.161.174] (dhcp-a1ae.meeting.ietf.org. [31.133.161.174]) by smtp.googlemail.com with ESMTPSA id ck18sm940336wjb.47.2015.07.23.04.31.31 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 23 Jul 2015 04:31:32 -0700 (PDT) To: Steven Barth , mif@ietf.org References: <55AF4226.8010803@openwrt.org> <55B07365.8080201@gmail.com> <55B09B1F.1030108@openwrt.org> From: Jouni Korhonen Message-ID: <55B0D093.1010809@gmail.com> Date: Thu, 23 Jul 2015 04:31:31 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: <55B09B1F.1030108@openwrt.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [mif] Comments on draft-ietf-mif-mpvd-id-01 X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jul 2015 11:31:37 -0000 Hi Steven, 7/23/2015, 12:43 AM, Steven Barth kirjoitti: > >> We need the length information for NDP case where the option carrying the ID has the length expressed in the units of 8. I do not like the idea of having different encodings based on the type. The "optimization" would be not be big enough to justivy that imho. > Yes, understood, makes sense. > >> >>> 3 I'm unsure if cross references to the draft that in turn references this >>> one are wise, also wrt. informative / normative reference sections. >> >> Referencing will explain the context better. Informative reference ensures that the document won't be blocked if the two referenced documents are not ready yet.. > Okay, not that important I suppose, personal feelings is just that circular references are bit uncomfortable, but feel free to ignore. Point taken. Thanks. >>> 3 id-type >>> Encoding and / or allowed lengths are entirely unclear for most types you declare. >>> Are they supposed to be strings, BE integers, ...? How big are they supposed to be? >>> Shall I be able to use 16, 32 or maybe even 24bit numbers for representing the OID? >> >> Will check the OID case. Most of the identifier formats have their "natural" encoding explained in their respective RFCs but having exact text here regarding coding would be good to avoid confussion. Thanks for pointing it. > Yeah, e.g. for UUID it wasn't clear to me if it refers to binary or string notation. FQDN basically the same and it didn't even reference any RFCs. I suppose RFC 1035 without "compression" was your intention here? I'll take a stab on this and will clarify. Should be "easy" if we end up to a single ID to be supported ;) >>> 0x04: RFC 4282 specifies the assignment of NAI Realms to be tied to domain names, >>> so this type seems mostly redundant since you alreay have FQDN. >> >> NAIs are different to FQDNs. Tieing NAIs to DNS administration is an "easy" way to guarantee they come from a managed nameespace. This is typical for example with AAA protocols. > I was mostly basing this comment on the IANA Considerations Section in RFC 4282, but if there is legitimate reason I guess its fine. Ok. NAIs and FQDNs are likely to be removed if we end up using only a single ID type. >>> 4 What if I want to use this outside a configuration protocol? >> >> You just do it. The PVD-ID is not explicitly tied to MPVD configuration protocols (two of those at the moment). >> >>> 4 Undefined reference to "PVD container option" >> >> What do you mean? >> >>> In general 4 seems awkward / misplaced here, since you are defining an abstract identifier. >> >> 4 meaning option type 0x04? > > > The 3 comments above were all intended to refer to Security Considerations (= Section 4). > Maybe to elaborate a bit more: You are only talking about Security Considerations in connection > with configuration protocols, therefore my first question. You also mention the "container option" > the first and only time in that section and it seems to be not really obvious what you are referring > to. All in all (comment 3) I think since this is just an abstract ID format that should be used in many > different usecases, maybe just mentioning that instead of a security considerations which applies > to some example usecases like NDP and DHCPv6. Okay. Thanks. Will take a look into this. - Jouni > > > > Cheers, > > Steven > > > From nobody Thu Jul 23 04:40:39 2015 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A386E1A854B for ; Thu, 23 Jul 2015 04:40:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.549 X-Spam-Level: X-Spam-Status: No, score=-1.549 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id is_TVsX8GFjX for ; Thu, 23 Jul 2015 04:40:35 -0700 (PDT) Received: from mail.core-networks.de (mx1.core-networks.de [IPv6:2001:1bc0:d::4:8]) (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 243661A89B3 for ; Thu, 23 Jul 2015 04:40:27 -0700 (PDT) Received: from localhost ([127.0.0.1]) by mail.core-networks.de id 1ZIErQ-0004r1-V1 with ESMTPSA (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) for ; Thu, 23 Jul 2015 13:40:25 +0200 To: Jouni Korhonen References: <55AF52F1.2040802@openwrt.org> <55B0CB0C.1010301@gmail.com> From: Steven Barth Message-ID: <55B0D2A8.4060807@openwrt.org> Date: Thu, 23 Jul 2015 13:40:24 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: <55B0CB0C.1010301@gmail.com> Content-Type: multipart/alternative; boundary="------------060904020402040609070502" Archived-At: Cc: "mif@ietf.org" Subject: Re: [mif] Comments on draft-ietf-mif-mpvd-ndp-support X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jul 2015 11:40:37 -0000 This is a multi-part message in MIME format. --------------060904020402040609070502 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit >> This is awkward. Foremost, hosts only send RSs when they change links >> and also replies to RS may be multicasted to all hosts on the links >> (and often in practice still are). > > And what is the issue in that case if all others on the same link see what you are asking for? No, what I find awkward is that a multicasted RA may be triggered by that special RS. So one client's RS now changes RAs for everyone else on the link. Also clients usually do not send RS regularly and rely on multicast RAs. Yes RA servers may behave differently but you should make clear how they should and that shouldn't clash with v6ops / 6man etc. > >> In any case I don't see the point of adding the container to the RS and / or >> maybe the Identity. This is just plain ambiguous. > > Could you open more the "plain ambiguous" part? Ambiguous how to implement or how/when to use? If you have a better wording in mind I am happy to see it & incorporate it. What is ambiguous is "However, including a PVD container or identity options inside a Router Solicitation (RS) NDP messages is also possible ". What's the point for making both possible or more specifically what's the point of having the container in the RS at all? Or another way: how would I request exactly: PVD identity inside container or just top-level identity? > >> 3 "The PVD container MUST NOT be fragmented i.e., should the >> IPv6 packet be fragmented, the PVD container and the accompanying PVD >> identity MUST both be inside the same fragment." >> >> The i.e. makes it ambiguous. Now MUST the whole container NOT be fragmented or >> MUST every fragment have a PVD Identity or only the first one? > > Again, what is ambiguous here? The container must not be fragmented. If the ipv6 packet itself is fragmented the container has to be as a whole in one of those fragment. If you have a better wording in mind I am happy to see it & incorporate it. You are saying "MUST NOT be fragmented" this is clear, but then you explain that statement to mean ("i.e.") that only identity must be in the same fragment as the container. The explanation itself is a bit strange as well since the identity is inside the container. > >> 3 "This MAY imply adding >> padding zero octets to the tail of the PVD container option until the >> alignment requirement has been met" >> >> A MAY padding seems awkward and actually ambiguous. (This also applies to >> 4 to a lesser degree) > > Care to explain more what is ambiguous? You may end up doing padding but not in all cases. If you have a better wording in mind I am happy to see it & incorporate it. You are using a normative MAY, to me that means if I feel like it I may pad here but if I won't nothing would break. > >> 9 RFC 3971 is in informative references but since you use it as source for >> your signature algorithm should it not be normative? > > Hmm.. good point. However, we do not want to mandate entire RFC3971 but only parts of it. Sure, but I must understand at least parts of that RFC to know the signatures work. Cheers, Steven --------------060904020402040609070502 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit

This is awkward. Foremost, hosts only send RSs when they change links
and also replies to RS may be multicasted to all hosts on the links
(and often in practice still are).

And what is the issue in that case if all others on the same link see what you are asking for?
No, what I find awkward is that a multicasted RA may be triggered by that special RS. So one client's
RS now changes RAs for everyone else on the link. Also clients usually do not send RS regularly and rely on multicast RAs. Yes RA servers may behave differently but you should make clear how they should and that shouldn't clash with v6ops / 6man etc.


In any case I don't see the point of adding the container to the RS and / or
maybe the Identity. This is just plain ambiguous.

Could you open more the "plain ambiguous" part? Ambiguous how to implement or how/when to use? If you have a better wording in mind I am happy to see it & incorporate it.
What is ambiguous is "However, including a PVD container or identity options inside a Router Solicitation (RS) NDP messages is also possible ". What's the point for making both possible or
more specifically what's the point of having the container in the RS at all?

Or another way: how would I request exactly: PVD identity inside container or just top-level identity?



3 "The PVD container MUST NOT be fragmented i.e., should the
    IPv6 packet be fragmented, the PVD container and the accompanying PVD
    identity MUST both be inside the same fragment."

The i.e. makes it ambiguous. Now MUST the whole container NOT be fragmented or
MUST every fragment have a PVD Identity or only the first one?

Again, what is ambiguous here? The container must not be fragmented. If the ipv6 packet itself is fragmented the container has to be as a whole in one of those fragment. If you have a better wording in mind I am happy to see it & incorporate it.
You are saying "MUST NOT be fragmented" this is clear, but then you explain that statement to mean ("i.e.") that only identity must be in the same fragment as the container. The explanation itself is a bit strange as well since the identity is inside the container.


3 "This MAY imply adding
    padding zero octets to the tail of the PVD container option until the
    alignment requirement has been met"

A MAY padding seems awkward and actually ambiguous. (This also applies to
4 to a lesser degree)

Care to explain more what is ambiguous? You may end up doing padding but not in all cases. If you have a better wording in mind I am happy to see it & incorporate it.
You are using a normative MAY, to me that means if I feel like it I may pad here but if I won't nothing would break.


9 RFC 3971 is in informative references but since you use it as source for
your signature algorithm should it not be normative?

Hmm.. good point. However, we do not want to mandate entire RFC3971 but only parts of it.

Sure, but I must understand at least parts of that RFC to know the signatures work.



Cheers,

Steven
--------------060904020402040609070502-- From nobody Thu Jul 23 06:45:43 2015 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AFBA1ACD16 for ; Thu, 23 Jul 2015 06:45:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zqvQdOevRDsw for ; Thu, 23 Jul 2015 06:45:40 -0700 (PDT) Received: from mail-wi0-x230.google.com (mail-wi0-x230.google.com [IPv6:2a00:1450:400c:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 948971A87E7 for ; Thu, 23 Jul 2015 06:44:36 -0700 (PDT) Received: by wibxm9 with SMTP id xm9so209215430wib.0 for ; Thu, 23 Jul 2015 06:44:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=KEgy5x9N0FbSkQkuOG95wsg9GIYXh7RFPqfZfCUw1jg=; b=CA3MsIx9uaiUuKmlwmt6WUwtbBwS4NTuEQuRmfwq7VZxsBnB8b/zVR3RbSI5nIeTci C+SeIlojklghxlbwnodbL4yoQeu2yEQFzbJ1XKVdqxDQVJwuLW7RwN3gOG+65ViY5ILp u+5hKGkmpxcGrK1uFQ9LsXYjoI4yfZkMt8h86NsdZG0pXqKVuHqlaWiZwfozJVyNgV2C blvScrhZbOrALaGw22FdYjLo/65ruHxY/bIUg7fiJEgzU+rZJZZ4hIjp4K1eihoAAP2A JWChpmMePyM9yTaWs820rS608k0uOYvzwlf+p9ldIyoDM+u+ap5CluyLNTYYaIN7mRvs YIwg== X-Received: by 10.194.158.42 with SMTP id wr10mr15485252wjb.81.1437659075381; Thu, 23 Jul 2015 06:44:35 -0700 (PDT) Received: from ?IPv6:2001:67c:370:136:a85e:b497:e6ca:88a0? ([2001:67c:370:136:a85e:b497:e6ca:88a0]) by smtp.googlemail.com with ESMTPSA id bu12sm884403wjb.44.2015.07.23.06.44.33 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 23 Jul 2015 06:44:34 -0700 (PDT) To: Steven Barth References: <55AF52F1.2040802@openwrt.org> <55B0CB0C.1010301@gmail.com> <55B0D2A8.4060807@openwrt.org> From: Jouni Korhonen Message-ID: <55B0EFC1.4080502@gmail.com> Date: Thu, 23 Jul 2015 06:44:33 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: <55B0D2A8.4060807@openwrt.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "mif@ietf.org" Subject: Re: [mif] Comments on draft-ietf-mif-mpvd-ndp-support X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jul 2015 13:45:42 -0000 Hi Steve, 7/23/2015, 4:40 AM, Steven Barth kirjoitti: > > >>> This is awkward. Foremost, hosts only send RSs when they change links >>> and also replies to RS may be multicasted to all hosts on the links >>> (and often in practice still are). >> >> And what is the issue in that case if all others on the same link see >> what you are asking for? > No, what I find awkward is that a multicasted RA may be triggered by > that special RS. So one client's > RS now changes RAs for everyone else on the link. Also clients usually > do not send RS regularly and rely on multicast RAs. Yes RA servers may I do not think we are changing anything or assuming new behavior regarding _when_ to send RS. The end host just can add PVD information to an RS it would send anyway based on the rules in RFC4861. I do agree that is it unnecessary for others in a broadcast link to see PVD information that was hinted by a specific end host. However, there are existing tools to around that. But anyway, I can add more clarification on the assumptions we have on the use here. > behave differently but you should make clear how they should and that > shouldn't clash with v6ops / 6man etc. I do not see what is clashing with V6OPS/6MAN. Please clarify. >>> In any case I don't see the point of adding the container to the RS >>> and / or >>> maybe the Identity. This is just plain ambiguous. >> >> Could you open more the "plain ambiguous" part? Ambiguous how to >> implement or how/when to use? If you have a better wording in mind I >> am happy to see it & incorporate it. > What is ambiguous is "However, including a PVD container or identity > options inside a Router Solicitation (RS) NDP messages is also possible > ". What's the point for making both possible or > more specifically what's the point of having the container in the RS at all? Since the PVD-ID option is like any ND option out there it can be in an RS with or without the container. If the end host wants to e.g. sign the PVD-ID, then it would use the container. > Or another way: how would I request exactly: PVD identity inside > container or just top-level identity? With container Section 3 should be clear enough with that. Without container, just add the PDV-ID into the RS like any other ND option. >>> 3 "The PVD container MUST NOT be fragmented i.e., should the >>> IPv6 packet be fragmented, the PVD container and the accompanying >>> PVD >>> identity MUST both be inside the same fragment." >>> >>> The i.e. makes it ambiguous. Now MUST the whole container NOT be >>> fragmented or >>> MUST every fragment have a PVD Identity or only the first one? >> >> Again, what is ambiguous here? The container must not be fragmented. >> If the ipv6 packet itself is fragmented the container has to be as a >> whole in one of those fragment. If you have a better wording in mind I >> am happy to see it & incorporate it. > You are saying "MUST NOT be fragmented" this is clear, but then you > explain that statement to mean ("i.e.") that only identity must be in > the same fragment as the container. The explanation itself is a bit > strange as well since the identity is inside the container. The text currently says "the PVD container and the accompanying PVD identity MUST both be inside the same fragment." I find this quite clear what it means. If you have a better way to describe this I am happy to see a text proposal and incorporate it. >>> 3 "This MAY imply adding >>> padding zero octets to the tail of the PVD container option until >>> the >>> alignment requirement has been met" >>> >>> A MAY padding seems awkward and actually ambiguous. (This also >>> applies to >>> 4 to a lesser degree) >> >> Care to explain more what is ambiguous? You may end up doing padding >> but not in all cases. If you have a better wording in mind I am happy >> to see it & incorporate it. > You are using a normative MAY, to me that means if I feel like it I may > pad here but if I won't nothing would break. While there is no such thing as "normative MAY" I agree using RFC2119 language might not be appropriate here. You do not need to add padding if the alignment is met it, which sometimes can be the case. Anyway, I would reword the sentence as: "This may require adding padding zero octets to the end of the PVD container option to meet the alignment requirement." >>> 9 RFC 3971 is in informative references but since you use it as >>> source for >>> your signature algorithm should it not be normative? >> >> Hmm.. good point. However, we do not want to mandate entire RFC3971 >> but only parts of it. > > Sure, but I must understand at least parts of that RFC to know the > signatures work. Maybe moving the reference to normative part and clarifying in the text that only specific sections of that reference are to be used? - JOuni > > > > Cheers, > > Steven From nobody Thu Jul 23 07:22:44 2015 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65B881ACE78 for ; Thu, 23 Jul 2015 07:22:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.95 X-Spam-Level: X-Spam-Status: No, score=-0.95 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, J_CHICKENPOX_62=0.6] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xZ1WFg_bKygq for ; Thu, 23 Jul 2015 07:22:42 -0700 (PDT) Received: from mail.core-networks.de (mx1.core-networks.de [IPv6:2001:1bc0:d::4:8]) (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 261F21ACE60 for ; Thu, 23 Jul 2015 07:22:36 -0700 (PDT) Received: from localhost ([127.0.0.1]) by mail.core-networks.de id 1ZIHON-0002VN-Ea with ESMTPSA (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) for ; Thu, 23 Jul 2015 16:22:35 +0200 To: Jouni Korhonen References: <55AF52F1.2040802@openwrt.org> <55B0CB0C.1010301@gmail.com> <55B0D2A8.4060807@openwrt.org> <55B0EFC1.4080502@gmail.com> From: Steven Barth Message-ID: <55B0F8A9.4060203@openwrt.org> Date: Thu, 23 Jul 2015 16:22:33 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: <55B0EFC1.4080502@gmail.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Cc: "mif@ietf.org" Subject: Re: [mif] Comments on draft-ietf-mif-mpvd-ndp-support X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jul 2015 14:22:43 -0000 > > Since the PVD-ID option is like any ND option out there it can be in an RS with or without the container. If the end host wants to e.g. sign the PVD-ID, then it would use the container. The latter is to my understanding not really mentioned yet. Personally I would not have imagined that this was intended. In any case I do not see the point in allowing both behaviors (with and without container). Aside my doubts in general about your use of RSs, I think you should decide that whether you want these signed requests then require that the PVD-ID must always be inside a container otherwise only allow them to be on top-level. Allowing both doesn't really give you anything aside unnecessarily bloating implementations. > > The text currently says "the PVD container and the accompanying PVD identity MUST both be inside the same fragment." > > I find this quite clear what it means. If you have a better way to describe this I am happy to see a text proposal and incorporate it. Both parts of the sentence make sense to me but not in the "i.e."-combination. The MUST NOT be fragmented parts sounds to me as if the whole container must not be fragmented but in the "i.e." you only talk about ID but not other encaps'ed options which is what confused me. Also what do you mean by fragmentation in the first place? IPv6-level fragmentation? If yes, (again aside ND and fragmentation issues in general) there should be an explanation for the MUST here since at least to me its not obvious. Cheers, Steven From nobody Thu Jul 23 08:08:02 2015 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B7391A0056 for ; Thu, 23 Jul 2015 08:08:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 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, J_CHICKENPOX_62=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id crT9e-f65AhA for ; Thu, 23 Jul 2015 08:08:00 -0700 (PDT) Received: from mail-wi0-x235.google.com (mail-wi0-x235.google.com [IPv6:2a00:1450:400c:c05::235]) (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 8DD281A00FE for ; Thu, 23 Jul 2015 08:07:59 -0700 (PDT) Received: by wibxm9 with SMTP id xm9so154007580wib.1 for ; Thu, 23 Jul 2015 08:07:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=vWmjKd2dvzoVZ2lxoGTzCy1h/ByvtDCuvtkheybW2Ow=; b=Smo2nKqrn5SL5j5uSUnw5/MbElR4bd2o1lns3bYTpN6Xs1b0ELJRBLMtBG54EVEVBV e5yvk7VMDPiWhx3b5nj+mysD6M2/XFyl+mluLdHIaQfGjwGnpXGHvcQVJQyO64KcqZxy TJ91zJUCdPSXCQIEC5N3jmGhzCh4svKCSOrsYkcsom07W/ly+tp/sp31mJh45PdRDUQ4 TB31uuad61V//VLC2Dtb26KNcRT5iMDykFwE5RL7U+JrjfofKCZRCS2cv53ZCMsoY3JV bB9wcTskGmgw9WyqOmZ2OIftAp/EsSWUq4G3G8qKQwiMWt0YE9Tri+37q7SKp3oYfurs X0qQ== X-Received: by 10.194.78.110 with SMTP id a14mr17937021wjx.87.1437664078244; Thu, 23 Jul 2015 08:07:58 -0700 (PDT) Received: from ?IPv6:2001:67c:370:136:a85e:b497:e6ca:88a0? ([2001:67c:370:136:a85e:b497:e6ca:88a0]) by smtp.googlemail.com with ESMTPSA id uo6sm7991080wjc.1.2015.07.23.08.07.57 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 23 Jul 2015 08:07:57 -0700 (PDT) To: Steven Barth References: <55AF52F1.2040802@openwrt.org> <55B0CB0C.1010301@gmail.com> <55B0D2A8.4060807@openwrt.org> <55B0EFC1.4080502@gmail.com> <55B0F8A9.4060203@openwrt.org> From: Jouni Korhonen Message-ID: <55B1034C.3010809@gmail.com> Date: Thu, 23 Jul 2015 08:07:56 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: <55B0F8A9.4060203@openwrt.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "mif@ietf.org" Subject: Re: [mif] Comments on draft-ietf-mif-mpvd-ndp-support X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jul 2015 15:08:01 -0000 Steven, 7/23/2015, 7:22 AM, Steven Barth kirjoitti: > >> >> Since the PVD-ID option is like any ND option out there it can be in an RS with or without the container. If the end host wants to e.g. sign the PVD-ID, then it would use the container. > > The latter is to my understanding not really mentioned yet. Personally I would not have imagined that this was intended. In any case I do not see the point in allowing both behaviors (with and without container). Aside my doubts in general about your use of RSs, I think you should decide that whether you want these signed requests then require that the PVD-ID must always be inside a container otherwise only allow them to be on top-level. Allowing both doesn't really give you anything aside unnecessarily bloating implementations. Fair enough.. I'll put some more clarifications there for reasons to use or not to use container. >> The text currently says "the PVD container and the accompanying PVD identity MUST both be inside the same fragment." >> >> I find this quite clear what it means. If you have a better way to describe this I am happy to see a text proposal and incorporate it. > Both parts of the sentence make sense to me but not in the "i.e."-combination. > The MUST NOT be fragmented parts sounds to me as if the whole container must not be fragmented but in the "i.e." you only talk about ID but not other encaps'ed options which is what confused me. > > Also what do you mean by fragmentation in the first place? IPv6-level fragmentation? If yes, (again aside ND and fragmentation issues in general) there should be an explanation for the MUST here since at least to me its not obvious. The text says "should the IPv6 packet be fragmented,.." which imho is rather clear it means IPv6 level fragmentation. Now that the intent should be clear could you propose text that makes sense to you? Just to avoid having the same discussion again when the next version is out ;) - Jouni > > > > Cheers, > > Steven > From nobody Thu Jul 23 22:00:10 2015 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77F3E1B2DD0 for ; Thu, 23 Jul 2015 22:00:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.55 X-Spam-Level: X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zHToN4N9hmHc for ; Thu, 23 Jul 2015 22:00:07 -0700 (PDT) Received: from mail.core-networks.de (mx1.core-networks.de [IPv6:2001:1bc0:d::4:8]) (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 DDD921A00B0 for ; Thu, 23 Jul 2015 22:00:06 -0700 (PDT) Received: from localhost ([127.0.0.1]) by mail.core-networks.de id 1ZIV5X-0000v2-S0 with ESMTPSA (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) for ; Fri, 24 Jul 2015 07:00:03 +0200 To: Jouni Korhonen References: <55AF52F1.2040802@openwrt.org> <55B0CB0C.1010301@gmail.com> <55B0D2A8.4060807@openwrt.org> <55B0EFC1.4080502@gmail.com> <55B0F8A9.4060203@openwrt.org> <55B1034C.3010809@gmail.com> From: Steven Barth Message-ID: <55B1C653.60507@openwrt.org> Date: Fri, 24 Jul 2015 07:00:03 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: <55B1034C.3010809@gmail.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Cc: "mif@ietf.org" Subject: Re: [mif] Comments on draft-ietf-mif-mpvd-ndp-support X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jul 2015 05:00:08 -0000 > > The text says "should the IPv6 packet be fragmented,.." which imho is rather clear it means IPv6 level fragmentation. It is indeed, I feel rather that the intention for your MUST is not obvious. To me I would either expect all fragmented ND packets to be dropped (esp. multicast), only some to be dropped but the packet to be discarded as a whole because of that, or the whole packet to be correctly reassembled. In all these cases I don't get the intention of your requirement. Beside that I think this requirement is a layer violation here and would require a very good justification (aside trying to work-around some broken host implementations) since it significantly increases the implementation complexity of the RA server (at least in case your RAs are getting big). From nobody Fri Jul 24 05:30:22 2015 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79E301A00A0 for ; Fri, 24 Jul 2015 05:30:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ro7YDc-0q6qK for ; Fri, 24 Jul 2015 05:30:18 -0700 (PDT) Received: from mail-wi0-x233.google.com (mail-wi0-x233.google.com [IPv6:2a00:1450:400c:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 801E71A00BD for ; Fri, 24 Jul 2015 05:30:17 -0700 (PDT) Received: by wibxm9 with SMTP id xm9so26836009wib.0 for ; Fri, 24 Jul 2015 05:30:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=BMhEVLOCIoXMlzAHkqG4UZHPUGp6ihOFJNHIL2s4WSE=; b=FDGfMR5tHVVTOCnxBTD4+b6RGJUVPZ6Mt95OPYivqBLAaMO/gpfBradsO6v3jx21m9 G/JWIxPsLifA/Ek7GDLte9CFkswTJMS/d74BU/Gnca8kHhlOJ1D/Msv3XBqMo1xjTTn2 1iBaG39fyw7CTJZkjOCuK9dJ0ZAUj9ETV2A6IFdYeSjbKKSC2RDlOil3DRUI1xUIGJGb 5MuAu9fCgcAJyHjQW9n01lwmF3QvDPKd67J+kdPOao3pes2P4qHOAKwWBl1/dQB2PSM8 53oDIN7MW4kfbdJMlgMh0n7DZLdk/dZwgFn949Yy7XIaZnMLVtxQ6qgW0+79y1pW+bYZ rprw== X-Received: by 10.180.21.175 with SMTP id w15mr7063292wie.58.1437741016210; Fri, 24 Jul 2015 05:30:16 -0700 (PDT) Received: from ?IPv6:2001:67c:370:136:cd92:da6:7e97:886f? ([2001:67c:370:136:cd92:da6:7e97:886f]) by smtp.googlemail.com with ESMTPSA id di7sm3299098wib.23.2015.07.24.05.30.14 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 24 Jul 2015 05:30:14 -0700 (PDT) To: Steven Barth References: <55AF52F1.2040802@openwrt.org> <55B0CB0C.1010301@gmail.com> <55B0D2A8.4060807@openwrt.org> <55B0EFC1.4080502@gmail.com> <55B0F8A9.4060203@openwrt.org> <55B1034C.3010809@gmail.com> <55B1C653.60507@openwrt.org> From: Jouni Korhonen Message-ID: <55B22FD5.3070303@gmail.com> Date: Fri, 24 Jul 2015 05:30:13 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: <55B1C653.60507@openwrt.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "mif@ietf.org" Subject: Re: [mif] Comments on draft-ietf-mif-mpvd-ndp-support X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jul 2015 12:30:20 -0000 Steven, 7/23/2015, 10:00 PM, Steven Barth kirjoitti: > >> >> The text says "should the IPv6 packet be fragmented,.." which imho is rather clear it means IPv6 level fragmentation. > > It is indeed, I feel rather that the intention for your MUST is not obvious. You mean having all options that belong to one PDV being inside one fragment? > To me I would either expect all fragmented ND packets to be dropped (esp. multicast), only some to be dropped but the packet to be discarded as a whole because of that, or the whole packet to be correctly reassembled. I do not understand what your "expactation" and the above sentence has to do with the text in the draft. Actually, I do not understand what the above sentence tries to say. > In all these cases I don't get the intention of your requirement. Trying to keep the container as a whole if someone for some reason wants to peek into it before reassembly.. but it is not a sticking point for the draft. SHOULD would be ok, even removing the whole fragmentation text could be ok. > Beside that I think this requirement is a layer violation here and would require a very good justification (aside trying to work-around some broken host implementations) since it significantly increases the implementation complexity of the RA server (at least in case your RAs are getting big). I don't understand the claim for layer violation.. the implementation complexity annoynace I understand. - Jouni > From nobody Sat Jul 25 05:46:51 2015 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA98D1AC3E0 for ; Sat, 25 Jul 2015 05:46:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FREEMAIL_FROM=0.001, GB_I_LETTER=-2, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ugA9XY8Q-_x5 for ; Sat, 25 Jul 2015 05:46:47 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 53D611A9147 for ; Sat, 25 Jul 2015 05:46:47 -0700 (PDT) Received: from ians-mbp.fritz.box ([89.0.144.132]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0MV30j-1ZQWpk0DgT-00YQLe for ; Sat, 25 Jul 2015 14:46:45 +0200 From: Ian Farrer Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: <66E246E2-0217-4410-BE8D-64A8F55B8E29@gmx.com> Date: Sat, 25 Jul 2015 14:46:46 +0200 To: mif@ietf.org Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) X-Mailer: Apple Mail (2.2102) X-Provags-ID: V03:K0:P9pVlUes4gT6lpJOWlIZQRgsk+RoxAptdkRhBHvTG9Qy52L2Yh7 mrnHf7d4CnniSntfNuedDy+g5CFK1C63e4PORwmodqkf32tPAe9iL2aeJMcbTWsN9Jm6aQu bl5lOeYwp3YDppdrDNLdNKAk3+UvzrR4ZME11+fPa3nHfCYrOwzcYNbarN0kZwdwpL6Ny2V xc2ZufMouTO7Np257z1ow== X-UI-Out-Filterresults: notjunk:1;V01:K0:u9hifiRd4Yw=:s8rzwsD5N8e/WR4Irytezs XcmyAaGbtSNS9OzufLbhS5XwRmSznxbaVgQplFBPQsMs5RDxjdBkyji/pL3cmjPSPkecC2/rZ VtH8uv0hrAFmmyeBRF6+a+/kRr+Gx011jUgNlz3ts15Dy+nMVYL8G8WPFytV9mZGCIK3ym4d0 IkU/tgGOV6Vig8vzKEJyBEv7s8QxoWmNTWJeVV4oU8ViMr5Dj6Q38ayRnVjZpOqfyTBllEwQJ giGqMFgxS6dr6AIQbu8hG7Cg9ipB0nANn9Fpqmay6ixfwMcvZKpZWaSX+J4DGuDFlT23ljoj6 VP+PR6SZtDbQCD7yhK46lQ+fBIqPcz7iJTJLIj74EEEp2zktYOjTy2pWeewBjdtjwX798Czab qJaaHeL1KDqppc4XJSDBLzOqeB4Aiu2z6toMsTQYHof/tIo8BZtVaVmP9+K8/3DHsTHqjjDzH WeOl0F2uhP8+MBPTDbzT0nH9Z7OxtmZAqqBNpyYWpqoK2dQZWozYf5HLqK8HiE7JI9pqvZi+j 9z1bw+O5J+F4s7cQOTsbix1lCHce8y+ds8q4U9IqwjxlmMewK1qnKTZxbkKYpIkRYPUbkZ42U 9HOHhnzDVP1maN3fQ9JAjvq7j36cQ+UHSgMh06Z99o+fzZGLpM/Dvbw5+St5R0Fyj5fBeRQTp hrWeoQO64NWN6HD/78Vbd/l++C80khBP9LF5GM7YTDmystDxiBGByBp1lWVkpmgUjm+I= Archived-At: Subject: [mif] Review of draft-ietf-mif-mpvd-ndp-support-01 X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Jul 2015 12:46:50 -0000 Hi, Here=E2=80=99s my review of the draft. Cheers, Ian Please note - I=E2=80=99m going to be on holiday for the next couple of = weeks so if I am slow in responding to any replies, then this is why. ----------- These comments are in addition to the one that I have raised in the mail = thread = https://mailarchive.ietf.org/arch/msg/mif/3LQ6W1kj7nwOIvI_KGfbKoyOkCs Depending on the outcome of this discussion, other changes to this = document may be necessary. Section 3 a) Which NDP messages can include this option? RA and RS messages are = mentioned, but is it envisaged that e.g. a host may make an NS request which contains the PVD_ID = option, in order to=20 find other hosts which are configured for the same PVD? My feeling is = that in this document and at this stage of the development, they should be restricted to RS = with requested PvDs and RAs with advertised PvD NDP messages only. b) I=E2=80=99m not clear on what the intended solicitation process for a = host requesting information for a specific PvD.=20 The behaviour seems to be that in an RA, a client includes a list of the = PVD_ID options which it is interested in receiving. But, para 2 of section 3 says that the RA can also include the PVD_CO. = What is this for? Do the requested=20 PVD_IDs need to be in a container, or are they listed directly in the RS = options (or are both allowed)? c) Para 2 The PVD container MUST NOT be fragmented" RFC6980 prevents NDP messages from being fragmented at all, so perhaps = this should be=20 referenced? Would it also help to describe how to correctly handle this situation = (i.e. send two RAs with un-fragmented PvD containers) Section 5 "The PVD container option MAY be used to encapsulate any allocated IPv6 = NDP options, which may appear more than once in a NDP message." Ambiguous text - Is the intention to say that the PVD container, or the = encapsulated options may appear more than once in the NDP message? If it is the encapsulated options, then the sentence restricts the = allowable options to only those options which can appear more than once (i.e. an option which can only appear once can not be encapsulated). I = guess that this is not the intention. Section 6 Per PVD certificates/sigs sound like they are going to cause problems = with the NDP message length. In the appendix of RFC6980, there=E2=80=99s some information about = message sizes when carrying=20 certificates. 864 bytes is given as the smallest size for the = certificate itself (1024 bytes), so for a 1280 v6 MTU,=20 2 and you=E2=80=99re bust. Language / grammar nits etc. Throughout: s/a NDP/an NDP Reason: With acronyms, =E2=80=98a=E2=80=99 or =E2=80=98an=E2=80=99 = before a consonant/vowel is chosen based on the sound of the letter when = spoken (i.e. =E2=80=99n=E2=80=99 is pronounced =E2=80=98en=E2=80=99) Section 1 Old This document describes an IPv6 Neighbor Discovery Protocol (NDP) = [RFC4861] mechanism for explicitly indicating provisioning domain information along with any configuration that will = be provided. New This document describes an IPv6 Neighbor Discovery Protocol (NDP) = [RFC4861] mechanism for explicitly indicating provisioning domain information along with any configuration which is = associated with that provisioning domain. Reason: new wording more clearly associates the configuration with the = PVD it is being provisioned for. Section 3 Old: Implementations that do not recognize the PVD container option plain = ignore it and also skip PVD container option "encapsulated" NDP options normally without associating them into = any provisioning domain (since the implementation has no notion of provisioning domains). New: Implementations that do not recognize the PVD container option will = ignore it, and any PVD container option "encapsulated" NDP options without associating them into any = provisioning domain (since the implementation has no notion of provisioning domains). Reason: Old version reads a little =E2=80=98colloquially=E2=80=99 :-) Old: certificates needed to sign PVD containers) belong New: =20 certificates needed to sign PVD containers belong Reason: ) with no corresponding ( Old: the length of the PVD identifier option and the optional Key = Hash/Digital Signature/Padding. New: the length of the PVD identifier option, and the optional Key = Hash/Digital Signature/Padding. Reason: Oxford comma. Might as well put it in now and save the editor = the job. Section 4 Old: =E2=80=A6 the natural NDP options=E2=80=99 alignment. New: ... the natural NDP option=E2=80=99s alignment. Reason: Option is singular and doesn=E2=80=99t end with an =E2=80=99s' Section 5 Old: If the receiver of the PVD identity option does not understand any of = the ID-Types, then anything belonging to this provisioning domain MUST be silently = discarded. =20 This would mean the PVD identity option, the PVD container option and = all other options. =20 New:=20 If the receiver of a PVD identity option does not have one (or more) of = the received ID-Type format=E2=80=99s implemented, then all configuration and options = which are associated with the unimplemented PvD(s) MUST be silently discarded. Reason: Original wording could be mis-interpreted to mean that the = entire NDP message, including options associated with implemented ID-types must be discarded Section 7 Old: The options TBD1 and TBD2 are described in Section 3 and Section 4 New: Options TBD1 and TBD2 are described in Section 3 and Section 4 = respectively. Reason: Clarity From nobody Mon Jul 27 06:00:07 2015 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B95FD1B2CF4 for ; Mon, 27 Jul 2015 06:00:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AX0J1aZvrlWT for ; Mon, 27 Jul 2015 06:00:05 -0700 (PDT) Received: from mail-lb0-x236.google.com (mail-lb0-x236.google.com [IPv6:2a00:1450:4010:c04::236]) (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 582B31B2CE9 for ; Mon, 27 Jul 2015 06:00:05 -0700 (PDT) Received: by lbbzr7 with SMTP id zr7so52832987lbb.1 for ; Mon, 27 Jul 2015 06:00:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-type:content-transfer-encoding; bh=gyaDq3VFMZm9zT8YcqaJ6+Sna5SQ1P8+s3lWT+CQ5Z0=; b=rtW19NQcs1af2I1nkBcAWEiF+j4o6jKxPNCdxTAdKCmayihmFQHWQvl4CRwoWf1FIx bJz68otzsnYmD1F5LfhBly5co/4A3xFlW3q+JPjzE4habSWvXXYGour+mx+2h1HVEP5T KJOM83ZpeJ1ibbcxWt9RCM6VcPMmxIoD4HnPZt1ptwA8Bntv33qwzBqGujVY4z/X6Etv YUmkSFqFl6EE8pR9L5lCfkshMqQZ0ApDQ72Vz+NGyckGYkrpME2ZQLF12ayH33R7mlSl jjEFUfGmsDo/RtahL+nN0zJ3KGYoZhjgu8s9oBQVaiAAg2EtZzQvx5Hf7kfbp730VQIU azAQ== X-Received: by 10.152.246.37 with SMTP id xt5mr26769002lac.83.1438002003698; Mon, 27 Jul 2015 06:00:03 -0700 (PDT) Received: from [192.168.100.24] (91-158-124-187.elisa-laajakaista.fi. [91.158.124.187]) by smtp.googlemail.com with ESMTPSA id w7sm3882094lag.42.2015.07.27.05.59.58 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 27 Jul 2015 06:00:03 -0700 (PDT) To: Ian Farrer , mif@ietf.org References: <66E246E2-0217-4410-BE8D-64A8F55B8E29@gmx.com> From: Jouni Korhonen Message-ID: <55B62B4B.9020103@gmail.com> Date: Mon, 27 Jul 2015 05:59:55 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: <66E246E2-0217-4410-BE8D-64A8F55B8E29@gmx.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [mif] Review of draft-ietf-mif-mpvd-ndp-support-01 X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jul 2015 13:00:06 -0000 > c) Para 2 > The PVD container MUST NOT be fragmented" > RFC6980 prevents NDP messages from being fragmented at all, so perhaps this should be > referenced? > Would it also help to describe how to correctly handle this situation (i.e. send two RAs with > un-fragmented PvD containers) Ah great.. I was looking for this one last week but just could not remember which RFC it was. Will align with this RFC. - Jouni From nobody Tue Jul 28 13:54:03 2015 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C60E51B30AE; Tue, 28 Jul 2015 13:54:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.15 X-Spam-Level: X-Spam-Status: No, score=-0.15 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HELO_EQ_DE=0.35] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vfjohhxJ5GM7; Tue, 28 Jul 2015 13:54:00 -0700 (PDT) Received: from mail.core-networks.de (mx1.core-networks.de [IPv6:2001:1bc0:d::4:8]) (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 214161B3066; Tue, 28 Jul 2015 13:54:00 -0700 (PDT) Received: from localhost ([127.0.0.1]) by mail.core-networks.de id 1ZKBsr-0006if-Tg with ESMTPSA (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) for ; Tue, 28 Jul 2015 22:53:58 +0200 From: Steven Barth To: "mif@ietf.org" Message-ID: <55B7EBE3.7030002@openwrt.org> Date: Tue, 28 Jul 2015 22:53:55 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "homenet@ietf.org Group" Subject: [mif] On mif and classifying prefixes X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2015 20:54:01 -0000 (x-post mif / homenet) Hello everyone, little backstory: when I learned about the multiple interfaces problematic in homenet, I was introduced to it with the anecdote of smartphone apps with "use over 3g", "use only on wifi" settings and at some point there was draft-bhandari-dhc-class-based-prefix-05 which sort of tried to define some generic properties (e.g. "not for internet usage", "usage is charged", ...) for prefixes as well as a (more or less?) opaque "class" identifier. Now that draft is expired for >1.5 years and mif seems to occupy that niche. So to my understanding (and what I got as feedback on the mic a few days ago), mif is (atm?) (exclusively?) about explicitly identified provisioning domains, and not about generic classification of prefixes and / or interfaces. That means: to actually use a provisioning domain I need to know the PVD-ID beforehand. There is no way for anyone not knowing the PVD-ID to guess what is inside, not even to the degree of "this is (not) for internet connectivity". Ideally from what I would have expected is that my applications may actually want to cope with multiple unknown prefixes and select a suitable one based on some generic "metric" (e.g. "high bandwidth" or "low latency" or "low cost" etc.), or maybe even just the basic "this is metered cellular connection" vs "this is unmetered broadband" would seem to me as a good start. So is what I am asking for out of scope for mif? Am I supposed to collect a database with all PVD-IDs to know what's inside? Is there any other way to do this? At least to me this explicitly known PVD-ID case seems important but a rather small aspect of the whole classification of address prefixes matter, especially for what I think homenet is concerned. Cheers, Steven