From nobody Fri May 5 05:28:46 2017 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95B00127076 for ; Fri, 5 May 2017 05:28:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.122 X-Spam-Level: X-Spam-Status: No, score=-13.122 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 2g0mp68px2wB for ; Fri, 5 May 2017 05:28:44 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D4484126DEE for ; Fri, 5 May 2017 05:28:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11700; q=dns/txt; s=iport; t=1493987323; x=1495196923; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=g/AhwErPMhfiDSCTMYjTTjpzhp/Zd3WAX/nwNhuBIms=; b=PICzJHkmcEn65ojYa3/Zho4wto2weWnQkwKA9VlIRn5k0l54HLvJE1x1 5sSa2reJfP1J1CI4vaa+Opp0b4EWmooGL0GPC4NOKnl8rv9zYg5BruZ7q kp9d5CXHSvWKPaWGl/54Da+ENM81bUABeFgCfwYzOgbpY5AIUAkYR4YJ5 U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D1AQDhbgxZ/4oNJK1cGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBgm5nYoEMB4NhihiRV5A4hTiCD4YkAhqELT8YAQIBAQEBAQEBax0LhRU?= =?us-ascii?q?BAQEBAyMKXAIBCBEEAQEoAwICAjAUCQgCBBMIihixTYImimUBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEdi1iBPINdglCCXwWdbwGTDYINhTmKK5Q2AR84gQpvFRyHHHa?= =?us-ascii?q?HaIENAQEB?= X-IronPort-AV: E=Sophos;i="5.38,292,1491264000"; d="scan'208,217";a="239771010" Received: from alln-core-5.cisco.com ([173.36.13.138]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 05 May 2017 12:28:42 +0000 Received: from XCH-ALN-004.cisco.com (xch-aln-004.cisco.com [173.36.7.14]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id v45CSgir005146 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Fri, 5 May 2017 12:28:42 GMT Received: from xch-aln-003.cisco.com (173.36.7.13) by XCH-ALN-004.cisco.com (173.36.7.14) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 5 May 2017 07:28:42 -0500 Received: from xch-aln-003.cisco.com ([173.36.7.13]) by XCH-ALN-003.cisco.com ([173.36.7.13]) with mapi id 15.00.1210.000; Fri, 5 May 2017 07:28:42 -0500 From: "Bernie Volz (volz)" To: "dhcwg@ietf.org" Thread-Topic: IETF-99 (Prague) Meeting Agenda Requests - due by May 28th Thread-Index: AQHSt8r0hSZfCLgt7kmWmK77CnIvAKHlxn8Q Date: Fri, 5 May 2017 12:28:41 +0000 Message-ID: <865f9e83c2d4420caf2a0999de12f787@XCH-ALN-003.cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.98.1.195] Content-Type: multipart/alternative; boundary="_000_865f9e83c2d4420caf2a0999de12f787XCHALN003ciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [dhcwg] IETF-99 (Prague) Meeting Agenda Requests - due by May 28th X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 May 2017 12:28:45 -0000 --_000_865f9e83c2d4420caf2a0999de12f787XCHALN003ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGk6DQoNCkp1c3QgYSByZW1pbmRlciB0byBzdWJtaXQgYWdlbmRhIHJlcXVlc3RzLg0KDQoNCi0g ICAgICAgICAgQmVybmllDQoNCkZyb206IGRoY3dnIFttYWlsdG86ZGhjd2ctYm91bmNlc0BpZXRm Lm9yZ10gT24gQmVoYWxmIE9mIEJlcm5pZSBWb2x6ICh2b2x6KQ0KU2VudDogTW9uZGF5LCBBcHJp bCAxNywgMjAxNyA2OjM2IFBNDQpUbzogZGhjd2dAaWV0Zi5vcmcNClN1YmplY3Q6IFtkaGN3Z10g SUVURi05OSAoUHJhZ3VlKSBNZWV0aW5nIEFnZW5kYSBSZXF1ZXN0cyAtIGR1ZSBieSBNYXkgMjh0 aA0KDQpIaToNCg0KSWYgeW91IGhhdmUgYW55IGludGVyZXN0IGluIHByZXNlbnRpbmcgdG8gdGhl IERIQyB3ZyBkdXJpbmcgSUVURi05OSwgcGxlYXNlIHN1Ym1pdCBhIHJlcXVlc3QgYnkgVHVlc2Rh eSwgTWF5IDI3dGguIFRvbWVrICYgSSBtdXN0IHN1Ym1pdCBhIHJlcXVlc3QgZm9yIGEgc2Vzc2lv biBieSBKdW5lIDJuZCBkZWFkbGluZS4NCkFzIGluIHRoZSBwYXN0LCBwbGVhc2UgcHJvdmlkZToN ClRpdGxlIE9mIFNlc3Npb246DQpQcmVzZW50ZXI6DQpSZWxhdGVkIERyYWZ0czoNClRpbWUgUmVx dWlyZWQ6DQpQdXJwb3NlIG9mIFNlc3Npb246DQpXZSBkbyB3YW50IHRvIHJlbWluZCB0aG9zZSBy ZXF1ZXN0aW5nIHRpbWUgdGhhdCB5b3Ugc2hvdWxkIGZvY3VzIG9uIGRpc2N1c3Npbmcga2V5IGlz c3VlcyB0aGF0IG5lZWQgcmVzb2x1dGlvbiB0byBtb3ZlIGEgZHJhZnQgZm9yd2FyZCBvciB0byBp bnRyb2R1Y2UgcG90ZW50aWFsIG5ldyB3b3JrLg0KV2hpbGUgd2UgYXJlIHN0aWxsIDMgbW9udGhz IGZyb20gdGhyIG1lZXRpbmcsIHRoZSBzZXNzaW9uIHJlcXVlc3RzIGhhdmUgb3BlbmVkIHVwIGFu ZCB3ZSBuZWVkIHRvIGtub3cgYXBwcm94aW1hdGVseSBob3cgbXVjaCB0aW1lIHRvIHJlcXVlc3Qu DQotIEJlcm5pZSAmIFRvbWVrDQo= --_000_865f9e83c2d4420caf2a0999de12f787XCHALN003ciscocom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1 IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg Um9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9 DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpw Lk1zb0xpc3RQYXJhZ3JhcGgsIGxpLk1zb0xpc3RQYXJhZ3JhcGgsIGRpdi5Nc29MaXN0UGFyYWdy YXBoDQoJe21zby1zdHlsZS1wcmlvcml0eTozNDsNCgltYXJnaW4tdG9wOjBpbjsNCgltYXJnaW4t cmlnaHQ6MGluOw0KCW1hcmdpbi1ib3R0b206MGluOw0KCW1hcmdpbi1sZWZ0Oi41aW47DQoJbWFy Z2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRp bWVzIE5ldyBSb21hbiIsc2VyaWY7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5 cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJ Y29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQt b25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjgu NWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRT ZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmluaXRpb25zICovDQpA bGlzdCBsMA0KCXttc28tbGlzdC1pZDoxODM5MjY5NzU0Ow0KCW1zby1saXN0LXR5cGU6aHlicmlk Ow0KCW1zby1saXN0LXRlbXBsYXRlLWlkczoxNjY1MDYxMzc2IC0xNDY1NjQ0OTM2IDY3Njk4Njkx IDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3 Njk4NjkzO30NCkBsaXN0IGwwOmxldmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxs ZXQ7DQoJbXNvLWxldmVsLXRleHQ6LTsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQt ZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCW1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OkNh bGlicmk7DQoJbXNvLWJpZGktZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7fQ0KQGxpc3Qg bDA6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwt dGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIg TmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0 Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQt ZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1m b3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4y NWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDUNCgl7bXNvLWxldmVs LW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRh Yi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k ZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVs Ng0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674Kn Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBs aXN0IGwwOmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxl dmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6U3lt Ym9sO30NCkBsaXN0IGwwOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7 DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFt aWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9w Om5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0u MjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0Kb2wNCgl7bWFyZ2luLWJvdHRvbTowaW47 fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28g OV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+ DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5 b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9v OnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4t VVMiIGxpbms9IiMwNTYzQzEiIHZsaW5rPSIjOTU0RjcyIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0 aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3 RCI+SGk6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5KdXN0IGEg cmVtaW5kZXIgdG8gc3VibWl0IGFnZW5kYSByZXF1ZXN0cy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0 eWxlPSJ0ZXh0LWluZGVudDotLjI1aW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPjwhW2lmICFz dXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48c3BhbiBzdHlsZT0i bXNvLWxpc3Q6SWdub3JlIj4tPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3 IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6IzFGNDk3RCI+QmVybmllPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9w OnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWYiPiBkaGN3ZyBbbWFpbHRvOmRoY3dnLWJvdW5jZXNAaWV0Zi5vcmddDQo8Yj5PbiBC ZWhhbGYgT2YgPC9iPkJlcm5pZSBWb2x6ICh2b2x6KTxicj4NCjxiPlNlbnQ6PC9iPiBNb25kYXks IEFwcmlsIDE3LCAyMDE3IDY6MzYgUE08YnI+DQo8Yj5Ubzo8L2I+IGRoY3dnQGlldGYub3JnPGJy Pg0KPGI+U3ViamVjdDo8L2I+IFtkaGN3Z10gSUVURi05OSAoUHJhZ3VlKSBNZWV0aW5nIEFnZW5k YSBSZXF1ZXN0cyAtIGR1ZSBieSBNYXkgMjh0aDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IaTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SWYgeW91IGhhdmUgYW55IGludGVyZXN0IGluIHBy ZXNlbnRpbmcgdG8gdGhlIERIQyB3ZyBkdXJpbmcgSUVURi05OSwgcGxlYXNlIHN1Ym1pdCBhIHJl cXVlc3QgYnkgVHVlc2RheSwgTWF5IDI3dGguIFRvbWVrICZhbXA7IEkgbXVzdCBzdWJtaXQgYSBy ZXF1ZXN0IGZvciBhIHNlc3Npb24gYnkgSnVuZSAybmQgZGVhZGxpbmUuPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkFzIGluIHRoZSBwYXN0LCBw bGVhc2UgcHJvdmlkZTo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+VGl0 bGUgT2YgU2Vzc2lvbjo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+UHJl c2VudGVyOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5SZWxhdGVkIERy YWZ0czo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+VGltZSBSZXF1aXJl ZDo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+UHVycG9zZSBvZiBTZXNz aW9uOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5XZSBkbyB3YW50IHRv IHJlbWluZCB0aG9zZSByZXF1ZXN0aW5nIHRpbWUgdGhhdCB5b3Ugc2hvdWxkIGZvY3VzIG9uIGRp c2N1c3Npbmcga2V5IGlzc3VlcyB0aGF0IG5lZWQgcmVzb2x1dGlvbiB0byBtb3ZlIGEgZHJhZnQg Zm9yd2FyZCBvciB0byBpbnRyb2R1Y2UgcG90ZW50aWFsIG5ldyB3b3JrLjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5XaGlsZSB3ZSBhcmUgc3RpbGwgMyBtb250aHMgZnJv bSB0aHImbmJzcDttZWV0aW5nLCB0aGUgc2Vzc2lvbiByZXF1ZXN0cyBoYXZlIG9wZW5lZCB1cCBh bmQgd2UgbmVlZCB0byBrbm93IGFwcHJveGltYXRlbHkgaG93IG11Y2ggdGltZSB0byByZXF1ZXN0 LjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi0gQmVybmllICZh bXA7IFRvbWVrPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+ DQo8L2h0bWw+DQo= --_000_865f9e83c2d4420caf2a0999de12f787XCHALN003ciscocom_-- From nobody Mon May 8 21:06:29 2017 Return-Path: X-Original-To: dhcwg@ietf.org Delivered-To: dhcwg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F4DD120227; Mon, 8 May 2017 21:06:28 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: dhcwg@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.50.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149430278799.22508.6260562390643195706@ietfa.amsl.com> Date: Mon, 08 May 2017 21:06:28 -0700 Archived-At: Subject: [dhcwg] I-D Action: draft-ietf-dhc-rfc3315bis-08.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.22 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 May 2017 04:06:28 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Dynamic Host Configuration of the IETF. Title : Dynamic Host Configuration Protocol for IPv6 (DHCPv6) bis Authors : Tomek Mrugalski Marcin Siodelski Bernie Volz Andrew Yourtchenko Michael C. Richardson Sheng Jiang Ted Lemon Timothy Winters Filename : draft-ietf-dhc-rfc3315bis-08.txt Pages : 139 Date : 2017-05-08 Abstract: This document describes the Dynamic Host Configuration Protocol for IPv6 (DHCPv6): an extensible mechanism for configuring nodes with network configuration parameters, IP addresses, and prefixes. Parameters can be provided statelessly, or in combination with stateful assignment of one or more IPv6 addresses and/or IPv6 prefixes. DHCPv6 can operate either in place of or in addition to stateless address autoconfiguration (SLAAC). This document updates the text from RFC3315, the original DHCPv6 specification, and incorporates prefix delegation (RFC3633), stateless DHCPv6 (RFC3736), an option to specify an upper bound for how long a client should wait before refreshing information (RFC4242), a mechanism for throttling DHCPv6 clients when DHCPv6 service is not available (RFC7083), and clarifies the interactions between modes of operation (RFC7550). As such, this document obsoletes RFC3315, RFC3633, RFC3736, RFC4242, RFC7083, and RFC7550. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dhc-rfc3315bis/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-dhc-rfc3315bis-08 https://datatracker.ietf.org/doc/html/draft-ietf-dhc-rfc3315bis-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dhc-rfc3315bis-08 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue May 9 07:52:55 2017 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD433129B79 for ; Tue, 9 May 2017 07:52:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 ycZ0FGHGSXOb for ; Tue, 9 May 2017 07:52:52 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 02CB312948D for ; Tue, 9 May 2017 07:52:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9469; q=dns/txt; s=iport; t=1494341572; x=1495551172; h=from:to:cc:subject:date:message-id:mime-version; bh=lTSIq2Yt3cbEqvAbzq4++1ARvwfmv/t6HtNHM61XPsY=; b=gfxREUBKW9fQ7dJE+RR1aNXJqzG+oVabdbvBz3q/+bCdHZUdES8FNA11 GvbXjb/0THLy6fPrgSEFhMFwb0Z7xIVihbjGZLGe2URIEmAl7FWVdS1a2 dmSx+8W5RDbrNf2Vznt49H7RSlWkqNTHE5FN+DodE5YHwvn87Pd1ZBi0q 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CaAACE1xFZ/4cNJK1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgm5nYoEMB4VoiBKiEYU4gg8nhCOBWoRrPxgBAgEBAQEBAQFrHQu?= =?us-ascii?q?FSUwSAYEAJgEEDg2KGQ61Aop1AQEBAQEBAQEBAQEBAQEBAQEBAQEBGAWIPYRXg?= =?us-ascii?q?WWHKwWJS5Q6AYcbi3SCDYFhg1qIb4E9lD8BHzhMPnAVRoQ7gjh2AQEBAYdkgQ0?= =?us-ascii?q?BAQE?= X-IronPort-AV: E=Sophos;i="5.38,315,1491264000"; d="scan'208,217";a="241277686" Received: from alln-core-2.cisco.com ([173.36.13.135]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 09 May 2017 14:52:50 +0000 Received: from XCH-RCD-003.cisco.com (xch-rcd-003.cisco.com [173.37.102.13]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id v49EqoWk009220 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 9 May 2017 14:52:50 GMT Received: from xch-aln-003.cisco.com (173.36.7.13) by XCH-RCD-003.cisco.com (173.37.102.13) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 9 May 2017 09:52:50 -0500 Received: from xch-aln-003.cisco.com ([173.36.7.13]) by XCH-ALN-003.cisco.com ([173.36.7.13]) with mapi id 15.00.1210.000; Tue, 9 May 2017 09:52:50 -0500 From: "Bernie Volz (volz)" To: "dhcwg@ietf.org" CC: Ralph Droms Thread-Topic: WGLC for draft-ietf-dhc-rfc3315bis-08 - Respond by May 30th, 2017 Thread-Index: AdLI0aZmS0Xgn7D6S1m3YZ8hZorkbQ== Date: Tue, 9 May 2017 14:52:50 +0000 Message-ID: <8418750467ae490ea50e342380a565be@XCH-ALN-003.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.131.32.178] Content-Type: multipart/alternative; boundary="_000_8418750467ae490ea50e342380a565beXCHALN003ciscocom_" MIME-Version: 1.0 Archived-At: Subject: [dhcwg] WGLC for draft-ietf-dhc-rfc3315bis-08 - Respond by May 30th, 2017 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 May 2017 14:52:54 -0000 --_000_8418750467ae490ea50e342380a565beXCHALN003ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello: The co-authors believe that all of the issues reported for the last August = WGLC on draft-ietf-dhc-rfc3315bis-05 have now been resolved. But, because o= f the large number of changes, the DHC WG co-chairs feel another "WGLC" is = appropriate. Please review this document and provide your comments and whether you suppo= rt the document moving forward by May 30th, 2017. The DHC WG co-chairs will= again ask Ralph to evaluate the responses. We are doing a 3 week WGLC as t= he document is rather large and important to get right! Please see https://tools.ietf.org/html/draft-ietf-dhc-rfc3315bis-08. If you'd like to see the differences from the 05 version, use the diff tool= at https://tools.ietf.org/rfcdiff: https://tools.ietf.org//rfcdiff?url1=3Dhttps://tools.ietf.org/id/draft-ietf= -dhc-rfc3315bis-08.txt&url2=3Dhttps://tools.ietf.org/id/draft-ietf-dhc-rfc3= 315bis-05.txt The list of issues we recorded and action/assignee details are at https://d= ocs.google.com/spreadsheets/d/1c3obOwmRQDldw0u_kv85B5Q4LnjnmvUp2MmsHDGmW98 = (some additional issues are in https://trac.tools.ietf.org/group/dhcpv6bis/= report). One very recent change to highlight is https://tools.ietf.org/html/draft-ie= tf-dhc-rfc3315bis-08#section-18.2.12 - this was to address a criticism that= DHCPv6 is not responsive enough for some network configuration changes. The co-authors thank those that reviewed this document during the previous = WGLC and hope that those same reviewers (and hopefully more) will endeavor = to do one more thorough review of the document. - Tomek & Bernie --_000_8418750467ae490ea50e342380a565beXCHALN003ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello:

 

The co-authors believe that all of the issues report= ed for the last August WGLC on draft-ietf-dhc-rfc3315bis-05 have now been r= esolved. But, because of the large number of changes, the DHC WG co-chairs = feel another “WGLC” is appropriate.

 

Please review this document and provide your comment= s and whether you support the document moving forward by May 30th, 2017. The DHC WG co-chairs will again ask Ralph to evaluate the response= s. We are doing a 3 week WGLC as the document is rather large and important to get right!

 

Please see https://tools.ietf.org/html/draft-ietf-dhc-rfc3315bis-08.

 

If you’d like to see the differences from the = 05 version, use the diff tool at https://tools.ietf.org/rfcdiff:

 

https://tools.ietf.org/= /rfcdiff?url1=3Dhttps://tools.ietf.org/id/draft-ietf-dhc-rfc3315bis-08.txt&= amp;url2=3Dhttps://tools.ietf.org/id/draft-ietf-dhc-rfc3315bis-05.txt

 

The list of issues we recorded and action/assignee d= etails are at https://docs.google.com/spreadsheets/d/1c3obOwmRQDldw0u_kv85B5Q4LnjnmvUp2Mm= sHDGmW98 (some additional issues are in https://trac= .tools.ietf.org/group/dhcpv6bis/report).

 

One very recent change to highlight is https://tools.ietf.org/html/draft-ietf-dhc-rfc3315bis-08#section-18.2.12 – this was to address a criticism that DHCPv6 is not responsive eno= ugh for some network configuration changes.

 

The co-authors thank those that reviewed this docume= nt during the previous WGLC and hope that those same reviewers (and hopeful= ly more) will endeavor to do one more thorough review of the document.=

 

-     &= nbsp;    Tomek & Bernie

--_000_8418750467ae490ea50e342380a565beXCHALN003ciscocom_-- From nobody Thu May 18 12:21:37 2017 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EAB512EAB1 for ; Thu, 18 May 2017 12:21:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.022 X-Spam-Level: X-Spam-Status: No, score=-14.022 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 leRcqzdnXjcc for ; Thu, 18 May 2017 12:21:31 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0059D129B7F for ; Thu, 18 May 2017 12:15:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=18866; q=dns/txt; s=iport; t=1495134924; x=1496344524; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=cQ7ABIy/rmsxoL5cJwPyrMGIIWDPdcz39XpE8WMW6Q0=; b=evyylDP06rwGFPNzNxL8yJQqxohHZA+4c74xfraHr3ED244hEZH+9vNX /Devz6b+8XuZqmb08PCzQIccx9zLSt6xUVo5BviBjQJEqh/NAdXcOPsky mZLYtDV8GeeezxC/nU59XsVOUbjLO3ClxOjH1KLOjEbbNjUHagu+BKe5t k=; X-IronPort-AV: E=Sophos;i="5.38,359,1491264000"; d="scan'208";a="250126874" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 18 May 2017 19:15:24 +0000 Received: from dhcp-161-44-67-116.cisco.com (dhcp-161-44-67-116.cisco.com [161.44.67.116]) (authenticated bits=0) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id v4IJFNRP015625 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 18 May 2017 19:15:23 GMT Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: kkinnear In-Reply-To: <8418750467ae490ea50e342380a565be@XCH-ALN-003.cisco.com> Date: Thu, 18 May 2017 15:15:22 -0400 Cc: Kim Kinnear , "Bernie Volz (volz)" Content-Transfer-Encoding: quoted-printable Message-Id: <455226D6-0A37-4D3E-A5BA-1832D1E3BB99@cisco.com> References: <8418750467ae490ea50e342380a565be@XCH-ALN-003.cisco.com> To: "dhcwg@ietf.org" , Ralph Droms X-Mailer: Apple Mail (2.3273) X-Authenticated-User: kkinnear@cisco.com Archived-At: Subject: Re: [dhcwg] WGLC for draft-ietf-dhc-rfc3315bis-08 - Respond by May 30th, 2017 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 May 2017 19:21:35 -0000 Folks, I did a pretty complete review of the document, and while most of the first issues I found were editorial, I found a number of technical issues as I went along. Of the 33 issues I found (all of which I felt important enough to write down), the following stand out as particularly important: Editorial: #8, #23 Technical: #10, #14, #15, #16, #17, #20.5, #21, #22, #26 #27, #28, #30, #31, #32 I have read this document, and I approve its moving forward. I would very much like to see the issues I've highlighted above addressed, either by taking my suggested corrections, or by explaining why the document is correct as it stands. =20 As it happens, a few of the issues I found were from RFC 3315 and not added by the -bis process. But, as I commented below, that doesn't make them correct. =20 Here are the issues: 1. Section 11, para 2, "such are those" -> "such as those" 2. Section 11, para 3, last sentence, "as specfic in" -> "as specified = in" 3. Section 13.2, para 4, "... with additional condition that the new address is not duplicated with any assigned addresses" ->=20 "... with the additional condition that any new address is not=20 the same as any assigned address." 4. Section 13.2, para 7, "of temporary address is unlinkability of = different actions over time." -> "of a temporary address is to make it=20 difficult to link the address to different actions over time." 5. Same as above, "though DHCP provides such possibility" ->=20 "though DHCP provides for such a possibility" 6. Section 14.2, list with 3 elements. I think we want to remove the ", and" at the end of item 2, the comma at the end of item 1, and the period at the end of item 3. In particular, the=20 ", and" kind of implies that item 2 and item 3 are linked, but I don't think they are. 7. [retracted correction: diff had a problem not present in the actual = draft] 8. Section 18, para 5. Paragraph beginning with "The client has = many..." and containing a list with 4 elements. This list appears to have = been moved to the first part of the section and slightly improved there,=20= and it looks like this older version of the list should have been=20 deleted. 9. Section 20.4.1. para 3 (or 2, depending on how you count). =20 "The format of the Authentication information..." -> "The format of the authentication information ...". In the option description (21.11), "authentication information" is not capitalized. 10. Section 20.4.3, para 1, "... in the initial Reply ..." -> "... in an=20= Authentication option in the initial Reply ..." 11. Section 21.4, para 2 after table after Figure 15. "Each IA_NA ... = attached to." -> "Each IA_NA carries one "set" of non-temporary addresses; it = is up to the server policy to determine how many addresses are assgined, but typically at most one address is assigned from each prefix = assigned to the link to which the client is attached." Note removal of double = quote before 'it' as well as improved wording. 12. Section 21.5, para 6 after table after Figure 16. "... MAY request = that valid lifetime ..." -> "... MAY request that the valid lifetimes = ...". Two changes, added "the", and made lifetime plural. I'm not = positive about making lifetime plural here, please validate that. 13. Same para as #12, "Extending only valid but not preferred ..." -> "Extending only the valid but not the preferred ..." 14. Section 21.6, para 1. The last sentence "The Options fields of the IA_NA or IA_TA option encapsulates those options that are=20 specific to this address." hasn't changed since the -05 draft, but it *is* different from RFC 3315, which said: "The Options field encapsulates those options that are specific to this address." I find the current language confusing. Why would the Options field of the IA_NA or IA_TA encapsulate options that are specific to this address, when there can be multiple IA Address options in an IA_NA or IA_TA? I would have expected this sentence to read "The IAaddr-options field encapsulates those options that are specific to this address.", since there seems to be no other=20 point to having an IAaddr-options field. But in any case, this = needs to be figured out and fixed, as it is plenty confusing as it now stands. 15. Section 21.7, para 1 after table after Figure 18. =20 Sections 21.24 and 21.25 state that the SOL_MAX_RT and INF_MAX_RT options MUST always be in every Option Request option. But this is contradicted by Table 1, which says that they MUST only appear for certain message types. I believe that Table 1 is in fact more correct than the statements in Section 21.24 and = 21.25. In which case, I would suggest that a new sentence be added here: "For certain message types, some Option codes MUST be included in the Option Request option, see Table 1 for details." And, Sections 21.24 and Section 21.25 should be corrected to mention the message type qualification: Section 21.24, para 1 after table after Figure 38: "A DHCP client ... it sends." -> "A DHCP client ... it sends in a SOLICIT message." Section 21.25, para 1 after table after Figure 39: "A DHCP client ... it sends." -> "A DHCP client ... it sends in an Information-request message." 16. Section 21.7, para 2 after table after Figure 18. "Only container options MUST appear in the Option Request," --- I think that this=20 is simply incorrect. The better way to say this would be "Only = container options MAY appear in the Option Request option,", but that is also incorrect. I believe that the statement is "Only top-level options MAY appear in the Option Request option." The next sentence should then be: "Options encapsulated in a container option MUST NOT appear in an Option Request option, see [RFC7598] as an example of container options." =20 17. same as #16. I think the last sentence should be replaced with=20 "Options MAY be defined which specify exceptions to the restriction on including encapsulated options in an Option Request option. For example, the Option Request option MAY be used to signal support for a feature even when that option is encapsulated, as in the case of = the Prefix Exclude option [RFC6603]. See Table 1." 18. Section 21.11, Authentication Option. In Figure 22, there is "auth-info" at the start of the "authentication information" section. I would remove the "auth-info", since this field is actually known as "authentication information" in the table below Figure 22. I don't think the "auth-info" label adds any value, and is rather inconsistent and might be confusing.=20 19. Section 21.14, DISCUSSION, para 1. Last sentence, RFC references have extraneous () around references. 20. Same as #19, para 2. Replace with "The problem of unused leases can = be minimized by designing the DHCP service so that only one server = responds to the Solicit, by using relatively short lifetimes for newly = assigned leases, or by having DHCP clients release unused leases using the=20 Release message." Whether or not this paragraph is used, the=20 word "initiatively" isn't commonly used, and some references label it "nonstandard" and others show it from the late 1700's. I don't think it belongs in an RFC. 20.5 Section 21.16, last sentence. "Each instance of OPTION_VENDOR_CLASS can carry multiple sub-options." I see no sub-options at all here, using the definition of sub-option from RFC 7227 (see item #21 for a link to the relevant section of this RFC). I see two possible things that this sentence could be trying to say: a) "Each instance of OPTION_VENDOR_CLASS can carry multiple enterprise-number and vendor-class-data pairs." b) "Each instance of OPTION_VENDOR_CLASS can carry multiple instances of vendor-class-data, all relating to the same enterprise-number." I don't know which was intended, if either. Or, possibly, both. I know that (b) is true, and I'm pretty sure that (a) is true but I could be wrong about that. If it is true, then it would be really good to confirm it here. This sentence is new since RFC 3315. 21. Section 21.17. This section uses the term "encapsulated options" throughout, which I believe is technically incorrect. See: https://tools.ietf.org/html/rfc7227#section-9=20 which explains the distinction between "encapsulated options" and "sub-options" really well. I believe that this section should be discussing "sub-options", not "encapsulated options", per RFC 7227. My suggestion would be to rename the "option-data" field in Figure 30 as "sub-option-data", to distinguish it from the "option-data" field in Figure 31. And replace the "option-data" line in the table after Figure 30 with: "sub-option-data Sub-options, interpreted by vendor-specific code on the clients and servers." =20 I would replace the paragraph before Figure 31 with: "The sub-option-data field MUST be encoded as a sequence of=20 code/length/value fields identical in format to the DHCP=20 options field (see Section 21.1). The sub-option codes are defined=20= by the vendor identified in the enterprise-number field, and are=20 not managed by IANA. See Section 9 of [RFC7227]. Each of the sub-options is formatted as follows:" In the table below Figure 31: "opt-code The code for the sub-option. option-len An unsigned integer giving the length of the option-data field in this sub-option in octets. option-data The data area for the sub-option." Replace the last line of the para 1 after the table after Figure 31: "... MAY contain multiple encapsulated options." -> "... MAY contain multiple sub-options." 22. Section 21.21, para 6 after table after Figure 35. This paragraph makes no sense. In RFC 3633 (the PD RFC), this paragraph talked about which numbers to put in T1 and T2. Now, it talks about T1 and T2 "fields" and T1 and T2 "parameters". The way it comes out now, it seems like it is talking about what the *client* should be doing with the T1 and T2 fields, not the server. In which case, the sentence should start out "In a message sent by a server to a client, the client MUST use..." This is exactly what the text in the IA_NA option says, for what that is worth. But as it is, it can't be correct. 23. Section 21.22, para 3 after table after Figure 36. This sentence also appears (slightly differently) in Section 21.6, the IA Address option. "A client discards any prefixes for which the preferred lifetine is greater than the valid lifetime." Shouldn't this be "A client MUST discard any prefixes..." in both sections? =20 24. Section 23, para 1, sentence 2. Replace "of said document" with=20 "of that document". 25. Section 27.1, Normative References. I think that RFC 7227 should be normative because if its discussion of the distinction between encapsulated options and sub-options in Section 9 of RFC 7227. 26. Appendix B., Info Refresh Time column. I don't understand why this option is shown for the Inform. message. I believe that the option code for it MUST be in an Option Request option for an Inform. message. But not that the option itself must be in the Inform. message, which is what this table is all about. Section 21.23 says directly that this option "MUST only appear in the top level option area of Reply messages.", so something is wrong in one of these places. I think the table in Appendix B is the one that is wrong, and that the * for Info Refresh Time should be removed from the row titled Inform. 27. Appendix B., SOL_MAX_RT column. I believe that the option code for the SOL_MAX_RT option MUST appear in an Option Request option in a Solicit message, but this table isn't about the Option Request option, it is about messages. So I believe that this is wrong, and that the * for SOL_MAX_RT should be removed from the Solicit message row. 28. Appendix B., INF_MAX_RT column. I can see no reason why this is listed as an option to appear in the Advertise message. I think this is simply an error and should be removed.=20 29. Appendix B. Interesting that the document mentions User Class, Vendor Class, and Vendor Specific Options as all valid for Relay-Forward and Relay-Reply messages. I'm not saying that isn't OK, but I didn't see anything in this document that would suggest anything other than an Interface Id option would go in a Relay-Forward or Relay-Reply message. Maybe I missed it. 30. Appendix C. This table is only relative to this document. Some of these options can appear in other DHCPv6 options defined in other RFC's. That exist today, not just future ones. Perhaps replacing the existing sentence "The following ... other options:" with "The following table indicates with a "*" where options defined in this document can appear in the options field of other options defined in this document. Other RFC's define additional situations where options defined in this document are encapsulated in other options." would make it more clear that this isn't the final word on what options can appear inside of what other options. 31. Appendix C. The sentence describing this table is moderately misleading. "where options can appear in the options field of other options." would seem to indicate that the column headings along the top of the table are all options. However, the first column isn't the name of an option, it is (presumably) the options field of any message. I think that we should remove this column, since any information that it contains is already covered (and in more correct detail) by the information in Appendix B, which discusses precisely which options can appear in the options field of individual messages. If I'm wrong about what the "Option Field" column represents, then it would be good to explain it more clearly. 32. Appendix C. Columns Relay-Forw, Relay-Reply, and Note. The note is just wrong, near as I can tell. There are no Relay-Forw or Relay-Reply options. There are Relay-Forward and Relay-Reply messages. I think having a Relay-Forw and Relay-Reply column in this table is very misleading, since as I said above, this table seems to be for options. These aren't options, they are messages. We already have the Relay Message option allowed in the Relay-Forward message and Relay-Reply message in Appendix B. In addition, the data there conflicts with the data here for the Relay-Forward and Relay-Reply messages. I don't know what someone was trying to communicate here, but I think that we=20 need to remove the Relay-Forw and Relay-Reply columns, and the Note. I recognize that this is left over from RFC 3315 and wasn't something added as part of the current process, but that doesn't make it right. 33. Appendix C. If we remove the first and last two columns, as I think makes sense, since this information is already covered in Appendix B, we are left with 3 options in the left column that have any * in any of the right 4 columns. Not the end of the world, but we could probably explain this with a sentence or two. For instance: "Several options may themselves appear in the options field of other options defined in this document. The IA Address options may appear in the options field of either the Identity Association for Non-temporay Addresses option or the Identity Association for Temporary Addresses option. The IA Prefix option may appear in the options field of the Identity Association for Prefix Delegation option. The Status Code option may appear in the options field of any of the three Identity Association options just discussed." I have no particular preference toward either approach (i.e., keep the table or replace it with the above paragraph), but offer the paragraph to show one possibility. Thanks -- Kim > On May 9, 2017, at 10:52 AM, Bernie Volz (volz) = wrote: >=20 > Hello: > =20 > The co-authors believe that all of the issues reported for the last = August WGLC on draft-ietf-dhc-rfc3315bis-05 have now been resolved. But, = because of the large number of changes, the DHC WG co-chairs feel = another =E2=80=9CWGLC=E2=80=9D is appropriate. > =20 > Please review this document and provide your comments and whether you = support the document moving forward by May 30th, 2017. The DHC WG = co-chairs will again ask Ralph to evaluate the responses. We are doing a = 3 week WGLC as the document is rather large and important to get right! > =20 > Please see https://tools.ietf.org/html/draft-ietf-dhc-rfc3315bis-08. > =20 > If you=E2=80=99d like to see the differences from the 05 version, use = the diff tool at https://tools.ietf.org/rfcdiff: > =20 > = https://tools.ietf.org//rfcdiff?url1=3Dhttps://tools.ietf.org/id/draft-iet= f-dhc-rfc3315bis-08.txt&url2=3Dhttps://tools.ietf.org/id/draft-ietf-dhc-rf= c3315bis-05.txt > =20 > The list of issues we recorded and action/assignee details are at = https://docs.google.com/spreadsheets/d/1c3obOwmRQDldw0u_kv85B5Q4LnjnmvUp2M= msHDGmW98(some additional issues are in = https://trac.tools.ietf.org/group/dhcpv6bis/report). > =20 > One very recent change to highlight is = https://tools.ietf.org/html/draft-ietf-dhc-rfc3315bis-08#section-18.2.12 = =E2=80=93 this was to address a criticism that DHCPv6 is not responsive = enough for some network configuration changes. > =20 > The co-authors thank those that reviewed this document during the = previous WGLC and hope that those same reviewers (and hopefully more) = will endeavor to do one more thorough review of the document. > =20 > - Tomek & Bernie > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg From nobody Tue May 23 09:10:10 2017 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95E10129BB2 for ; Tue, 23 May 2017 09:10:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.119 X-Spam-Level: X-Spam-Status: No, score=-1.119 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6eVh8lE1ry03 for ; Tue, 23 May 2017 09:10:05 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (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 AB1BC129418 for ; Tue, 23 May 2017 09:10:04 -0700 (PDT) Received: from [192.168.1.206] ([83.131.122.17]) by mail.gmx.com (mrgmx003 [212.227.17.184]) with ESMTPSA (Nemesis) id 0LnxQO-1dt6hd2sS8-00fyup for ; Tue, 23 May 2017 18:10:01 +0200 From: Ian Farrer Content-Type: multipart/alternative; boundary="Apple-Mail=_1A629A9F-823A-4829-BC27-6255E46DEEAD" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Message-Id: <03C4A74B-918F-4ECF-B8FF-075CBF7477DF@gmx.com> References: <65646669-e32f-958c-684c-a36d4272b046@gmail.com> To: dhcwg Date: Tue, 23 May 2017 18:10:00 +0200 X-Mailer: Apple Mail (2.3273) X-Provags-ID: V03:K0:1JLpeIH/CGFaXAvtvMdgZZDRaOSn2YWaEA8gEaX3HJcT/IgXaDB DBVSRlv+YndMkLTWZUqbrR5knTn5GnOBP+lXi9TJKgO+hHnEDDl+jpCvs4IUQkJ9Zwr34db UhUwhvPTFkXo9YoIl2tNI9LT6IyHPKUOXClbX5NiFeH1uMe3cPhtnpwn1fPla2CwkXzRRhr eaS0h8GJIH3yO2HWjPNGg== X-UI-Out-Filterresults: notjunk:1;V01:K0:G1HoC8xz/6U=:LSpNDK9jvyyeyvbWZbBHmn IC3qKPYR5tfVBSmIrXfp7fMCEd8dits272df24DLpGfM9rZYv8yViCVNQ++FLBm3wRpwz287X JiLsi/Xc0MEEZ2WujJQ1O3FiC9EXnmBCu9qvIHxzPZE67Cp2GK4ih3bIafJEB48ZKY5b/vjcE JZkuMOj/YDr/5qK318NMzZYKSonaN4ua1MQRsGB5RwXTFTq+XagUW33prhj/G9g0dvfwwx3bH W2AFfNw2WPqhBvQR2pGSUocwmXZbc73S5teUvvRPKS6fryjMGml8yjUD7e8/Eqm5b6P210eUq 9lOkfshc5XlL/EKmLYSWBFGiYsnCi18asVcF202/tAdMa6gT+IHTdCMg/ZKLEfN8bE3+NJu14 4qabY/pkEjdxQ/hqxScDaSikFeDQg5frHWJmGfVbPaYVJKCrngzuCktIOEx5c+B2pfG9rGRkx Al58rxKSbhWl0dEFHw9Hxstp+ju8xJOGqtRuGHcykKeMtRrB8KxI9cClLMrwoskLAe0MITWvx XZR1lO4ZqLpytuu802pD6HycRzsKwVaADuzIMfIBl0Xr/zHnLmTaJzJtkxPJ8NHPO1pNs7Rhl gj2nxtlVAEmDVZsyXO6U8spmBwElsw+zRvlEVJQSTeWIf2SxYeUNNGmHqLOkcN3J9O057SeE8 A7htMdmEdmdlm6uBsjV1g8qiR2jISrVtRM8cvRliTdsP4jdRYOKcdOU62cl3KWG8twdOaQCMW AAySwlgYQUHUCIVDNg3llynJNyxYx2WgH9EcA0CH/N9aUAwN1V0tWC4RnJPWjfZQtFO49e+UO Zw2VA0j Archived-At: Subject: [dhcwg] Fwd: [Softwires] Adoption call for draft-fsc-softwire-dhcp4o6-saddr-opt-07 - Respond by Mar 8th, 2017 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 May 2017 16:10:08 -0000 --Apple-Mail=_1A629A9F-823A-4829-BC27-6255E46DEEAD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Forwarding to DHC as this is the current home for the draft. Cheers, Ian > Begin forwarded message: >=20 > From: Jonas Gorski > Subject: Re: [Softwires] Adoption call for = draft-fsc-softwire-dhcp4o6-saddr-opt-07 - Respond by Mar 8th, 2017 > Date: 19. May 2017 at 14:18:21 GMT+2 > To: tomasz.mrugalski@gmail.com, dhcwg@ietf.org > Cc: softwires@ietf.org, draft-fsc-softwire-dhcp4o6-saddr-opt@ietf.org >=20 > Hi, >=20 > On 22.02.2017 18:37, tomasz.mrugalski@gmail.com = wrote: >> Hi, >>=20 >> This message initiates a two weeks long DHC WG adoption call on: >>=20 >> Title: DHCPv4 over DHCPv6 Source Address Option >> Pages: 9 >> Date: 2017-02-01 >> Document: draft-fsc-softwire-dhcp4o6-saddr-opt-07 >> Link: tools.ietf.org/html/draft-fsc-softwire-dhcp4o6-saddr-opt-07 >>=20 >> This document initially started as work intended to be adopted in >> Softwires, but after a discussion with chairs, responsible AD = (Suresh) >> and presenting this work in DHC, the conclusion is to aim for DHC >> adoption, not Softwires. Therefore this is a DHC adoption call. >>=20 >> This message is cross-posted to Softwires to let Softwire experts = weigh >> in their opinion. Please be sure to post your comments to DHC list, >> though. Comments sent by end of March 8th, 2017 are much appreciated. >=20 > I am working on implementing this draft (started in version 4), and = like=20 > to add a few comments. It is based on an existing RFC 7341 client=20 > (DHCPv4 over DHCPv6) which wasn't written by me, which was done by=20 > modifying an existing DHCPv4 client to transparently wrap all messages = in > DHCPv6 messages, so the DHCPv4 part doesn't really know about it. >=20 > My comments are split into three parts, first about the place of the=20= > options, then about handling them, and finally some nitpicks. >=20 > 1. The placement of the new options >=20 > I'll start with the placement of the (new) options. Pre-draft, the=20 > DHCPv6 encapsulation was a strict transport and stateless. This draft=20= > now adds both new options to the outer DHCPv6 messages as well the = inner=20 > DHCPv4 one. This seems quite awkward, as the client now needs to be = able=20 > to access both the outer envelope as well the inner message at the = same=20 > time for a full picture. IMHO especially awkward is the change from a=20= > DHCPv6 OPTION_DHCP4O6_SADDR_HINT to a DHCPv4 OPTION_DHCP4O6_SADDR. = This=20 > caused a bit of spaghetti-code when trying to somehow pass information=20= > between the (separated) code responsible for the DHCPv6=20 > en-/decapsulation, and the actual DHCPv4 code. The DHCPv4 code needed = to=20 > get the contents of the DHCPv6 envelope at the appropriate place. >=20 > Having all three as DHCPv4 options would make it much more consistent,=20= > as everything is now kept in one channel. This would also then = preserve=20 > RFC 7341's statement that "The DHCPv6-relay encapsulation is used = solely=20 > to deliver DHCPv4 packets to a DHCPv4-capable server, and does not=20 > allocate any IPv6 addresses nor does it provide IPv6-configuration=20 > information to the client." >=20 > The alternative that I could think of would be to move the _SADDR_HINT=20= > and _BR options to the original DHCPv6 message that contains the=20 > OPTION_DHCP4_O_DHCP6_SERVER option. Maybe create an container for = them,=20 > similar to how RFC 7598 defines containers for software46. The RFC = 7341=20 > client would then be able to already send the _SADDR in its discovers. >=20 > 2. Handling the new options >=20 > The OPTION_S46_BR poses no large issues. The new=20 > OPTION_DHCP4O6_SADDR_HINT caused and still causes a lot of headaches = for=20 > me. As far as my understanding with modern distributions (be they=20 > desktop or embedded) is that the DHCP clients usually do no=20 > configuration by their own, and just pass on the Lease's contents to a=20= > networking management deamon after they received the ACK. This works=20= > fine with DHCPv6, with DHCPv4, and with RFC 7341 DHCPv4overDHCPv6. >=20 > The new OPTION_DHCP4O6_SADDR_HINT now requires the network management=20= > daemon to (potentially) allocate/assign a new IP address during the=20 > offer/request phase (including the DAD), which makes the interaction=20= > quite a bit more complex, as there are a few new potential error=20 > transitions. There is now the awkward state where you might need to=20 > revert network configuration after a NACK or error from the server, or = a=20 > timeout despite never having a valid lease. Of course if one wants to=20= > avoid complexity one can just hope that we have a global address on = the=20 > wan interface already and always return that. This would be alleviated=20= > by already having this option in the original DHCPv6 lease, as then = the=20 > network management daemon could allocate the IP address already during=20= > the DHCPv6 lease acquisition handling phase. >=20 > And finally when adding support for it to a client that does=20 > "transparent" DHCPv6 en-/decapsulation this means that the DHCPv6 code=20= > now needs access to the DHCPv4 state machine to know when to include = the=20 > _SADDR option, and when to (not) expect it, as it has no DHCPv6 = message=20 > types to rely on. >=20 > 3. Nitpicks >=20 > The flow diagram in "5. IPv6/IPv4 Binding Message Flow" makes it look=20= > like the OPTION_DHCP4O6_SADDR is part of the DHCPv6 message, not part = of=20 > the embedded DHCPv4 message. >=20 > The option OPTION_DHCP4O6_SADDR is described in a subsection of "6.=20= > DHCPv6 Options", despite it being a DHCPv4 option (and there being = only > one DHCPv6 option, so the plural doesn't help either). >=20 > Both make it easy to mistake OPTION_DHCP4O6_SADDR as a DHCPv6 option,=20= > and not a DHCPv4 one (as I did until I read the newest draft, and will=20= > need to fix). >=20 > Also it feels a bit like the draft doesn't handle potential error = cases=20 > enough, although I can't really put my finger on it. One thing I am > wondering about is how the client should behave when it doesn't have = any > assigned prefixes or global addresses? Is sending the link local = address > fine? Should it abort in that case? How about ULA addresses? In case = of > using DHCPv6 broadcast address as DHCP4ov6 server this could happen > AFAICT. >=20 > I hope these comments help improving the proposed standard. >=20 >=20 > Regards > Jonas Gorski >=20 > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires = --Apple-Mail=_1A629A9F-823A-4829-BC27-6255E46DEEAD Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Forwarding to DHC as this is the current home for the = draft.

Cheers,
Ian

Begin = forwarded message:

From: = Jonas Gorski <jonas.gorski@gmail.com>
Subject: = Re: [Softwires] = Adoption call for draft-fsc-softwire-dhcp4o6-saddr-opt-07 - Respond by = Mar 8th, 2017
Date: 19. May 2017 at 14:18:21 GMT+2
To: tomasz.mrugalski@gmail.com, dhcwg@ietf.org
Cc: = softwires@ietf.org, draft-fsc-softwire-dhcp4o6-saddr-opt@ietf.org

Hi,
On 22.02.2017 18:37, tomasz.mrugalski@gmail.com wrote:
Hi,

This message initiates a two weeks long DHC WG adoption call = on:

Title: DHCPv4 over DHCPv6 Source = Address Option
Pages: 9
Date: 2017-02-01
Document: draft-fsc-softwire-dhcp4o6-saddr-opt-07
Link: tools.ietf.org/html/draft-fsc-softwire-dhcp4o6-saddr-opt-07=

This document initially started as work = intended to be adopted in
Softwires, but after a = discussion with chairs, responsible AD (Suresh)
and = presenting this work in DHC, the conclusion is to aim for DHC
adoption, not Softwires. Therefore this is a DHC adoption = call.

This message is cross-posted to = Softwires to let Softwire experts weigh
in their opinion. = Please be sure to post your comments to DHC list,
though. = Comments sent by end of March 8th, 2017 are much appreciated.

I am working on implementing this draft = (started in version 4), and like 
to add a few comments. It is based on an = existing RFC 7341 client 
(DHCPv4 over DHCPv6) which wasn't written by me, = which was done by 
modifying an existing DHCPv4 client to = transparently wrap all messages in
DHCPv6 messages, so the DHCPv4 = part doesn't really know about it.

My comments are split into three parts, first = about the place of the 
options, then about handling them, and finally = some nitpicks.

1. The placement of the new = options

I'll start with the placement of = the (new) options. Pre-draft, the 
DHCPv6 encapsulation was a strict transport and = stateless. This draft 
now adds both new options to the outer DHCPv6 = messages as well the inner 
DHCPv4 one. This seems quite awkward, as the = client now needs to be able 
to access both the outer envelope as well the = inner message at the same 
time for a full picture. IMHO especially awkward = is the change from a 
DHCPv6 OPTION_DHCP4O6_SADDR_HINT to a DHCPv4 = OPTION_DHCP4O6_SADDR. This 
caused a bit of spaghetti-code when trying to = somehow pass information 
between the (separated) code responsible for the = DHCPv6 
en-/decapsulation, and the actual DHCPv4 code. = The DHCPv4 code needed to 
get the contents of the DHCPv6 envelope at the = appropriate place.

Having all three as DHCPv4 = options would make it much more consistent, 
as everything is now kept in one channel. This = would also then preserve 
RFC 7341's statement that "The DHCPv6-relay = encapsulation is used solely 
to deliver DHCPv4 packets to a DHCPv4-capable = server, and does not 
allocate any IPv6 addresses nor does it provide = IPv6-configuration 
information to the client."
The alternative that I could think of would be = to move the _SADDR_HINT 
and _BR options to the original DHCPv6 message = that contains the 
OPTION_DHCP4_O_DHCP6_SERVER option. Maybe create = an container for them, 
similar to how RFC 7598 defines containers for = software46. The RFC 7341 
client would then be able to already send the = _SADDR in its discovers.

2. Handling the new options
The OPTION_S46_BR poses no large issues. The = new 
OPTION_DHCP4O6_SADDR_HINT caused and still = causes a lot of headaches for 
me. As far as my understanding with modern = distributions (be they 
desktop or embedded) is that the DHCP clients = usually do no configuration by their own, and just pass on the = Lease's contents to a 
networking management deamon after they received = the ACK. This works 
fine with DHCPv6, with DHCPv4, and with RFC 7341 = DHCPv4overDHCPv6.

The new = OPTION_DHCP4O6_SADDR_HINT now requires the network management 
daemon to (potentially) allocate/assign a new IP = address during the 
offer/request phase (including the DAD), which = makes the interaction 
quite a bit more complex, as there are a few new = potential error 
transitions. There is now the awkward state = where you might need to 
revert network configuration after a NACK or = error from the server, or a 
timeout despite never having a valid lease. Of = course if one wants to 
avoid complexity one can just hope that we have = a global address on the 
wan interface already and always return that. = This would be alleviated 
by already having this option in the original = DHCPv6 lease, as then the 
network management daemon could allocate the IP = address already during 
the DHCPv6 lease acquisition handling = phase.

And finally when adding support = for it to a client that does 
"transparent" DHCPv6 en-/decapsulation this = means that the DHCPv6 code 
now needs access to the DHCPv4 state machine to = know when to include the 
_SADDR option, and when to (not) expect it, as = it has no DHCPv6 message 
types to rely on.

3. Nitpicks

The flow diagram in "5. IPv6/IPv4 Binding = Message Flow" makes it look 
like the OPTION_DHCP4O6_SADDR is part of the = DHCPv6 message, not part of 
the embedded DHCPv4 message.
The option OPTION_DHCP4O6_SADDR is described in = a subsection of  "6. 
DHCPv6 Options", despite it being a DHCPv4 = option (and there being only
one DHCPv6 option, so the plural = doesn't help either).

Both make it easy to mistake = OPTION_DHCP4O6_SADDR as a DHCPv6 option, 
and not a DHCPv4 one (as I did until I read the = newest draft, and will 
need to fix).

Also it feels a bit like the draft doesn't = handle potential error cases 
enough, although I can't really put my finger on = it. One thing I am
wondering about is how the client should = behave when it doesn't have any
assigned prefixes or global = addresses? Is sending the link local address
fine? Should it abort in that case? How about = ULA addresses? In case of
using  DHCPv6 broadcast = address as DHCP4ov6 server this could happen
AFAICT.

I hope these comments help improving the = proposed standard.


Regards
Jonas Gorski
_______________________________________________
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires

= --Apple-Mail=_1A629A9F-823A-4829-BC27-6255E46DEEAD-- From nobody Tue May 23 13:18:05 2017 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFC2112EAFE for ; Tue, 23 May 2017 13:18:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.999 X-Spam-Level: X-Spam-Status: No, score=0.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, GUARANTEED_100_PERCENT=2.699, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JnFOOhn-8PGb for ; Tue, 23 May 2017 13:18:02 -0700 (PDT) Received: from mail-qt0-x234.google.com (mail-qt0-x234.google.com [IPv6:2607:f8b0:400d:c0d::234]) (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 687B112778E for ; Tue, 23 May 2017 13:18:02 -0700 (PDT) Received: by mail-qt0-x234.google.com with SMTP id f55so138414787qta.3 for ; Tue, 23 May 2017 13:18:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-transfer-encoding; bh=6PO670SB7Qp/2M4MxgKUSzB0HyGT2DsCvQRRIiwhCAM=; b=o9mEeAL017eJEGupPuSETyIDv5c8kc+letmAgwE7Q7Hl39V442pz5RaHkw/kmw4yKG edUHawyl2VfGO/ViVSV8Fwlax4WfaSb2XXZ540NUG4dQlqpEod0aWjKOAa/4KHg8vLpM ZfK//80gkHNF+R7H4nW0RoYIlHzO1dWBGjCxPczcLe6NDDY5o3q7KgD8B+yNrGhnXEHv taSEoq8J2mrZGC5LkoS6aNTOwQ1fZd01726cSTNmMW6618r6A52z/SifYQgngRaQa89k ccQit7q55OLCSgPxuQo0vuNyxCbPAhjrEsM4wyjjeEsgrxigUMc632HtmEB1Xs8z+8wa gjYA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc:content-transfer-encoding; bh=6PO670SB7Qp/2M4MxgKUSzB0HyGT2DsCvQRRIiwhCAM=; b=DhaCUoXyPbL+mk3073o1ClEa6l/a1rrZ3LNzPNyWji4FHDm8r0bpjPshjIoevjxIbp KzvN9WE+o33AtslV2HPbS//QG1RW8c8ia26EC5si4QB6YMuJRvruooxGSNl2Xwicd1iy vYotrTLDkma+N88UgiXI03eKnaXjV6nwcSTa7boQIV6uZbXMYFOFOoQJ8f9NGkZnORmu vwdE2DBEnETfj+6FdLWyP5MzwaP1t0n6RZx9luQ9OrMjxNTHuMANEgfDoWHeIPLvmbh+ AkOBqPpC6gzlwf2+ej2vebBOi+yh+rPQBdJNAcG94zc2MHZmqPe+kpN5jhGRxWunyxIK fqmg== X-Gm-Message-State: AODbwcCM8TRa8OndGkS6+TubLMbd2dUmGy6lu179RtiN8RotAAJfQ/C6 JTOnzj/DxTgMw++/iHAN9DFjMMZklysz/Js= X-Received: by 10.200.49.75 with SMTP id h11mr29644600qtb.13.1495570681376; Tue, 23 May 2017 13:18:01 -0700 (PDT) MIME-Version: 1.0 Sender: jinmei.tatuya@gmail.com Received: by 10.200.48.141 with HTTP; Tue, 23 May 2017 13:18:00 -0700 (PDT) In-Reply-To: <8418750467ae490ea50e342380a565be@XCH-ALN-003.cisco.com> References: <8418750467ae490ea50e342380a565be@XCH-ALN-003.cisco.com> From: =?UTF-8?B?56We5piO6YGU5ZOJ?= Date: Tue, 23 May 2017 13:18:00 -0700 X-Google-Sender-Auth: e4vcQgUPKY2pt7hhhuPXDN97a98 Message-ID: To: "Bernie Volz (volz)" Cc: "dhcwg@ietf.org" , Ralph Droms Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [dhcwg] WGLC for draft-ietf-dhc-rfc3315bis-08 - Respond by May 30th, 2017 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 May 2017 20:18:04 -0000 On Tue, May 9, 2017 at 7:52 AM, Bernie Volz (volz) wrote: > The co-authors believe that all of the issues reported for the last Augus= t > WGLC on draft-ietf-dhc-rfc3315bis-05 have now been resolved. But, because= of > the large number of changes, the DHC WG co-chairs feel another =E2=80=9CW= GLC=E2=80=9D is > appropriate. > > Please review this document and provide your comments and whether you > support the document moving forward by May 30th, 2017. The DHC WG co-chai= rs > will again ask Ralph to evaluate the responses. We are doing a 3 week WGL= C > as the document is rather large and important to get right! I'd still abstain about whether to advance the document as I stated for the previous WGLC: https://www.ietf.org/mail-archive/web/dhcwg/current/msg17577.html but I've checked if the 08 version has addressed my LC comments. I found some of them still open (perhaps they are intentionally left open or unchanged, but it's not clear to me). I'm listing them below, with followup comments for some of them. >> - I'm okay with deprecating the delayed authentication protocol, >> but I'm not sure if it's okay to ship the spec with no built-in >> authentication (the reconfigure key protocol is very limited and >> too weak). >> - I wonder whether we should still keep IA_TA. >> link-local address An IPv6 address having a link-only scope, >> indicated by having the prefix (FE80::/10), >> You might want to lower-case the prefix (i.e., to "fe80::/10"). This is not fully addressed as the case is still mixed (Sections 7.1 and 24 use upper case hex). >> - Section 5.2 >> the "stateful address autoconfiguration protocol" for IPv6 [RFC2462]. >> s/RFC2462/RFC4862/. and there are still more references to RFC2462. >> - Section 5.4 >> [...] the requesting router MUST set the valid lifetime in those >> advertisements to be no later than the valid lifetime specified in >> the IA_PD Prefix option. >> "no later than" sounds awkward as the lifetime is a duration, not >> a particular point in time. This is simply open as before. >> - Section 8.1 [...] >> site-scope unicast address has been deprecated. Also, the phrase >> "global or ULA" is awkward as ULA is a global (scoped) address. The 08 version states: This is typically a globally unique address or unique local address (ULA) [RFC4193], This is still awkward to me, since in a sense ULAs are also "globally unique" (even if the uniqueness is not 100% guaranteed). Personally I'd simply avoid mentioning ULAs unless there is a specific to reason to refer to it in the context (and I don't see such a reason here), but if we want to refer to ULAs here, I'd say, e.g., "a global address (including unique local addresses)". >> - Section 10 >> [...] The DUID is designed to be unique across all DHCP clients and >> servers, and stable for any specific client or server - that is, >> the DUID used by a client or server SHOULD NOT change over time if >> at all possible; >> I guess this property is now changing because of the privacy >> concerns. The main change that may be related to this comment is probably the following new sentence: [...] The client may change its DUID as specific in [RFC7844]. I personally don't think this fully addresses the point of the comment, although I can live with it. btw, I believe there's a typo: s/specific/specified/. >> - Section 15.11 >> - the message was not unicast to the client. >> I'm not sure why we bother to say this, and only for Reconfigure. >> Is there any case where a DHCPv6 message to a client isn't >> unicasted at all? There doesn't seem to be any change regarding this comment. I was not sure if it was intentional or oversight. >> - Section 17.1.10.1 >> "no later than" sounds awkward for these lifetimes (see also Sec >> 5.4). >> - Section 17.1.10.1 [...] >> Specifically, the bullet description seems to lead to multiple >> separate state machines for different bindings. These two don't seem to be addressed. >> - Section 18.1.1 >> s/global, ULA [RFC4193] or site-scoped/global/ (see comment on Sec 8.1) The revised text still has an issue: If the relay agent received the message to be relayed from a client, the relay agent places a global or unique local [RFC4193] address "global or unique local" is redundant since ULAs are global addresses (scope wise). >> - Section 18.1.2 >> s/global or site-scoped/global/ (see above) Same here. >> - Section 19.4 [...] >> This statement now sounds awkward since this is now the only >> defined authentication protocol. (see also comment on Section >> 17.2.2) There doesn't seem to be any change to address this point. >> - Section 20.7 >> encapsulated in the container MUST NOT by in the Option Request, see >> s/Option Request/Option Request option/ 'option' (after 'Request') is still missing. >> - Section 20.22 [...] >> This choice of valid/preferred lifetime in an IA prefix and the >> (possible) relationship between them and those lifetimes advertised >> in the delegated site do not make perfect sense to me. [...] I don't think the revised version addresses the main point. The new text simply avoids saying specifics about these lifetimes, but then it's even more unclear about what these lifetimes are (especially the preferred lifetime). >> - Section 20.23 [...] >> The expected usage is not very clear to me here. Is it intended to >> be used for Advertise and apply the value to the ongoing >> Solicit-Advertise exchange? Or is it mainly intended to be used >> for a possible subsequent restart of a DHCPv6 session? I guess it was supposed to be addressed by the newly added paragraph at the end of the section: The requirement for the client to request SOL_MAX_RT serves two purposes. First, it distinguishes between legacy and modern clients. Second, it allows modern clients to take advantage of the configurable SOL_MAX_RT values, even if the server is a legacy one. of which I don't understand the second purpose: if the server is legacy, how the client can benefit from the option? -- JINMEI, Tatuya From nobody Fri May 26 10:56:24 2017 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6D8F129B17 for ; Fri, 26 May 2017 10:56:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.823 X-Spam-Level: X-Spam-Status: No, score=-11.823 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, GUARANTEED_100_PERCENT=2.699, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 J_dyEj-RdQTv for ; Fri, 26 May 2017 10:56:20 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 90CA4129B13 for ; Fri, 26 May 2017 10:56:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14838; q=dns/txt; s=iport; t=1495821380; x=1497030980; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=X2pXEatC/C82ntTLDmibJLzWzCN2Nf4F8NIcITOj4p0=; b=gERZ8Zknddv45rk8MQolyP/H07HMA+U/LsXuJzEl5/MupISavY/YIplX KY2zqBfvOeM0TyYVfXs4Qbn4lyh55/kMNn/oAKOQczerq57ereuMImZHc yk7PP5ou8wi2vXQTh4PFJAlR5+IO5p9dFG5GK4Cr5S/ii6vtYVHynwOyT s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AQAQBeayhZ/4UNJK1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1VigQ0Hg2iKGJFlgyKFB41Qgg8uhSxKAhqCcD8YAQIBAQEBAQE?= =?us-ascii?q?BayiFGAEBAQECASMRPgcFBwQCAQgRBAEBAwIjAwICAh8RFAEICAEBBA4FCIoKA?= =?us-ascii?q?w0IEKsYgiaHNw2EEQEBAQEBAQEBAQEBAQEBAQEBAQEBARgFgQuHNQGCE4EMgT2?= =?us-ascii?q?BG4FtBwEBBQY2gmyCYAWWeYZvOwGHH4cwhE+CD4U8iHiBPYsyiRsBHziBCnQVh?= =?us-ascii?q?UkcgWN2AQSGRw8XgQqBDQEBAQ?= X-IronPort-AV: E=Sophos;i="5.38,398,1491264000"; d="scan'208";a="427048763" Received: from alln-core-11.cisco.com ([173.36.13.133]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 26 May 2017 17:56:19 +0000 Received: from XCH-ALN-003.cisco.com (xch-aln-003.cisco.com [173.36.7.13]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id v4QHuJcU000496 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 26 May 2017 17:56:19 GMT Received: from xch-aln-003.cisco.com (173.36.7.13) by XCH-ALN-003.cisco.com (173.36.7.13) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 26 May 2017 12:56:18 -0500 Received: from xch-aln-003.cisco.com ([173.36.7.13]) by XCH-ALN-003.cisco.com ([173.36.7.13]) with mapi id 15.00.1210.000; Fri, 26 May 2017 12:56:18 -0500 From: "Bernie Volz (volz)" To: =?utf-8?B?56We5piO6YGU5ZOJ?= CC: "dhcwg@ietf.org" , Ralph Droms Thread-Topic: [dhcwg] WGLC for draft-ietf-dhc-rfc3315bis-08 - Respond by May 30th, 2017 Thread-Index: AdLI0aZmS0Xgn7D6S1m3YZ8hZorkbQLWe7cAAIVlReA= Date: Fri, 26 May 2017 17:56:18 +0000 Message-ID: <67c761541b674041ba5a2eb0b9ea41fa@XCH-ALN-003.cisco.com> References: <8418750467ae490ea50e342380a565be@XCH-ALN-003.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.98.1.196] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [dhcwg] WGLC for draft-ietf-dhc-rfc3315bis-08 - Respond by May 30th, 2017 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 May 2017 17:56:23 -0000 SGkgSmlubWVpOg0KDQpUaGFua3MgZm9yIHJldmlld2luZy4gQ29tbWVudHMgZnJvbSBtZSBpbmxp bmUgYmVsb3cgKEJWPikuDQoNCllvdSBjYW4gdmlldyB0aGUgY2hhbmdlcyB0byB0aGUgWE1MIG1h ZGUgZnJvbSB0aGVzZSBjb21tZW50cyBhdDoNCg0KaHR0cHM6Ly9naXRodWIuY29tL2RoY3dnL3Jm YzMzMTViaXMvY29tbWl0LzM1N2U5OGQ4NGY3MjhlNTkwOTU5OGE4MjY3MjU2MmIwODg5ZjFmMTMN Cg0KLSBCZXJuaWUNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IGppbm1laS50 YXR1eWFAZ21haWwuY29tIFttYWlsdG86amlubWVpLnRhdHV5YUBnbWFpbC5jb21dIE9uIEJlaGFs ZiBPZiA/Pz8/DQpTZW50OiBUdWVzZGF5LCBNYXkgMjMsIDIwMTcgNDoxOCBQTQ0KVG86IEJlcm5p ZSBWb2x6ICh2b2x6KSA8dm9sekBjaXNjby5jb20+DQpDYzogZGhjd2dAaWV0Zi5vcmc7IFJhbHBo IERyb21zIDxyZHJvbXMuaWV0ZkBnbWFpbC5jb20+DQpTdWJqZWN0OiBSZTogW2RoY3dnXSBXR0xD IGZvciBkcmFmdC1pZXRmLWRoYy1yZmMzMzE1YmlzLTA4IC0gUmVzcG9uZCBieSBNYXkgMzB0aCwg MjAxNw0KDQpPbiBUdWUsIE1heSA5LCAyMDE3IGF0IDc6NTIgQU0sIEJlcm5pZSBWb2x6ICh2b2x6 KSA8dm9sekBjaXNjby5jb20+IHdyb3RlOg0KDQo+IFRoZSBjby1hdXRob3JzIGJlbGlldmUgdGhh dCBhbGwgb2YgdGhlIGlzc3VlcyByZXBvcnRlZCBmb3IgdGhlIGxhc3QgDQo+IEF1Z3VzdCBXR0xD IG9uIGRyYWZ0LWlldGYtZGhjLXJmYzMzMTViaXMtMDUgaGF2ZSBub3cgYmVlbiByZXNvbHZlZC4g DQo+IEJ1dCwgYmVjYXVzZSBvZiB0aGUgbGFyZ2UgbnVtYmVyIG9mIGNoYW5nZXMsIHRoZSBESEMg V0cgY28tY2hhaXJzIGZlZWwgDQo+IGFub3RoZXIg4oCcV0dMQ+KAnSBpcyBhcHByb3ByaWF0ZS4N Cj4NCj4gUGxlYXNlIHJldmlldyB0aGlzIGRvY3VtZW50IGFuZCBwcm92aWRlIHlvdXIgY29tbWVu dHMgYW5kIHdoZXRoZXIgeW91IA0KPiBzdXBwb3J0IHRoZSBkb2N1bWVudCBtb3ZpbmcgZm9yd2Fy ZCBieSBNYXkgMzB0aCwgMjAxNy4gVGhlIERIQyBXRyANCj4gY28tY2hhaXJzIHdpbGwgYWdhaW4g YXNrIFJhbHBoIHRvIGV2YWx1YXRlIHRoZSByZXNwb25zZXMuIFdlIGFyZSBkb2luZyANCj4gYSAz IHdlZWsgV0dMQyBhcyB0aGUgZG9jdW1lbnQgaXMgcmF0aGVyIGxhcmdlIGFuZCBpbXBvcnRhbnQg dG8gZ2V0IHJpZ2h0IQ0KDQpJJ2Qgc3RpbGwgYWJzdGFpbiBhYm91dCB3aGV0aGVyIHRvIGFkdmFu Y2UgdGhlIGRvY3VtZW50IGFzIEkgc3RhdGVkIGZvciB0aGUgcHJldmlvdXMgV0dMQzoNCmh0dHBz Oi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvZGhjd2cvY3VycmVudC9tc2cxNzU3Ny5o dG1sDQpidXQgSSd2ZSBjaGVja2VkIGlmIHRoZSAwOCB2ZXJzaW9uIGhhcyBhZGRyZXNzZWQgbXkg TEMgY29tbWVudHMuDQoNCkkgZm91bmQgc29tZSBvZiB0aGVtIHN0aWxsIG9wZW4gKHBlcmhhcHMg dGhleSBhcmUgaW50ZW50aW9uYWxseSBsZWZ0IG9wZW4gb3IgdW5jaGFuZ2VkLCBidXQgaXQncyBu b3QgY2xlYXIgdG8gbWUpLiAgSSdtIGxpc3RpbmcgdGhlbSBiZWxvdywgd2l0aCBmb2xsb3d1cCBj b21tZW50cyBmb3Igc29tZSBvZiB0aGVtLg0KDQo+PiAtIEknbSBva2F5IHdpdGggZGVwcmVjYXRp bmcgdGhlIGRlbGF5ZWQgYXV0aGVudGljYXRpb24gcHJvdG9jb2wsIGJ1dCANCj4+IEknbSBub3Qg c3VyZSBpZiBpdCdzIG9rYXkgdG8gc2hpcCB0aGUgc3BlYyB3aXRoIG5vIGJ1aWx0LWluIA0KPj4g YXV0aGVudGljYXRpb24gKHRoZSByZWNvbmZpZ3VyZSBrZXkgcHJvdG9jb2wgaXMgdmVyeSBsaW1p dGVkIGFuZCB0b28gDQo+PiB3ZWFrKS4NCg0KQlY+IFdlIGFyZSB3b3JraW5nIG9uIHNlZGhjcHY2 IGJ1dCB0aGlzIGhhcyBub3QgYmVlbiBzbyBzaW1wbGUgYW5kIHF1aWNrLiBBbmQsIERIQ1B2NiBp cyBpbiB1c2UgYW5kIGRlcGxveWVkIHRvZGF5IHdpdGhvdXQgYW4gYXV0aGVudGljYXRpb24gcHJv dG9jb2wuIFRoZXJlIGFyZSBvdGhlciBhY3Rpb25zIHRoYXQgY2FuIGJlIHRha2VuIHN1Y2ggYXMg c3RhdGVkIGluIHNlY3Rpb24gMjI6DQoNCiAgIE1hbnkgb2YgdGhlc2Ugcm9ndWUgc2VydmVyIGF0 dGFja3MgY2FuIGJlIG1pdGlnYXRlZCBieSBtYWtpbmcgdXNlIG9mDQogICB0aGUgbWVjaGFuaXNt IGRlc2NyaWJlZCBpbiBbUkZDNzYxMF0uDQoNCj4+IC0gSSB3b25kZXIgd2hldGhlciB3ZSBzaG91 bGQgc3RpbGwga2VlcCBJQV9UQS4NCg0KQlY+IFdlIGRlY2lkZWQgYXMgYSBXRyBub3QgdG8gcmVt b3ZlIElBX1RBLiBTZWUgaHR0cHM6Ly90cmFjLnRvb2xzLmlldGYub3JnL2dyb3VwL2RoY3B2NmJp cy90aWNrZXQvMTI0Lg0KDQo+PiAgIGxpbmstbG9jYWwgYWRkcmVzcyAgICAgICAgQW4gSVB2NiBh ZGRyZXNzIGhhdmluZyBhIGxpbmstb25seSBzY29wZSwNCj4+ICAgICAgICAgICAgICAgICAgICAg ICAgICAgICBpbmRpY2F0ZWQgYnkgaGF2aW5nIHRoZSBwcmVmaXggDQo+PiAoRkU4MDo6LzEwKSwg IFlvdSBtaWdodCB3YW50IHRvIGxvd2VyLWNhc2UgdGhlIHByZWZpeCAoaS5lLiwgdG8gImZlODA6 Oi8xMCIpLg0KDQpUaGlzIGlzIG5vdCBmdWxseSBhZGRyZXNzZWQgYXMgdGhlIGNhc2UgaXMgc3Rp bGwgbWl4ZWQgKFNlY3Rpb25zIDcuMSBhbmQgMjQgdXNlIHVwcGVyIGNhc2UgaGV4KS4NCg0KQlY+ IE9LLiBUaGUgRkYweDogY2FzZXMgd2VyZSBqdXN0IG1pc3NlZC4gVGhpcyBpcyBub3cgZml4ZWQu DQoNCj4+IC0gU2VjdGlvbiA1LjINCj4+ICAgdGhlICJzdGF0ZWZ1bCBhZGRyZXNzIGF1dG9jb25m aWd1cmF0aW9uIHByb3RvY29sIiBmb3IgSVB2NiBbUkZDMjQ2Ml0uDQo+PiAgcy9SRkMyNDYyL1JG QzQ4NjIvLg0KDQphbmQgdGhlcmUgYXJlIHN0aWxsIG1vcmUgcmVmZXJlbmNlcyB0byBSRkMyNDYy Lg0KDQpCVj4gVGhpcyBpcyBieSBkZXNpZ24uIFJGQzQ4NjIgZG9lcyBub3QgbWVudGlvbiB0aGUg TSAmIE8gYml0cyBzbyB3ZSBjYW4ndCByZWZlcmVuY2UgdGhhdCBSRkMuIFdlIGRvY3VtZW50ZWQg dGhlIHJlYXNvbiBmb3IgdGhpcyBpbiBBcHBlbmRpeCBBOg0KDQogICAyNi4gIC4uLg0KICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIE5vdGUgdGhhdCBpbiBhIGZldw0KICAg ICAgICBwbGFjZXMsIG9sZGVyIG9ic29sZXRlZCBSRkNzIChzdWNoIGFzIFJGQzI0NjIgcmVsYXRl ZCB0byBNIGFuZCBPDQogICAgICAgIGJpdCBoYW5kbGluZykgYXJlIHN0aWxsIHJlZmVyZW5jZWQg YXMgdGhlIG1hdGVyaWFsIGNpdGVkIHdhcyBub3QNCiAgICAgICAgYWRkZWQgaW4gdGhlIHJlcGxh Y2VtZW50IFJGQy4NCg0KQlY+IFRoZSBvdGhlciBwbGFjZSB3ZSB1c2VzIGlzIHdoZW4gbWVudGlv bmluZyAic3RhdGVmdWwgYWRkcmVzcyBhdXRvY29uZmlndXJhdGlvbiBwcm90b2NvbCIgYXMgUkZD IDQ4NjIgZG9lcyBub3QgdXNlIHRoaXMgdGVybWlub2xvZ3kgZXhjZXB0IGluIEFwcGVuZGl4IEM6 DQoNCiAgIG8gIEF2b2lkZWQgdGhlIHdvcmRpbmcgb2YgInN0YXRlZnVsIGNvbmZpZ3VyYXRpb24i LCB3aGljaCBpcyBrbm93biB0bw0KICAgICAgYmUgcXVpdGUgY29uZnVzaW5nLCBhbmQgc2ltcGx5 IHVzZWQgIkRIQ1B2NiIgd2hlcmV2ZXIgYXBwcm9wcmlhdGUuDQoNCkJWPiBJIGhvcGUgdGhpcyBl eHBsYWlucyB0byB5b3Ugd2h5IHdlIGxlYXZlIHRoaXMgcmVmZXJlbmNlIGluIHRoZSA0IHBsYWNl cyAoZXhjZXB0aW5nIEFwcGVuZGl4IEEpIHdoZXJlIGl0IGlzIHN0aWxsIHVzZWQuDQoNCg0KPj4g LSBTZWN0aW9uIDUuNA0KPj4gWy4uLl0gdGhlIHJlcXVlc3Rpbmcgcm91dGVyIE1VU1Qgc2V0IHRo ZSB2YWxpZCBsaWZldGltZSBpbiB0aG9zZSANCj4+IGFkdmVydGlzZW1lbnRzIHRvIGJlIG5vIGxh dGVyIHRoYW4gdGhlIHZhbGlkIGxpZmV0aW1lIHNwZWNpZmllZCBpbiANCj4+IHRoZSBJQV9QRCBQ cmVmaXggb3B0aW9uLg0KPj4gICJubyBsYXRlciB0aGFuIiBzb3VuZHMgYXdrd2FyZCBhcyB0aGUg bGlmZXRpbWUgaXMgYSBkdXJhdGlvbiwgbm90ICBhIA0KPj4gcGFydGljdWxhciBwb2ludCBpbiB0 aW1lLg0KDQpUaGlzIGlzIHNpbXBseSBvcGVuIGFzIGJlZm9yZS4NCg0KQlY+IFVubGVzcyB5b3Ug c3VnZ2VzdCBzb21lIHRleHQsIHdlIHdpbGwgbGVhdmUgdGhpcyBiZS4gSSB0aGluayB0aGUgcG9p bnQgb2YgdGhlIHRleHQgaXMgcmF0aGVyIGNsZWFyLg0KDQo+PiAtIFNlY3Rpb24gOC4xDQpbLi4u XQ0KDQo+PiBzaXRlLXNjb3BlIHVuaWNhc3QgYWRkcmVzcyBoYXMgYmVlbiBkZXByZWNhdGVkLiAg QWxzbywgdGhlIHBocmFzZSANCj4+ICJnbG9iYWwgb3IgVUxBIiBpcyBhd2t3YXJkIGFzIFVMQSBp cyBhIGdsb2JhbCAoc2NvcGVkKSBhZGRyZXNzLg0KDQpUaGUgMDggdmVyc2lvbiBzdGF0ZXM6DQoN CiAgICAgICAgICAgICAgICAgICAgICAgICAgIFRoaXMgaXMgdHlwaWNhbGx5IGEgZ2xvYmFsbHkg dW5pcXVlDQogICAgICAgICAgICAgICAgICAgICAgICAgICBhZGRyZXNzIG9yIHVuaXF1ZSBsb2Nh bCBhZGRyZXNzIChVTEEpDQogICAgICAgICAgICAgICAgICAgICAgICAgICBbUkZDNDE5M10sDQoN ClRoaXMgaXMgc3RpbGwgYXdrd2FyZCB0byBtZSwgc2luY2UgaW4gYSBzZW5zZSBVTEFzIGFyZSBh bHNvICJnbG9iYWxseSB1bmlxdWUiIChldmVuIGlmIHRoZSB1bmlxdWVuZXNzIGlzIG5vdCAxMDAl IGd1YXJhbnRlZWQpLiAgUGVyc29uYWxseSBJJ2Qgc2ltcGx5IGF2b2lkIG1lbnRpb25pbmcgVUxB cyB1bmxlc3MgdGhlcmUgaXMgYSBzcGVjaWZpYyB0byByZWFzb24gdG8gcmVmZXIgdG8gaXQgaW4g dGhlIGNvbnRleHQgKGFuZCBJIGRvbid0IHNlZSBzdWNoIGEgcmVhc29uIGhlcmUpLCBidXQgaWYg d2Ugd2FudCB0byByZWZlciB0byBVTEFzIGhlcmUsIEknZCBzYXksIGUuZy4sICJhIGdsb2JhbCBh ZGRyZXNzIChpbmNsdWRpbmcgdW5pcXVlIGxvY2FsIGFkZHJlc3NlcykiLg0KDQpCVj4gVW5sZXNz IHlvdSBzdWdnZXN0IHNvbWUgdGV4dCwgd2Ugd2lsbCBsZWF2ZSBpdCBiZS4gSSBkb24ndCBzZWUg dGhhdCB0aGlzIGlzIG5lY2Vzc2FyaWx5IGluIGNvbmZsaWN0IC0geWVzLCBVTEEgaXMgaW4gdGhl ICJnbG9iYWwgYWRkcmVzcyBzcGFjZSIuIEJ1dCBJIGFsc28gdGhpbmsgaXQgYWRkcyB2YWx1ZSB0 byBleHBsaWNpdGx5IG1lbnRpb24gVUxBcyBoZXJlIGFzIG90aGVyd2lzZSBzb21lb25lIGNvdWxk IGNvbmZ1c2UgdGhlIHN1YnRseSB0aGF0IFVMQSBpcyBhbGxvd2VkLg0KDQoNCj4+IC0gU2VjdGlv biAxMA0KDQo+PiBbLi4uXSBUaGUgRFVJRCBpcyBkZXNpZ25lZCB0byBiZSB1bmlxdWUgYWNyb3Nz IGFsbCBESENQIGNsaWVudHMgYW5kIA0KPj4gc2VydmVycywgYW5kIHN0YWJsZSBmb3IgYW55IHNw ZWNpZmljIGNsaWVudCBvciBzZXJ2ZXIgLSB0aGF0IGlzLCB0aGUgDQo+PiBEVUlEIHVzZWQgYnkg YSBjbGllbnQgb3Igc2VydmVyIFNIT1VMRCBOT1QgY2hhbmdlIG92ZXIgdGltZSBpZiBhdCBhbGwg DQo+PiBwb3NzaWJsZTsNCg0KPj4gSSBndWVzcyB0aGlzIHByb3BlcnR5IGlzIG5vdyBjaGFuZ2lu ZyBiZWNhdXNlIG9mIHRoZSBwcml2YWN5IA0KPj4gY29uY2VybnMuDQoNClRoZSBtYWluIGNoYW5n ZSB0aGF0IG1heSBiZSByZWxhdGVkIHRvIHRoaXMgY29tbWVudCBpcyBwcm9iYWJseSB0aGUgZm9s bG93aW5nIG5ldyBzZW50ZW5jZToNCg0KICAgWy4uLl0gIFRoZSBjbGllbnQgbWF5IGNoYW5nZSBp dHMgRFVJRCBhcyBzcGVjaWZpYyBpbiBbUkZDNzg0NF0uDQoNCkkgcGVyc29uYWxseSBkb24ndCB0 aGluayB0aGlzIGZ1bGx5IGFkZHJlc3NlcyB0aGUgcG9pbnQgb2YgdGhlIGNvbW1lbnQsIGFsdGhv dWdoIEkgY2FuIGxpdmUgd2l0aCBpdC4gIGJ0dywgSSBiZWxpZXZlICB0aGVyZSdzIGEgdHlwbzoN CnMvc3BlY2lmaWMvc3BlY2lmaWVkLy4NCg0KQlY+IFRoYW5rcyBmb3IgY2F0Y2hpbmcgdHlwbywg d2lsbCBiZSBmaXhlZC4gQXMgeW91IGNhbiBsaXZlIHdpdGggaXQsIHdlIHdpbGwgbGVhdmUgYWxv bmUgb3RoZXJ3aXNlLg0KDQo+PiAtIFNlY3Rpb24gMTUuMTENCg0KPj4gICAtICB0aGUgbWVzc2Fn ZSB3YXMgbm90IHVuaWNhc3QgdG8gdGhlIGNsaWVudC4NCg0KPj4gSSdtIG5vdCBzdXJlIHdoeSB3 ZSBib3RoZXIgdG8gc2F5IHRoaXMsIGFuZCBvbmx5IGZvciBSZWNvbmZpZ3VyZS4NCj4+IElzIHRo ZXJlIGFueSBjYXNlIHdoZXJlIGEgREhDUHY2IG1lc3NhZ2UgdG8gYSBjbGllbnQgaXNuJ3QgdW5p Y2FzdGVkIA0KPj4gYXQgYWxsPw0KDQpUaGVyZSBkb2Vzbid0IHNlZW0gdG8gYmUgYW55IGNoYW5n ZSByZWdhcmRpbmcgdGhpcyBjb21tZW50LiAgSSB3YXMgbm90IHN1cmUgaWYgaXQgd2FzIGludGVu dGlvbmFsIG9yIG92ZXJzaWdodC4NCg0KQlY+IFRoaXMgaXMgaW50ZW50aW9uYWwgYXMgdGhlIHNw ZWNpZmljYXRpb24gY2xlYXJseSBkb2VzIE5PVCBhbGxvdyBmb3IgbXVsdGljYXN0IFJlY29uZmln dXJlIHRvIGJlIHZhbGlkLiBQZXJoYXBzIGEgZnV0dXJlIGRyYWZ0IHdpbGwgc3VwcG9ydCB0aGlz LCBidXQgZm9yIG5vdyB0aGlzIHByb2hpYml0aW9uIGlzIGFwcHJvcHJpYXRlLg0KDQo+PiAtIFNl Y3Rpb24gMTcuMS4xMC4xDQo+PiAibm8gbGF0ZXIgdGhhbiIgc291bmRzIGF3a3dhcmQgZm9yIHRo ZXNlIGxpZmV0aW1lcyAoc2VlIGFsc28gU2VjIA0KPj4gNS40KS4NCg0KQlY+IFNlZSBhYm92ZS4N Cg0KPj4gLSBTZWN0aW9uIDE3LjEuMTAuMQ0KWy4uLl0NCj4+IFNwZWNpZmljYWxseSwgdGhlIGJ1 bGxldCBkZXNjcmlwdGlvbiBzZWVtcyB0byBsZWFkIHRvIG11bHRpcGxlIA0KPj4gc2VwYXJhdGUg c3RhdGUgbWFjaGluZXMgZm9yIGRpZmZlcmVudCBiaW5kaW5ncy4NCg0KQlY+IEkgYmVsaWV2ZSB3 ZSBhZGRyZXNzZWQgdGhpcyBieSBvdGhlciB0ZXh0IGluIHRoZSBkb2N1bWVudCAtIGZvciBleGFt cGxlLCBzZWUgaW4gMTguMi40IHRoZSBmb2xsb3dpbmcgdGV4dDoNCg0KICAgVGhlIHNlcnZlciBj b250cm9scyB0aGUgdGltZSBhdCB3aGljaCB0aGUgY2xpZW50IHNob3VsZCBjb250YWN0IHRoZQ0K ICAgc2VydmVyIHRvIGV4dGVuZCB0aGUgbGlmZXRpbWVzIG9uIGFzc2lnbmVkIGxlYXNlcyB0aHJv dWdoIHRoZSBUMSBhbmQNCiAgIFQyIHBhcmFtZXRlcnMgYXNzaWduZWQgdG8gYW4gSUEuICBIb3dl dmVyLCBhcyB0aGUgY2xpZW50IFJlbmV3cy8NCiAgIFJlYmluZHMgYWxsIElBcyBmcm9tIHRoZSBz ZXJ2ZXIgYXQgdGhlIHNhbWUgdGltZSwgdGhlIGNsaWVudCBNVVNUDQogICBzZWxlY3QgYSBUMSBh bmQgVDIgdGltZSBmcm9tIGFsbCBJQSBvcHRpb25zLCB3aGljaCB3aWxsIGd1YXJhbnRlZQ0KICAg dGhhdCB0aGUgY2xpZW50IHdpbGwgc2VuZCBSZW5ldy9SZWJpbmQgbWVzc2FnZXMgbm90IGxhdGVy IHRoYW4gYXQgdGhlDQogICBUMS9UMiB0aW1lcyBhc3NvY2lhdGVkIHdpdGggYW55IG9mIHRoZSBj bGllbnQncyBiaW5kaW5ncyAoZWFybGllc3QNCiAgIFQxL1QyKS4NCg0KVGhlc2UgdHdvIGRvbid0 IHNlZW0gdG8gYmUgYWRkcmVzc2VkLg0KDQo+PiAtIFNlY3Rpb24gMTguMS4xDQo+PiAgcy9nbG9i YWwsIFVMQSBbUkZDNDE5M10gb3Igc2l0ZS1zY29wZWQvZ2xvYmFsLyAoc2VlIGNvbW1lbnQgb24g U2VjIA0KPj4gOC4xKQ0KDQpUaGUgcmV2aXNlZCB0ZXh0IHN0aWxsIGhhcyBhbiBpc3N1ZToNCg0K ICAgSWYgdGhlIHJlbGF5IGFnZW50IHJlY2VpdmVkIHRoZSBtZXNzYWdlIHRvIGJlIHJlbGF5ZWQg ZnJvbSBhIGNsaWVudCwNCiAgIHRoZSByZWxheSBhZ2VudCBwbGFjZXMgYSBnbG9iYWwgb3IgdW5p cXVlIGxvY2FsIFtSRkM0MTkzXSBhZGRyZXNzDQoNCiJnbG9iYWwgb3IgdW5pcXVlIGxvY2FsIiBp cyByZWR1bmRhbnQgc2luY2UgVUxBcyBhcmUgZ2xvYmFsIGFkZHJlc3NlcyAoc2NvcGUgd2lzZSku DQoNCkJWPiBTZWUgY29tbWVudCBlYXJsaWVyIGFzIEkgdGhpbmsgbWVudGlvbiBib3RoIGRvZXMg bm8gaGFybSBhbmQgaGVscHMgdG8gY2xhcmlmeSB0aGF0IGl0IHdvdWxkIGJlIGVpdGhlci4NCg0K Pj4gLSBTZWN0aW9uIDE4LjEuMg0KPj4gcy9nbG9iYWwgb3Igc2l0ZS1zY29wZWQvZ2xvYmFsLyAo c2VlIGFib3ZlKQ0KDQpTYW1lIGhlcmUuDQoNCkJWPiBTZWUgY29tbWVudCBlYXJsaWVyIGFzIEkg dGhpbmsgbWVudGlvbiBib3RoIGRvZXMgbm8gaGFybSBhbmQgaGVscHMgdG8gY2xhcmlmeSB0aGF0 IGl0IHdvdWxkIGJlIGVpdGhlci4NCg0KPj4gLSBTZWN0aW9uIDE5LjQNClsuLi5dDQo+PiBUaGlz IHN0YXRlbWVudCBub3cgc291bmRzIGF3a3dhcmQgc2luY2UgdGhpcyBpcyBub3cgdGhlIG9ubHkg ZGVmaW5lZCANCj4+IGF1dGhlbnRpY2F0aW9uIHByb3RvY29sLiAoc2VlIGFsc28gY29tbWVudCBv biBTZWN0aW9uDQo+PiAxNy4yLjIpDQoNClRoZXJlIGRvZXNuJ3Qgc2VlbSB0byBiZSBhbnkgY2hh bmdlIHRvIGFkZHJlc3MgdGhpcyBwb2ludC4NCg0KQlY+IFdoaWxlIGl0IGRvZXMgc291bmQgYSBi aXQgYXdrd2FyZCwgd2UgbGVmdCB0aGlzIGluIGdpdmVuIHNlREhDUHY2IHdvcmsgYXMgdGhlcmUg d291bGQgYmUgbGl0dGxlIHBvaW50IGluIHVzaW5nIFJLQVAgaWYgdGhhdCB3YXMgdXNlZC4gV2Ug Y2FuIHJlbW92ZSAidGhlIGNsaWVudCBhbmQgc2VydmVyIGFyZSBub3QgdXNpbmcgYW55IG90aGVy IGF1dGhlbnRpY2F0aW9uIHByb3RvY29sIiBhbmQgYXNzdW1lIHRoZSBzZURIQ1B2NiB3aWxsIG1h a2UgdGhpcyBjbGVhci4NCg0KPj4gLSBTZWN0aW9uIDIwLjcNCj4+ICAgZW5jYXBzdWxhdGVkIGlu IHRoZSBjb250YWluZXIgTVVTVCBOT1QgYnkgaW4gdGhlIE9wdGlvbiBSZXF1ZXN0LCANCj4+IHNl ZSAgcy9PcHRpb24gUmVxdWVzdC9PcHRpb24gUmVxdWVzdCBvcHRpb24vDQoNCidvcHRpb24nIChh ZnRlciAnUmVxdWVzdCcpIGlzIHN0aWxsIG1pc3NpbmcuDQoNCkJWPiBPSywgdGhpcyBtdXN0IGhh dmUganVzdCBiZWVuIG1pc3NlZC4NCg0KPj4gLSBTZWN0aW9uIDIwLjIyDQpbLi4uXQ0KPj4gVGhp cyBjaG9pY2Ugb2YgdmFsaWQvcHJlZmVycmVkIGxpZmV0aW1lIGluIGFuIElBIHByZWZpeCBhbmQg dGhlDQo+PiAocG9zc2libGUpIHJlbGF0aW9uc2hpcCBiZXR3ZWVuIHRoZW0gYW5kIHRob3NlIGxp ZmV0aW1lcyBhZHZlcnRpc2VkIA0KPj4gaW4gdGhlIGRlbGVnYXRlZCBzaXRlIGRvIG5vdCBtYWtl IHBlcmZlY3Qgc2Vuc2UgdG8gbWUuIFsuLi5dDQoNCkkgZG9uJ3QgdGhpbmsgdGhlIHJldmlzZWQg dmVyc2lvbiBhZGRyZXNzZXMgdGhlIG1haW4gcG9pbnQuICBUaGUgbmV3IHRleHQgc2ltcGx5IGF2 b2lkcyBzYXlpbmcgc3BlY2lmaWNzIGFib3V0IHRoZXNlIGxpZmV0aW1lcywgYnV0IHRoZW4gaXQn cyBldmVuIG1vcmUgdW5jbGVhciBhYm91dCB3aGF0IHRoZXNlIGxpZmV0aW1lcyBhcmUgKGVzcGVj aWFsbHkgdGhlIHByZWZlcnJlZCBsaWZldGltZSkuDQoNCkJWPiBVbmxlc3MgeW91IHByb3ZpZGUg dGV4dCwgSSB0aGluayB3ZSdsbCBsZWF2ZSB0aGlzIGFsb25lIGFzIG1lbnRpb25lZCBlYXJsaWVy IHdlIGZlZWwgdGhhdCB0aGlzIGRvY3VtZW50IGlzIG5vdCB0aGUgb25lIHRoYXQgc2hvdWxkIGRl c2NyaWJlIGhvdyB0aGVzZSBsaWZldGltZXMgYXJlIHRvIGJlIHVzZWQuDQoNCj4+IC0gU2VjdGlv biAyMC4yMw0KWy4uLl0NCj4+IFRoZSBleHBlY3RlZCB1c2FnZSBpcyBub3QgdmVyeSBjbGVhciB0 byBtZSBoZXJlLiAgSXMgaXQgaW50ZW5kZWQgdG8gDQo+PiBiZSB1c2VkIGZvciBBZHZlcnRpc2Ug YW5kIGFwcGx5IHRoZSB2YWx1ZSB0byB0aGUgb25nb2luZyANCj4+IFNvbGljaXQtQWR2ZXJ0aXNl IGV4Y2hhbmdlPyAgT3IgaXMgaXQgbWFpbmx5IGludGVuZGVkIHRvIGJlIHVzZWQgZm9yIA0KPj4g YSBwb3NzaWJsZSBzdWJzZXF1ZW50IHJlc3RhcnQgb2YgYSBESENQdjYgc2Vzc2lvbj8NCg0KSSBn dWVzcyBpdCB3YXMgc3VwcG9zZWQgdG8gYmUgYWRkcmVzc2VkIGJ5IHRoZSBuZXdseSBhZGRlZCBw YXJhZ3JhcGggYXQgdGhlIGVuZCBvZiB0aGUgc2VjdGlvbjoNCg0KICAgVGhlIHJlcXVpcmVtZW50 IGZvciB0aGUgY2xpZW50IHRvIHJlcXVlc3QgU09MX01BWF9SVCBzZXJ2ZXMgdHdvDQogICBwdXJw b3Nlcy4gIEZpcnN0LCBpdCBkaXN0aW5ndWlzaGVzIGJldHdlZW4gbGVnYWN5IGFuZCBtb2Rlcm4g Y2xpZW50cy4NCiAgIFNlY29uZCwgaXQgYWxsb3dzIG1vZGVybiBjbGllbnRzIHRvIHRha2UgYWR2 YW50YWdlIG9mIHRoZQ0KICAgY29uZmlndXJhYmxlIFNPTF9NQVhfUlQgdmFsdWVzLCBldmVuIGlm IHRoZSBzZXJ2ZXIgaXMgYSBsZWdhY3kgb25lLg0KDQpvZiB3aGljaCBJIGRvbid0IHVuZGVyc3Rh bmQgdGhlIHNlY29uZCBwdXJwb3NlOiBpZiB0aGUgc2VydmVyIGlzIGxlZ2FjeSwgaG93IHRoZSBj bGllbnQgY2FuIGJlbmVmaXQgZnJvbSB0aGUgb3B0aW9uPw0KDQpCVj4gSSdtIG5vdCBzdXJlIHdo eSB3ZSB3b3VsZCB3YW50IHRoaXMgcGFyYWdyYXBoIGF0IGFsbC4gU28gSSB0aGluayBiZXN0IHRv IGp1c3QgcmVtb3ZlIGl0Lg0KQlY+IFlvdSBvcmlnaW5hbCBxdWVzdGlvbiB3YXMgSSB0aGluayBh Ym91dCB3aHkgU09MX01BWF9SVCBNVVNUIGJlIGluIE9STy4gSXQgTVVTVCBiZSBhcyBwZXIgUkZD IDcwODMgc28gdGhhdCBjbGllbnRzIGNhbiBnZXQgdXBkYXRlZCBTT0xfTUFYX1JUIHZhbHVlcy4g QW5kLCB5ZXMsIHRoZSBpZGVhIGlzIHRoYXQgdGhlIEFkdmVydGlzZSB3aXRoIHRoZSBTT0xfTUFY X1JUIHZhbHVlIGlzIHVzZWQgKGV2ZW4gaWYgaXQgb2ZmZXJzIG5vIGxlYXNlcykgc28gdGhhdCB0 aGUgY2xpZW50IGFwcGxpZXMgdGhpcyB2YWx1ZSBmb3IgYW55IGZ1dHVyZSByZXF1ZXN0cy4gSSBk b24ndCBzZWUgdGhlIG5lZWQgZm9yIHRoaXMgdG8gYmUgc3BlbGxlZCBvdXQ/DQoNCi0tDQpKSU5N RUksIFRhdHV5YQ0K From nobody Mon May 29 15:20:06 2017 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CAB412945A for ; Mon, 29 May 2017 15:20:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 ITbwVauIw375 for ; Mon, 29 May 2017 15:20:00 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3AAE01270A3 for ; Mon, 29 May 2017 15:20:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=39672; q=dns/txt; s=iport; t=1496096400; x=1497306000; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=l2ulDMJ5HDQ/mJUZcjYJtxdYwTRznr9PDmGX6xQCtnQ=; b=LTG2TZXrJMSBZK6aVq6Blvoqq0Zi9FP1O1vhjPD6/sfFUdq8Mm3xKeuS 96nAvJad+FRZ26ukux4q7fqE9ICcNBOLsgg4Cdacva89Fmi9Dd2YIs07u H5bdFMg1m0hAMo5BSKW6hOC5WsWOxYeBZ8gYXiNyJhMxY3yem6lk5AJ5/ I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CYAAA+nixZ/5hdJa1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgm5nYoENB4VxiBKRZogpjVCCDyeCR4FcgVoCglk/GAECAQEBAQE?= =?us-ascii?q?BAWsdC4UYAQEBAQECLUwQAgEIEQQBASEBBgchERQJCAEBBA4FCIk+TAMVEK4Zh?= =?us-ascii?q?ycNhBEBAQEBAQEBAQEBAQEBAQEBAQEBAQEYBYhBgx+BPYEbTYEqBEyFPAWJTpQ?= =?us-ascii?q?aOwGHH4cwhE+CD4Fig1qIeIE9izKJGwEfOEw+dBUcKoRKORyBY3YBAQEBhzgGg?= =?us-ascii?q?SqBDQEBAQ?= X-IronPort-AV: E=Sophos;i="5.38,415,1491264000"; d="scan'208,217";a="433075815" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 29 May 2017 22:19:56 +0000 Received: from XCH-RCD-004.cisco.com (xch-rcd-004.cisco.com [173.37.102.14]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id v4TMJuFS022239 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 29 May 2017 22:19:56 GMT Received: from xch-aln-003.cisco.com (173.36.7.13) by XCH-RCD-004.cisco.com (173.37.102.14) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 29 May 2017 17:19:55 -0500 Received: from xch-aln-003.cisco.com ([173.36.7.13]) by XCH-ALN-003.cisco.com ([173.36.7.13]) with mapi id 15.00.1210.000; Mon, 29 May 2017 17:19:55 -0500 From: "Bernie Volz (volz)" To: "dhcwg@ietf.org" CC: Ralph Droms Thread-Topic: WGLC for draft-ietf-dhc-rfc3315bis-08 - Respond by May 30th, 2017 Thread-Index: AdLI0aZmS0Xgn7D6S1m3YZ8hZorkbQP683mQ Date: Mon, 29 May 2017 22:19:55 +0000 Message-ID: <609fa1196113448dbffd5c4efeee21e1@XCH-ALN-003.cisco.com> References: <8418750467ae490ea50e342380a565be@XCH-ALN-003.cisco.com> In-Reply-To: <8418750467ae490ea50e342380a565be@XCH-ALN-003.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.98.1.196] Content-Type: multipart/alternative; boundary="_000_609fa1196113448dbffd5c4efeee21e1XCHALN003ciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [dhcwg] WGLC for draft-ietf-dhc-rfc3315bis-08 - Respond by May 30th, 2017 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 May 2017 22:20:04 -0000 --_000_609fa1196113448dbffd5c4efeee21e1XCHALN003ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi: I have reviewed the document and while there are some minor issues, I did n= ot find anything major. Therefore, I do support this document moving forwar= d (once the minor issues are corrected). Most of my issues are minor typos or wording improvements and I suspect Kim= and/or Jinmei's review got most of them, so I will not waste the time to d= ocument them (I will apply the changes to the XML in the GitHub repository = soon). Here are other comments which might require some discussion (at leas= t among the co-authors): [Page numbers are based on https://tools.ietf.org/pdf/draft-ietf-dhc-rfc331= 5bis-08.pdf.] Page 25, section 8: We don't define the "size" of the msg-type and transact= ion-id fields; might be worth clarifying these (1-octet and 3-octets, respe= ctively). Page 27, section 9.1: Same as above, msg-type (1-octet), hop-count (1-octet= ), link-address/peer-address (16-octets). Page 44, section 16.11: "the message does not include DHCP authentication .= ..", should we explicitly say RKAP or leave general? We might also want to = just say uses RKAP or some other (yet to be developed, such as ) authentication? Page 44, section 17: What does this 1 paragarph section intend to say/mean?= ("Client's behavior is different depending on the purpose of the configura= tion.") Can we drop it? Should we say something else/more? Page 45, section 8 (Kim mentioned this): There's a bunch of text duplicated= in this section (more than just the list). I do think "The client has many= " and the list following should be removed. I also wonder if the later para= graph (The client is responsible for creating IAs ...) should be moved up a= s part of the Solicit exchange (but it would need to be edited/merged in to= that earlier material). The duplicated instance of "A server may initiate = a message exchange" should be dropped. Page 50, section 18.2 (last paragraph): The "and duplicate responses by ser= vers" doesn't make any sense in this regard. Unicast can only be used for i= nstances where a single server is being addressed so it makes no sense to s= ay this. Page 51,section 18.2.1: The "after a power outage" is technically wrong as = it should be "after recovery from a power outage"? We should double check i= f used elsewhere and correct. Page 57, section 18.2.4 (last paragraph): So this says "If the terminated R= enew exchange was not initiated as a result of receiving a Reconfigure mess= age, the client begins Rebind message exchange...". But isn't this true eve= n it was initiate by receiving a Reconfigure? The Renew is terminated at (e= arlist) T2 and a Rebind would start then anyway? This doesn't make sense to= me. I think we should just drop the "was not initiated as a result of rece= iving a Reconfigure message"? Or what does happen in that case that is diff= erent? Page 63, section 18.2.10: (Top of page paragraph) - "The client resends the= original message using multicast". So should we qualify this to only happe= n if the client was using unicast (otherwise a storm could occur if "server= " sends use Multicast and client retransmits using multicast)? Other option= might be to say that retransmission doesn't happen until normal timer expi= res? Perhaps we can let client implementers chose either one depending on w= hat's easier to implement for them? Page 63, section 18.2.10: (2nd to last paragraph of section) - "This behavi= or does not apply to other IA containers, and their processing is described= in detail on other parts of this document.". I'm not exactly sure where th= at is described. Could we add references? Or was this intended to reference= other documents that might describe containers? Page 67, section 18.2.11: (top of page) "Subsequent Reconfigure messages ca= use the client to initiate a new exchange." Subsequent here is a bit confus= ing since the text preceding just said "the client MUST ignore any addition= al Reconfigure messages until the exchange is complete". Perhaps we should = change subsequent to "After the exchange is complete, ..."? Page 68, section 18.3: (2nd to last paragraph on page) I think we can say "= These Advertise and Reply messages MUST" (instead of just "This reply")? Page 68, section 18.3 (top of page paragraph) I think "reply message" shoul= d be "response message" (that was used on previous page). Page 68, section 18.3 (1st full paragraph, end) I think the printing and ne= w software examples probably aren't that hot? DHCPv6 has no printing option= s so why would printing impact client configuration. And, while software mi= ght be OK given the BOOTFILE options, but it seems unlikely. Perhaps we jus= t say when "other configuration options are updated, perhaps because server= s are moved, added, or removed" or something more general? Page 78 & 80, sections 18.3.9, 18.3.11: I suggest cleaning this up a bit as= follows: - Change 18.3.9 title to remove transmission (so just "Creation of= Advertise Messages") - Change 18.3.9 to remove the last two paragarphs (perhaps replace= with text to say "Transmission of the Advertise message is described in th= e next section.") - Change 18.3.10 title to "Transmission of Advertise and Reply Mes= sages" - Change text in 18.3.10 from using "Reply" to "Advertise or Reply= ". - Add a reference to section 19.3 as that talks about how the serv= er should response. This is probably better reference than just to 21.10 (w= hich could be moved to 19.3). Pages 85 & 86, sections 20.2 and 20.3 - Merge these as we could just remove= the section break and the first paragraph of 20.3. Page 95, section 21.6 - Drop the last sentence of first paragraph; seems br= oken. Page 117, section 21.24 (also 118 and 21.25): Replace "in the main body of = the message to client" with "top-level option"? We have "top-level option" = in terminology section. Page 121, section 24: Remove "IANA is requested to add a column to the DHCP= v6 Option table" as next paragraph asks them to add two columns and this sh= ould be been deleted. Page 136, Appendix B: The "Auth." Option was incorrectly marked as being us= ed in an Information-Request, but it should have been in the Reconfigure (1= line earlier). So, this needs to be moved "up". - Bernie From: dhcwg [mailto:dhcwg-bounces@ietf.org] On Behalf Of Bernie Volz (volz) Sent: Tuesday, May 09, 2017 10:53 AM To: dhcwg@ietf.org Cc: Ralph Droms Subject: [dhcwg] WGLC for draft-ietf-dhc-rfc3315bis-08 - Respond by May 30t= h, 2017 Hello: The co-authors believe that all of the issues reported for the last August = WGLC on draft-ietf-dhc-rfc3315bis-05 have now been resolved. But, because o= f the large number of changes, the DHC WG co-chairs feel another "WGLC" is = appropriate. Please review this document and provide your comments and whether you suppo= rt the document moving forward by May 30th, 2017. The DHC WG co-chairs will= again ask Ralph to evaluate the responses. We are doing a 3 week WGLC as t= he document is rather large and important to get right! Please see https://tools.ietf.org/html/draft-ietf-dhc-rfc3315bis-08. If you'd like to see the differences from the 05 version, use the diff tool= at https://tools.ietf.org/rfcdiff: https://tools.ietf.org//rfcdiff?url1=3Dhttps://tools.ietf.org/id/draft-ietf= -dhc-rfc3315bis-08.txt&url2=3Dhttps://tools.ietf.org/id/draft-ietf-dhc-rfc3= 315bis-05.txt The list of issues we recorded and action/assignee details are at https://d= ocs.google.com/spreadsheets/d/1c3obOwmRQDldw0u_kv85B5Q4LnjnmvUp2MmsHDGmW98 = (some additional issues are in https://trac.tools.ietf.org/group/dhcpv6bis/= report). One very recent change to highlight is https://tools.ietf.org/html/draft-ie= tf-dhc-rfc3315bis-08#section-18.2.12 - this was to address a criticism that= DHCPv6 is not responsive enough for some network configuration changes. The co-authors thank those that reviewed this document during the previous = WGLC and hope that those same reviewers (and hopefully more) will endeavor = to do one more thorough review of the document. - Tomek & Bernie --_000_609fa1196113448dbffd5c4efeee21e1XCHALN003ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi:<= /p>

 

I have reviewed the do= cument and while there are some minor issues, I did not find anything major= . Therefore, I do support this document moving forward (once the minor issu= es are corrected).

 

Most of my issues are = minor typos or wording improvements and I suspect Kim and/or Jinmei’s= review got most of them, so I will not waste the time to document them (I = will apply the changes to the XML in the GitHub repository soon). Here are other comments which might require some discuss= ion (at least among the co-authors):

 

[Page numbers are base= d on https://tools.ietf.org/pdf/draft-ietf-dhc-rfc3315bis-08.pdf.]

 

Page 25, section 8: We= don’t define the “size” of the msg-type and transaction-= id fields; might be worth clarifying these (1-octet and 3-octets, respectiv= ely).

 

Page 27, section 9.1: = Same as above, msg-type (1-octet), hop-count (1-octet), link-address/peer-a= ddress (16-octets).

 

Page 44, section 16.11= : “the message does not include DHCP authentication …”, s= hould we explicitly say RKAP or leave general? We might also want to just s= ay uses RKAP or some other (yet to be developed, such as <ref to sedhcpv6>) authentication?

 

Page 44, section 17: W= hat does this 1 paragarph section intend to say/mean? (“Client’= s behavior is different depending on the purpose of the configuration.̶= 1;) Can we drop it? Should we say something else/more?

 

Page 45, section 8 (Ki= m mentioned this): There’s a bunch of text duplicated in this section= (more than just the list). I do think “The client has many” an= d the list following should be removed. I also wonder if the later paragraph (The client is responsible for creating IAs …= ) should be moved up as part of the Solicit exchange (but it would need to = be edited/merged in to that earlier material). The duplicated instance of &= #8220;A server may initiate a message exchange” should be dropped.

 

Page 50, section 18.2 = (last paragraph): The “and duplicate responses by servers” does= n’t make any sense in this regard. Unicast can only be used for insta= nces where a single server is being addressed so it makes no sense to say this.

 

Page 51,section 18.2.1= : The “after a power outage” is technically wrong as it should = be “after recovery from a power outage”? We should double check= if used elsewhere and correct.

 

Page 57, section 18.2.= 4 (last paragraph): So this says “If the terminated Renew exchange wa= s not initiated as a result of receiving a Reconfigure message, the client = begins Rebind message exchange…”. But isn’t this true even it was initiate by receiving a Reconfigure? The Renew is te= rminated at (earlist) T2 and a Rebind would start then anyway? This doesn&#= 8217;t make sense to me. I think we should just drop the “was not ini= tiated as a result of receiving a Reconfigure message”? Or what does happen in that case that is different?

 

Page 63, section 18.2.= 10: (Top of page paragraph) – “The client resends the original = message using multicast”. So should we qualify this to only happen if= the client was using unicast (otherwise a storm could occur if “server” sends use Multicast and client retransmits u= sing multicast)? Other option might be to say that retransmission doesnR= 17;t happen until normal timer expires? Perhaps we can let client implement= ers chose either one depending on what’s easier to implement for them?

 

Page 63, section 18.2.= 10: (2nd to last paragraph of section) – “This behav= ior does not apply to other IA containers, and their processing is describe= d in detail on other parts of this document.”. I’m not exactly sure where that is described. Could we add references? Or was = this intended to reference other documents that might describe containers?<= o:p>

 

Page 67, section 18.2.= 11: (top of page) “Subsequent Reconfigure messages cause the client t= o initiate a new exchange.” Subsequent here is a bit confusing since = the text preceding just said “the client MUST ignore any additional Reconfigure messages until the exchange is complete”.= Perhaps we should change subsequent to “After the exchange is comple= te, …”?

 

Page 68, section 18.3:= (2nd to last paragraph on page) I think we can say “These= Advertise and Reply messages MUST” (instead of just “This repl= y”)?

 

Page 68, section 18.3 = (top of page paragraph) I think “reply message” should be ̶= 0;response message” (that was used on previous page).

 

Page 68, section 18.3 = (1st full paragraph, end) I think the printing and new software examples probabl= y aren’t that hot? DHCPv6 has no printing options so why would printi= ng impact client configuration. And, while software might be OK given the B= OOTFILE options, but it seems unlikely. Perhaps we just say when “other configuration options are updated, p= erhaps because servers are moved, added, or removed” or something mor= e general?

 

Page 78 & 80, sect= ions 18.3.9, 18.3.11: I suggest cleaning this up a bit as follows:

-&nb= sp;         Change 18.3.9 = title to remove transmission (so just “Creation of Advertise Messages= ”)

-&nb= sp;         Change 18.3.9 = to remove the last two paragarphs (perhaps replace with text to say “= Transmission of the Advertise message is described in the next section.R= 21;)

-&nb= sp;         Change 18.3.10= title to “Transmission of Advertise and Reply Messages”

-&nb= sp;         Change text in= 18.3.10 from using “Reply” to “Advertise or Reply”= .

-&nb= sp;         Add a referenc= e to section 19.3 as that talks about how the server should response. This = is probably better reference than just to 21.10 (which could be moved to 19= .3).

 

Pages 85 & 86, sec= tions 20.2 and 20.3 – Merge these as we could just remove the section= break and the first paragraph of 20.3.

 

Page 95, section 21.6 = – Drop the last sentence of first paragraph; seems broken.=

 

Page 117, section 21.2= 4 (also 118 and 21.25): Replace “in the main body of the message to c= lient” with “top-level option”? We have “top-level = option” in terminology section.

 

Page 121, section 24: = Remove “IANA is requested to add a column to the DHCPv6 Option table&= #8221; as next paragraph asks them to add two columns and this should be be= en deleted.

 

Page 136, Appendix B: = The “Auth.” Option was incorrectly marked as being used in an I= nformation-Request, but it should have been in the Reconfigure (1 line earl= ier). So, this needs to be moved “up”.

 

-&nb= sp;         Bernie

 

From: dhcwg [mailto:dhcwg-bounces@ietf.org] <= b>On Behalf Of Bernie Volz (volz)
Sent: Tuesday, May 09, 2017 10:53 AM
To: dhcwg@ietf.org
Cc: Ralph Droms <rdroms.ietf@gmail.com>
Subject: [dhcwg] WGLC for draft-ietf-dhc-rfc3315bis-08 - Respond by = May 30th, 2017

 

Hello:

 

The co-authors believe that all of the issues report= ed for the last August WGLC on draft-ietf-dhc-rfc3315bis-05 have now been r= esolved. But, because of the large number of changes, the DHC WG co-chairs = feel another “WGLC” is appropriate.

 

Please review this document and provide your comment= s and whether you support the document moving forward by May 30th, 2017. The DHC WG co-chairs will again ask Ralph to evaluate the response= s. We are doing a 3 week WGLC as the document is rather large and important to get right!

 

Please see https://tools.ietf.org/html/draft-ietf-dhc-rfc3315bis-08.

 

If you’d like to see the differences from the = 05 version, use the diff tool at https://tools.ietf.org/rfcdiff:

 

https://tools.ietf.org/= /rfcdiff?url1=3Dhttps://tools.ietf.org/id/draft-ietf-dhc-rfc3315bis-08.txt&= amp;url2=3Dhttps://tools.ietf.org/id/draft-ietf-dhc-rfc3315bis-05.txt

 

The list of issues we recorded and action/assignee d= etails are at https://docs.google.com/spreadsheets/d/1c3obOwmRQDldw0u_kv85B5Q4LnjnmvUp2Mm= sHDGmW98 (some additional issues are in https://trac= .tools.ietf.org/group/dhcpv6bis/report).

 

One very recent change to highlight is https://tools.ietf.org/html/draft-ietf-dhc-rfc3315bis-08#section-18.2.12 – this was to address a criticism that DHCPv6 is not responsive eno= ugh for some network configuration changes.

 

The co-authors thank those that reviewed this docume= nt during the previous WGLC and hope that those same reviewers (and hopeful= ly more) will endeavor to do one more thorough review of the document.=

 

-     &= nbsp;    Tomek & Bernie

--_000_609fa1196113448dbffd5c4efeee21e1XCHALN003ciscocom_-- From nobody Tue May 30 13:57:38 2017 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EDA3126CD8 for ; Tue, 30 May 2017 13:57:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.521 X-Spam-Level: X-Spam-Status: No, score=-14.521 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 4s8t3MPL_zCA for ; Tue, 30 May 2017 13:57:32 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 84F61129443 for ; Tue, 30 May 2017 13:57:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=28366; q=dns/txt; s=iport; t=1496177852; x=1497387452; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=WjCQ4FLfV9AW3C5bk3WyXhjWLTWGYKh+aGtkVWwSwGQ=; b=Ea6xzIT1QzyZn4amqDt28ML6yGQNP5j5/i2N672TgQzyTkCiquZgemIu jHsaemZu4GuNxM6xn8/A/OtWAfW19ADig7gS10Nth6v1u3ZKWkIAZT1rH RUcJsUtehgTmmVvGChQrYD+A7mD64+wASs3zoWEHx6RcRNX32o1UNH5Kt 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DYAADl2y1Z/5NdJa1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgm5nYoENB4NrihiRapV5gg+GJAIagjo/GAECAQEBAQEBAWsdC4U?= =?us-ascii?q?YAQEBAQMjClwCAQgRBAEBIQcDAgICMBQJCAIEEwiJPmSsIYImi08BAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEdiEGDH4E9g2KCXIJgBYk/iEWMHwGTHoIPhTyKNYkBi0w?= =?us-ascii?q?BHziBCnQVHIUtHIFjdohGgQ0BAQE?= X-IronPort-AV: E=Sophos;i="5.38,420,1491264000"; d="scan'208,217";a="431369638" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 30 May 2017 20:57:31 +0000 Received: from XCH-RCD-004.cisco.com (xch-rcd-004.cisco.com [173.37.102.14]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id v4UKvVqw014713 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Tue, 30 May 2017 20:57:31 GMT Received: from xch-aln-003.cisco.com (173.36.7.13) by XCH-RCD-004.cisco.com (173.37.102.14) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 30 May 2017 15:57:30 -0500 Received: from xch-aln-003.cisco.com ([173.36.7.13]) by XCH-ALN-003.cisco.com ([173.36.7.13]) with mapi id 15.00.1210.000; Tue, 30 May 2017 15:57:30 -0500 From: "Bernie Volz (volz)" To: "dhcwg@ietf.org" Thread-Topic: IETF-99 (Prague) Meeting Agenda Requests - due by May 28th Thread-Index: AQHSt8r0hSZfCLgt7kmWmK77CnIvAKHlxn8QgCfVqUA= Date: Tue, 30 May 2017 20:57:30 +0000 Message-ID: <823f70102d2042ef9dffeb291d1cf04c@XCH-ALN-003.cisco.com> References: <865f9e83c2d4420caf2a0999de12f787@XCH-ALN-003.cisco.com> In-Reply-To: <865f9e83c2d4420caf2a0999de12f787@XCH-ALN-003.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.131.32.244] Content-Type: multipart/alternative; boundary="_000_823f70102d2042ef9dffeb291d1cf04cXCHALN003ciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [dhcwg] IETF-99 (Prague) Meeting Agenda Requests - due by May 28th X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 May 2017 20:57:36 -0000 --_000_823f70102d2042ef9dffeb291d1cf04cXCHALN003ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGk6DQoNClRvbWVrIGFuZCBJIHdpbGwgYmUgc3VibWl0dGluZyB0aGUgdGltZSByZXF1ZXN0IG9u IFdlZG5lc2RheSBhZnRlcm5vb24hIFdlIGhhdmVu4oCZdCBoYWQgYW55b25lIHN1Z2dlc3QgYW55 IHRvcGljcyBpbiByZXNwb25zZSB0byB0aGVzZSByZXF1ZXN0cy4NCg0KVGhlIGRvY3VtZW50cyBh dCBwbGF5IGZvciB0aGUgV0cgYXJlOg0KDQpXRyBEb2N1bWVudHM6DQoNCmRyYWZ0LWlldGYtZGhj LWRoY3A0bzYtc2FkZHItb3B0LTAwICwgREhDUHY0IG92ZXIgREhDUHY2IFNvdXJjZSBBZGRyZXNz IE9wdGlvbg0KICAgICAgICAgICAgICAgIE9uZSBzZXQgb2YgY29tbWVudHMgcmVjZWl2ZWQgb24g dGhpcyBkb2N1bWVudDsgYXV0aG9ycyBsaWtlbHkgbmVlZCB0byB1cGRhdGU/DQpkcmFmdC1pZXRm LWRoYy1kaGNwdjQtZm9yY2VyZW5ldy1leHRlbnNpb25zLTAyICwgRm9yY2VyZW5ldyBSZWNvbmZp Z3VyYXRpb24gRXh0ZW5zaW9ucyBmb3IgREhDUHY0DQogICAgICAgICAgICAgICAgVGhpcyBvbmUg aXMgcGFya2VkIGZvciBub3csIHVudGlsIGF1dGhvcnMgcmVxdWVzdCBmdXJ0aGVyIGFjdGlvbi4N CmRyYWZ0LWlldGYtZGhjLWRoY3B2Ni1hZ2VudG9wdC1kZWxlZ2F0ZS0wNSAsIERIQ1B2NiBSZWxh eSBBZ2VudCBBc3NpZ25tZW50IE5vdGlmaWNhdGlvbiAoUkFBTikgT3B0aW9uDQogICAgICAgICAg ICAgICAgVGhpcyBvbmUgaXMgYXdhaXRpbmcgbW9yZSBwcm9ncmVzcyBvbiBzZURIQ1B2NjsgYnV0 IGNvbW1lbnRzIHdlbGNvbWUuIE5vIHBsYW5zIHRvIGRpc2N1c3MgYXQgSUVURi05OS4NCmRyYWZ0 LWlldGYtZGhjLXJmYzMzMTViaXMtMDggLCBEeW5hbWljIEhvc3QgQ29uZmlndXJhdGlvbiBQcm90 b2NvbCBmb3IgSVB2NiAoREhDUHY2KSBiaXMNCiAgICAgICAgICAgICAgICBUaGlzIG9uZSBpcyBp biBXR0xDLCB3aXRoIHNvbWUgY29tbWVudHMgcmVjZWl2ZWQuIFRoaXMgTUFZIGhhdmUgYSBzaG9y dCBkaXNjdXNzaW9uIGF0IElFVEYtOTkgaWYgdGhlcmUgYXJlIGlzc3VlcyB0aGF0IG5lZWQgV0cg aW5wdXQuDQpkcmFmdC1pZXRmLWRoYy1zZWRoY3B2Ni0yMSwgU2VjdXJlIERIQ1B2Ng0KICAgICAg ICAgICAgICAgIFRoZSBvbmUgbmVlZHMgdG8gYmUgcmV2aXNlZCBiYXNlZCBvbiBXR0xDIGNvbW1l bnRzIHJlY2VpdmVkLg0KDQpFeHBpcmVkIFdHIERyYWZ0Og0KDQpkcmFmdC1pZXRmLWRoYy1kaGNw djYteWFuZy0wMywgWUFORyBEYXRhIE1vZGVsIGZvciBESENQdjYgQ29uZmlndXJhdGlvbg0KICAg ICAgICAgICAgICAgIEV4cGVjdGluZyB1cGRhdGU/Pw0KDQpSZWxhdGVkIEludGVybmV0LURyYWZ0 czoNCg0KZHJhZnQtbGl1LWRoYy1kaGNwLXlhbmctbW9kZWwtMDYgLCBZYW5nIERhdGEgTW9kZWwg Zm9yIERIQ1AgUHJvdG9jb2wNCiAgICAgICAgICAgICAgICBUaGlzIGlzIGF3YWl0aW5nIG1vcmUg cHJvZ3Jlc3Mgb24gREhDUHY2IFlBTkcgTW9kZWwuDQpkcmFmdC1uYWxsdXJpLWRoYy1kaGNwdjYt bHdtMm0tYm9vdHN0cmFwLW9wdGlvbnMtMDIsIERIQ1B2NiBPcHRpb25zIGZvciBMV00yTSBib290 c3RyYXAgaW5mb3JtYXRpb24NCiAgICAgICAgICAgICAgICBOb3Qgc3VyZSBvZiBzdGF0dXM/DQpk cmFmdC1yZW4tZGhjLW1yZWRoY3B2Ni0wMCAsIE11bHRpLXJlcXVpcmVtZW50IEV4dGVuc2lvbnMg Zm9yIER5bmFtaWMgSG9zdCBDb25maWd1cmF0aW9uIFByb3RvY29sIGZvciBJUHY2IChESENQdjYp DQogICAgICAgICAgICAgICAgVGhpcyBvbmUgZGlkIG5vdCByZWNlaXZlIGZhdm9yYWJsZSBjb21t ZW50cyBhdCBJRVRGLTk4LiBOb3Qgc3VyZSBvZiBuZXh0IHN0ZXBzLg0KDQoNCi0gICAgICAgICAg QmVybmllDQoNCkZyb206IGRoY3dnIFttYWlsdG86ZGhjd2ctYm91bmNlc0BpZXRmLm9yZ10gT24g QmVoYWxmIE9mIEJlcm5pZSBWb2x6ICh2b2x6KQ0KU2VudDogRnJpZGF5LCBNYXkgMDUsIDIwMTcg ODoyOSBBTQ0KVG86IGRoY3dnQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW2RoY3dnXSBJRVRGLTk5 IChQcmFndWUpIE1lZXRpbmcgQWdlbmRhIFJlcXVlc3RzIC0gZHVlIGJ5IE1heSAyOHRoDQoNCkhp Og0KDQpKdXN0IGEgcmVtaW5kZXIgdG8gc3VibWl0IGFnZW5kYSByZXF1ZXN0cy4NCg0KDQotICAg ICAgICAgIEJlcm5pZQ0KDQpGcm9tOiBkaGN3ZyBbbWFpbHRvOmRoY3dnLWJvdW5jZXNAaWV0Zi5v cmddIE9uIEJlaGFsZiBPZiBCZXJuaWUgVm9seiAodm9seikNClNlbnQ6IE1vbmRheSwgQXByaWwg MTcsIDIwMTcgNjozNiBQTQ0KVG86IGRoY3dnQGlldGYub3JnDQpTdWJqZWN0OiBbZGhjd2ddIElF VEYtOTkgKFByYWd1ZSkgTWVldGluZyBBZ2VuZGEgUmVxdWVzdHMgLSBkdWUgYnkgTWF5IDI4dGgN Cg0KSGk6DQoNCklmIHlvdSBoYXZlIGFueSBpbnRlcmVzdCBpbiBwcmVzZW50aW5nIHRvIHRoZSBE SEMgd2cgZHVyaW5nIElFVEYtOTksIHBsZWFzZSBzdWJtaXQgYSByZXF1ZXN0IGJ5IFR1ZXNkYXks IE1heSAyN3RoLiBUb21layAmIEkgbXVzdCBzdWJtaXQgYSByZXF1ZXN0IGZvciBhIHNlc3Npb24g YnkgSnVuZSAybmQgZGVhZGxpbmUuDQpBcyBpbiB0aGUgcGFzdCwgcGxlYXNlIHByb3ZpZGU6DQpU aXRsZSBPZiBTZXNzaW9uOg0KUHJlc2VudGVyOg0KUmVsYXRlZCBEcmFmdHM6DQpUaW1lIFJlcXVp cmVkOg0KUHVycG9zZSBvZiBTZXNzaW9uOg0KV2UgZG8gd2FudCB0byByZW1pbmQgdGhvc2UgcmVx dWVzdGluZyB0aW1lIHRoYXQgeW91IHNob3VsZCBmb2N1cyBvbiBkaXNjdXNzaW5nIGtleSBpc3N1 ZXMgdGhhdCBuZWVkIHJlc29sdXRpb24gdG8gbW92ZSBhIGRyYWZ0IGZvcndhcmQgb3IgdG8gaW50 cm9kdWNlIHBvdGVudGlhbCBuZXcgd29yay4NCldoaWxlIHdlIGFyZSBzdGlsbCAzIG1vbnRocyBm cm9tIHRociBtZWV0aW5nLCB0aGUgc2Vzc2lvbiByZXF1ZXN0cyBoYXZlIG9wZW5lZCB1cCBhbmQg d2UgbmVlZCB0byBrbm93IGFwcHJveGltYXRlbHkgaG93IG11Y2ggdGltZSB0byByZXF1ZXN0Lg0K LSBCZXJuaWUgJiBUb21law0K --_000_823f70102d2042ef9dffeb291d1cf04cXCHALN003ciscocom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1 IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg Um9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9 DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpw Lk1zb0xpc3RQYXJhZ3JhcGgsIGxpLk1zb0xpc3RQYXJhZ3JhcGgsIGRpdi5Nc29MaXN0UGFyYWdy YXBoDQoJe21zby1zdHlsZS1wcmlvcml0eTozNDsNCgltYXJnaW4tdG9wOjBpbjsNCgltYXJnaW4t cmlnaHQ6MGluOw0KCW1hcmdpbi1ib3R0b206MGluOw0KCW1hcmdpbi1sZWZ0Oi41aW47DQoJbWFy Z2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRp bWVzIE5ldyBSb21hbiIsc2VyaWY7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5 cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6 IzFGNDk3RDt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1y ZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdE O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQt c2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0K CW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3Bh Z2U6V29yZFNlY3Rpb24xO30NCi8qIExpc3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJe21z by1saXN0LWlkOjE1NjY2NDQ2OTI7DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3Qt dGVtcGxhdGUtaWRzOi0xNDg5MjMwMjI4IC0xODQ5Njg1MDEyIDY3Njk4NjkxIDY3Njk4NjkzIDY3 Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzO30NCkBs aXN0IGwwOmxldmVsMQ0KCXttc28tbGV2ZWwtc3RhcnQtYXQ6MDsNCgltc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6LTsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4y NWluOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCW1zby1mYXJlYXN0LWZv bnQtZmFtaWx5OkNhbGlicmk7DQoJbXNvLWJpZGktZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21h biI7fQ0KQGxpc3QgbDA6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsN Cgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1p bHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1m b3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4y NWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDQNCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDUN Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJ bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBs aXN0IGwwOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxl dmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2lu Z2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxs ZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9u dC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZv cm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9u ZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWlu Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWw5DQoJe21zby1s ZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxl dmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDENCgl7 bXNvLWxpc3QtaWQ6MTgzOTI2OTc1NDsNCgltc28tbGlzdC10eXBlOmh5YnJpZDsNCgltc28tbGlz dC10ZW1wbGF0ZS1pZHM6MTY2NTA2MTM3NiAtMTQ2NTY0NDkzNiA2NzY5ODY5MSA2NzY5ODY5MyA2 NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5Mzt9DQpA bGlzdCBsMTpsZXZlbDENCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1s ZXZlbC10ZXh0Oi07DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ2Fs aWJyaSIsc2Fucy1zZXJpZjsNCgltc28tZmFyZWFzdC1mb250LWZhbWlseTpDYWxpYnJpOw0KCW1z by1iaWRpLWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iO30NCkBsaXN0IGwxOmxldmVsMg0K CXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCglt c28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxp c3QgbDE6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2 ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5n ZGluZ3M7fQ0KQGxpc3QgbDE6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxl dDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250 LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDE6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9y bWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25l Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47 DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMTpsZXZlbDYNCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMTpsZXZl bDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+C tzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlz dCBsMTpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZl bC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmll ciBOZXciO30NCkBsaXN0IGwxOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxs ZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9u dC1mYW1pbHk6V2luZ2RpbmdzO30NCm9sDQoJe21hcmdpbi1ib3R0b206MGluO30NCnVsDQoJe21h cmdpbi1ib3R0b206MGluO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8 bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFb ZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0i ZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91 dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSIj MDU2M0MxIiB2bGluaz0iIzk1NEY3MiI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkhpOjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+VG9tZWsgYW5kIEkgd2lsbCBi ZSBzdWJtaXR0aW5nIHRoZSB0aW1lIHJlcXVlc3Qgb24gV2VkbmVzZGF5IGFmdGVybm9vbiEgV2Ug aGF2ZW7igJl0IGhhZCBhbnlvbmUgc3VnZ2VzdCBhbnkgdG9waWNzIGluIHJlc3BvbnNlIHRvIHRo ZXNlIHJlcXVlc3RzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+ VGhlIGRvY3VtZW50cyBhdCBwbGF5IGZvciB0aGUgV0cgYXJlOjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+V0cgRG9jdW1lbnRzOjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+ZHJhZnQtaWV0Zi1kaGMtZGhjcDRvNi1zYWRkci1vcHQt MDAgLCBESENQdjQgb3ZlciBESENQdjYgU291cmNlIEFkZHJlc3MgT3B0aW9uPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMx RjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBPbmUgc2V0IG9mIGNvbW1l bnRzIHJlY2VpdmVkIG9uIHRoaXMgZG9jdW1lbnQ7IGF1dGhvcnMgbGlrZWx5IG5lZWQgdG8gdXBk YXRlPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojMUY0OTdEIj5kcmFmdC1pZXRmLWRoYy1kaGNwdjQtZm9yY2VyZW5ldy1l eHRlbnNpb25zLTAyICwgRm9yY2VyZW5ldyBSZWNvbmZpZ3VyYXRpb24gRXh0ZW5zaW9ucyBmb3Ig REhDUHY0PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyBUaGlzIG9uZSBpcyBwYXJrZWQgZm9yIG5vdywgdW50aWwgYXV0aG9ycyByZXF1ZXN0IGZ1cnRo ZXIgYWN0aW9uLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5kcmFmdC1pZXRmLWRoYy1kaGNwdjYtYWdlbnRv cHQtZGVsZWdhdGUtMDUgLCBESENQdjYgUmVsYXkgQWdlbnQgQXNzaWdubWVudCBOb3RpZmljYXRp b24gKFJBQU4pIE9wdGlvbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgVGhpcyBvbmUgaXMgYXdhaXRpbmcgbW9yZSBwcm9ncmVzcyBvbiBzZURIQ1B2 NjsgYnV0IGNvbW1lbnRzIHdlbGNvbWUuIE5vIHBsYW5zIHRvIGRpc2N1c3MgYXQgSUVURi05OS48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6IzFGNDk3RCI+ZHJhZnQtaWV0Zi1kaGMtcmZjMzMxNWJpcy0wOCAsIER5bmFtaWMg SG9zdCBDb25maWd1cmF0aW9uIFByb3RvY29sIGZvciBJUHY2IChESENQdjYpIGJpczxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgVGhpcyBvbmUgaXMg aW4gV0dMQywgd2l0aCBzb21lIGNvbW1lbnRzIHJlY2VpdmVkLiBUaGlzIE1BWSBoYXZlIGEgc2hv cnQgZGlzY3Vzc2lvbiBhdCBJRVRGLTk5IGlmIHRoZXJlIGFyZSBpc3N1ZXMgdGhhdCBuZWVkIFdH IGlucHV0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5kcmFmdC1pZXRmLWRoYy1zZWRoY3B2Ni0yMSwgU2Vj dXJlIERIQ1B2NjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgVGhlIG9uZSBuZWVkcyB0byBiZSByZXZpc2VkIGJhc2VkIG9uIFdHTEMgY29tbWVudHMg cmVjZWl2ZWQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5FeHBp cmVkIFdHIERyYWZ0OjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+ ZHJhZnQtaWV0Zi1kaGMtZGhjcHY2LXlhbmctMDMsIFlBTkcgRGF0YSBNb2RlbCBmb3IgREhDUHY2 IENvbmZpZ3VyYXRpb248bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IEV4cGVjdGluZyB1cGRhdGU/PzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6IzFGNDk3RCI+UmVsYXRlZCBJbnRlcm5ldC1EcmFmdHM6PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Qi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5kcmFmdC1saXUtZGhjLWRoY3AteWFuZy1tb2RlbC0w NiAsIFlhbmcgRGF0YSBNb2RlbCBmb3IgREhDUCBQcm90b2NvbDxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgVGhpcyBpcyBhd2FpdGluZyBtb3JlIHBy b2dyZXNzIG9uIERIQ1B2NiBZQU5HIE1vZGVsLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5kcmFmdC1uYWxs dXJpLWRoYy1kaGNwdjYtbHdtMm0tYm9vdHN0cmFwLW9wdGlvbnMtMDIsIERIQ1B2NiBPcHRpb25z IGZvciBMV00yTSBib290c3RyYXAgaW5mb3JtYXRpb248bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IE5vdCBzdXJlIG9mIHN0YXR1cz88bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 IzFGNDk3RCI+ZHJhZnQtcmVuLWRoYy1tcmVkaGNwdjYtMDAgLCBNdWx0aS1yZXF1aXJlbWVudCBF eHRlbnNpb25zIGZvciBEeW5hbWljIEhvc3QgQ29uZmlndXJhdGlvbiBQcm90b2NvbCBmb3IgSVB2 NiAoREhDUHY2KTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgVGhpcyBvbmUgZGlkIG5vdCByZWNlaXZlIGZhdm9yYWJsZSBjb21tZW50cyBhdCBJRVRG LTk4LiBOb3Qgc3VyZSBvZiBuZXh0IHN0ZXBzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9InRl eHQtaW5kZW50Oi0uMjVpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZvMyI+PCFbaWYgIXN1cHBvcnRM aXN0c10+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxzcGFuIHN0eWxlPSJtc28tbGlz dDpJZ25vcmUiPi08c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4m cXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojMUY0OTdEIj5CZXJuaWU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQg I0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp ZiI+IGRoY3dnIFttYWlsdG86ZGhjd2ctYm91bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBP ZiA8L2I+QmVybmllIFZvbHogKHZvbHopPGJyPg0KPGI+U2VudDo8L2I+IEZyaWRheSwgTWF5IDA1 LCAyMDE3IDg6MjkgQU08YnI+DQo8Yj5Ubzo8L2I+IGRoY3dnQGlldGYub3JnPGJyPg0KPGI+U3Vi amVjdDo8L2I+IFJlOiBbZGhjd2ddIElFVEYtOTkgKFByYWd1ZSkgTWVldGluZyBBZ2VuZGEgUmVx dWVzdHMgLSBkdWUgYnkgTWF5IDI4dGg8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+SGk6PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5KdXN0IGEgcmVtaW5kZXIgdG8gc3Vi bWl0IGFnZW5kYSByZXF1ZXN0cy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0LWluZGVu dDotLjI1aW47bXNvLWxpc3Q6bDEgbGV2ZWwxIGxmbzIiPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3Jl Ij4tPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwv c3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3 RCI+QmVybmllPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEg MS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBkaGN3 ZyBbbWFpbHRvOmRoY3dnLWJvdW5jZXNAaWV0Zi5vcmddDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPkJl cm5pZSBWb2x6ICh2b2x6KTxicj4NCjxiPlNlbnQ6PC9iPiBNb25kYXksIEFwcmlsIDE3LCAyMDE3 IDY6MzYgUE08YnI+DQo8Yj5Ubzo8L2I+IGRoY3dnQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8 L2I+IFtkaGN3Z10gSUVURi05OSAoUHJhZ3VlKSBNZWV0aW5nIEFnZW5kYSBSZXF1ZXN0cyAtIGR1 ZSBieSBNYXkgMjh0aDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5IaTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+SWYgeW91IGhhdmUgYW55IGludGVyZXN0IGluIHByZXNlbnRpbmcgdG8gdGhl IERIQyB3ZyBkdXJpbmcgSUVURi05OSwgcGxlYXNlIHN1Ym1pdCBhIHJlcXVlc3QgYnkgVHVlc2Rh eSwgTWF5IDI3dGguIFRvbWVrICZhbXA7IEkgbXVzdCBzdWJtaXQgYSByZXF1ZXN0IGZvciBhIHNl c3Npb24gYnkgSnVuZSAybmQgZGVhZGxpbmUuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkFzIGluIHRoZSBwYXN0LCBwbGVhc2UgcHJvdmlkZTo8 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+VGl0bGUgT2YgU2Vzc2lvbjo8 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+UHJlc2VudGVyOjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5SZWxhdGVkIERyYWZ0czo8bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+VGltZSBSZXF1aXJlZDo8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+UHVycG9zZSBvZiBTZXNzaW9uOjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5XZSBkbyB3YW50IHRvIHJlbWluZCB0aG9zZSBy ZXF1ZXN0aW5nIHRpbWUgdGhhdCB5b3Ugc2hvdWxkIGZvY3VzIG9uIGRpc2N1c3Npbmcga2V5IGlz c3VlcyB0aGF0IG5lZWQgcmVzb2x1dGlvbiB0byBtb3ZlIGEgZHJhZnQgZm9yd2FyZCBvciB0byBp bnRyb2R1Y2UgcG90ZW50aWFsIG5ldyB3b3JrLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj5XaGlsZSB3ZSBhcmUgc3RpbGwgMyBtb250aHMgZnJvbSB0aHImbmJzcDttZWV0 aW5nLCB0aGUgc2Vzc2lvbiByZXF1ZXN0cyBoYXZlIG9wZW5lZCB1cCBhbmQgd2UgbmVlZCB0byBr bm93IGFwcHJveGltYXRlbHkgaG93IG11Y2ggdGltZSB0byByZXF1ZXN0LjxvOnA+PC9vOnA+PC9w Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi0gQmVybmllICZhbXA7IFRvbWVrPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_823f70102d2042ef9dffeb291d1cf04cXCHALN003ciscocom_-- From nobody Wed May 31 08:36:13 2017 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7174128D6F for ; Wed, 31 May 2017 08:36:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.3 X-Spam-Level: X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z_1nFjpouA5S for ; Wed, 31 May 2017 08:36:10 -0700 (PDT) Received: from mail-lf0-x230.google.com (mail-lf0-x230.google.com [IPv6:2a00:1450:4010:c07::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 BF7EC1243F6 for ; Wed, 31 May 2017 08:36:09 -0700 (PDT) Received: by mail-lf0-x230.google.com with SMTP id 99so11714171lfu.1 for ; Wed, 31 May 2017 08:36:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:references:from:to:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=5TvXqHLZqJI2zmVDoXOMz5K2Er1ja95iFk77Q9FofTo=; b=RoPNvXJ17QEjOLxL1FBezqlE92Z9AGUm1v+q/q0rtGEkqwt/f88HROAVQsjzc0TC1P SFadYvn+6er1b7RbrUW09T6alj/OuV2xp3EGXpGEa3dOhyJ6YYdTPEvwu5A6+rJ/rq6u kJXHWi1fZbiGZI0PDktYZ+YL1wS1e+sjuQz9lpG3Qmrk3nzgOr2lCOm/puyvElXEu1ht XNktbW7O4YLtSvuncbdMKZe0rrERf4wUHNjbu4ydmo/UO0MvcnGs9NQW3Bk4dCIagC2/ gkxrU1vcWdV3wcHuWRyDnXA1Gzl7+GyMymyh+4l2OGtP8N+n+nU0BbLpOOkrb5CdM2fA H5Rw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:references:from:to:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=5TvXqHLZqJI2zmVDoXOMz5K2Er1ja95iFk77Q9FofTo=; b=XbQZeTtLYFgsiLQbXn3/NJxoig8ySOI7+ixswXBlZHcH38H3QDNwlTDvxIUM9H+QPR coiv/s0nfbaShLe0GYacidDvT6/ShecMXm0WFFubPi+njTKO5c1KBHYbfwSaZTE9HPQm 0h7QFdzi093SwffOt/478EGvQHknmrpOc6D0y1nxJ44LOXA66L9DO2MyD9ExMnNGz1T4 0JNtdJYAqkqIoT+P1sgL4fkkNNiNJPZnPiU6Nsj9mO3iUC10pcs2lko785GCUD+W5CbA G4twyjDFFaPvOD8a/rhdyEuYtVj5iUo0qwQ1ogTRqC5gZK0H3GxGlRTensnVhkSqZsR8 Fn0A== X-Gm-Message-State: AODbwcC5TMcWPEpv3V2l1cZT3vul7YBOAwIvYYrVJ8/i9XoZ3kYh8lLg 0/iF+z/NQmmS20kd X-Received: by 10.46.21.68 with SMTP id 4mr8148494ljv.50.1496244967780; Wed, 31 May 2017 08:36:07 -0700 (PDT) Received: from [192.168.0.5] (109241207033.gdansk.vectranet.pl. [109.241.207.33]) by smtp.googlemail.com with ESMTPSA id 19sm3674003ljf.32.2017.05.31.08.36.06 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 31 May 2017 08:36:06 -0700 (PDT) References: From: Tomek Mrugalski To: dhcwg X-Forwarded-Message-Id: Message-ID: <166ebb54-9a71-5bf9-669b-ff7be6f65ec7@gmail.com> Date: Wed, 31 May 2017 17:36:05 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: 8bit Archived-At: Subject: [dhcwg] DHCP hackathon in Prague: SeDHCPv6 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 May 2017 15:36:12 -0000 Folks, As previously mentioned, we'll have a DHCP hackathon in Prague. As usual, the hackathon will take place on the weekend immediately before IETF (July 15-16). This time we will be focusing on SeDHCPv6. If you somehow missed all the discussions so far, the draft-ietf-dhc-sedhcpv6-21 defines Secure DHCPv6, an encrypted and possibly authenticated version of DHCPv6 protocol. The goal of this hackathon is to extend existing DHCPv6 implementations and attempt inter-operability testing for encryption and authentication. We hope to have the following implementations at various stages of maturity: * WIDE - A client code is available from earlier hackathon, back in 2015: https://github.com/jinmei/wide-dhcpv6/tree/sedhcpv6. * Cisco CNR - http://www.cisco.com/c/en/us/products/cloud-systems-management/network-registrar/index.html. * Kea - A server code is available form earlier hackathon, back in 2015. https://github.com/isc-projects/kea/tree/sedhcpv6a. Other implementations are more than welcome. Also, we're looking for volunteers to help with existing projects. It seems plausible that some of the effort during the hackathon will be spent on extending wireshark to be able to parse the encrypted traffic, assuming necessary security details (keys, certs) are provided. This work hasn't started yet, and volunteers are more than welcome. Note that although there is existing code for some implementations, it is based on a very old -08 draft. The recent -21 draft has changed substantially (in particular, mandatory encryption has been added). Here's the page for the hackathon (with links to details and registration): https://www.ietf.org/registration/MeetingWiki/wiki/99hackathon Participation in the hackathon is free, but requires registration. The best place to discuss implementation aspects would be the hackathon list. If we discover any protocol issues, those should be discussed on the DHC list. Hope to see you there! Bernie & Tomek From nobody Wed May 31 09:35:17 2017 Return-Path: X-Original-To: dhcwg@ietf.org Delivered-To: dhcwg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 122C01298BA; Wed, 31 May 2017 09:35:15 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: dhc-chairs@ietf.org, suresh.krishnan@gmail.com, volz@cisco.com, dhcwg@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.52.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149624851497.19821.16380437136816329225.idtracker@ietfa.amsl.com> Date: Wed, 31 May 2017 09:35:14 -0700 Archived-At: Subject: [dhcwg] dhc - New Meeting Session Request for IETF 99 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.22 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 May 2017 16:35:15 -0000 A new meeting session request has just been submitted by Bernie Volz, a Chair of the dhc working group. --------------------------------------------------------- Working Group Name: Dynamic Host Configuration Area Name: Internet Area Session Requester: Bernie Volz Number of Sessions: 1 Length of Session(s): 1.5 Hours Number of Attendees: 40 Conflicts to Avoid: First Priority: v6ops 6man softwire homenet Second Priority: sunset4 dnssd dnsop intarea People who must be present: Suresh Krishnan Bernie Volz Tomek Mrugalski Resources Requested: Special Requests: One co-chair is NOT able to attend Friday (must return to US early Friday AM). We are still finalizing agenda & not yet clear whether we need 90 minutes. So, OK with 60 minutes if that helps. --------------------------------------------------------- From nobody Wed May 31 09:54:08 2017 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62C12126DFB for ; Wed, 31 May 2017 09:54:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 3U4QHX_JWTQH for ; Wed, 31 May 2017 09:54:05 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6EFAC126B6D for ; Wed, 31 May 2017 09:54:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13709; q=dns/txt; s=iport; t=1496249645; x=1497459245; h=from:to:cc:subject:date:message-id:mime-version; bh=AUMFaVY0CLq3Uf4d9gqC8Q1LCTnU+cIw601lR+nkN5k=; b=VGFoORARF61ssvbjy+EL3HhZqYgL+8ik7u2skoOTJo9wO0TYQoQSsPPZ LcFRQ2MM27rBL9iECYGCw+rYt/wAp6l73j9KzDmGsvqDqh+KMylcKA/7V 75zWAxuMMK7Yhz2whUXzR5tKaXkx3FdEk47gDfhZs57FYwfUVSLyev1vW E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CYAADM9C5Z/4MNJK1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgm5nYoENB4VxiBKRb4gpiBiFOIIPJ4QjgVoCgmY/GAECAQEBAQE?= =?us-ascii?q?BAWsdC4UYAQECAykETBIBAgYRBAEBKCgRFAkJAQQOBQiJPkwDFRCuSw+HMw2EE?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBAQEBARgFiEGDH4E9gRtNgXqFPAWJTpQaOwGHH4c?= =?us-ascii?q?whE+CD4Fig1qIeIE9izKJGwEfOEw+dBVGhEqCOHYBAQEBiEKBDQEBAQ?= X-IronPort-AV: E=Sophos;i="5.39,275,1493683200"; d="scan'208,217";a="433942737" Received: from alln-core-1.cisco.com ([173.36.13.131]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 31 May 2017 16:54:04 +0000 Received: from XCH-RCD-005.cisco.com (xch-rcd-005.cisco.com [173.37.102.15]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id v4VGs4vo007036 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 31 May 2017 16:54:04 GMT Received: from xch-aln-003.cisco.com (173.36.7.13) by XCH-RCD-005.cisco.com (173.37.102.15) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 31 May 2017 11:54:03 -0500 Received: from xch-aln-003.cisco.com ([173.36.7.13]) by XCH-ALN-003.cisco.com ([173.36.7.13]) with mapi id 15.00.1210.000; Wed, 31 May 2017 11:54:03 -0500 From: "Bernie Volz (volz)" To: "dhcwg@ietf.org" CC: Ralph Droms Thread-Topic: WGLC for draft-ietf-dhc-rfc3315bis-08 - Respond by June 6th, 2017 Thread-Index: AdLaLlsd9IiMjy2OQmywHG+6QlpKqw== Importance: high X-Priority: 1 Date: Wed, 31 May 2017 16:54:03 +0000 Message-ID: <8083bab53ebb474b9fef05fea5fcbdd2@XCH-ALN-003.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.131.32.217] Content-Type: multipart/alternative; boundary="_000_8083bab53ebb474b9fef05fea5fcbdd2XCHALN003ciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [dhcwg] WGLC for draft-ietf-dhc-rfc3315bis-08 - Respond by June 6th, 2017 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 May 2017 16:54:07 -0000 --_000_8083bab53ebb474b9fef05fea5fcbdd2XCHALN003ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi: Tomek and I decided to extend the WGLC by about a week (to June 6th) in the= hopes of soliciting more feedback. Please take some time to review this document as this work is a critical pr= oduct of the DHC WG! - Bernie From: dhcwg [mailto:dhcwg-bounces@ietf.org] On Behalf Of Bernie Volz (volz) Sent: Tuesday, May 09, 2017 10:53 AM To: dhcwg@ietf.org Cc: Ralph Droms Subject: [dhcwg] WGLC for draft-ietf-dhc-rfc3315bis-08 - Respond by May 30t= h, 2017 Hello: The co-authors believe that all of the issues reported for the last August = WGLC on draft-ietf-dhc-rfc3315bis-05 have now been resolved. But, because o= f the large number of changes, the DHC WG co-chairs feel another "WGLC" is = appropriate. Please review this document and provide your comments and whether you suppo= rt the document moving forward by May 30th, 2017. The DHC WG co-chairs will= again ask Ralph to evaluate the responses. We are doing a 3 week WGLC as t= he document is rather large and important to get right! Please see https://tools.ietf.org/html/draft-ietf-dhc-rfc3315bis-08. If you'd like to see the differences from the 05 version, use the diff tool= at https://tools.ietf.org/rfcdiff: https://tools.ietf.org//rfcdiff?url1=3Dhttps://tools.ietf.org/id/draft-ietf= -dhc-rfc3315bis-08.txt&url2=3Dhttps://tools.ietf.org/id/draft-ietf-dhc-rfc3= 315bis-05.txt The list of issues we recorded and action/assignee details are at https://d= ocs.google.com/spreadsheets/d/1c3obOwmRQDldw0u_kv85B5Q4LnjnmvUp2MmsHDGmW98 = (some additional issues are in https://trac.tools.ietf.org/group/dhcpv6bis/= report). One very recent change to highlight is https://tools.ietf.org/html/draft-ie= tf-dhc-rfc3315bis-08#section-18.2.12 - this was to address a criticism that= DHCPv6 is not responsive enough for some network configuration changes. The co-authors thank those that reviewed this document during the previous = WGLC and hope that those same reviewers (and hopefully more) will endeavor = to do one more thorough review of the document. - Tomek & Bernie --_000_8083bab53ebb474b9fef05fea5fcbdd2XCHALN003ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi:<= /p>

 

Tomek and I decided to= extend the WGLC by about a week (to June 6th) in the hopes of s= oliciting more feedback.

 

Please take some time = to review this document as this work is a critical product of the DHC WG!

 

-&nb= sp;         Bernie

 

From: dhcwg [mailto:dhcwg-bounces@ietf.org] <= b>On Behalf Of Bernie Volz (volz)
Sent: Tuesday, May 09, 2017 10:53 AM
To: dhcwg@ietf.org
Cc: Ralph Droms <rdroms.ietf@gmail.com>
Subject: [dhcwg] WGLC for draft-ietf-dhc-rfc3315bis-08 - Respond by = May 30th, 2017

 

Hello:

 

The co-authors believe that all of the issues report= ed for the last August WGLC on draft-ietf-dhc-rfc3315bis-05 have now been r= esolved. But, because of the large number of changes, the DHC WG co-chairs = feel another “WGLC” is appropriate.

 

Please review this document and provide your comment= s and whether you support the document moving forward by May 30th, 2017. The DHC WG co-chairs will again ask Ralph to evaluate the response= s. We are doing a 3 week WGLC as the document is rather large and important to get right!

 

Please see https://tools.ietf.org/html/draft-ietf-dhc-rfc3315bis-08.

 

If you’d like to see the differences from the = 05 version, use the diff tool at https://tools.ietf.org/rfcdiff:

 

https://tools.ietf.org/= /rfcdiff?url1=3Dhttps://tools.ietf.org/id/draft-ietf-dhc-rfc3315bis-08.txt&= amp;url2=3Dhttps://tools.ietf.org/id/draft-ietf-dhc-rfc3315bis-05.txt

 

The list of issues we recorded and action/assignee d= etails are at https://docs.google.com/spreadsheets/d/1c3obOwmRQDldw0u_kv85B5Q4LnjnmvUp2Mm= sHDGmW98 (some additional issues are in https://trac= .tools.ietf.org/group/dhcpv6bis/report).

 

One very recent change to highlight is https://tools.ietf.org/html/draft-ietf-dhc-rfc3315bis-08#section-18.2.12 – this was to address a criticism that DHCPv6 is not responsive eno= ugh for some network configuration changes.

 

The co-authors thank those that reviewed this docume= nt during the previous WGLC and hope that those same reviewers (and hopeful= ly more) will endeavor to do one more thorough review of the document.=

 

-     &= nbsp;    Tomek & Bernie

--_000_8083bab53ebb474b9fef05fea5fcbdd2XCHALN003ciscocom_-- From nobody Wed May 31 11:01:49 2017 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 438EE12957B for ; Wed, 31 May 2017 11:01:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.4 X-Spam-Level: X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HwxKzVW6thvJ for ; Wed, 31 May 2017 11:01:45 -0700 (PDT) Received: from mail-qk0-x232.google.com (mail-qk0-x232.google.com [IPv6:2607:f8b0:400d:c09::232]) (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 6FB36128BBB for ; Wed, 31 May 2017 11:01:45 -0700 (PDT) Received: by mail-qk0-x232.google.com with SMTP id 19so18252692qke.2 for ; Wed, 31 May 2017 11:01:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=dMI3GfRtGMiWl+3miRyhdj4Csim34+JwlIB841shssY=; b=WjFvHJie4NBGKKimErpcv+MvF2/lYK28GNwGl0RqJaJHW1npZ190uzlFKeGYVfxy34 6k4t9p0dNO1pKIZH74tOdOllj9gR9GuMZcAiny3FrSKeR0adccHyZXQBtfN3Zd6X5aDU s7tWRhSjEwB4gNCqEca4iZdk74YWASEhhv5SCiHVkPuI1RUstGn+GcF5OHcuV6iqRY1O FB1hFy0EnvuFsSBFnfZr7SWFOXz2GaDl7tSVF6hy1WEK78ixHAZUzMoWkdAUTj4NoIAi 8Gg0gCN4+5ZFGB1zvyg/MSyXumZ9Osu6h8YKM5Si7CDnV8kHVE+e7uO9GzyHivpv+yzd muCA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=dMI3GfRtGMiWl+3miRyhdj4Csim34+JwlIB841shssY=; b=LcCb8ID3N6SzjQNYx2mJSleh/TZdQnpOSCstBriPPPvbBp+ZeEsRbXnTxnmN8JxyNY tKGwgDyOuiL+Iup/AIfqRdaUL8dSs2GHs2cFe+Hz/rvu6ylfinlYNGHnpRU/IwD8AvuB lyAev6BGscwEsu/xGrWWoGCefQUjR4JUDxiB2epptEEvpHm9RuHLDDsdwnBQIkCk51NU FUOKp9Xj+fUNC8jWKK0cJk3SHJ7drBo1Q1zfJLaBoTbgtjZKRIYP1rhwmlMw50leeloa qY5rDA+4u781VYlYESP0kz/nOe+s0UHb88jQhcfUlFWqDATtbfKC8+nTE0r3+FgRcomN Fzbg== X-Gm-Message-State: AODbwcBYU6IZGKLt0hOUwNKVJZhrG0iiW5tZGdJlWL3Ap8mxuCfXNx+X oZ7BGHyuMG2jDUyWR10XmqspO8QUHG4ZWmo= X-Received: by 10.55.22.193 with SMTP id 62mr28043973qkw.242.1496253704428; Wed, 31 May 2017 11:01:44 -0700 (PDT) MIME-Version: 1.0 Sender: jinmei.tatuya@gmail.com Received: by 10.200.48.141 with HTTP; Wed, 31 May 2017 11:01:44 -0700 (PDT) In-Reply-To: <166ebb54-9a71-5bf9-669b-ff7be6f65ec7@gmail.com> References: <166ebb54-9a71-5bf9-669b-ff7be6f65ec7@gmail.com> From: =?UTF-8?B?56We5piO6YGU5ZOJ?= Date: Wed, 31 May 2017 11:01:44 -0700 X-Google-Sender-Auth: 5mEMhVBVrix1pNyKTRmRuvTOziE Message-ID: To: Tomek Mrugalski Cc: dhcwg Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [dhcwg] DHCP hackathon in Prague: SeDHCPv6 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 May 2017 18:01:47 -0000 At Wed, 31 May 2017 17:36:05 +0200, Tomek Mrugalski wrote: > As previously mentioned, we'll have a DHCP hackathon in Prague. As > usual, the hackathon will take place on the weekend immediately before > IETF (July 15-16). This time we will be focusing on SeDHCPv6. If you > somehow missed all the discussions so far, the > draft-ietf-dhc-sedhcpv6-21 defines Secure DHCPv6, an encrypted and > possibly authenticated version of DHCPv6 protocol. The goal of this > hackathon is to extend existing DHCPv6 implementations and attempt > inter-operability testing for encryption and authentication. We hope to > have the following implementations at various stages of maturity: I guess there's at least one fundamental open issue to be resolved before even trying to implement it: https://www.ietf.org/mail-archive/web/dhcwg/current/msg18116.html I'm afraid this is so fundamental that it's almost useless to have a hackathon without a consensus on it. (For some other issues yet to be uncovered hackathon would actually be a good opportunity to find them. But I suspect this one is too fundamental to be that type of issue). -- JINMEI, Tatuya From nobody Wed May 31 12:03:03 2017 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D661129AA3 for ; Wed, 31 May 2017 12:03:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FRYadRHhADJt for ; Wed, 31 May 2017 12:02:59 -0700 (PDT) Received: from mail-qt0-x22b.google.com (mail-qt0-x22b.google.com [IPv6:2607:f8b0:400d:c0d::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 36773128ACA for ; Wed, 31 May 2017 12:02:59 -0700 (PDT) Received: by mail-qt0-x22b.google.com with SMTP id f55so19775356qta.3 for ; Wed, 31 May 2017 12:02:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=tenJoD9dSCZWO+le+gbX8F1lqWIJhZDfc6lMV9T9LSc=; b=ro7iTfXVIEY52umq9oZUWuya+jYngTMSQ66Rh9Rjwd+r3ntrYi/n4lqyHSJKYwM+d5 AXIlEfUiK02K60DcztTqIieGnMlxFhocUMjHksC6aND4yt05oOjZUvEh+zOBP5Elf/+u bgOBC9oZs3sfGrxRrd+LGSgQdVh1ALRpsENlKqqzmlcpfOSH2Isgk79yOklsp2zUPEJH gWlb6OPZEJ6TDAybGEcj/Hw0UyOR6rg44LjuAexf5siMtg2UBBp1lZ9tqZixF57Rbqx1 L7vggSaSJqFihXlheuGBNH3VFhTa1Pv7juoetqV5sq8pM8hheHUcaiwYEb2yeZzvPp5l NiHA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=tenJoD9dSCZWO+le+gbX8F1lqWIJhZDfc6lMV9T9LSc=; b=BihR6pCM7IRB4c9ikyvgrlOsu45Ftu4X1tHNrfUwtGBVxgvLVqfvbwldKbbVsFRiPa FqgZ0pW0JeLzOvIGkDHdJ1I3NOUYMHRpb0S0ImCHbk1EkSFmxfBKuJ7wQiidvF1YR/jC vjB4SDruVseB/jv52sSHXB8E2d74vQbF6779f1zgPzdojRQ9CTjC1336uwmCi9xXqYuK 8cclJXDHUAaaJwJPedx+6XH/r0hnWfTm5lVgCdvXt0H5vwEUvW/0Nd7q1T7w/fj6hnTl xYpsS5x3Nw1sjxPopVt6HK59X+KRzLwkR86E7r7hlEQUZyMd/SF7G5/IEo1MOlU2DvAL 4mkw== X-Gm-Message-State: AODbwcB3UJIQPFq36txVXiju3IOJ8TE8DmakzgsfocGN14GxWopgcMqG 2sYyjjVXoL/Tv9wzOezuNg== X-Received: by 10.237.53.149 with SMTP id c21mr34570958qte.191.1496257378363; Wed, 31 May 2017 12:02:58 -0700 (PDT) Received: from [10.0.20.228] (c-73-167-64-188.hsd1.nh.comcast.net. [73.167.64.188]) by smtp.gmail.com with ESMTPSA id c5sm10920633qkf.14.2017.05.31.12.02.57 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 31 May 2017 12:02:57 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Ted Lemon In-Reply-To: Date: Wed, 31 May 2017 15:02:55 -0400 Cc: Tomek Mrugalski , dhcwg Content-Transfer-Encoding: quoted-printable Message-Id: <07525FFD-54C7-486E-B71C-9A282FD45967@fugue.com> References: <166ebb54-9a71-5bf9-669b-ff7be6f65ec7@gmail.com> To: =?utf-8?B?56We5piO6YGU5ZOJ?= X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [dhcwg] DHCP hackathon in Prague: SeDHCPv6 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 May 2017 19:03:01 -0000 This is only an issue if the transport can't handle packets larger than = 512 bytes. > On May 31, 2017, at 2:01 PM, =E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89 = wrote: >=20 > At Wed, 31 May 2017 17:36:05 +0200, > Tomek Mrugalski wrote: >=20 >> As previously mentioned, we'll have a DHCP hackathon in Prague. As >> usual, the hackathon will take place on the weekend immediately = before >> IETF (July 15-16). This time we will be focusing on SeDHCPv6. If you >> somehow missed all the discussions so far, the >> draft-ietf-dhc-sedhcpv6-21 defines Secure DHCPv6, an encrypted and >> possibly authenticated version of DHCPv6 protocol. The goal of this >> hackathon is to extend existing DHCPv6 implementations and attempt >> inter-operability testing for encryption and authentication. We hope = to >> have the following implementations at various stages of maturity: >=20 > I guess there's at least one fundamental open issue to be resolved > before even trying to implement it: > https://www.ietf.org/mail-archive/web/dhcwg/current/msg18116.html >=20 > I'm afraid this is so fundamental that it's almost useless to have a > hackathon without a consensus on it. (For some other issues yet to be > uncovered hackathon would actually be a good opportunity to find them. > But I suspect this one is too fundamental to be that type of issue). >=20 > -- > JINMEI, Tatuya >=20 > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg From nobody Wed May 31 14:54:29 2017 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 508021293FD for ; Wed, 31 May 2017 14:54:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8CbvKBAfrz11 for ; Wed, 31 May 2017 14:54:27 -0700 (PDT) Received: from mail-qt0-x236.google.com (mail-qt0-x236.google.com [IPv6:2607:f8b0:400d:c0d::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 3E9C0126D85 for ; Wed, 31 May 2017 14:54:27 -0700 (PDT) Received: by mail-qt0-x236.google.com with SMTP id v27so23258734qtg.2 for ; Wed, 31 May 2017 14:54:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=yjeWT7kb/4Ui8BlF/gl48sP+pltc5QpkdpzdaosqYTE=; b=O5k0d9hWLdQHsGxUpRIyhesJf+/h+E9HUhWo6MHCvNszRz1BwJtNcQS2g7Gf1gOH/B Pb5DFKombUH/1AVpJ/I4g7vDQ6lMWH/NY4NDNLh1tmUHQmgPHoS48yiCKkxdp76oqI+w Oz2yZXJGaakKMNRe+mbN7wjcxuTciX4zfzkrug7Ze/yCmM3+oqfUyQ6dB/0VhcEETyTh AqR7faTnn6/Drd/nvuYTOtdRsug4hVIAtUhOYYDc6H/A2oGMEvKJbaaDpbk49435SFEj P8QSrYw9ik7hH8wTKk2sVSVcVA/C9Qac2H7d8lOdk1TyA+iZgDEV+0NEPkZ5FeGuj4YY tWmQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=yjeWT7kb/4Ui8BlF/gl48sP+pltc5QpkdpzdaosqYTE=; b=efwnw5gGgu0o6vIlcy+ysiEBarDAj7tS44Pxy6uNGz6Dqh/RkMBWIpW5FIQ4XUNswB 9LWNKEiiL364G8V/2gBezTsxkUXRhhwJzP2lQ1T9PiEbDqicb/n0oZl9RJgDqwlqdEPv AL11ZDRxXvtVYr7W+i3gmRXtYKa04SUep2p69zh3z3ifpbJZbmJmfK2urQaW4iuJurSM tfgDOjj6jLQxY1A+MMfaMFmx09G8ZYJrd/qqHelf4Pza/VlitNIjLkJZhcJWy6msMvDT JuoraPvEC/TIEpoZ1Zt2eNoNZMc3hdRW9sjQL4bHf5sKdbAnX318LxtE74/jPkMcdnaq CzbQ== X-Gm-Message-State: AODbwcDZVJZ2bRmT9Le3RQLpi5jZVUM+XhEdMSF1jtMx189zea8AVRho RYXqPjSBv/dA+D7B9RIJVAeFnpgNB0WSM7U= X-Received: by 10.200.44.186 with SMTP id 55mr32813252qtw.173.1496267666409; Wed, 31 May 2017 14:54:26 -0700 (PDT) MIME-Version: 1.0 Sender: jinmei.tatuya@gmail.com Received: by 10.200.48.141 with HTTP; Wed, 31 May 2017 14:54:26 -0700 (PDT) In-Reply-To: <07525FFD-54C7-486E-B71C-9A282FD45967@fugue.com> References: <166ebb54-9a71-5bf9-669b-ff7be6f65ec7@gmail.com> <07525FFD-54C7-486E-B71C-9A282FD45967@fugue.com> From: =?UTF-8?B?56We5piO6YGU5ZOJ?= Date: Wed, 31 May 2017 14:54:26 -0700 X-Google-Sender-Auth: Pscipye-XdFaUu2A3XIiUSyW4uk Message-ID: To: Ted Lemon Cc: dhcwg Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [dhcwg] DHCP hackathon in Prague: SeDHCPv6 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 May 2017 21:54:28 -0000 At Wed, 31 May 2017 15:02:55 -0400, Ted Lemon wrote: > This is only an issue if the transport can't handle packets larger > than 512 bytes. So are you suggesting we should divide large messages into multiple small chunks and encrypt them separately (and send the result in a single encapsulated DHCPv6 message)? (Asking just so I can understand it). -- JINMEI, Tatuya From nobody Wed May 31 15:02:09 2017 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C825C126D85 for ; Wed, 31 May 2017 15:02:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p9mGEzh1If1f for ; Wed, 31 May 2017 15:02:05 -0700 (PDT) Received: from mail-pf0-x22f.google.com (mail-pf0-x22f.google.com [IPv6:2607:f8b0:400e:c00::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 4E43C12EA55 for ; Wed, 31 May 2017 15:02:05 -0700 (PDT) Received: by mail-pf0-x22f.google.com with SMTP id m17so18876946pfg.3 for ; Wed, 31 May 2017 15:02:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=IoB1+IRtwIt/zzw36Z2026j2bBF84mNFdkMBy6lX4nE=; b=1k+d6LUoJTZr6oZwenca0ue7cYxhQ28/KuE98eFwKRpUUE0Zg8bcZWAljy4tjlRfQb eX5XOpM4foUG2J5zun4KCQhuAVav77WVnZ4uIlvvl31tBvJ3CPWEdgyIm6k/UIHaIlX8 In8xaU2rSYfZ77D9Wmpc4f94kxHno+FnJsi22mvpNVfMSLm4GBRujZ+3d0TxkpzAl+0N AstweDDWawgi5P1oVUUuYn2ZpbOK4wG3U7RgrmAN8uJIv+rWaKKwMqFmTBaROiJMqY7M tFJyJ0BuFGPvPUo4KmlnM/Pb9sfi23aB5m9s4AknS/Fl6NgjbvNNurHKB/OFGuNd8MFQ Ncdg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=IoB1+IRtwIt/zzw36Z2026j2bBF84mNFdkMBy6lX4nE=; b=AZStSSR+julPzJFntGJzn2CRML/2LPkx0yIpA5QQswFEr08Pt/74GNS6xrLmRaxFf9 toZaClLlTkYgVPbAzwsMfvwNI+y3CZ1JPnYM1hODNyDDEPkKKkBclj9i2qacykSRUWcn egX9R6u+Hlp4qyXb6j9oH+plEs/wL4xb3K5Zn0R6Ckm9Uj9Sp8doDNl3RbEI19M6NXZx 4cRHhUla7mWRVdJygas+/kefrbjII1dibb0LD+DstPukOaOqmY0C+Dx9TlfwDGiCA+/y p9oW76YEfoKg+xNBK4FbI5YhpKN8S7BVsSBCR4ILFYdxgAdXonqJz4TMkWqv9NthDx4B 8jhA== X-Gm-Message-State: AODbwcD9XDQzJbqxMXlGqYw+tExFbCjM1uE9gwBqDnV1d3FSYRiOq3b8 j/Zzwxm+r4pElqCx62r65PJ22IuSBYEb X-Received: by 10.98.153.153 with SMTP id t25mr33252314pfk.160.1496268124966; Wed, 31 May 2017 15:02:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.180.45 with HTTP; Wed, 31 May 2017 15:02:04 -0700 (PDT) Received: by 10.100.180.45 with HTTP; Wed, 31 May 2017 15:02:04 -0700 (PDT) In-Reply-To: References: <166ebb54-9a71-5bf9-669b-ff7be6f65ec7@gmail.com> <07525FFD-54C7-486E-B71C-9A282FD45967@fugue.com> From: Ted Lemon Date: Wed, 31 May 2017 18:02:04 -0400 Message-ID: To: =?UTF-8?B?56We5piO6YGU5ZOJ?= Cc: dhcwg Content-Type: multipart/alternative; boundary="94eb2c0ed79a13e7460550d91204" Archived-At: Subject: Re: [dhcwg] DHCP hackathon in Prague: SeDHCPv6 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 May 2017 22:02:07 -0000 --94eb2c0ed79a13e7460550d91204 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Ah, I see. Let me get back to you on that. :) On May 31, 2017 5:54 PM, "=E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89" wrote: > At Wed, 31 May 2017 15:02:55 -0400, > Ted Lemon wrote: > > > This is only an issue if the transport can't handle packets larger > > than 512 bytes. > > So are you suggesting we should divide large messages into multiple > small chunks and encrypt them separately (and send the result in a > single encapsulated DHCPv6 message)? (Asking just so I can understand > it). > > -- > JINMEI, Tatuya > --94eb2c0ed79a13e7460550d91204 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Ah, I see. Let me get back to you on that. =C2=A0:)
=

On May 31, 2017 5= :54 PM, "=E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89" <jinmei@wide.ad.jp> wrote:
At Wed, 31 May 2017 15:02:55 -0400,
Ted Lemon <mellon@fugue.com> = wrote:

> This is only an issue if the transport can't handle packets larger=
> than 512 bytes.

So are you suggesting we should divide large messages into multiple
small chunks and encrypt them separately (and send the result in a
single encapsulated DHCPv6 message)? (Asking just so I can understand
it).

--
JINMEI, Tatuya
--94eb2c0ed79a13e7460550d91204-- From nobody Wed May 31 15:14:49 2017 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2A4D12EB0E; Wed, 31 May 2017 15:14:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.203 X-Spam-Level: X-Spam-Status: No, score=-4.203 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 09W5xoY_sJa3; Wed, 31 May 2017 15:14:21 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D541126D85; Wed, 31 May 2017 15:14:18 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 6A9D5B80D58; Wed, 31 May 2017 15:13:57 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 1005:ams_util_lib.php From: rfc-editor@rfc-editor.org Cc: rfc-editor@rfc-editor.org, drafts-update-ref@iana.org, dhcwg@ietf.org Message-Id: <20170531221357.6A9D5B80D58@rfc-editor.org> Date: Wed, 31 May 2017 15:13:57 -0700 (PDT) Archived-At: Subject: [dhcwg] RFC 8168 on DHCPv6 Prefix-Length Hint Issues X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 May 2017 22:14:35 -0000 A new Request for Comments is now available in online RFC libraries. RFC 8168 Title: DHCPv6 Prefix-Length Hint Issues Author: T. Li, C. Liu, Y. Cui Status: Standards Track Stream: IETF Date: May 2017 Mailbox: peter416733@gmail.com, gnocuil@gmail.com, yong.cui.thu@gmail.com Pages: 9 Characters: 21936 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-dhc-dhcpv6-prefix-length-hint-issue-06.txt URL: https://www.rfc-editor.org/info/rfc8168 DOI: 10.17487/RFC8168 DHCPv6 Prefix Delegation allows a client to include a prefix-length hint value in the IA_PD option to indicate a preference for the size of the prefix to be delegated, but it is unclear about how the client and server should act in different situations involving the prefix-length hint. This document provides a summary of the existing problems with the prefix-length hint and guidance on what the client and server could do in different situations. This document is a product of the Dynamic Host Configuration Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet Standards Track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Official Internet Protocol Standards (https://www.rfc-editor.org/standards) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC