From nobody Mon Apr 4 07:16:02 2016 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 F06CF12D6EF; Mon, 4 Apr 2016 07:15:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.53 X-Spam-Level: X-Spam-Status: No, score=-14.53 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 KkUxgMX0fhhw; Mon, 4 Apr 2016 07:15:48 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA74412D70F; Mon, 4 Apr 2016 07:15:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1926; q=dns/txt; s=iport; t=1459779346; x=1460988946; h=from:to:cc:subject:date:message-id:mime-version; bh=kR7RWalONFmN4tvOPgrukcltVtOhYA63g05znQft1qc=; b=mA+ilauwQ9ULI8ojJ48NCPmBu3VotbJYMOzBdt8VJU6Ji+YnAuUQgF16 o1xKkwj5GA88eBwwgtEmX9sFpp9Zw7/7667Css1GfTfN4+qCAYNtd7IPt c1HbIzQBU9Te/M6sb/habOYe3F3yO5QdHxqmHjfdJFpT4cfm+hXMsBwL6 w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AdAgC7dgJX/4QNJK1dgzdTtzSEcAENg?= =?us-ascii?q?XIhhWwegRc4FAEBAQEBAQFlHAuEOAwEI1YSAQsBPgIEMCcEDogsDqtAkTsBAQE?= =?us-ascii?q?BAQEBAQEBAQEBAQEBAQEBAQERBIgVh0GCUyuCKwWYAQGFcogVgWiETYhajxkBH?= =?us-ascii?q?gEBQoNniRIBAQE?= X-IronPort-AV: E=Sophos;i="5.24,440,1454976000"; d="scan'208,217";a="256522045" Received: from alln-core-10.cisco.com ([173.36.13.132]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 04 Apr 2016 14:15:45 +0000 Received: from XCH-RCD-001.cisco.com (xch-rcd-001.cisco.com [173.37.102.11]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id u34EFi2L003325 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 4 Apr 2016 14:15:45 GMT Received: from xch-aln-003.cisco.com (173.36.7.13) by XCH-RCD-001.cisco.com (173.37.102.11) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 4 Apr 2016 09:15:44 -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.1104.009; Mon, 4 Apr 2016 09:15:44 -0500 From: "Bernie Volz (volz)" To: "dhcpv6bis@ietf.org" Thread-Topic: DHCPv6 bis coauthors meeting - Wed 1400-1600 in Alerce (5th floor) Thread-Index: AQHRjnx5bVWsQe5E70GKZaa/9crpEw== Date: Mon, 4 Apr 2016 14:15:44 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted Content-Type: multipart/alternative; boundary="_000_CAA6375CB9D44A1BB00D82402DC3E28Aciscocom_" MIME-Version: 1.0 Archived-At: Cc: "dhcwg@ietf.org" Subject: [dhcwg] DHCPv6 bis coauthors meeting - Wed 1400-1600 in Alerce (5th floor) X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2016 14:16:01 -0000 --_000_CAA6375CB9D44A1BB00D82402DC3E28Aciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGk6DQoNCldlIHdpbGwgYmUgaW4gQWxlcmNlIG9uIDV0aCBmbG9vciBvZiBIaWx0b24gb24gV2Vk bmVzZGF5ICg0LzYpIGZyb20gMTQwMC0xNjAwIEFSVC4NCg0KQ29hdXRob3JzIG9mIGh0dHBzOi8v ZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtZGhjLXJmYzMzMTViaXMvIHRoYXQg YXJlIGF0IElFVEYtOTUgYXJlIHJlcXVlc3RlZCB0byBhdHRlbmQuIFRob3NlIG5vdCBoZXJlIHRo YXQgY291bGQgam9pbiB2aWEgSml0c2kgKG9yIHdlYmV4KSwgcGxlYXNlIGxldCBtZSBrbm93IHNv IHdlIGNhbiBzZXQgc29tZXRoaW5nIHVwLg0KDQpBbnlvbmUgZWxzZSB0aGF0IGhhZCBpbnRlcmVz dCwgZmVlbCBmcmVlIHRvIGpvaW4gdXMuDQoNCi0gQmVybmllIChmcm9tIGlQaG9uZSkNCg== --_000_CAA6375CB9D44A1BB00D82402DC3E28Aciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <502814695898A542AD292C107D2FA532@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IGRpcj0iYXV0byI+DQo8 ZGl2PkhpOjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+V2Ugd2lsbCBiZSBpbiBBbGVy Y2Ugb24gNXRoIGZsb29yIG9mIEhpbHRvbiBvbiBXZWRuZXNkYXkgKDQvNikgZnJvbSAxNDAwLTE2 MDAgQVJULjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+Q29hdXRob3JzIG9mJm5ic3A7 PGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1kaGMt cmZjMzMxNWJpcy8iPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYt ZGhjLXJmYzMzMTViaXMvPC9hPiZuYnNwO3RoYXQgYXJlIGF0IElFVEYtOTUgYXJlIHJlcXVlc3Rl ZCB0byBhdHRlbmQuIFRob3NlIG5vdCBoZXJlIHRoYXQgY291bGQgam9pbiB2aWEgSml0c2kgKG9y IHdlYmV4KSwgcGxlYXNlDQogbGV0IG1lIGtub3cgc28gd2UgY2FuIHNldCBzb21ldGhpbmcgdXAu PC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5BbnlvbmUgZWxzZSB0aGF0IGhhZCBpbnRl cmVzdCwgZmVlbCBmcmVlIHRvIGpvaW4gdXMuPC9kaXY+DQo8ZGl2Pjxicj4NCjxkaXY+LSBCZXJu aWUgKGZyb20gaVBob25lKTwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_CAA6375CB9D44A1BB00D82402DC3E28Aciscocom_-- From nobody Wed Apr 6 11:54:11 2016 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 DA77B12D74F for ; Wed, 6 Apr 2016 11:54:06 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: X-Test-IDTracker: no X-IETF-IDTracker: 6.19.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160406185406.24993.54634.idtracker@ietfa.amsl.com> Date: Wed, 06 Apr 2016 11:54:06 -0700 From: IETF Secretariat Archived-At: Subject: [dhcwg] Milestones changed for dhc WG X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.17 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2016 18:54:07 -0000 Changed milestone "Submit DHCP privacy drafts to IESG", resolved as "Done". Changed milestone "WG last call on 331bis draft", set due date to July 2016 from April 2016. Changed milestone "Submit 3315bis draft to IESG", set due date to September 2016 from June 2016. URL: https://datatracker.ietf.org/wg/dhc/charter/ From nobody Wed Apr 20 06:11:27 2016 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 9BECB12DD19 for ; Wed, 20 Apr 2016 06:11:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.517 X-Spam-Level: X-Spam-Status: No, score=-15.517 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_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, 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 G1s2bTMOF-6H for ; Wed, 20 Apr 2016 06:11:24 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0616612DC91 for ; Wed, 20 Apr 2016 06:11:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2386; q=dns/txt; s=iport; t=1461157884; x=1462367484; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=3ihl5VlAvlB1+XVYCahc1A4fmQxI5guvx37OE9k9QGc=; b=B+GtFUWcsK1S7Id7j36rfLv2qrWHtO8d1o3LN1os8/UwZSFe58n/RR6v lQNKTaZkzbHK+x3b/4598agDG0fI6s+2V7PnVIA5m1r1p1ds2hpcoPG/1 QItnnErcHzfm9v2vU9umLI/SrmzOKa8PaF/sNoyh6H3m2fER7RJuybwyr M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BKAgC9fxdX/5tdJa1egzhTfQa5ZAENg?= =?us-ascii?q?XEkhWoCHIEjOBQBAQEBAQEBZRwLhEEBAQECAiMRUQYBGQQBAQMCIwMCBDAUAQg?= =?us-ascii?q?JAQQTCIghDp0Mj12RPAEBAQEBAQEDAQEBAQEBAQEBEwR8jheDGIJWBY1ThUuEc?= =?us-ascii?q?QGBLYRNiBKBbYRNiF2PLAEeAQFCg2hsAYdIfgEBAQ?= X-IronPort-AV: E=Sophos;i="5.24,509,1454976000"; d="scan'208";a="263096917" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 20 Apr 2016 13:11:17 +0000 Received: from XCH-ALN-005.cisco.com (xch-aln-005.cisco.com [173.36.7.15]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id u3KDBH5S007771 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Wed, 20 Apr 2016 13:11:17 GMT Received: from xch-aln-003.cisco.com (173.36.7.13) by XCH-ALN-005.cisco.com (173.36.7.15) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 20 Apr 2016 08:11:17 -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.1104.009; Wed, 20 Apr 2016 08:11:17 -0500 From: "Bernie Volz (volz)" To: "dhcwg@ietf.org" Thread-Topic: Submitted draft-volz-dhc-relay-server-security-00.txt Thread-Index: AdGbBbNQZAYkAhluToSAVAOkTsobJw== Date: Wed, 20 Apr 2016 13:11:16 +0000 Message-ID: <5c300ea84859409a9f619267bf2e92e7@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.76.109] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: [dhcwg] Submitted draft-volz-dhc-relay-server-security-00.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2016 13:11:25 -0000 SGk6DQoNCkkganVzdCBzdWJtaXR0ZWQgYSBuZXcgKGluZGl2aWR1YWwgc3VibWlzc2lvbikgSW50 ZXJuZXQtRHJhZnQgdG8gYWRkcmVzcyByZWxheS9zZXJ2ZXIgZXhjaGFuZ2VzIGFuZCBwZXJ2YXNp dmUgbW9uaXRvcmluZywgYXMgSSBtZW50aW9uZWQgYXQgSUVURi05NSAtIHNlZSBodHRwczovL3d3 dy5pZXRmLm9yZy9wcm9jZWVkaW5ncy85NS9zbGlkZXMvc2xpZGVzLTk1LWRoYy0zLnBkZi4NCg0K UGxlYXNlIGxvb2sgYXQgdGhlIGRyYWZ0IGFuZCBjb21tZW50IHRvIHRoZSBsaXN0Lg0KDQpUaGFu a3MuDQoNCi0gQmVybmllDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBpbnRl cm5ldC1kcmFmdHNAaWV0Zi5vcmcgW21haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmddIA0K U2VudDogV2VkbmVzZGF5LCBBcHJpbCAyMCwgMjAxNiA5OjA4IEFNDQpTdWJqZWN0OiBOZXcgVmVy c2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LXZvbHotZGhjLXJlbGF5LXNlcnZlci1zZWN1cml0 eS0wMC50eHQNCg0KDQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtdm9sei1kaGMtcmVsYXkt c2VydmVyLXNlY3VyaXR5LTAwLnR4dA0KaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBi eSBCZXJuaWUgVm9seiBhbmQgcG9zdGVkIHRvIHRoZSBJRVRGIHJlcG9zaXRvcnkuDQoNCk5hbWU6 CQlkcmFmdC12b2x6LWRoYy1yZWxheS1zZXJ2ZXItc2VjdXJpdHkNClJldmlzaW9uOgkwMA0KVGl0 bGU6CQlTZWN1cml0eSBvZiBNZXNzYWdlcyBFeGNoYW5nZWQgQmV0d2VlbiBTZXJ2ZXJzIGFuZCBS ZWxheSBBZ2VudHMNCkRvY3VtZW50IGRhdGU6CTIwMTYtMDQtMjANCkdyb3VwOgkJSW5kaXZpZHVh bCBTdWJtaXNzaW9uDQpQYWdlczoJCTcNClVSTDogICAgICAgICAgICBodHRwczovL3d3dy5pZXRm Lm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtdm9sei1kaGMtcmVsYXktc2VydmVyLXNlY3VyaXR5 LTAwLnR4dA0KU3RhdHVzOiAgICAgICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9j L2RyYWZ0LXZvbHotZGhjLXJlbGF5LXNlcnZlci1zZWN1cml0eS8NCkh0bWxpemVkOiAgICAgICBo dHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtdm9sei1kaGMtcmVsYXktc2VydmVyLXNl Y3VyaXR5LTAwDQoNCg0KQWJzdHJhY3Q6DQogICBUaGUgRHluYW1pYyBIb3N0IENvbmZpZ3VyYXRp b24gUHJvdG9jb2wgZm9yIElQdjQgKERIQ1B2NCkgaGFzIG5vDQogICBndWlkYW5jZSBmb3IgaG93 IHRvIHNlY3VyZSBtZXNzYWdlcyBleGNoYW5nZWQgYmV0d2VlbiBzZXJ2ZXJzIGFuZA0KICAgcmVs YXkgYWdlbnRzLiAgVGhlIER5bmFtaWMgSG9zdCBDb25maWd1cmF0aW9uIFByb3RvY29sIGZvciBJ UHY2DQogICAoREhDUHY2KSBzdGF0ZXMgdGhhdCBJUHNlYyBzaG91bGQgYmUgdXNlZCB0byBzZWN1 cmUgbWVzc2FnZXMNCiAgIGV4Y2hhbmdlZCBiZXR3ZWVuIHNlcnZlcnMgYW5kIHJlbGF5IGFnZW50 cywgYnV0IGRvZXMgbm90IHJlY29tbWVuZA0KICAgZW5jcnlwdGlvbi4gIEFuZCwgd2l0aCByZWNl bnQgY29uY2VybnMgYWJvdXQgcGVydmFzaXZlIG1vbml0b3JpbmcgaXQNCiAgIGlzIGFwcHJvcHJp YXRlIHRvIHByb3ZpZGUgcmVjb21tZW5kYXRpb25zIGZvciBESENQdjQgYW5kIGFsc28gaW1wcm92 ZQ0KICAgdGhlIHJlY29tbWVuZGF0aW9ucyBmb3IgREhDUHY2LiAgVGhpcyBkb2N1bWVudCB1cGRh dGVzIFJGQzE1NDIgYW5kDQogICBSRkMzMzE1Lg0KDQo= From nobody Thu Apr 21 09:45:21 2016 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 8E8ED12DC4F for ; Thu, 21 Apr 2016 09:45:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.516 X-Spam-Level: X-Spam-Status: No, score=-15.516 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.996, 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 ysfpj-xJg0_e for ; Thu, 21 Apr 2016 09:45:19 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2452712D1D1 for ; Thu, 21 Apr 2016 09:45:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8479; q=dns/txt; s=iport; t=1461257118; x=1462466718; h=from:to:subject:date:message-id:mime-version; bh=aj/QjsyQWhAlkp09aIgKhaKPrGMzYcAwji5ud5GypAo=; b=cWkBFXvBwuNXnsBvEG7IaKkIdJEdmptcNPQSDhBbgW0uNaBROBCa/i/o 5hDibD8HyVtYT7YPy9qFpON5F/uoEdWMZGJAjVBHQaQWoFFosEi0Duibl SxI8HPAcdDVOAkGhgbx3+I7rhToCnEmvt/T0VU6X/cuS3QnNduKNOUoxn E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0A7AgAqAxlX/5JdJa1egmxMU4EDtHuCY?= =?us-ascii?q?4IPAQ2Bc4dDOBQBAQEBAQEBZRwLhEgtXgGBACYBBBuIIp8woHoBAQEBBgEBAQE?= =?us-ascii?q?BARqVAQWTHoRxAYEtjF+BbYRNiF2GI4kJAR4BAUKDaIhkfgEBAQ?= X-IronPort-AV: E=Sophos; i="5.24,513,1454976000"; d="scan'208,217"; a="99769639" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 21 Apr 2016 16:45:18 +0000 Received: from XCH-RCD-005.cisco.com (xch-rcd-005.cisco.com [173.37.102.15]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id u3LGjImG003897 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Thu, 21 Apr 2016 16:45:18 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.1104.5; Thu, 21 Apr 2016 11:45:17 -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.1104.009; Thu, 21 Apr 2016 11:45:17 -0500 From: "Bernie Volz (volz)" To: "dhcwg@ietf.org" Thread-Topic: Follow up from IETF-95 - draft-ietf-dhc-dhcpv6-prefix-length-hint-issue Thread-Index: AdGb7R0TyBAg+bfuQhK82oWwAy+O+A== Date: Thu, 21 Apr 2016 16:45:17 +0000 Message-ID: <0a8817dba2ea46c88ca67334a11c956d@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.77.252] Content-Type: multipart/alternative; boundary="_000_0a8817dba2ea46c88ca67334a11c956dXCHALN003ciscocom_" MIME-Version: 1.0 Archived-At: Subject: [dhcwg] Follow up from IETF-95 - draft-ietf-dhc-dhcpv6-prefix-length-hint-issue X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2016 16:45:20 -0000 --_000_0a8817dba2ea46c88ca67334a11c956dXCHALN003ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi: One item that was raised at the IETF-95 DHC WG session was the recent chang= e (suggested by me before draft-cui-dhc-dhcpv6-prefix-length-hint-issue-02 = was published) to switch draft-ietf-dhc-dhcpv6-prefix-length-hint-issue to = Informational rather than Standards Track. Marcin Siodelski suggested that = the document be Standards Track: The brief (draft) minutes for this discuss are: --- 5. DHCPv6 Prefix Length Hint Issues, Bernie Volz (for Tianxiang Li) - 10 mi= nutes, 14:50 draft-ietf-dhc-dhcpv6-prefix-length-hint-issue The authors believe work is ready for WGLC. Ian: Is this now informational? "This is the suggested way to do it"? Bernie: Correct. There were some discussions and the conclusion was to = not enforce it. Marcin (on jabber): I'd suggest this is standards track doc with normat= ive language in. Otherwise implementations will ignore hints. --- Once we resolve this open question (and after a possible update to the docu= ment), we intend to start a WGLC on the document. Please respond with your comments as to whether this document should be Inf= ormational or Standards Track by May 5th, 2016. Of course, any other commen= ts are welcome as well! Thanks! - Tomek & Bernie --_000_0a8817dba2ea46c88ca67334a11c956dXCHALN003ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi:

 

One item that was raised at the IETF-95 DHC WG sessi= on was the recent change (suggested by me before draft-cui-dhc-dhcpv6-prefi= x-length-hint-issue-02 was published) to switch draft-ietf-dhc-dhcpv6-prefi= x-length-hint-issue to Informational rather than Standards Track. Marcin Siodelski suggested that the document = be Standards Track:

 

The brief (draft) minutes for this discuss are:=

 

---

5. DHCPv6 Prefix Length Hint Issues, Bernie Volz (fo= r Tianxiang Li) - 10 minutes, 14:50

    draft-ietf-dhc-dhcpv6-prefix-leng= th-hint-issue

   

    The authors believe work is = ready for WGLC.

   

    Ian: Is this now information= al? "This is the suggested way to do it"?

    Bernie: Correct. There were some = discussions and the conclusion was to not

       enforce it.

    Marcin (on jabber): I'd suggest t= his is standards track doc with normative language

       in. Otherwise i= mplementations will ignore hints.

---

 

Once we resolve this open question (and after a poss= ible update to the document), we intend to start a WGLC on the document.

 

Please respond with your comments as to whether this= document should be Informational or Standards Track by May 5th,= 2016. Of course, any other comments are welcome as well!

 

Thanks!

 

-     &= nbsp;    Tomek & Bernie

--_000_0a8817dba2ea46c88ca67334a11c956dXCHALN003ciscocom_-- From nobody Thu Apr 21 09:50:04 2016 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 A2C7312E472 for ; Thu, 21 Apr 2016 09:50:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 ai7KbbY5yU4e for ; Thu, 21 Apr 2016 09:49:59 -0700 (PDT) Received: from mail-lb0-x229.google.com (mail-lb0-x229.google.com [IPv6:2a00:1450:4010:c04::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9FD2812E39F for ; Thu, 21 Apr 2016 09:49:56 -0700 (PDT) Received: by mail-lb0-x229.google.com with SMTP id b1so26807961lbi.1 for ; Thu, 21 Apr 2016 09:49:56 -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=EXR20Bhhj9UPrvJ5/mwfpsVqlPvTTIqxvdb/WJgCgjM=; b=VHDXv1UBMa0vF/S194dlTs/JPlxbOeSs1x9vXPLkcLb60G3Dp68BxqUDLca4qopBbs d0Igru6dIKAvBmx3GZb4BIuCezM+tQedsLJB6uhR+M8gA3UdE3GKoWd8oLV/eNmT290e 6xQYxRw9B6L3Q4SspNo9PXiC+4329euttLpNciYQow3mhJlHCnyaolcZgo5kQHLPsYrg 5CBapnnatp+3gm8EHcgx/IrHK20yTBxgfTW6hIOtezu8S4GaWm63pIFRbJ/ZlvsfVTtN QeTz2H5RrIGQYwu+V/cD2H4DC+Csw53Gf1gMoIMM+uWlX1Jqzj1Fx3BrlrgqIy+uT+op D6oQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=EXR20Bhhj9UPrvJ5/mwfpsVqlPvTTIqxvdb/WJgCgjM=; b=mVox0dN1yOArQ33s6amDakePW4AW63K1dm1DPxIgQPACYcMSozNdrTsB/JvCAat0ww ZVYawWmUXGkXdSEYMDOrdRxTW5KUstsBQlWQmNzRw81/hETOJiMV2QObvFtNPqwfP7eV wCNOciYXF2fCVNo95ZLA5ufK8kKyP5rlxi2+YD8vSdbfukPI0M8miLkf0MLbrs+cp6hI WMWRKKQufMAuctbAd/LadoUHIQcy4PQMxa8xcOC0Dxs1v8x0YRuzW31Fsm1o/Ea5sjZy YnhoGuCSQ8gw3n4Q/5Z0BYA8dA7MJGmfwEoKLEgDS/E5U8+oNq7jBHvsHb3weFwMZD42 tTZA== X-Gm-Message-State: AOPr4FVcqrYHOdyz5Wi+Vmq81pZHAiuhXk2nvv/6dUN/bGGNpznabqNLhZiXqEp593PwJzNXe1+bXviXcEAgPw== X-Received: by 10.112.13.8 with SMTP id d8mr6776831lbc.110.1461257394673; Thu, 21 Apr 2016 09:49:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.213.19 with HTTP; Thu, 21 Apr 2016 09:49:15 -0700 (PDT) X-Originating-IP: [71.233.41.235] In-Reply-To: <0a8817dba2ea46c88ca67334a11c956d@XCH-ALN-003.cisco.com> References: <0a8817dba2ea46c88ca67334a11c956d@XCH-ALN-003.cisco.com> From: Ted Lemon Date: Thu, 21 Apr 2016 12:49:15 -0400 Message-ID: To: "Bernie Volz (volz)" Content-Type: multipart/alternative; boundary=001a11c3b44eef76580531017fd3 Archived-At: Cc: "dhcwg@ietf.org" Subject: Re: [dhcwg] Follow up from IETF-95 - draft-ietf-dhc-dhcpv6-prefix-length-hint-issue X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2016 16:50:02 -0000 --001a11c3b44eef76580531017fd3 Content-Type: text/plain; charset=UTF-8 I think it's normative. On Thu, Apr 21, 2016 at 12:45 PM, Bernie Volz (volz) wrote: > Hi: > > > > One item that was raised at the IETF-95 DHC WG session was the recent > change (suggested by me before > draft-cui-dhc-dhcpv6-prefix-length-hint-issue-02 was published) to switch > draft-ietf-dhc-dhcpv6-prefix-length-hint-issue to Informational rather than > Standards Track. Marcin Siodelski suggested that the document be Standards > Track: > > > > The brief (draft) minutes for this discuss are: > > > > --- > > 5. DHCPv6 Prefix Length Hint Issues, Bernie Volz (for Tianxiang Li) - 10 > minutes, 14:50 > > draft-ietf-dhc-dhcpv6-prefix-length-hint-issue > > > > The authors believe work is ready for WGLC. > > > > Ian: Is this now informational? "This is the suggested way to do it"? > > Bernie: Correct. There were some discussions and the conclusion was to > not > > enforce it. > > Marcin (on jabber): I'd suggest this is standards track doc with > normative language > > in. Otherwise implementations will ignore hints. > > --- > > > > Once we resolve this open question (and after a possible update to the > document), we intend to start a WGLC on the document. > > > > Please respond with your comments as to whether this document should be > Informational or Standards Track by May 5th, 2016. Of course, any other > comments are welcome as well! > > > > Thanks! > > > > - Tomek & Bernie > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg > > --001a11c3b44eef76580531017fd3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I think it's normative.

On Thu, Apr 21, 2016 at 12:45 PM, Bernie V= olz (volz) <volz@cisco.com> wrote:

Hi:

=C2=A0

One item that was raised at the IETF-95 DHC WG sessi= on was the recent change (suggested by me before draft-cui-dhc-dhcpv6-prefi= x-length-hint-issue-02 was published) to switch draft-ietf-dhc-dhcpv6-prefi= x-length-hint-issue to Informational rather than Standards Track. Marcin Siodelski suggested that the document = be Standards Track:

=C2=A0

The brief (draft) minutes for this discuss are:

=C2=A0

---

5. DHCPv6 Prefix Length Hint Issues, Bernie Volz (fo= r Tianxiang Li) - 10 minutes, 14:50

=C2=A0=C2=A0=C2=A0 draft-ietf-dhc-dhcpv6-prefix-leng= th-hint-issue

=C2=A0=C2=A0=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0The authors believe work is = ready for WGLC.

=C2=A0=C2=A0=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0Ian: Is this now information= al? "This is the suggested way to do it"?

=C2=A0=C2=A0=C2=A0 Bernie: Correct. There were some = discussions and the conclusion was to not

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 enforce it.<= /u>

=C2=A0=C2=A0=C2=A0 Marcin (on jabber): I'd sugge= st this is standards track doc with normative language

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 in. Otherwise i= mplementations will ignore hints.

---

=C2=A0

Once we resolve this open question (and after a poss= ible update to the document), we intend to start a WGLC on the document.=

=C2=A0

Please respond with your comments as to whether this= document should be Informational or Standards Track by May 5th,= 2016. Of course, any other comments are welcome as well!

=C2=A0

Thanks!

=C2=A0

-=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Tomek & Bernie


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


--001a11c3b44eef76580531017fd3-- From nobody Thu Apr 21 09:58:24 2016 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 8FC7912DF3C for ; Thu, 21 Apr 2016 09:58:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.898 X-Spam-Level: X-Spam-Status: No, score=-2.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.996, 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 hr0xzdQg4ktT for ; Thu, 21 Apr 2016 09:58:21 -0700 (PDT) Received: from givry.fdupont.fr (givry.fdupont.fr [IPv6:2001:41d0:1:6d55:211:5bff:fe98:d51e]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C88B12D7B7 for ; Thu, 21 Apr 2016 09:58:21 -0700 (PDT) Received: from givry.fdupont.fr (localhost [IPv6:::1]) by givry.fdupont.fr (8.14.7/8.14.7) with ESMTP id u3LGmK63032066; Thu, 21 Apr 2016 18:48:20 +0200 (CEST) (envelope-from dupont@givry.fdupont.fr) Message-Id: <201604211648.u3LGmK63032066@givry.fdupont.fr> From: Francis Dupont To: "Bernie Volz (volz)" In-reply-to: Your message of Thu, 21 Apr 2016 16:45:17 -0000. <0a8817dba2ea46c88ca67334a11c956d@XCH-ALN-003.cisco.com> Date: Thu, 21 Apr 2016 18:48:20 +0200 Archived-At: Cc: "dhcwg@ietf.org" Subject: Re: [dhcwg] Follow up from IETF-95 - draft-ietf-dhc-dhcpv6-prefix-length-hint-issue X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2016 16:58:23 -0000 In your previous mail you wrote: > Please respond with your comments as to whether this document should > be Informational or Standards Track by May 5th, 2016. Of course, any > other comments are welcome as well! => from the subject (in particular the term "hint") and the wording I am more for Informational. Note BTW this is not an answer to Marcin's concern as he proposed first to change the wording for a normative one. Regards Francis.Dupont@fdupont.fr From nobody Thu Apr 21 10:08:26 2016 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 AA50F12E6D1 for ; Thu, 21 Apr 2016 10:08:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 DakJWMl5SqXA for ; Thu, 21 Apr 2016 10:08:24 -0700 (PDT) Received: from mail-wm0-x244.google.com (mail-wm0-x244.google.com [IPv6:2a00:1450:400c:c09::244]) (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 5EA4D12E61F for ; Thu, 21 Apr 2016 10:08:24 -0700 (PDT) Received: by mail-wm0-x244.google.com with SMTP id n3so23180107wmn.1 for ; Thu, 21 Apr 2016 10:08:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=RBop9B3DvmR83Tat4GGEdglyr0Bkdi9lmke4XT24CXo=; b=hW5cMhlXNOXnu8Jc1UrCdsu3ghWrIXBF8jMmir70A4yVrttyJmwgWZptIJ/N32TfoW mmg1ToBppIK3Veqeob9peOmuxEDw/Gr8XzF57pU8LHor07LWSKU5ZgJj+YRz84S9pKly yOVn0XXhG+TMDxXaU136p7pe2d+PHIr4dgh9dbYD+aPb80LTvy4JMtoALJ1hXKxzZ5q0 BekVJ7kauDRhzMt2Rohv0UCMOE3boEpRcjgbGossytlOrgD99dgnuJE0xX7wUUSz6kHf XguZEJ/4TWCNqsnhoKszKn7Wix9NktfCYk3qckMcQMr5aL/BrS4lrek6mFj10aj6RGPD ZQaQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=RBop9B3DvmR83Tat4GGEdglyr0Bkdi9lmke4XT24CXo=; b=eHecBkoXwx2e23vTNS+ba2BA2f5b2LKZbjTZ3JLohJu4FlGDJ2JytbPcK8+2QzCR3N h2U/I3h6wYd+uI7HI+XLT1eePywrr9dCxaKCxlHQWD4hc11AZSroDbkr66PrPvP3njrE kcp/RdCxVnflz27xvzwTH0etFuATUD+dld37JVGgh+Lu22nekD8hyDvql2R3sHchUggU RwLlrRTyPPGhRnmiDkXauH41r6OnddaIVdGD9o3gM1f+HMfxpELP66qSWY0jSbegT2Fe 5GV2u5eKUfxgTnxxXoCcXRWO9my47vNc2Yrbh9BBqcoVSGNiI6Ob69DZZBAtU0EtFwBo 8JsQ== X-Gm-Message-State: AOPr4FUM1z3eReA/1jGx6QXHDclvSe8d7SljqsirFlNYUuuC/bjofYRcDYZh3RtVHS2mqQ== X-Received: by 10.28.111.77 with SMTP id k74mr15906600wmc.37.1461258502975; Thu, 21 Apr 2016 10:08:22 -0700 (PDT) Received: from dhcp-wifi-232.sql1.isc.org ([2001:4f8:3:65:d1eb:17ed:1226:80db]) by smtp.googlemail.com with ESMTPSA id a75sm2463718wme.18.2016.04.21.10.08.20 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 21 Apr 2016 10:08:22 -0700 (PDT) To: Francis Dupont , "Bernie Volz (volz)" References: <201604211648.u3LGmK63032066@givry.fdupont.fr> From: Marcin Siodelski Message-ID: <57190903.6070705@gmail.com> Date: Thu, 21 Apr 2016 10:08:19 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <201604211648.u3LGmK63032066@givry.fdupont.fr> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Cc: "dhcwg@ietf.org" Subject: Re: [dhcwg] Follow up from IETF-95 - draft-ietf-dhc-dhcpv6-prefix-length-hint-issue X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2016 17:08:25 -0000 On 21.04.2016 09:48, Francis Dupont wrote: > In your previous mail you wrote: > >> Please respond with your comments as to whether this document should >> be Informational or Standards Track by May 5th, 2016. Of course, any >> other comments are welcome as well! > > => from the subject (in particular the term "hint") and the wording > I am more for Informational. Note BTW this is not an answer to Marcin's > concern as he proposed first to change the wording for a normative one. > In this case, can you answer the actual question? Should the document become Standards Track and (as consequence) the wording should be changed to normative? Marcin From nobody Thu Apr 21 10:33:21 2016 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 1157812E64E for ; Thu, 21 Apr 2016 10:33:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.898 X-Spam-Level: X-Spam-Status: No, score=-2.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.996, 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 3sjpWxC8xrO5 for ; Thu, 21 Apr 2016 10:33:18 -0700 (PDT) Received: from givry.fdupont.fr (givry.fdupont.fr [IPv6:2001:41d0:1:6d55:211:5bff:fe98:d51e]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8DB7812DD24 for ; Thu, 21 Apr 2016 10:33:18 -0700 (PDT) Received: from givry.fdupont.fr (localhost [IPv6:::1]) by givry.fdupont.fr (8.14.7/8.14.7) with ESMTP id u3LHNIRN034297; Thu, 21 Apr 2016 19:23:18 +0200 (CEST) (envelope-from dupont@givry.fdupont.fr) Message-Id: <201604211723.u3LHNIRN034297@givry.fdupont.fr> From: Francis Dupont To: Marcin Siodelski In-reply-to: Your message of Thu, 21 Apr 2016 10:08:19 -0700. <57190903.6070705@gmail.com> Date: Thu, 21 Apr 2016 19:23:18 +0200 Archived-At: Cc: "dhcwg@ietf.org" , "Bernie Volz \(volz\)" Subject: Re: [dhcwg] Follow up from IETF-95 - draft-ietf-dhc-dhcpv6-prefix-length-hint-issue X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2016 17:33:20 -0000 In your previous mail you wrote: > >> Please respond with your comments as to whether this document should > >> be Informational or Standards Track by May 5th, 2016. Of course, any > >> other comments are welcome as well! > > > > => from the subject (in particular the term "hint") and the wording > > I am more for Informational. Note BTW this is not an answer to Marcin's > > concern as he proposed first to change the wording for a normative one. > > > > In this case, can you answer the actual question? => argh! (:-) > Should the document become Standards Track and (as consequence) the > wording should be changed to normative? => as the long term plan should be to merge this clarification into the RFC3633 successor a normative wording makes sense so (as consequence) Normative status too. I know my answer is more to the "publish as Informational as it vs. rewrite and publish as Standard" question. Regards Francis.Dupont@fdupont.fr From nobody Thu Apr 21 10:36:40 2016 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 314C912E839 for ; Thu, 21 Apr 2016 10:36:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 HhKEsrk9M7VR for ; Thu, 21 Apr 2016 10:36:37 -0700 (PDT) Received: from mail-lf0-x22a.google.com (mail-lf0-x22a.google.com [IPv6:2a00:1450:4010:c07::22a]) (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 E333512E81D for ; Thu, 21 Apr 2016 10:36:36 -0700 (PDT) Received: by mail-lf0-x22a.google.com with SMTP id j11so65112625lfb.1 for ; Thu, 21 Apr 2016 10:36:36 -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=4e9yFNrIrzfvn5dirE8zLdSxm1L7OWx6FpfcFdjZ3Uk=; b=ylHQZOwOhBP1HwBXhHdNSi/w8Yl7fUFD5nbeElk+JezeYxthhHh9Tr4MGZNICI2FaQ YsNCt0W7bObAhwtvCV93c0ejXPbOgIb/HWQHA/+6t1jEkAENBrBqenJTQcpa8CYorhIZ R8cfUTGMBm4rOIBiaEWZX/XGuko4LAp8YdEUJZeT28d6033YWnnrKjEiZZeQIN4k8kmJ dLkpVp+LcEoE+wr0zAGxBv4OrargHrfoaimNweWAd/0dch//ml/FQa1LtoVUTUOBYtex /y1X7QIiQGyU2l7ovsxRtOmfOVQtroAFJU/KDzLOjH4hNLpbCMy/jC7dcA+lgNmylh94 Y/Sg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=4e9yFNrIrzfvn5dirE8zLdSxm1L7OWx6FpfcFdjZ3Uk=; b=BTf2FHlwoNELS9La+B8Jr5ac05XvoI5dYZEUYKiPR6TMSA44yG/B0VIJCqTwOxDXk5 76YAsKIeWiyAYRg8YKGrVDLuVdohIOC5o+xHSC0ML/osASgnXZKK+GXTvovjACPTnyXk 9bFxUNPHk7Y2zESScpeXmN8+WhQHMX9VhRdfjFiNO0r2Urf5X68Aau8yCqBo9CL7k0ka ystwved8ScdcuaJmsxMQg/znNucHhmqAEGp+9xo41WWYiHcg4MhRE+3yHVr1Ewnqc0oq hksyK91zgst9jOzt8fORqyjgckCcw+XoX0/U0ZiCv3vgL263cJ+6R90Cs56u8XFXyYlx ly1A== X-Gm-Message-State: AOPr4FVI+9YW40NhlPqIiaDcUVxtxzD+MzTCajncemnmiZ54Y5Kuk0U5jSYBsrjTzObHnpxwJqBCrtLQJaEVEw== X-Received: by 10.25.73.212 with SMTP id w203mr5983552lfa.22.1461260195084; Thu, 21 Apr 2016 10:36:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.213.19 with HTTP; Thu, 21 Apr 2016 10:35:55 -0700 (PDT) X-Originating-IP: [71.233.41.235] In-Reply-To: <201604211723.u3LHNIRN034297@givry.fdupont.fr> References: <57190903.6070705@gmail.com> <201604211723.u3LHNIRN034297@givry.fdupont.fr> From: Ted Lemon Date: Thu, 21 Apr 2016 13:35:55 -0400 Message-ID: To: Francis Dupont Content-Type: multipart/alternative; boundary=001a114b1592da52ef0531022684 Archived-At: Cc: "dhcwg@ietf.org" , "Bernie Volz \(volz\)" Subject: Re: [dhcwg] Follow up from IETF-95 - draft-ietf-dhc-dhcpv6-prefix-length-hint-issue X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2016 17:36:39 -0000 --001a114b1592da52ef0531022684 Content-Type: text/plain; charset=UTF-8 If it's normative, it's standards track. Informational can't be normative. Of course, we sometimes treat informational documents as normative, but this is usually because they become standard practice over time through repeated use. Since we know that we mean this advice to be normative now, it doesn't make any sense for us to say that the document should be informational. On Thu, Apr 21, 2016 at 1:23 PM, Francis Dupont wrote: > In your previous mail you wrote: > > > >> Please respond with your comments as to whether this document should > > >> be Informational or Standards Track by May 5th, 2016. Of course, any > > >> other comments are welcome as well! > > > > > > => from the subject (in particular the term "hint") and the wording > > > I am more for Informational. Note BTW this is not an answer to > Marcin's > > > concern as he proposed first to change the wording for a normative > one. > > > > > > > In this case, can you answer the actual question? > > => argh! (:-) > > > Should the document become Standards Track and (as consequence) the > > wording should be changed to normative? > > => as the long term plan should be to merge this clarification into > the RFC3633 successor a normative wording makes sense so (as consequence) > Normative status too. I know my answer is more to the "publish as > Informational as it vs. rewrite and publish as Standard" question. > > Regards > > Francis.Dupont@fdupont.fr > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg > --001a114b1592da52ef0531022684 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
If it's normative, it's standards track. =C2=A0 In= formational can't be normative. =C2=A0 Of course, we sometimes treat in= formational documents as normative, but this is usually because they become= standard practice over time through repeated use. =C2=A0 Since we know tha= t we mean this advice to be normative now, it doesn't make any sense fo= r us to say that the document should be informational.

On Thu, Apr 21, 2016 at 1:23 PM,= Francis Dupont <Francis.Dupont@fdupont.fr> wrote:
=C2=A0In your previous ma= il you wrote:

>=C2=A0 >> Please respond with your comments as to whether this do= cument should
>=C2=A0 >> be Informational or Standards Track by May 5th, 2016. O= f course, any
>=C2=A0 >> other comments are welcome as well!
>=C2=A0 >
>=C2=A0 > =3D> from the subject (in particular the term "hint= ") and the wording
>=C2=A0 > I am more for Informational. Note BTW this is not an answer= to Marcin's
>=C2=A0 > concern as he proposed first to change the wording for a no= rmative one.
>=C2=A0 >
>
>=C2=A0 In this case, can you answer the actual question?

=3D> argh! (:-)

> Should the document become Standards Track and (as consequence) the > wording should be changed to normative?

=3D> as the long term plan should be to merge this clarification = into
the RFC3633 successor a normative wording makes sense so (as consequence) Normative status too. I know my answer is more to the "publish as
Informational as it vs. rewrite and publish as Standard" question.

Regards

Francis.Dupont@fdupont.fr<= br>

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

--001a114b1592da52ef0531022684-- From nobody Thu Apr 21 10:56:24 2016 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 2E93012EA43 for ; Thu, 21 Apr 2016 10:56:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.516 X-Spam-Level: X-Spam-Status: No, score=-15.516 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_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, 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 cHsvBM43hVmP for ; Thu, 21 Apr 2016 10:56:18 -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 BCA6312EA38 for ; Thu, 21 Apr 2016 10:56:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5660; q=dns/txt; s=iport; t=1461261378; x=1462470978; h=from:to:subject:date:message-id:mime-version; bh=lac6p7WdZsJdtvrUXTDs/hPzMH7LN1jngfgD3AAH67A=; b=aOX0//CRpVr2nW8VQFUpu+5KvylxkXZScb1gNXo6m3WNcdny3rKB8LH2 RkZctwJh2rt+H+QjlF1CrOe2t9NC25iwjpwhAB3bQsVUscdlycePRQTJX vAoya1KIO2wxdkxG/z461l0Sl7q0RpAZg3ZCU8SRdUo3WYp+547rfNgGy g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BMAgDVEhlX/4YNJK1egmxMU4EDtQOCY?= =?us-ascii?q?4IPAQ2BdCKFbIE2OBQBAQEBAQEBZRwLhEgtXgGBACYBBBuIIg6fIKB8AQEBAQE?= =?us-ascii?q?BBAEBAQEBAQEVBI9YhSkFmA8BjgyBbYRNiF2PLQEeAQFCg2mIZH4BAQE?= X-IronPort-AV: E=Sophos;i="5.24,513,1454976000"; d="scan'208,217";a="263603626" Received: from alln-core-12.cisco.com ([173.36.13.134]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 21 Apr 2016 17:56:18 +0000 Received: from XCH-ALN-001.cisco.com (xch-aln-001.cisco.com [173.36.7.11]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id u3LHuHj1016466 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Thu, 21 Apr 2016 17:56:18 GMT Received: from xch-aln-003.cisco.com (173.36.7.13) by XCH-ALN-001.cisco.com (173.36.7.11) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 21 Apr 2016 12:56:17 -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.1104.009; Thu, 21 Apr 2016 12:56:17 -0500 From: "Bernie Volz (volz)" To: "dhcwg@ietf.org" Thread-Topic: DRAFT Minutes of IETF-95 Session Thread-Index: AdGb9t0FHCHCAR+NT6q8ORw1H3235A== Date: Thu, 21 Apr 2016 17:56:16 +0000 Message-ID: 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.77.252] Content-Type: multipart/alternative; boundary="_000_d400b4f0482f4e5caf8ec9cc7a56e1c2XCHALN003ciscocom_" MIME-Version: 1.0 Archived-At: Subject: [dhcwg] DRAFT Minutes of IETF-95 Session X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2016 17:56:22 -0000 --_000_d400b4f0482f4e5caf8ec9cc7a56e1c2XCHALN003ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi: If you attended (in person or virtually) the DHC WG session at IETF-95, ple= ase review the minutes at https://www.ietf.org/proceedings/95/minutes/minut= es-95-dhc and let us know of any issues. Thanks to Sheng Jiang for finishing them up and to all those that contribut= ed to the etherpad notes. - Bernie --_000_d400b4f0482f4e5caf8ec9cc7a56e1c2XCHALN003ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi:

 

If you attended (in person or virtually) the DHC WG = session at IETF-95, please review the minutes at http= s://www.ietf.org/proceedings/95/minutes/minutes-95-dhc and let us know = of any issues.

 

Thanks to Sheng Jiang for finishing them up and to a= ll those that contributed to the etherpad notes.

 

-     &= nbsp;    Bernie

--_000_d400b4f0482f4e5caf8ec9cc7a56e1c2XCHALN003ciscocom_-- From nobody Thu Apr 21 11:28:14 2016 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 34A7C12D60E for ; Thu, 21 Apr 2016 11:28:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.566 X-Spam-Level: X-Spam-Status: No, score=-0.566 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_SORBS_WEB=0.77, SPF_HELO_PASS=-0.001, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=employees.org; domainkeys=pass (1024-bit key) header.from=otroan@employees.org header.d=employees.org 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 g6TcLN344HkF for ; Thu, 21 Apr 2016 11:28:10 -0700 (PDT) Received: from incoming.kjsl.com (inbound02.kjsl.com [IPv6:2001:1868:2002::144]) by ietfa.amsl.com (Postfix) with ESMTP id 4189012D15A for ; Thu, 21 Apr 2016 11:28:09 -0700 (PDT) Received: from cowbell.employees.org ([65.50.211.142]) by ironport02.kjsl.com with ESMTP; 21 Apr 2016 18:28:08 +0000 Received: from cowbell.employees.org (localhost [127.0.0.1]) by cowbell.employees.org (Postfix) with ESMTP id D91769CCFB; Thu, 21 Apr 2016 11:28:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h=subject :mime-version:content-type:from:in-reply-to:date:cc:message-id :references:to; s=selector1; bh=e7g2/gzxIuIMrwhLF1mw2lFRli8=; b= kFttTjKGn0eGp6vVLRhmKWVJSYOl0AD7jlWuFPtmjYLtCi+ePga7Ej1iDJ6thnoi tuRFJDSZVV66cCvgoV4VONMsK3x6VuMnyAJYjcEPcEpHQEwpwN/NTg981xLdz/Nc byddEZ8dRRUYBCLnAZyhyy/bfD+/cutQIIWwOFR/Gn8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h=subject :mime-version:content-type:from:in-reply-to:date:cc:message-id :references:to; q=dns; s=selector1; b=U1kR7HMzRc9yzW5NrYxrmOj4+L YFl1djMpzwrofJhayWGwly5GQDINVD874UpDq2SEqK0A6+esgA0hEt29AuFteEJ1 OMInUdvwjZ8oJEKeTx+JHnWnWNjUOVJZeIXG4DGgQeg2ksvZ9y5DEpuAFVgWjgUd /55oEGjd72pdgJu3U= Received: from h.hanazo.no (cm-84.213.17.83.getinternet.no [84.213.17.83]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: otroan) by cowbell.employees.org (Postfix) with ESMTPSA id 566B39CC0F; Thu, 21 Apr 2016 11:28:07 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by h.hanazo.no (Postfix) with ESMTP id ED5C0148742E; Thu, 21 Apr 2016 20:28:03 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_C1597EDB-E3DD-42F1-BDC4-FC246C1B93D0"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.6b2 From: otroan@employees.org In-Reply-To: <0a8817dba2ea46c88ca67334a11c956d@XCH-ALN-003.cisco.com> Date: Thu, 21 Apr 2016 20:28:02 +0200 Message-Id: References: <0a8817dba2ea46c88ca67334a11c956d@XCH-ALN-003.cisco.com> To: "Bernie Volz (volz)" X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "dhcwg@ietf.org" Subject: Re: [dhcwg] Follow up from IETF-95 - draft-ietf-dhc-dhcpv6-prefix-length-hint-issue X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2016 18:28:13 -0000 --Apple-Mail=_C1597EDB-E3DD-42F1-BDC4-FC246C1B93D0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii there are some parts that could be made normative, like section 2.5. but most of the document appears informational in nature. paraphrased example: "the server should delegates a /48 if the client = requests it". that's clearly policy, and a matter of the possible commercial = arrangement, seems strange if the IETF should try to codify that. I lean towards informational. the document also does not say anything about _how_ the client is = supposed to figure out what sized address block to request. if the answer to that is manual configuration, then there are tens of = ways that could be done differently out of band. cheers, Ole > On 21 Apr 2016, at 18:45, Bernie Volz (volz) wrote: >=20 > Hi: >=20 > One item that was raised at the IETF-95 DHC WG session was the recent = change (suggested by me before = draft-cui-dhc-dhcpv6-prefix-length-hint-issue-02 was published) to = switch draft-ietf-dhc-dhcpv6-prefix-length-hint-issue to Informational = rather than Standards Track. Marcin Siodelski suggested that the = document be Standards Track: >=20 > The brief (draft) minutes for this discuss are: >=20 > --- > 5. DHCPv6 Prefix Length Hint Issues, Bernie Volz (for Tianxiang Li) - = 10 minutes, 14:50 > draft-ietf-dhc-dhcpv6-prefix-length-hint-issue >=20 > The authors believe work is ready for WGLC. >=20 > Ian: Is this now informational? "This is the suggested way to do = it"? > Bernie: Correct. There were some discussions and the conclusion = was to not > enforce it. > Marcin (on jabber): I'd suggest this is standards track doc with = normative language > in. Otherwise implementations will ignore hints. > --- >=20 > Once we resolve this open question (and after a possible update to the = document), we intend to start a WGLC on the document. >=20 > Please respond with your comments as to whether this document should = be Informational or Standards Track by May 5th, 2016. Of course, any = other comments are welcome as well! >=20 > Thanks! >=20 > - Tomek & Bernie > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg --Apple-Mail=_C1597EDB-E3DD-42F1-BDC4-FC246C1B93D0 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJXGRuzAAoJEL7aWKiYQt92JwQQAMRkBhN/TeNFd1LJi7YsDnP+ 6K6RrcSVUL8T8GKdQwuha9WextwWfEdGVVkv0CmsJ3SxPlbdeDvJqNfeJ4temJU6 q2xeL4hXLeZ1vozD62TRmNHPTLBXthrNcvO1eaorzJDDs/d+JtB64+zdupiPBR9C grjfBMja0s1BCF5sw2V/R2kzDrSeq+e8doH7dif2crn5lYzDGuKCmiTcfbmHe9Kc McHMou+63Z8IwtmPzu6ABkOLNlOw2sx455CVOWF5vpJ9qR8eMqpRMJfmY+qqnGPg pv7QsINgi5IrfctVUQEA4NuWS/Rw97a6uW4AI+lsEM8N+Js0OEyHNbP3Os28AAtA c7ne5bdQziP27W+/X9RP6uTswixKbSbsmMc9PCeZ6dwRgKfbbzpH4NN+4bhN2Zzv DHiWuGoX3hbM0pRtThrUAxzPYuqqG2AzVtA3v5SYZ5VKzAKPvPUKwqgRln7ba97G tnrctwT+qdosZWPZb/QeocqC714VwDBDmQMbaTjz8HBpfRnai+QDQ4sx0cscStqd hmtAJWFD0MQnlrCXZkcunOiLYUQGP3BPszMXAoUFswx9LdSlptjjPM+S/aQW6Bxh YcRaLofnaZ89/2YqCf3tCRWh4mIMWwwguLfZro7l3KZ+zJRbkRuSyTcZszeZW8YY baciYGSS34CcnTMbUmj8 =vVpX -----END PGP SIGNATURE----- --Apple-Mail=_C1597EDB-E3DD-42F1-BDC4-FC246C1B93D0-- From nobody Thu Apr 21 11:33:40 2016 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 2E96012E578 for ; Thu, 21 Apr 2016 11:33:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 2zWGMjRrBZsm for ; Thu, 21 Apr 2016 11:33:33 -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 EDD8112E304 for ; Thu, 21 Apr 2016 11:33:28 -0700 (PDT) Received: by mail-lf0-x230.google.com with SMTP id j11so65986743lfb.1 for ; Thu, 21 Apr 2016 11:33:28 -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=oLCiBGKXgJ2e8RbmYM/M2sHb5tWGyCYCm+qWlZXGJrM=; b=jlhmXwbdQBVuVdi0DfvkUVJcT3iWjiA2Brps2LoQk162H4wZy+ihrdu+qmPnXx1F9n H2ty3uOjTaQwXq9hPwVmepJROyjM4ETodD7YD+FxTwgs2CGVrTL67Y3P8Vse1Kyrhfpf E6NFtdZT8mY9hY4z1AGV9dIfMbjiU5NqYT26W8ik4X9byJYlQGjC5BcFkBPBC6u5DIWj HFdaLn6etO1+SSYBeDoMR6kKO9bEye4SrtFdYA6ocI7cmUQv5sgnuvrm9wyDRUkuJj1V cx4Wd4DfbIRkG3GSeKeWWpPvO1n3EqcpQWrT0KV2+AiAJDDsrRB0xbGQ8ojj/ZZ4n8xO T1yw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=oLCiBGKXgJ2e8RbmYM/M2sHb5tWGyCYCm+qWlZXGJrM=; b=drPftZFj77iW3rEk2BFa1rFjPJSMSbBvHvFBdn6Z6uiGQiRbzwAAACtcL7yNY4skpT BS5+EcWgwKQ0TqvWu8xBBO9BEonih93EaJPJx0Y63wWegbzK2WWSU6TQE9CjW/aWR9pH yg5EbXP2b49xcUvDJbHSRZkefvENCG4XJA1Z9Ekilyi7eNUFf70uMQwHGuTUmXUoMlBk Q/qMa9kwiUAMHU6OkFoLBB0C9uMH673gCiI1jyDF51rVxcr42I9KKgMVg5SWTS6acMST qKmbrT/D0blcirB5E2t6AfHIwJaRl4QfwYeEsrgrqFwax+9v2rzIPHqj+xCb+j3lwXNC EkrQ== X-Gm-Message-State: AOPr4FWHnVxMckAAix6nE60TjJZxWky3XrlCpCee49HS0qou2j75KA4xlc5qrdDLn7LYFefK/r/AxaSwcwrY/Q== X-Received: by 10.25.85.210 with SMTP id j201mr6062167lfb.132.1461263607111; Thu, 21 Apr 2016 11:33:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.213.19 with HTTP; Thu, 21 Apr 2016 11:32:47 -0700 (PDT) X-Originating-IP: [71.233.41.235] In-Reply-To: References: <0a8817dba2ea46c88ca67334a11c956d@XCH-ALN-003.cisco.com> From: Ted Lemon Date: Thu, 21 Apr 2016 14:32:47 -0400 Message-ID: To: otroan@employees.org Content-Type: multipart/alternative; boundary=001a1141d82639cab7053102f283 Archived-At: Cc: "dhcwg@ietf.org" , "Bernie Volz \(volz\)" Subject: Re: [dhcwg] Follow up from IETF-95 - draft-ietf-dhc-dhcpv6-prefix-length-hint-issue X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2016 18:33:38 -0000 --001a1141d82639cab7053102f283 Content-Type: text/plain; charset=UTF-8 Ole, the point is that if the document makes any normative statements, it's got to be standards-track. You are quite right that the particular statements you call out should not be made normatively, though! On Thu, Apr 21, 2016 at 2:28 PM, wrote: > there are some parts that could be made normative, like section 2.5. > but most of the document appears informational in nature. > paraphrased example: "the server should delegates a /48 if the client > requests it". > that's clearly policy, and a matter of the possible commercial > arrangement, seems strange if the IETF should try to codify that. > > I lean towards informational. > > the document also does not say anything about _how_ the client is supposed > to figure out what sized address block to request. > if the answer to that is manual configuration, then there are tens of ways > that could be done differently out of band. > > cheers, > Ole > > > > > On 21 Apr 2016, at 18:45, Bernie Volz (volz) wrote: > > > > Hi: > > > > One item that was raised at the IETF-95 DHC WG session was the recent > change (suggested by me before > draft-cui-dhc-dhcpv6-prefix-length-hint-issue-02 was published) to switch > draft-ietf-dhc-dhcpv6-prefix-length-hint-issue to Informational rather than > Standards Track. Marcin Siodelski suggested that the document be Standards > Track: > > > > The brief (draft) minutes for this discuss are: > > > > --- > > 5. DHCPv6 Prefix Length Hint Issues, Bernie Volz (for Tianxiang Li) - 10 > minutes, 14:50 > > draft-ietf-dhc-dhcpv6-prefix-length-hint-issue > > > > The authors believe work is ready for WGLC. > > > > Ian: Is this now informational? "This is the suggested way to do it"? > > Bernie: Correct. There were some discussions and the conclusion was > to not > > enforce it. > > Marcin (on jabber): I'd suggest this is standards track doc with > normative language > > in. Otherwise implementations will ignore hints. > > --- > > > > Once we resolve this open question (and after a possible update to the > document), we intend to start a WGLC on the document. > > > > Please respond with your comments as to whether this document should be > Informational or Standards Track by May 5th, 2016. Of course, any other > comments are welcome as well! > > > > Thanks! > > > > - Tomek & Bernie > > _______________________________________________ > > dhcwg mailing list > > dhcwg@ietf.org > > https://www.ietf.org/mailman/listinfo/dhcwg > > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg > > --001a1141d82639cab7053102f283 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Ole, the point is that if the document makes any normative= statements, it's got to be standards-track. =C2=A0 You are quite right= that the particular statements you call out should not be made normatively= , though!

On= Thu, Apr 21, 2016 at 2:28 PM, <otroan@employees.org> wr= ote:
there are some parts that could be m= ade normative, like section 2.5.
but most of the document appears informational in nature.
paraphrased example: "the server should delegates a /48 if the client = requests it".
that's clearly policy, and a matter of the possible commercial arrangem= ent, seems strange if the IETF should try to codify that.

I lean towards informational.

the document also does not say anything about _how_ the client is supposed = to figure out what sized address block to request.
if the answer to that is manual configuration, then there are tens of ways = that could be done differently out of band.

cheers,
Ole



> On 21 Apr 2016, at 18:45, Bernie Volz (volz) <volz@cisco.com> wrote:
>
> Hi:
>
> One item that was raised at the IETF-95 DHC WG session was the recent = change (suggested by me before draft-cui-dhc-dhcpv6-prefix-length-hint-issu= e-02 was published) to switch draft-ietf-dhc-dhcpv6-prefix-length-hint-issu= e to Informational rather than Standards Track. Marcin Siodelski suggested = that the document be Standards Track:
>
> The brief (draft) minutes for this discuss are:
>
> ---
> 5. DHCPv6 Prefix Length Hint Issues, Bernie Volz (for Tianxiang Li) - = 10 minutes, 14:50
>=C2=A0 =C2=A0 =C2=A0draft-ietf-dhc-dhcpv6-prefix-length-hint-issue
>
>=C2=A0 =C2=A0 =C2=A0The authors believe work is ready for WGLC.
>
>=C2=A0 =C2=A0 =C2=A0Ian: Is this now informational? "This is the s= uggested way to do it"?
>=C2=A0 =C2=A0 =C2=A0Bernie: Correct. There were some discussions and th= e conclusion was to not
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 enforce it.
>=C2=A0 =C2=A0 =C2=A0Marcin (on jabber): I'd suggest this is standar= ds track doc with normative language
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 in. Otherwise implementations will ignore h= ints.
> ---
>
> Once we resolve this open question (and after a possible update to the= document), we intend to start a WGLC on the document.
>
> Please respond with your comments as to whether this document should b= e Informational or Standards Track by May 5th, 2016. Of course, any other c= omments are welcome as well!
>
> Thanks!
>
> -=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Tomek & Bernie
> __________________= _____________________________
> dhcwg mailing list
> dhcwg@ietf.org
> https://www.ietf.org/mailman/listinfo/dhcwg


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


--001a1141d82639cab7053102f283-- From nobody Thu Apr 21 12:00:10 2016 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 6B2CF12DA1A for ; Thu, 21 Apr 2016 12:00:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.336 X-Spam-Level: X-Spam-Status: No, score=-1.336 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=employees.org; domainkeys=pass (1024-bit key) header.from=otroan@employees.org header.d=employees.org 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 rZvaUTJ595Nz for ; Thu, 21 Apr 2016 12:00:06 -0700 (PDT) Received: from incoming.kjsl.com (inbound02.kjsl.com [IPv6:2001:1868:2002::144]) by ietfa.amsl.com (Postfix) with ESMTP id 2922B12DB78 for ; Thu, 21 Apr 2016 12:00:06 -0700 (PDT) Received: from cowbell.employees.org ([IPv6:2001:1868:a000:17::142]) by ironport02.kjsl.com with ESMTP; 21 Apr 2016 19:00:05 +0000 Received: from cowbell.employees.org (localhost [127.0.0.1]) by cowbell.employees.org (Postfix) with ESMTP id F16639CD48; Thu, 21 Apr 2016 12:00:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h=subject :mime-version:content-type:from:in-reply-to:date:cc:message-id :references:to; s=selector1; bh=bqdPyhiq9zfxBgeir4n9njXlGtU=; b= krCDS3tG4UDn1E7dJNMcJUKGWas6IdX1nZyQZuOLf0W4g4k0D4HuncMbOtHaOdvP HNkKRyWDXey/pSeKcyDAQfhQDYpd8iCL+KXw8YZIpgAEe26iKRmrhMc+kMOawFQH FPWJoADPvMJFbgOkXQTnkGvl4JUPq+fif0g+x7wdEcs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h=subject :mime-version:content-type:from:in-reply-to:date:cc:message-id :references:to; q=dns; s=selector1; b=qw4gPUixLrVjjAHeURL7SVrRdQ 9gPnVTX/BWOEh/JqNC5YCVA+WanrypdSFTLQzDPssyXto+Od7IE6oR0zCjD/AvUH m73VxSei7KuHTQYYaHX3pS8UAXcuxVTZb0njur5lmGWE0UiaBKjGxZ594yGfHkhI N88FyGM1XATLDEhKM= Received: from h.hanazo.no (cm-84.213.17.83.getinternet.no [84.213.17.83]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: otroan) by cowbell.employees.org (Postfix) with ESMTPSA id 768EA9CCFC; Thu, 21 Apr 2016 12:00:02 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by h.hanazo.no (Postfix) with ESMTP id 16F431487631; Thu, 21 Apr 2016 21:00:00 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_1A64E499-C85A-458B-ACE0-18877C06BA81"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.6b2 From: otroan@employees.org In-Reply-To: Date: Thu, 21 Apr 2016 20:59:58 +0200 Message-Id: <778BB254-D3FF-4FF3-9AC5-CA2B8DF6F04D@employees.org> References: <0a8817dba2ea46c88ca67334a11c956d@XCH-ALN-003.cisco.com> To: Ted Lemon X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "dhcwg@ietf.org" , "Bernie Volz \(volz\)" Subject: Re: [dhcwg] Follow up from IETF-95 - draft-ietf-dhc-dhcpv6-prefix-length-hint-issue X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2016 19:00:08 -0000 --Apple-Mail=_1A64E499-C85A-458B-ACE0-18877C06BA81 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Ted, > Ole, the point is that if the document makes any normative statements, = it's got to be standards-track. You are quite right that the = particular statements you call out should not be made normatively, = though! Agree, one option if we can identify what's normative in the document = would be to add that text to the 3315bis and leave this informational. RFC2119-ifying the text the authors think should be normative would be a = good start. cheers, Ole >=20 > On Thu, Apr 21, 2016 at 2:28 PM, wrote: > there are some parts that could be made normative, like section 2.5. > but most of the document appears informational in nature. > paraphrased example: "the server should delegates a /48 if the client = requests it". > that's clearly policy, and a matter of the possible commercial = arrangement, seems strange if the IETF should try to codify that. >=20 > I lean towards informational. >=20 > the document also does not say anything about _how_ the client is = supposed to figure out what sized address block to request. > if the answer to that is manual configuration, then there are tens of = ways that could be done differently out of band. >=20 > cheers, > Ole >=20 >=20 >=20 > > On 21 Apr 2016, at 18:45, Bernie Volz (volz) wrote: > > > > Hi: > > > > One item that was raised at the IETF-95 DHC WG session was the = recent change (suggested by me before = draft-cui-dhc-dhcpv6-prefix-length-hint-issue-02 was published) to = switch draft-ietf-dhc-dhcpv6-prefix-length-hint-issue to Informational = rather than Standards Track. Marcin Siodelski suggested that the = document be Standards Track: > > > > The brief (draft) minutes for this discuss are: > > > > --- > > 5. DHCPv6 Prefix Length Hint Issues, Bernie Volz (for Tianxiang Li) = - 10 minutes, 14:50 > > draft-ietf-dhc-dhcpv6-prefix-length-hint-issue > > > > The authors believe work is ready for WGLC. > > > > Ian: Is this now informational? "This is the suggested way to do = it"? > > Bernie: Correct. There were some discussions and the conclusion = was to not > > enforce it. > > Marcin (on jabber): I'd suggest this is standards track doc with = normative language > > in. Otherwise implementations will ignore hints. > > --- > > > > Once we resolve this open question (and after a possible update to = the document), we intend to start a WGLC on the document. > > > > Please respond with your comments as to whether this document should = be Informational or Standards Track by May 5th, 2016. Of course, any = other comments are welcome as well! > > > > Thanks! > > > > - Tomek & Bernie > > _______________________________________________ > > dhcwg mailing list > > dhcwg@ietf.org > > https://www.ietf.org/mailman/listinfo/dhcwg >=20 >=20 > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg >=20 >=20 --Apple-Mail=_1A64E499-C85A-458B-ACE0-18877C06BA81 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJXGSMvAAoJEL7aWKiYQt92plMP/RWSgDE/lml6Lt6PJZHBBZ7+ PH1eDr1nWe9KPaOomRfCyRrCMRIKjfFTgChPViWcs8Nq1zrPKO8dTpJ7203WgXzd 0LNYHFX0oAAhlkM/8oKkuZRDe9huCrVNr9vQSLu/hUEaWXIM+xSAwkBQVtha1Rzw 41j9aiBtryGAI+b/cc1hU5XqXEQip55ph875aNNkV6yuXfIjSdgSfmD7dmWpRbxc ETWQWTokXvtbOaWu9ss5ZiIcOdkTdPtunkVsNnla715yn1O8eqht0I3/SKuWafbi wc9yUVM6fiAKG91cU0O7LYO0Tor/Hg3gYYigvOVxelXyCTaOYPEE6aOgaG0T+KW0 W93pXfieypR9s4kwxvEP5iWUnfaWRd7SGuVj5EYpS+jX4FYUhzRNN1tWHkW6z/1L xf1NEfrRvx5tZZc2f5Pr4HK1S7Rn//JzGA9eE0CiSpEcNVQEwk14XTurv015O5fR AB+ebRqH1Kl9tBjA530N/z6fLi8EXk/etBjnCTUjvJgpbrC8mIOPK15uSSn/sIxU dFrwrpa7D+V+9mYx5E5ZP+JeHLm+JXsnOA+Yk+uWuUYA6l3yFJK+PUAKi0/GBY0e ndgl1NQwWBESK7l6VGA/P6a3dh1CVEeNybr/HiCUBbsunFxCo3QoBFSEzc8MM1+h 794S/xdy6cGsZhpMGHIv =Sduc -----END PGP SIGNATURE----- --Apple-Mail=_1A64E499-C85A-458B-ACE0-18877C06BA81-- From nobody Thu Apr 21 13:02:17 2016 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 6A8C712E757 for ; Thu, 21 Apr 2016 13:02:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.517 X-Spam-Level: X-Spam-Status: No, score=-15.517 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_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, 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 JGp432QFS2Ut for ; Thu, 21 Apr 2016 13:02:14 -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 B772912E6C0 for ; Thu, 21 Apr 2016 13:02:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4430; q=dns/txt; s=iport; t=1461268934; x=1462478534; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=2RHk1UtwV/WQZdSyzlsRt6tHYQpHAH7ewdXyzap6QIY=; b=LKIJtpuioLafeFs3g/KQCf0DL5ETz4/FRMg6A30bkf3qyyU1Gbcb6hYM hMlrc9eqf7iTc5k3veB8WkHTStsqzZkQEsxYfQU9kO7leCPn3tzFByQuo 5QQJvG4cFmjq3SOLIrAihHcrODqQEDDiENyqORmbvZHY3tiOezheUz+g8 g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AFAgBUMRlX/4cNJK1UCoM4U30GuXcBD?= =?us-ascii?q?YF0Fw2FagKBMzgUAQEBAQEBAWUnhEEBAQEDAQEBATc0CwUHBAIBCBEEAQEBHgk?= =?us-ascii?q?HJwsUCQgBAQQBDQUIiBoIDsANAQEBAQEBAQEBAQEBAQEBAQEBAQEBEQSKbIQVE?= =?us-ascii?q?oVuBZgPAYV6iBKBbYRNiF2GI4kKAR4BAUKCNIE1bId4fgEBAQ?= X-IronPort-AV: E=Sophos;i="5.24,514,1454976000"; d="scan'208";a="264523595" Received: from alln-core-2.cisco.com ([173.36.13.135]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 21 Apr 2016 20:02:13 +0000 Received: from XCH-ALN-002.cisco.com (xch-aln-002.cisco.com [173.36.7.12]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id u3LK2DWi026905 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 21 Apr 2016 20:02:13 GMT Received: from xch-aln-003.cisco.com (173.36.7.13) by XCH-ALN-002.cisco.com (173.36.7.12) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 21 Apr 2016 15:02:13 -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.1104.009; Thu, 21 Apr 2016 15:02:12 -0500 From: "Bernie Volz (volz)" To: "otroan@employees.org" , Ted Lemon Thread-Topic: [dhcwg] Follow up from IETF-95 - draft-ietf-dhc-dhcpv6-prefix-length-hint-issue Thread-Index: AdGb7R0TyBAg+bfuQhK82oWwAy+O+AAOFV4AAAAqeIAAAPMKAAAIpAiw Date: Thu, 21 Apr 2016 20:02:12 +0000 Message-ID: References: <0a8817dba2ea46c88ca67334a11c956d@XCH-ALN-003.cisco.com> <778BB254-D3FF-4FF3-9AC5-CA2B8DF6F04D@employees.org> In-Reply-To: <778BB254-D3FF-4FF3-9AC5-CA2B8DF6F04D@employees.org> 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.77.252] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "dhcwg@ietf.org" Subject: Re: [dhcwg] Follow up from IETF-95 - draft-ietf-dhc-dhcpv6-prefix-length-hint-issue X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2016 20:02:16 -0000 While https://tools.ietf.org/html/draft-cui-dhc-dhcpv6-prefix-length-hint-i= ssue-01 was standards track and had RFC2119 "requirements language", it was= never used. So, the draft-cui-dhc-dhcpv6-prefix-length-hint-issue-02 was c= hanged to informational. However, The RFC2119 requirements language section= wasn't removed until draft-ietf-dhc-dhcpv6-prefix-length-hint-issue-00 was= published. So, perhaps Ole's suggestion for the authors to propose what they think sho= uld be normative (there was a suggestion that section 2.5 be) is a good one= . And, from that we can see if Standards Track is more appropriate. BTW: The text about assigning a /48 was in an "e.g." (for example) section.= And that would not be normative and was never intended to be: E.g. If the delegating router could only provide prefixes of lengths /30, /48, and /56, and the requesting router is requesting for a /50 in the prefix-length hint, then the delegating router should provide the /48 to the requesting router - Bernie -----Original Message----- From: otroan@employees.org [mailto:otroan@employees.org]=20 Sent: Thursday, April 21, 2016 3:00 PM To: Ted Lemon Cc: Bernie Volz (volz) ; dhcwg@ietf.org Subject: Re: [dhcwg] Follow up from IETF-95 - draft-ietf-dhc-dhcpv6-prefix-= length-hint-issue Ted, > Ole, the point is that if the document makes any normative statements, it= 's got to be standards-track. You are quite right that the particular sta= tements you call out should not be made normatively, though! Agree, one option if we can identify what's normative in the document would= be to add that text to the 3315bis and leave this informational. RFC2119-ifying the text the authors think should be normative would be a go= od start. cheers, Ole >=20 > On Thu, Apr 21, 2016 at 2:28 PM, wrote: > there are some parts that could be made normative, like section 2.5. > but most of the document appears informational in nature. > paraphrased example: "the server should delegates a /48 if the client req= uests it". > that's clearly policy, and a matter of the possible commercial arrangemen= t, seems strange if the IETF should try to codify that. >=20 > I lean towards informational. >=20 > the document also does not say anything about _how_ the client is suppose= d to figure out what sized address block to request. > if the answer to that is manual configuration, then there are tens of way= s that could be done differently out of band. >=20 > cheers, > Ole >=20 >=20 >=20 > > On 21 Apr 2016, at 18:45, Bernie Volz (volz) wrote: > > > > Hi: > > > > One item that was raised at the IETF-95 DHC WG session was the recent c= hange (suggested by me before draft-cui-dhc-dhcpv6-prefix-length-hint-issue= -02 was published) to switch draft-ietf-dhc-dhcpv6-prefix-length-hint-issue= to Informational rather than Standards Track. Marcin Siodelski suggested t= hat the document be Standards Track: > > > > The brief (draft) minutes for this discuss are: > > > > --- > > 5. DHCPv6 Prefix Length Hint Issues, Bernie Volz (for Tianxiang Li) - 1= 0 minutes, 14:50 > > draft-ietf-dhc-dhcpv6-prefix-length-hint-issue > > > > The authors believe work is ready for WGLC. > > > > Ian: Is this now informational? "This is the suggested way to do it= "? > > Bernie: Correct. There were some discussions and the conclusion was= to not > > enforce it. > > Marcin (on jabber): I'd suggest this is standards track doc with no= rmative language > > in. Otherwise implementations will ignore hints. > > --- > > > > Once we resolve this open question (and after a possible update to the = document), we intend to start a WGLC on the document. > > > > Please respond with your comments as to whether this document should be= Informational or Standards Track by May 5th, 2016. Of course, any other co= mments are welcome as well! > > > > Thanks! > > > > - Tomek & Bernie > > _______________________________________________ > > dhcwg mailing list > > dhcwg@ietf.org > > https://www.ietf.org/mailman/listinfo/dhcwg >=20 >=20 > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg >=20 >=20 From nobody Thu Apr 21 13:28:10 2016 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 8C2C412E21E for ; Thu, 21 Apr 2016 13:28:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 rw6gRJEjXG9a for ; Thu, 21 Apr 2016 13:28:07 -0700 (PDT) Received: from mail-lf0-x232.google.com (mail-lf0-x232.google.com [IPv6:2a00:1450:4010:c07::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 2E8B012D943 for ; Thu, 21 Apr 2016 13:28:03 -0700 (PDT) Received: by mail-lf0-x232.google.com with SMTP id e190so67753889lfe.0 for ; Thu, 21 Apr 2016 13:28:03 -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:date:message-id:subject:from:to :cc; bh=J1to7JIEJ3Zy65NW/1JQPWME/ScnNdJJGERi93zkSJY=; b=Zm/LEaULXd46tzRzYLmvf/6VRomkpZ1Pq2g1L2Nuiki3NQ/BJVTKVuQZQ8e8RaqUF3 CcsfK3RkVcMIyi1+RCeI9X1XixtQmAqz0n4bF34ooOa6cnStiQbvlXaTIFQttZQUIk78 rNh4AhHipVxKQh2/z1XQXHJPO8LMaiYfwEjLuLVaMuby1E21tFUaKnmqJ48c+mrzPjPW rk5ZF1AuH1LbAxUPeOlRip/dzdKGFcR28wJcnKu3PAk8XemazE3pQfBDJ2OxpC4DKo6y UDSvE8kwWM9uKE0pc8TO4UB4Dd80Ag1+hXhJ2xz1TITHhJ3UDiWDwcgSWKq1QO524RYg u2Yg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=J1to7JIEJ3Zy65NW/1JQPWME/ScnNdJJGERi93zkSJY=; b=YdTloYCXPOTm4ZLyEIO4TLS8TjfkyBcTY0duTUmI3UX+c1vrh2DE4/SCihK9XjtX8u 3oAqrbwcZyjevIohS4eznOmE/w+qHO2RRorcilexauV5qRgrkyFdGg2oNMGQnrxp6dsh x4/9QIMuzr+feQK6cqBCBEJ/zY9TC9If9UT9n9+TUFCI8hXbwOa+hWVTvY9TuQYk+FNU iA37lFQDy8C/CI1NSgnxCEAEQcbjmB3LlKfkY9T6WXIUFnuYdhUTniG1m+LyJx1wly6D Osi7IbFBegaIGM9EwnfU63UAt3EHxnLsRdZLbZbzQomJn5VrOjEFE8RY4qGd8XfwWW+K TO4Q== X-Gm-Message-State: AOPr4FWoQbcWCX0ZPO4PIcbxnYsJzFyeERuBAArkm4gNiCbyhVZEwXHw0NtxOX5BBLB1T9n70MEuNAAOUmSv5A== MIME-Version: 1.0 X-Received: by 10.25.205.146 with SMTP id d140mr7556186lfg.109.1461270481315; Thu, 21 Apr 2016 13:28:01 -0700 (PDT) Received: by 10.25.213.19 with HTTP; Thu, 21 Apr 2016 13:28:01 -0700 (PDT) X-Originating-IP: [71.233.41.235] Received: by 10.25.213.19 with HTTP; Thu, 21 Apr 2016 13:28:01 -0700 (PDT) In-Reply-To: References: <0a8817dba2ea46c88ca67334a11c956d@XCH-ALN-003.cisco.com> <778BB254-D3FF-4FF3-9AC5-CA2B8DF6F04D@employees.org> Date: Thu, 21 Apr 2016 16:28:01 -0400 Message-ID: From: Ted Lemon To: "Bernie Volz (volz)" Content-Type: multipart/alternative; boundary=001a114128caf5c4290531048b66 Archived-At: Cc: dhcwg@ietf.org Subject: Re: [dhcwg] Follow up from IETF-95 - draft-ietf-dhc-dhcpv6-prefix-length-hint-issue X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2016 20:28:09 -0000 --001a114128caf5c4290531048b66 Content-Type: text/plain; charset=UTF-8 Ole's suggestion is correct except that if we have normative language in the document, the iesg is going to ask why it's informative. There isn't any question to debate here. Either it's normative, iwc PS, or it's not normative, iwc informative. I feel like Ole may just be resisting publishing it at all, iwc we should do that, not confuse the iesg. But I think that would be the wrong move, because we don't know when 3315bis will get consensus. On Apr 21, 2016 4:02 PM, "Bernie Volz (volz)" wrote: > While > https://tools.ietf.org/html/draft-cui-dhc-dhcpv6-prefix-length-hint-issue-01 > was standards track and had RFC2119 "requirements language", it was never > used. So, the draft-cui-dhc-dhcpv6-prefix-length-hint-issue-02 was changed > to informational. However, The RFC2119 requirements language section wasn't > removed until draft-ietf-dhc-dhcpv6-prefix-length-hint-issue-00 was > published. > > So, perhaps Ole's suggestion for the authors to propose what they think > should be normative (there was a suggestion that section 2.5 be) is a good > one. And, from that we can see if Standards Track is more appropriate. > > BTW: The text about assigning a /48 was in an "e.g." (for example) > section. And that would not be normative and was never intended to be: > > E.g. If the delegating router could only > provide prefixes of lengths /30, /48, and /56, and the requesting > router is requesting for a /50 in the prefix-length hint, then the > delegating router should provide the /48 to the requesting router > > - Bernie > > -----Original Message----- > From: otroan@employees.org [mailto:otroan@employees.org] > Sent: Thursday, April 21, 2016 3:00 PM > To: Ted Lemon > Cc: Bernie Volz (volz) ; dhcwg@ietf.org > Subject: Re: [dhcwg] Follow up from IETF-95 - > draft-ietf-dhc-dhcpv6-prefix-length-hint-issue > > Ted, > > > Ole, the point is that if the document makes any normative statements, > it's got to be standards-track. You are quite right that the particular > statements you call out should not be made normatively, though! > > Agree, one option if we can identify what's normative in the document > would be to add that text to the 3315bis and leave this informational. > > RFC2119-ifying the text the authors think should be normative would be a > good start. > > cheers, > Ole > > > > > On Thu, Apr 21, 2016 at 2:28 PM, wrote: > > there are some parts that could be made normative, like section 2.5. > > but most of the document appears informational in nature. > > paraphrased example: "the server should delegates a /48 if the client > requests it". > > that's clearly policy, and a matter of the possible commercial > arrangement, seems strange if the IETF should try to codify that. > > > > I lean towards informational. > > > > the document also does not say anything about _how_ the client is > supposed to figure out what sized address block to request. > > if the answer to that is manual configuration, then there are tens of > ways that could be done differently out of band. > > > > cheers, > > Ole > > > > > > > > > On 21 Apr 2016, at 18:45, Bernie Volz (volz) wrote: > > > > > > Hi: > > > > > > One item that was raised at the IETF-95 DHC WG session was the recent > change (suggested by me before > draft-cui-dhc-dhcpv6-prefix-length-hint-issue-02 was published) to switch > draft-ietf-dhc-dhcpv6-prefix-length-hint-issue to Informational rather than > Standards Track. Marcin Siodelski suggested that the document be Standards > Track: > > > > > > The brief (draft) minutes for this discuss are: > > > > > > --- > > > 5. DHCPv6 Prefix Length Hint Issues, Bernie Volz (for Tianxiang Li) - > 10 minutes, 14:50 > > > draft-ietf-dhc-dhcpv6-prefix-length-hint-issue > > > > > > The authors believe work is ready for WGLC. > > > > > > Ian: Is this now informational? "This is the suggested way to do > it"? > > > Bernie: Correct. There were some discussions and the conclusion > was to not > > > enforce it. > > > Marcin (on jabber): I'd suggest this is standards track doc with > normative language > > > in. Otherwise implementations will ignore hints. > > > --- > > > > > > Once we resolve this open question (and after a possible update to the > document), we intend to start a WGLC on the document. > > > > > > Please respond with your comments as to whether this document should > be Informational or Standards Track by May 5th, 2016. Of course, any other > comments are welcome as well! > > > > > > Thanks! > > > > > > - Tomek & Bernie > > > _______________________________________________ > > > dhcwg mailing list > > > dhcwg@ietf.org > > > https://www.ietf.org/mailman/listinfo/dhcwg > > > > > > _______________________________________________ > > dhcwg mailing list > > dhcwg@ietf.org > > https://www.ietf.org/mailman/listinfo/dhcwg > > > > > > --001a114128caf5c4290531048b66 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Ole's suggestion is correct except that if we have norma= tive language in the document, the iesg is going to ask why it's inform= ative. There isn't any question to debate here. Either it's normati= ve, iwc PS, or it's not normative, iwc informative. I feel like Ole may= just be resisting publishing it at all, iwc we should do that, not confuse= the iesg. But I think that would be the wrong move, because we don't k= now when 3315bis will get consensus.

On Apr 21, 2016 4:02 PM, "Bernie Volz (volz= )" <volz@cisco.com> wrote:=
While https://tools.ietf.org/html/draft-cui= -dhc-dhcpv6-prefix-length-hint-issue-01 was standards track and had RFC= 2119 "requirements language", it was never used. So, the draft-cu= i-dhc-dhcpv6-prefix-length-hint-issue-02 was changed to informational. Howe= ver, The RFC2119 requirements language section wasn't removed until dra= ft-ietf-dhc-dhcpv6-prefix-length-hint-issue-00 was published.

So, perhaps Ole's suggestion for the authors to propose what they think= should be normative (there was a suggestion that section 2.5 be) is a good= one. And, from that we can see if Standards Track is more appropriate.

BTW: The text about assigning a /48 was in an "e.g." (for example= ) section. And that would not be normative and was never intended to be:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 E.g.=C2=A0 If the delegating router = could only
=C2=A0 =C2=A0provide prefixes of lengths /30, /48, and /56, and the request= ing
=C2=A0 =C2=A0router is requesting for a /50 in the prefix-length hint, then= the
=C2=A0 =C2=A0delegating router should provide the /48 to the requesting rou= ter

- Bernie

-----Original Message-----
From: otroan@employees.org [mai= lto:otroan@employees.org]
Sent: Thursday, April 21, 2016 3:00 PM
To: Ted Lemon <mellon@fugue.com&= gt;
Cc: Bernie Volz (volz) <volz@cisco.com= >; dhcwg@ietf.org
Subject: Re: [dhcwg] Follow up from IETF-95 - draft-ietf-dhc-dhcpv6-prefix-= length-hint-issue

Ted,

> Ole, the point is that if the document makes any normative statements,= it's got to be standards-track.=C2=A0 =C2=A0You are quite right that t= he particular statements you call out should not be made normatively, thoug= h!

Agree, one option if we can identify what's normative in the document w= ould be to add that text to the 3315bis and leave this informational.

RFC2119-ifying the text the authors think should be normative would be a go= od start.

cheers,
Ole

>
> On Thu, Apr 21, 2016 at 2:28 PM, <otroan@employees.org> wrote:
> there are some parts that could be made normative, like section 2.5. > but most of the document appears informational in nature.
> paraphrased example: "the server should delegates a /48 if the cl= ient requests it".
> that's clearly policy, and a matter of the possible commercial arr= angement, seems strange if the IETF should try to codify that.
>
> I lean towards informational.
>
> the document also does not say anything about _how_ the client is supp= osed to figure out what sized address block to request.
> if the answer to that is manual configuration, then there are tens of = ways that could be done differently out of band.
>
> cheers,
> Ole
>
>
>
> > On 21 Apr 2016, at 18:45, Bernie Volz (volz) <volz@cisco.com> wrote:
> >
> > Hi:
> >
> > One item that was raised at the IETF-95 DHC WG session was the re= cent change (suggested by me before draft-cui-dhc-dhcpv6-prefix-length-hint= -issue-02 was published) to switch draft-ietf-dhc-dhcpv6-prefix-length-hint= -issue to Informational rather than Standards Track. Marcin Siodelski sugge= sted that the document be Standards Track:
> >
> > The brief (draft) minutes for this discuss are:
> >
> > ---
> > 5. DHCPv6 Prefix Length Hint Issues, Bernie Volz (for Tianxiang L= i) - 10 minutes, 14:50
> >=C2=A0 =C2=A0 =C2=A0draft-ietf-dhc-dhcpv6-prefix-length-hint-issue=
> >
> >=C2=A0 =C2=A0 =C2=A0The authors believe work is ready for WGLC. > >
> >=C2=A0 =C2=A0 =C2=A0Ian: Is this now informational? "This is = the suggested way to do it"?
> >=C2=A0 =C2=A0 =C2=A0Bernie: Correct. There were some discussions a= nd the conclusion was to not
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 enforce it.
> >=C2=A0 =C2=A0 =C2=A0Marcin (on jabber): I'd suggest this is st= andards track doc with normative language
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 in. Otherwise implementations will ign= ore hints.
> > ---
> >
> > Once we resolve this open question (and after a possible update t= o the document), we intend to start a WGLC on the document.
> >
> > Please respond with your comments as to whether this document sho= uld be Informational or Standards Track by May 5th, 2016. Of course, any ot= her comments are welcome as well!
> >
> > Thanks!
> >
> > -=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Tomek & Bernie
> > _______________________________________________
> > dhcwg mailing list
> > dhcwg@ietf.org
> > https://www.ietf.org/mailman/listinfo/dhcwg=
>
>
> _______________________________________________
> dhcwg mailing list
> dhcwg@ietf.org
> https://www.ietf.org/mailman/listinfo/dhcwg
>
>

--001a114128caf5c4290531048b66-- From nobody Thu Apr 21 14:14:15 2016 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 A134F12E51D for ; Thu, 21 Apr 2016 14:14:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.516 X-Spam-Level: X-Spam-Status: No, score=-15.516 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.996, 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 eUsUQnraglX0 for ; Thu, 21 Apr 2016 14:14:08 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6740412DF13 for ; Thu, 21 Apr 2016 14:14:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=24696; q=dns/txt; s=iport; t=1461273248; x=1462482848; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=2Yj3fvzUfCuElMM66t+g8cdC10hXbWda3dGmxi3jd6Q=; b=kPoHG6nagRMlwfcP4s00fP3G+9roHhv1slEVFI33CMfsOkSd3YkJnq9J jxZsbFxx/KTcq/ybcEhsIq5poafSu6jS1NpnxBMIOj5qmDyvTPpOy/kQ0 Tgzb7m6hVwIYwsvh7svRUssffkt2DdCAz5UJwCFzveVRdmkPvfd1jex4P A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BPAgAyQhlX/5NdJa1UCoJsTFN9BrUFh?= =?us-ascii?q?HIBDYF0FwEMhWoCHIEROBQBAQEBAQEBZSeEQQEBAQMBAQEBIApBCwUHBAIBCA4?= =?us-ascii?q?DBAEBAScDAgICJQsUCQgCBA4FCIgaCA6ubZEfAQEBAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBEQSKbIQVEkUJgkqCVgWYDwGFeogSgW2ETYhdhiOJCgEeAQFCgjSBNWyHeH4?= =?us-ascii?q?BAQE?= X-IronPort-AV: E=Sophos; i="5.24,514,1454976000"; d="scan'208,217"; a="96285722" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 21 Apr 2016 21:13:40 +0000 Received: from XCH-RCD-001.cisco.com (xch-rcd-001.cisco.com [173.37.102.11]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id u3LLDedD025623 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 21 Apr 2016 21:13:40 GMT Received: from xch-aln-003.cisco.com (173.36.7.13) by XCH-RCD-001.cisco.com (173.37.102.11) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 21 Apr 2016 16:13:39 -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.1104.009; Thu, 21 Apr 2016 16:13:39 -0500 From: "Bernie Volz (volz)" To: Ted Lemon Thread-Topic: [dhcwg] Follow up from IETF-95 - draft-ietf-dhc-dhcpv6-prefix-length-hint-issue Thread-Index: AdGb7R0TyBAg+bfuQhK82oWwAy+O+AAOFV4AAAAqeIAAAPMKAAAIpAiw///TeYCAAEdW4A== Date: Thu, 21 Apr 2016 21:13:39 +0000 Message-ID: <48d576be7b85448b99e9b2745837e59a@XCH-ALN-003.cisco.com> References: <0a8817dba2ea46c88ca67334a11c956d@XCH-ALN-003.cisco.com> <778BB254-D3FF-4FF3-9AC5-CA2B8DF6F04D@employees.org> 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.131.77.252] Content-Type: multipart/alternative; boundary="_000_48d576be7b85448b99e9b2745837e59aXCHALN003ciscocom_" MIME-Version: 1.0 Archived-At: Cc: "dhcwg@ietf.org" Subject: Re: [dhcwg] Follow up from IETF-95 - draft-ietf-dhc-dhcpv6-prefix-length-hint-issue X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2016 21:14:12 -0000 --_000_48d576be7b85448b99e9b2745837e59aXCHALN003ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGVkIOKApiBpZiB3ZSBwdXQgbm9ybWF0aXZlIHRleHQgaW4sIGl0IHdpbGwgYmUgU3RhbmRhcmRz IFRyYWNrLg0KDQoNCi0gICAgICAgICAgQmVybmllDQoNCkZyb206IFRlZCBMZW1vbiBbbWFpbHRv Om1lbGxvbkBmdWd1ZS5jb21dDQpTZW50OiBUaHVyc2RheSwgQXByaWwgMjEsIDIwMTYgNDoyOCBQ TQ0KVG86IEJlcm5pZSBWb2x6ICh2b2x6KSA8dm9sekBjaXNjby5jb20+DQpDYzogZGhjd2dAaWV0 Zi5vcmc7IG90cm9hbkBlbXBsb3llZXMub3JnDQpTdWJqZWN0OiBSRTogW2RoY3dnXSBGb2xsb3cg dXAgZnJvbSBJRVRGLTk1IC0gZHJhZnQtaWV0Zi1kaGMtZGhjcHY2LXByZWZpeC1sZW5ndGgtaGlu dC1pc3N1ZQ0KDQoNCk9sZSdzIHN1Z2dlc3Rpb24gaXMgY29ycmVjdCBleGNlcHQgdGhhdCBpZiB3 ZSBoYXZlIG5vcm1hdGl2ZSBsYW5ndWFnZSBpbiB0aGUgZG9jdW1lbnQsIHRoZSBpZXNnIGlzIGdv aW5nIHRvIGFzayB3aHkgaXQncyBpbmZvcm1hdGl2ZS4gVGhlcmUgaXNuJ3QgYW55IHF1ZXN0aW9u IHRvIGRlYmF0ZSBoZXJlLiBFaXRoZXIgaXQncyBub3JtYXRpdmUsIGl3YyBQUywgb3IgaXQncyBu b3Qgbm9ybWF0aXZlLCBpd2MgaW5mb3JtYXRpdmUuIEkgZmVlbCBsaWtlIE9sZSBtYXkganVzdCBi ZSByZXNpc3RpbmcgcHVibGlzaGluZyBpdCBhdCBhbGwsIGl3YyB3ZSBzaG91bGQgZG8gdGhhdCwg bm90IGNvbmZ1c2UgdGhlIGllc2cuIEJ1dCBJIHRoaW5rIHRoYXQgd291bGQgYmUgdGhlIHdyb25n IG1vdmUsIGJlY2F1c2Ugd2UgZG9uJ3Qga25vdyB3aGVuIDMzMTViaXMgd2lsbCBnZXQgY29uc2Vu c3VzLg0KT24gQXByIDIxLCAyMDE2IDQ6MDIgUE0sICJCZXJuaWUgVm9seiAodm9seikiIDx2b2x6 QGNpc2NvLmNvbTxtYWlsdG86dm9sekBjaXNjby5jb20+PiB3cm90ZToNCldoaWxlIGh0dHBzOi8v dG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1jdWktZGhjLWRoY3B2Ni1wcmVmaXgtbGVuZ3RoLWhp bnQtaXNzdWUtMDEgd2FzIHN0YW5kYXJkcyB0cmFjayBhbmQgaGFkIFJGQzIxMTkgInJlcXVpcmVt ZW50cyBsYW5ndWFnZSIsIGl0IHdhcyBuZXZlciB1c2VkLiBTbywgdGhlIGRyYWZ0LWN1aS1kaGMt ZGhjcHY2LXByZWZpeC1sZW5ndGgtaGludC1pc3N1ZS0wMiB3YXMgY2hhbmdlZCB0byBpbmZvcm1h dGlvbmFsLiBIb3dldmVyLCBUaGUgUkZDMjExOSByZXF1aXJlbWVudHMgbGFuZ3VhZ2Ugc2VjdGlv biB3YXNuJ3QgcmVtb3ZlZCB1bnRpbCBkcmFmdC1pZXRmLWRoYy1kaGNwdjYtcHJlZml4LWxlbmd0 aC1oaW50LWlzc3VlLTAwIHdhcyBwdWJsaXNoZWQuDQoNClNvLCBwZXJoYXBzIE9sZSdzIHN1Z2dl c3Rpb24gZm9yIHRoZSBhdXRob3JzIHRvIHByb3Bvc2Ugd2hhdCB0aGV5IHRoaW5rIHNob3VsZCBi ZSBub3JtYXRpdmUgKHRoZXJlIHdhcyBhIHN1Z2dlc3Rpb24gdGhhdCBzZWN0aW9uIDIuNSBiZSkg aXMgYSBnb29kIG9uZS4gQW5kLCBmcm9tIHRoYXQgd2UgY2FuIHNlZSBpZiBTdGFuZGFyZHMgVHJh Y2sgaXMgbW9yZSBhcHByb3ByaWF0ZS4NCg0KQlRXOiBUaGUgdGV4dCBhYm91dCBhc3NpZ25pbmcg YSAvNDggd2FzIGluIGFuICJlLmcuIiAoZm9yIGV4YW1wbGUpIHNlY3Rpb24uIEFuZCB0aGF0IHdv dWxkIG5vdCBiZSBub3JtYXRpdmUgYW5kIHdhcyBuZXZlciBpbnRlbmRlZCB0byBiZToNCg0KICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBFLmcuICBJZiB0aGUgZGVsZWdhdGluZyByb3V0 ZXIgY291bGQgb25seQ0KICAgcHJvdmlkZSBwcmVmaXhlcyBvZiBsZW5ndGhzIC8zMCwgLzQ4LCBh bmQgLzU2LCBhbmQgdGhlIHJlcXVlc3RpbmcNCiAgIHJvdXRlciBpcyByZXF1ZXN0aW5nIGZvciBh IC81MCBpbiB0aGUgcHJlZml4LWxlbmd0aCBoaW50LCB0aGVuIHRoZQ0KICAgZGVsZWdhdGluZyBy b3V0ZXIgc2hvdWxkIHByb3ZpZGUgdGhlIC80OCB0byB0aGUgcmVxdWVzdGluZyByb3V0ZXINCg0K LSBCZXJuaWUNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IG90cm9hbkBlbXBs b3llZXMub3JnPG1haWx0bzpvdHJvYW5AZW1wbG95ZWVzLm9yZz4gW21haWx0bzpvdHJvYW5AZW1w bG95ZWVzLm9yZzxtYWlsdG86b3Ryb2FuQGVtcGxveWVlcy5vcmc+XQ0KU2VudDogVGh1cnNkYXks IEFwcmlsIDIxLCAyMDE2IDM6MDAgUE0NClRvOiBUZWQgTGVtb24gPG1lbGxvbkBmdWd1ZS5jb208 bWFpbHRvOm1lbGxvbkBmdWd1ZS5jb20+Pg0KQ2M6IEJlcm5pZSBWb2x6ICh2b2x6KSA8dm9sekBj aXNjby5jb208bWFpbHRvOnZvbHpAY2lzY28uY29tPj47IGRoY3dnQGlldGYub3JnPG1haWx0bzpk aGN3Z0BpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbZGhjd2ddIEZvbGxvdyB1cCBmcm9tIElFVEYt OTUgLSBkcmFmdC1pZXRmLWRoYy1kaGNwdjYtcHJlZml4LWxlbmd0aC1oaW50LWlzc3VlDQoNClRl ZCwNCg0KPiBPbGUsIHRoZSBwb2ludCBpcyB0aGF0IGlmIHRoZSBkb2N1bWVudCBtYWtlcyBhbnkg bm9ybWF0aXZlIHN0YXRlbWVudHMsIGl0J3MgZ290IHRvIGJlIHN0YW5kYXJkcy10cmFjay4gICBZ b3UgYXJlIHF1aXRlIHJpZ2h0IHRoYXQgdGhlIHBhcnRpY3VsYXIgc3RhdGVtZW50cyB5b3UgY2Fs bCBvdXQgc2hvdWxkIG5vdCBiZSBtYWRlIG5vcm1hdGl2ZWx5LCB0aG91Z2ghDQoNCkFncmVlLCBv bmUgb3B0aW9uIGlmIHdlIGNhbiBpZGVudGlmeSB3aGF0J3Mgbm9ybWF0aXZlIGluIHRoZSBkb2N1 bWVudCB3b3VsZCBiZSB0byBhZGQgdGhhdCB0ZXh0IHRvIHRoZSAzMzE1YmlzIGFuZCBsZWF2ZSB0 aGlzIGluZm9ybWF0aW9uYWwuDQoNClJGQzIxMTktaWZ5aW5nIHRoZSB0ZXh0IHRoZSBhdXRob3Jz IHRoaW5rIHNob3VsZCBiZSBub3JtYXRpdmUgd291bGQgYmUgYSBnb29kIHN0YXJ0Lg0KDQpjaGVl cnMsDQpPbGUNCg0KPg0KPiBPbiBUaHUsIEFwciAyMSwgMjAxNiBhdCAyOjI4IFBNLCA8b3Ryb2Fu QGVtcGxveWVlcy5vcmc8bWFpbHRvOm90cm9hbkBlbXBsb3llZXMub3JnPj4gd3JvdGU6DQo+IHRo ZXJlIGFyZSBzb21lIHBhcnRzIHRoYXQgY291bGQgYmUgbWFkZSBub3JtYXRpdmUsIGxpa2Ugc2Vj dGlvbiAyLjUuDQo+IGJ1dCBtb3N0IG9mIHRoZSBkb2N1bWVudCBhcHBlYXJzIGluZm9ybWF0aW9u YWwgaW4gbmF0dXJlLg0KPiBwYXJhcGhyYXNlZCBleGFtcGxlOiAidGhlIHNlcnZlciBzaG91bGQg ZGVsZWdhdGVzIGEgLzQ4IGlmIHRoZSBjbGllbnQgcmVxdWVzdHMgaXQiLg0KPiB0aGF0J3MgY2xl YXJseSBwb2xpY3ksIGFuZCBhIG1hdHRlciBvZiB0aGUgcG9zc2libGUgY29tbWVyY2lhbCBhcnJh bmdlbWVudCwgc2VlbXMgc3RyYW5nZSBpZiB0aGUgSUVURiBzaG91bGQgdHJ5IHRvIGNvZGlmeSB0 aGF0Lg0KPg0KPiBJIGxlYW4gdG93YXJkcyBpbmZvcm1hdGlvbmFsLg0KPg0KPiB0aGUgZG9jdW1l bnQgYWxzbyBkb2VzIG5vdCBzYXkgYW55dGhpbmcgYWJvdXQgX2hvd18gdGhlIGNsaWVudCBpcyBz dXBwb3NlZCB0byBmaWd1cmUgb3V0IHdoYXQgc2l6ZWQgYWRkcmVzcyBibG9jayB0byByZXF1ZXN0 Lg0KPiBpZiB0aGUgYW5zd2VyIHRvIHRoYXQgaXMgbWFudWFsIGNvbmZpZ3VyYXRpb24sIHRoZW4g dGhlcmUgYXJlIHRlbnMgb2Ygd2F5cyB0aGF0IGNvdWxkIGJlIGRvbmUgZGlmZmVyZW50bHkgb3V0 IG9mIGJhbmQuDQo+DQo+IGNoZWVycywNCj4gT2xlDQo+DQo+DQo+DQo+ID4gT24gMjEgQXByIDIw MTYsIGF0IDE4OjQ1LCBCZXJuaWUgVm9seiAodm9seikgPHZvbHpAY2lzY28uY29tPG1haWx0bzp2 b2x6QGNpc2NvLmNvbT4+IHdyb3RlOg0KPiA+DQo+ID4gSGk6DQo+ID4NCj4gPiBPbmUgaXRlbSB0 aGF0IHdhcyByYWlzZWQgYXQgdGhlIElFVEYtOTUgREhDIFdHIHNlc3Npb24gd2FzIHRoZSByZWNl bnQgY2hhbmdlIChzdWdnZXN0ZWQgYnkgbWUgYmVmb3JlIGRyYWZ0LWN1aS1kaGMtZGhjcHY2LXBy ZWZpeC1sZW5ndGgtaGludC1pc3N1ZS0wMiB3YXMgcHVibGlzaGVkKSB0byBzd2l0Y2ggZHJhZnQt aWV0Zi1kaGMtZGhjcHY2LXByZWZpeC1sZW5ndGgtaGludC1pc3N1ZSB0byBJbmZvcm1hdGlvbmFs IHJhdGhlciB0aGFuIFN0YW5kYXJkcyBUcmFjay4gTWFyY2luIFNpb2RlbHNraSBzdWdnZXN0ZWQg dGhhdCB0aGUgZG9jdW1lbnQgYmUgU3RhbmRhcmRzIFRyYWNrOg0KPiA+DQo+ID4gVGhlIGJyaWVm IChkcmFmdCkgbWludXRlcyBmb3IgdGhpcyBkaXNjdXNzIGFyZToNCj4gPg0KPiA+IC0tLQ0KPiA+ IDUuIERIQ1B2NiBQcmVmaXggTGVuZ3RoIEhpbnQgSXNzdWVzLCBCZXJuaWUgVm9seiAoZm9yIFRp YW54aWFuZyBMaSkgLSAxMCBtaW51dGVzLCAxNDo1MA0KPiA+ICAgICBkcmFmdC1pZXRmLWRoYy1k aGNwdjYtcHJlZml4LWxlbmd0aC1oaW50LWlzc3VlDQo+ID4NCj4gPiAgICAgVGhlIGF1dGhvcnMg YmVsaWV2ZSB3b3JrIGlzIHJlYWR5IGZvciBXR0xDLg0KPiA+DQo+ID4gICAgIElhbjogSXMgdGhp cyBub3cgaW5mb3JtYXRpb25hbD8gIlRoaXMgaXMgdGhlIHN1Z2dlc3RlZCB3YXkgdG8gZG8gaXQi Pw0KPiA+ICAgICBCZXJuaWU6IENvcnJlY3QuIFRoZXJlIHdlcmUgc29tZSBkaXNjdXNzaW9ucyBh bmQgdGhlIGNvbmNsdXNpb24gd2FzIHRvIG5vdA0KPiA+ICAgICAgICBlbmZvcmNlIGl0Lg0KPiA+ ICAgICBNYXJjaW4gKG9uIGphYmJlcik6IEknZCBzdWdnZXN0IHRoaXMgaXMgc3RhbmRhcmRzIHRy YWNrIGRvYyB3aXRoIG5vcm1hdGl2ZSBsYW5ndWFnZQ0KPiA+ICAgICAgICBpbi4gT3RoZXJ3aXNl IGltcGxlbWVudGF0aW9ucyB3aWxsIGlnbm9yZSBoaW50cy4NCj4gPiAtLS0NCj4gPg0KPiA+IE9u Y2Ugd2UgcmVzb2x2ZSB0aGlzIG9wZW4gcXVlc3Rpb24gKGFuZCBhZnRlciBhIHBvc3NpYmxlIHVw ZGF0ZSB0byB0aGUgZG9jdW1lbnQpLCB3ZSBpbnRlbmQgdG8gc3RhcnQgYSBXR0xDIG9uIHRoZSBk b2N1bWVudC4NCj4gPg0KPiA+IFBsZWFzZSByZXNwb25kIHdpdGggeW91ciBjb21tZW50cyBhcyB0 byB3aGV0aGVyIHRoaXMgZG9jdW1lbnQgc2hvdWxkIGJlIEluZm9ybWF0aW9uYWwgb3IgU3RhbmRh cmRzIFRyYWNrIGJ5IE1heSA1dGgsIDIwMTYuIE9mIGNvdXJzZSwgYW55IG90aGVyIGNvbW1lbnRz IGFyZSB3ZWxjb21lIGFzIHdlbGwhDQo+ID4NCj4gPiBUaGFua3MhDQo+ID4NCj4gPiAtICAgICAg ICAgIFRvbWVrICYgQmVybmllDQo+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCj4gPiBkaGN3ZyBtYWlsaW5nIGxpc3QNCj4gPiBkaGN3Z0BpZXRmLm9y ZzxtYWlsdG86ZGhjd2dAaWV0Zi5vcmc+DQo+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9kaGN3Zw0KPg0KPg0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KPiBkaGN3ZyBtYWlsaW5nIGxpc3QNCj4gZGhjd2dAaWV0Zi5vcmc8 bWFpbHRvOmRoY3dnQGlldGYub3JnPg0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL2RoY3dnDQo+DQo+DQo= --_000_48d576be7b85448b99e9b2745837e59aXCHALN003ciscocom_ 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 aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnANCgl7 bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdp bi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6 MGluOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIs c2VyaWY7fQ0KcC5Nc29MaXN0UGFyYWdyYXBoLCBsaS5Nc29MaXN0UGFyYWdyYXBoLCBkaXYuTXNv TGlzdFBhcmFncmFwaA0KCXttc28tc3R5bGUtcHJpb3JpdHk6MzQ7DQoJbWFyZ2luLXRvcDowaW47 DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltYXJnaW4tYm90dG9tOjBpbjsNCgltYXJnaW4tbGVmdDou NWluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQt ZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21z by1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5z LXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5 cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KQHBh Z2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBp biAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30N Ci8qIExpc3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0LWlkOjE2MzU5MTMz MjY7DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi0xMjE0 MTg3MzI4IDEzOTMzMjkwNDYgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2 OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTM7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJe21z by1sZXZlbC1zdGFydC1hdDoyOw0KCW1zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCglt c28tbGV2ZWwtdGV4dDotOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6 IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6Q2FsaWJyaTsN Cgltc28tYmlkaS1mb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9DQpAbGlzdCBsMDpsZXZl bDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87 DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps ZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30N CkBsaXN0IGwwOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNv LWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6 V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpi dWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJ Zm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4y NWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWw2DQoJe21z by1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNv LWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6 bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4 dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0K QGxpc3QgbDA6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28t bGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNv dXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0K CWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpvbA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQp1bA0K CXttYXJnaW4tYm90dG9tOjBpbjt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1s Pg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1s PjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpl eHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVs YXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGlu az0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlRlZCDigKYg aWYgd2UgcHV0IG5vcm1hdGl2ZSB0ZXh0IGluLCBpdCB3aWxsIGJlIFN0YW5kYXJkcyBUcmFjay48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0LWluZGVudDotLjI1aW47bXNvLWxpc3Q6bDAg bGV2ZWwxIGxmbzEiPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MUY0OTdEIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj4tPHNwYW4gc3R5bGU9ImZvbnQ6 Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwh W2VuZGlmXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+QmVybmllPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMx RjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IFRl ZCBMZW1vbiBbbWFpbHRvOm1lbGxvbkBmdWd1ZS5jb21dDQo8YnI+DQo8Yj5TZW50OjwvYj4gVGh1 cnNkYXksIEFwcmlsIDIxLCAyMDE2IDQ6MjggUE08YnI+DQo8Yj5Ubzo8L2I+IEJlcm5pZSBWb2x6 ICh2b2x6KSAmbHQ7dm9sekBjaXNjby5jb20mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBkaGN3Z0BpZXRm Lm9yZzsgb3Ryb2FuQGVtcGxveWVlcy5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUkU6IFtkaGN3 Z10gRm9sbG93IHVwIGZyb20gSUVURi05NSAtIGRyYWZ0LWlldGYtZGhjLWRoY3B2Ni1wcmVmaXgt bGVuZ3RoLWhpbnQtaXNzdWU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwPk9sZSdzIHN1Z2dlc3Rpb24gaXMgY29ycmVj dCBleGNlcHQgdGhhdCBpZiB3ZSBoYXZlIG5vcm1hdGl2ZSBsYW5ndWFnZSBpbiB0aGUgZG9jdW1l bnQsIHRoZSBpZXNnIGlzIGdvaW5nIHRvIGFzayB3aHkgaXQncyBpbmZvcm1hdGl2ZS4gVGhlcmUg aXNuJ3QgYW55IHF1ZXN0aW9uIHRvIGRlYmF0ZSBoZXJlLiBFaXRoZXIgaXQncyBub3JtYXRpdmUs IGl3YyBQUywgb3IgaXQncyBub3Qgbm9ybWF0aXZlLCBpd2MgaW5mb3JtYXRpdmUuIEkgZmVlbCBs aWtlDQogT2xlIG1heSBqdXN0IGJlIHJlc2lzdGluZyBwdWJsaXNoaW5nIGl0IGF0IGFsbCwgaXdj IHdlIHNob3VsZCBkbyB0aGF0LCBub3QgY29uZnVzZSB0aGUgaWVzZy4gQnV0IEkgdGhpbmsgdGhh dCB3b3VsZCBiZSB0aGUgd3JvbmcgbW92ZSwgYmVjYXVzZSB3ZSBkb24ndCBrbm93IHdoZW4gMzMx NWJpcyB3aWxsIGdldCBjb25zZW5zdXMuDQo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5PbiBBcHIgMjEsIDIwMTYgNDowMiBQTSwgJnF1b3Q7QmVybmllIFZvbHog KHZvbHopJnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86dm9sekBjaXNjby5jb20iPnZvbHpAY2lz Y28uY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0i Ym9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAw aW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij5XaGlsZSA8YSBocmVm PSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtY3VpLWRoYy1kaGNwdjYtcHJlZml4 LWxlbmd0aC1oaW50LWlzc3VlLTAxIiB0YXJnZXQ9Il9ibGFuayI+DQpodHRwczovL3Rvb2xzLmll dGYub3JnL2h0bWwvZHJhZnQtY3VpLWRoYy1kaGNwdjYtcHJlZml4LWxlbmd0aC1oaW50LWlzc3Vl LTAxPC9hPiB3YXMgc3RhbmRhcmRzIHRyYWNrIGFuZCBoYWQgUkZDMjExOSAmcXVvdDtyZXF1aXJl bWVudHMgbGFuZ3VhZ2UmcXVvdDssIGl0IHdhcyBuZXZlciB1c2VkLiBTbywgdGhlIGRyYWZ0LWN1 aS1kaGMtZGhjcHY2LXByZWZpeC1sZW5ndGgtaGludC1pc3N1ZS0wMiB3YXMgY2hhbmdlZCB0byBp bmZvcm1hdGlvbmFsLiBIb3dldmVyLA0KIFRoZSBSRkMyMTE5IHJlcXVpcmVtZW50cyBsYW5ndWFn ZSBzZWN0aW9uIHdhc24ndCByZW1vdmVkIHVudGlsIGRyYWZ0LWlldGYtZGhjLWRoY3B2Ni1wcmVm aXgtbGVuZ3RoLWhpbnQtaXNzdWUtMDAgd2FzIHB1Ymxpc2hlZC48YnI+DQo8YnI+DQpTbywgcGVy aGFwcyBPbGUncyBzdWdnZXN0aW9uIGZvciB0aGUgYXV0aG9ycyB0byBwcm9wb3NlIHdoYXQgdGhl eSB0aGluayBzaG91bGQgYmUgbm9ybWF0aXZlICh0aGVyZSB3YXMgYSBzdWdnZXN0aW9uIHRoYXQg c2VjdGlvbiAyLjUgYmUpIGlzIGEgZ29vZCBvbmUuIEFuZCwgZnJvbSB0aGF0IHdlIGNhbiBzZWUg aWYgU3RhbmRhcmRzIFRyYWNrIGlzIG1vcmUgYXBwcm9wcmlhdGUuPGJyPg0KPGJyPg0KQlRXOiBU aGUgdGV4dCBhYm91dCBhc3NpZ25pbmcgYSAvNDggd2FzIGluIGFuICZxdW90O2UuZy4mcXVvdDsg KGZvciBleGFtcGxlKSBzZWN0aW9uLiBBbmQgdGhhdCB3b3VsZCBub3QgYmUgbm9ybWF0aXZlIGFu ZCB3YXMgbmV2ZXIgaW50ZW5kZWQgdG8gYmU6PGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IEUuZy4mbmJzcDsgSWYgdGhlIGRl bGVnYXRpbmcgcm91dGVyIGNvdWxkIG9ubHk8YnI+DQombmJzcDsgJm5ic3A7cHJvdmlkZSBwcmVm aXhlcyBvZiBsZW5ndGhzIC8zMCwgLzQ4LCBhbmQgLzU2LCBhbmQgdGhlIHJlcXVlc3Rpbmc8YnI+ DQombmJzcDsgJm5ic3A7cm91dGVyIGlzIHJlcXVlc3RpbmcgZm9yIGEgLzUwIGluIHRoZSBwcmVm aXgtbGVuZ3RoIGhpbnQsIHRoZW4gdGhlPGJyPg0KJm5ic3A7ICZuYnNwO2RlbGVnYXRpbmcgcm91 dGVyIHNob3VsZCBwcm92aWRlIHRoZSAvNDggdG8gdGhlIHJlcXVlc3Rpbmcgcm91dGVyPGJyPg0K PGJyPg0KLSBCZXJuaWU8YnI+DQo8YnI+DQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxicj4N CkZyb206IDxhIGhyZWY9Im1haWx0bzpvdHJvYW5AZW1wbG95ZWVzLm9yZyI+b3Ryb2FuQGVtcGxv eWVlcy5vcmc8L2E+IFttYWlsdG86PGEgaHJlZj0ibWFpbHRvOm90cm9hbkBlbXBsb3llZXMub3Jn Ij5vdHJvYW5AZW1wbG95ZWVzLm9yZzwvYT5dPGJyPg0KU2VudDogVGh1cnNkYXksIEFwcmlsIDIx LCAyMDE2IDM6MDAgUE08YnI+DQpUbzogVGVkIExlbW9uICZsdDs8YSBocmVmPSJtYWlsdG86bWVs bG9uQGZ1Z3VlLmNvbSI+bWVsbG9uQGZ1Z3VlLmNvbTwvYT4mZ3Q7PGJyPg0KQ2M6IEJlcm5pZSBW b2x6ICh2b2x6KSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnZvbHpAY2lzY28uY29tIj52b2x6QGNpc2Nv LmNvbTwvYT4mZ3Q7OyA8YSBocmVmPSJtYWlsdG86ZGhjd2dAaWV0Zi5vcmciPg0KZGhjd2dAaWV0 Zi5vcmc8L2E+PGJyPg0KU3ViamVjdDogUmU6IFtkaGN3Z10gRm9sbG93IHVwIGZyb20gSUVURi05 NSAtIGRyYWZ0LWlldGYtZGhjLWRoY3B2Ni1wcmVmaXgtbGVuZ3RoLWhpbnQtaXNzdWU8YnI+DQo8 YnI+DQpUZWQsPGJyPg0KPGJyPg0KJmd0OyBPbGUsIHRoZSBwb2ludCBpcyB0aGF0IGlmIHRoZSBk b2N1bWVudCBtYWtlcyBhbnkgbm9ybWF0aXZlIHN0YXRlbWVudHMsIGl0J3MgZ290IHRvIGJlIHN0 YW5kYXJkcy10cmFjay4mbmJzcDsgJm5ic3A7WW91IGFyZSBxdWl0ZSByaWdodCB0aGF0IHRoZSBw YXJ0aWN1bGFyIHN0YXRlbWVudHMgeW91IGNhbGwgb3V0IHNob3VsZCBub3QgYmUgbWFkZSBub3Jt YXRpdmVseSwgdGhvdWdoITxicj4NCjxicj4NCkFncmVlLCBvbmUgb3B0aW9uIGlmIHdlIGNhbiBp ZGVudGlmeSB3aGF0J3Mgbm9ybWF0aXZlIGluIHRoZSBkb2N1bWVudCB3b3VsZCBiZSB0byBhZGQg dGhhdCB0ZXh0IHRvIHRoZSAzMzE1YmlzIGFuZCBsZWF2ZSB0aGlzIGluZm9ybWF0aW9uYWwuPGJy Pg0KPGJyPg0KUkZDMjExOS1pZnlpbmcgdGhlIHRleHQgdGhlIGF1dGhvcnMgdGhpbmsgc2hvdWxk IGJlIG5vcm1hdGl2ZSB3b3VsZCBiZSBhIGdvb2Qgc3RhcnQuPGJyPg0KPGJyPg0KY2hlZXJzLDxi cj4NCk9sZTxicj4NCjxicj4NCiZndDs8YnI+DQomZ3Q7IE9uIFRodSwgQXByIDIxLCAyMDE2IGF0 IDI6MjggUE0sICZsdDs8YSBocmVmPSJtYWlsdG86b3Ryb2FuQGVtcGxveWVlcy5vcmciPm90cm9h bkBlbXBsb3llZXMub3JnPC9hPiZndDsgd3JvdGU6PGJyPg0KJmd0OyB0aGVyZSBhcmUgc29tZSBw YXJ0cyB0aGF0IGNvdWxkIGJlIG1hZGUgbm9ybWF0aXZlLCBsaWtlIHNlY3Rpb24gMi41Ljxicj4N CiZndDsgYnV0IG1vc3Qgb2YgdGhlIGRvY3VtZW50IGFwcGVhcnMgaW5mb3JtYXRpb25hbCBpbiBu YXR1cmUuPGJyPg0KJmd0OyBwYXJhcGhyYXNlZCBleGFtcGxlOiAmcXVvdDt0aGUgc2VydmVyIHNo b3VsZCBkZWxlZ2F0ZXMgYSAvNDggaWYgdGhlIGNsaWVudCByZXF1ZXN0cyBpdCZxdW90Oy48YnI+ DQomZ3Q7IHRoYXQncyBjbGVhcmx5IHBvbGljeSwgYW5kIGEgbWF0dGVyIG9mIHRoZSBwb3NzaWJs ZSBjb21tZXJjaWFsIGFycmFuZ2VtZW50LCBzZWVtcyBzdHJhbmdlIGlmIHRoZSBJRVRGIHNob3Vs ZCB0cnkgdG8gY29kaWZ5IHRoYXQuPGJyPg0KJmd0Ozxicj4NCiZndDsgSSBsZWFuIHRvd2FyZHMg aW5mb3JtYXRpb25hbC48YnI+DQomZ3Q7PGJyPg0KJmd0OyB0aGUgZG9jdW1lbnQgYWxzbyBkb2Vz IG5vdCBzYXkgYW55dGhpbmcgYWJvdXQgX2hvd18gdGhlIGNsaWVudCBpcyBzdXBwb3NlZCB0byBm aWd1cmUgb3V0IHdoYXQgc2l6ZWQgYWRkcmVzcyBibG9jayB0byByZXF1ZXN0Ljxicj4NCiZndDsg aWYgdGhlIGFuc3dlciB0byB0aGF0IGlzIG1hbnVhbCBjb25maWd1cmF0aW9uLCB0aGVuIHRoZXJl IGFyZSB0ZW5zIG9mIHdheXMgdGhhdCBjb3VsZCBiZSBkb25lIGRpZmZlcmVudGx5IG91dCBvZiBi YW5kLjxicj4NCiZndDs8YnI+DQomZ3Q7IGNoZWVycyw8YnI+DQomZ3Q7IE9sZTxicj4NCiZndDs8 YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDsgJmd0OyBPbiAyMSBBcHIgMjAxNiwgYXQgMTg6 NDUsIEJlcm5pZSBWb2x6ICh2b2x6KSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnZvbHpAY2lzY28uY29t Ij52b2x6QGNpc2NvLmNvbTwvYT4mZ3Q7IHdyb3RlOjxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsg Jmd0OyBIaTo8YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgT25lIGl0ZW0gdGhhdCB3YXMg cmFpc2VkIGF0IHRoZSBJRVRGLTk1IERIQyBXRyBzZXNzaW9uIHdhcyB0aGUgcmVjZW50IGNoYW5n ZSAoc3VnZ2VzdGVkIGJ5IG1lIGJlZm9yZSBkcmFmdC1jdWktZGhjLWRoY3B2Ni1wcmVmaXgtbGVu Z3RoLWhpbnQtaXNzdWUtMDIgd2FzIHB1Ymxpc2hlZCkgdG8gc3dpdGNoIGRyYWZ0LWlldGYtZGhj LWRoY3B2Ni1wcmVmaXgtbGVuZ3RoLWhpbnQtaXNzdWUgdG8gSW5mb3JtYXRpb25hbCByYXRoZXIg dGhhbiBTdGFuZGFyZHMNCiBUcmFjay4gTWFyY2luIFNpb2RlbHNraSBzdWdnZXN0ZWQgdGhhdCB0 aGUgZG9jdW1lbnQgYmUgU3RhbmRhcmRzIFRyYWNrOjxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsg Jmd0OyBUaGUgYnJpZWYgKGRyYWZ0KSBtaW51dGVzIGZvciB0aGlzIGRpc2N1c3MgYXJlOjxicj4N CiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyAtLS08YnI+DQomZ3Q7ICZndDsgNS4gREhDUHY2IFBy ZWZpeCBMZW5ndGggSGludCBJc3N1ZXMsIEJlcm5pZSBWb2x6IChmb3IgVGlhbnhpYW5nIExpKSAt IDEwIG1pbnV0ZXMsIDE0OjUwPGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDtkcmFm dC1pZXRmLWRoYy1kaGNwdjYtcHJlZml4LWxlbmd0aC1oaW50LWlzc3VlPGJyPg0KJmd0OyAmZ3Q7 PGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDtUaGUgYXV0aG9ycyBiZWxpZXZlIHdv cmsgaXMgcmVhZHkgZm9yIFdHTEMuPGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7 ICZuYnNwOyAmbmJzcDtJYW46IElzIHRoaXMgbm93IGluZm9ybWF0aW9uYWw/ICZxdW90O1RoaXMg aXMgdGhlIHN1Z2dlc3RlZCB3YXkgdG8gZG8gaXQmcXVvdDs/PGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7 ICZuYnNwOyAmbmJzcDtCZXJuaWU6IENvcnJlY3QuIFRoZXJlIHdlcmUgc29tZSBkaXNjdXNzaW9u cyBhbmQgdGhlIGNvbmNsdXNpb24gd2FzIHRvIG5vdDxicj4NCiZndDsgJmd0OyZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyBlbmZvcmNlIGl0Ljxicj4NCiZndDsgJmd0OyZuYnNwOyAmbmJzcDsg Jm5ic3A7TWFyY2luIChvbiBqYWJiZXIpOiBJJ2Qgc3VnZ2VzdCB0aGlzIGlzIHN0YW5kYXJkcyB0 cmFjayBkb2Mgd2l0aCBub3JtYXRpdmUgbGFuZ3VhZ2U8YnI+DQomZ3Q7ICZndDsmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgaW4uIE90aGVyd2lzZSBpbXBsZW1lbnRhdGlvbnMgd2lsbCBpZ25v cmUgaGludHMuPGJyPg0KJmd0OyAmZ3Q7IC0tLTxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0 OyBPbmNlIHdlIHJlc29sdmUgdGhpcyBvcGVuIHF1ZXN0aW9uIChhbmQgYWZ0ZXIgYSBwb3NzaWJs ZSB1cGRhdGUgdG8gdGhlIGRvY3VtZW50KSwgd2UgaW50ZW5kIHRvIHN0YXJ0IGEgV0dMQyBvbiB0 aGUgZG9jdW1lbnQuPGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7IFBsZWFzZSByZXNwb25k IHdpdGggeW91ciBjb21tZW50cyBhcyB0byB3aGV0aGVyIHRoaXMgZG9jdW1lbnQgc2hvdWxkIGJl IEluZm9ybWF0aW9uYWwgb3IgU3RhbmRhcmRzIFRyYWNrIGJ5IE1heSA1dGgsIDIwMTYuIE9mIGNv dXJzZSwgYW55IG90aGVyIGNvbW1lbnRzIGFyZSB3ZWxjb21lIGFzIHdlbGwhPGJyPg0KJmd0OyAm Z3Q7PGJyPg0KJmd0OyAmZ3Q7IFRoYW5rcyE8YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsg LSZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgVG9tZWsgJmFtcDsgQmVybmllPGJy Pg0KJmd0OyAmZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fPGJyPg0KJmd0OyAmZ3Q7IGRoY3dnIG1haWxpbmcgbGlzdDxicj4NCiZndDsgJmd0OyA8YSBo cmVmPSJtYWlsdG86ZGhjd2dAaWV0Zi5vcmciPmRoY3dnQGlldGYub3JnPC9hPjxicj4NCiZndDsg Jmd0OyA8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RoY3dn IiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9k aGN3ZzwvYT48YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDsgX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQomZ3Q7IGRoY3dnIG1haWxpbmcgbGlz dDxicj4NCiZndDsgPGEgaHJlZj0ibWFpbHRvOmRoY3dnQGlldGYub3JnIj5kaGN3Z0BpZXRmLm9y ZzwvYT48YnI+DQomZ3Q7IDxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vZGhjd2ciIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL2RoY3dnPC9hPjxicj4NCiZndDs8YnI+DQomZ3Q7PG86cD48L286cD48L3A+DQo8 L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_48d576be7b85448b99e9b2745837e59aXCHALN003ciscocom_-- From nobody Thu Apr 21 18:52:49 2016 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 DFD8D12DD4E for ; Thu, 21 Apr 2016 18:52:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 55rc8yVi0PZJ for ; Thu, 21 Apr 2016 18:52:45 -0700 (PDT) Received: from mail-lf0-x22e.google.com (mail-lf0-x22e.google.com [IPv6:2a00:1450:4010:c07::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 711E612DD3E for ; Thu, 21 Apr 2016 18:52:44 -0700 (PDT) Received: by mail-lf0-x22e.google.com with SMTP id c126so71126974lfb.2 for ; Thu, 21 Apr 2016 18:52:44 -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=QPW7HvFQeioNtxY2q2EplIAKYQjbXmERvh7TqNVnBaQ=; b=p7v0VMM3p95CzfzEFeW/RCQdnqMLWDjqIE63Qr09+Ar7VOFvPFM+keMHhnd1Wd6vkz RyRAhYX4+Sx1yot2askFXvSGToeKSJC5ADjbTDqQFZ9cXzladUiMv3/v9KprPXElicHG yicd+fGiZY+JzuM9axqTjj7nO1i+fXwtGG+YEM/2xCdgcjX9tg4J3DrTI8OX2fC1dFl1 bOGKp7bl1cSXd3UsGHhYUaJMf69U8LRGxyW7MYKZE8PVGrtbKCD50wtwOyvQS5xK99Kl 588zvmdUdRjT4q6/pagPR+2lbX9s/c85ry2UBwHPOVJQgcjkiJ1qrjduFDVfsuAECATr 5XNQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=QPW7HvFQeioNtxY2q2EplIAKYQjbXmERvh7TqNVnBaQ=; b=f289PPk/Dh8xa1g77WqK2NjW9Bfu4Yja3WkeyWmPUAzzfB5F/EaoIgOoc+GFyPGmcs KkjkGq++rdR2yavFBxf3FFoMd1omwc1NO2vRnoqvjrUExTkGLe5R4EDjgn2hU9KiwJ/2 dtGSBH9M3ahz3jjND2WPHneP/VnHKxPPQhvUe881fkEDALxtITPG64Z52boIXIprS30C kdm8uspWpNM3vCmjQBDXh1GFow8OYuxANp0raWJf8m7DdBe6282XNGwMM6xaWsqgssLi OAYokUnaoqy52sB/osmMFWuqF3ETI5K5ivNH44xohQo5HKHemJOcU71sWNc208e46WUt 7hew== X-Gm-Message-State: AOPr4FUArtjKHHmKTggR90ba4E4ZMx1bvPcuSB4Q3Z3TrGxULEB+0O/YiY0fpZhpZFZ6d/FENyqOtsvearKUFg== X-Received: by 10.25.85.210 with SMTP id j201mr6616343lfb.132.1461289962556; Thu, 21 Apr 2016 18:52:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.213.19 with HTTP; Thu, 21 Apr 2016 18:52:02 -0700 (PDT) X-Originating-IP: [71.233.41.235] In-Reply-To: <48d576be7b85448b99e9b2745837e59a@XCH-ALN-003.cisco.com> References: <0a8817dba2ea46c88ca67334a11c956d@XCH-ALN-003.cisco.com> <778BB254-D3FF-4FF3-9AC5-CA2B8DF6F04D@employees.org> <48d576be7b85448b99e9b2745837e59a@XCH-ALN-003.cisco.com> From: Ted Lemon Date: Thu, 21 Apr 2016 21:52:02 -0400 Message-ID: To: "Bernie Volz (volz)" Content-Type: multipart/alternative; boundary=001a1141d82621e57305310915ba Archived-At: Cc: "dhcwg@ietf.org" Subject: Re: [dhcwg] Follow up from IETF-95 - draft-ietf-dhc-dhcpv6-prefix-length-hint-issue X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Apr 2016 01:52:48 -0000 --001a1141d82621e57305310915ba Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Right. Sorry, was I packet-storming? Maybe I misunderstood what Ole was suggesting. On Thu, Apr 21, 2016 at 5:13 PM, Bernie Volz (volz) wrote: > Ted =E2=80=A6 if we put normative text in, it will be Standards Track. > > > > - Bernie > > > > *From:* Ted Lemon [mailto:mellon@fugue.com] > *Sent:* Thursday, April 21, 2016 4:28 PM > *To:* Bernie Volz (volz) > *Cc:* dhcwg@ietf.org; otroan@employees.org > *Subject:* RE: [dhcwg] Follow up from IETF-95 - > draft-ietf-dhc-dhcpv6-prefix-length-hint-issue > > > > Ole's suggestion is correct except that if we have normative language in > the document, the iesg is going to ask why it's informative. There isn't > any question to debate here. Either it's normative, iwc PS, or it's not > normative, iwc informative. I feel like Ole may just be resisting > publishing it at all, iwc we should do that, not confuse the iesg. But I > think that would be the wrong move, because we don't know when 3315bis wi= ll > get consensus. > > On Apr 21, 2016 4:02 PM, "Bernie Volz (volz)" wrote: > > While > https://tools.ietf.org/html/draft-cui-dhc-dhcpv6-prefix-length-hint-issue= -01 > was standards track and had RFC2119 "requirements language", it was never > used. So, the draft-cui-dhc-dhcpv6-prefix-length-hint-issue-02 was change= d > to informational. However, The RFC2119 requirements language section wasn= 't > removed until draft-ietf-dhc-dhcpv6-prefix-length-hint-issue-00 was > published. > > So, perhaps Ole's suggestion for the authors to propose what they think > should be normative (there was a suggestion that section 2.5 be) is a goo= d > one. And, from that we can see if Standards Track is more appropriate. > > BTW: The text about assigning a /48 was in an "e.g." (for example) > section. And that would not be normative and was never intended to be: > > E.g. If the delegating router could only > provide prefixes of lengths /30, /48, and /56, and the requesting > router is requesting for a /50 in the prefix-length hint, then the > delegating router should provide the /48 to the requesting router > > - Bernie > > -----Original Message----- > From: otroan@employees.org [mailto:otroan@employees.org] > Sent: Thursday, April 21, 2016 3:00 PM > To: Ted Lemon > Cc: Bernie Volz (volz) ; dhcwg@ietf.org > Subject: Re: [dhcwg] Follow up from IETF-95 - > draft-ietf-dhc-dhcpv6-prefix-length-hint-issue > > Ted, > > > Ole, the point is that if the document makes any normative statements, > it's got to be standards-track. You are quite right that the particular > statements you call out should not be made normatively, though! > > Agree, one option if we can identify what's normative in the document > would be to add that text to the 3315bis and leave this informational. > > RFC2119-ifying the text the authors think should be normative would be a > good start. > > cheers, > Ole > > > > > On Thu, Apr 21, 2016 at 2:28 PM, wrote: > > there are some parts that could be made normative, like section 2.5. > > but most of the document appears informational in nature. > > paraphrased example: "the server should delegates a /48 if the client > requests it". > > that's clearly policy, and a matter of the possible commercial > arrangement, seems strange if the IETF should try to codify that. > > > > I lean towards informational. > > > > the document also does not say anything about _how_ the client is > supposed to figure out what sized address block to request. > > if the answer to that is manual configuration, then there are tens of > ways that could be done differently out of band. > > > > cheers, > > Ole > > > > > > > > > On 21 Apr 2016, at 18:45, Bernie Volz (volz) wrote: > > > > > > Hi: > > > > > > One item that was raised at the IETF-95 DHC WG session was the recent > change (suggested by me before > draft-cui-dhc-dhcpv6-prefix-length-hint-issue-02 was published) to switch > draft-ietf-dhc-dhcpv6-prefix-length-hint-issue to Informational rather th= an > Standards Track. Marcin Siodelski suggested that the document be Standard= s > Track: > > > > > > The brief (draft) minutes for this discuss are: > > > > > > --- > > > 5. DHCPv6 Prefix Length Hint Issues, Bernie Volz (for Tianxiang Li) - > 10 minutes, 14:50 > > > draft-ietf-dhc-dhcpv6-prefix-length-hint-issue > > > > > > The authors believe work is ready for WGLC. > > > > > > Ian: Is this now informational? "This is the suggested way to do > it"? > > > Bernie: Correct. There were some discussions and the conclusion > was to not > > > enforce it. > > > Marcin (on jabber): I'd suggest this is standards track doc with > normative language > > > in. Otherwise implementations will ignore hints. > > > --- > > > > > > Once we resolve this open question (and after a possible update to th= e > document), we intend to start a WGLC on the document. > > > > > > Please respond with your comments as to whether this document should > be Informational or Standards Track by May 5th, 2016. Of course, any othe= r > comments are welcome as well! > > > > > > Thanks! > > > > > > - Tomek & Bernie > > > _______________________________________________ > > > dhcwg mailing list > > > dhcwg@ietf.org > > > https://www.ietf.org/mailman/listinfo/dhcwg > > > > > > _______________________________________________ > > dhcwg mailing list > > dhcwg@ietf.org > > https://www.ietf.org/mailman/listinfo/dhcwg > > > > > > --001a1141d82621e57305310915ba Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Right. =C2=A0 Sorry, was I packet-storming? =C2=A0 Maybe I= misunderstood what Ole was suggesting.
On Thu, Apr 21, 2016 at 5:13 PM, Bernie Volz (v= olz) <volz@cisco.com> wrote:

Ted =E2=80=A6 if we put normative tex= t in, it will be Standards Track.

=C2=A0

-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Bernie

=C2=A0

From: Ted Lemon [mailto:mellon@fugue.com]
Sent: Thursday, April 21, 2016 4:28 PM
To: Bernie Volz (volz) <volz@cisco.com>
Cc: dhcwg@ietf.o= rg; otroan@em= ployees.org
Subject: RE: [dhcwg] Follow up from IETF-95 - draft-ietf-dhc-dhcpv6-= prefix-length-hint-issue

=C2=A0

Ole's suggestion is correct except that if we have normative languag= e in the document, the iesg is going to ask why it's informative. There= isn't any question to debate here. Either it's normative, iwc PS, = or it's not normative, iwc informative. I feel like Ole may just be resisting publishing it at all, iwc we should do that, not= confuse the iesg. But I think that would be the wrong move, because we don= 't know when 3315bis will get consensus.

On Apr 21, 2016 4:02 PM, "Bernie Volz (volz)&qu= ot; <volz@cisco.com<= /a>> wrote:

While https://tools.ietf.org/html/draft-cui-dhc-dhcpv6-prefix-length-hint-issue-0= 1 was standards track and had RFC2119 "requirements language"= , it was never used. So, the draft-cui-dhc-dhcpv6-prefix-length-hint-issue-= 02 was changed to informational. However, The RFC2119 requirements language section wasn't removed until draft-i= etf-dhc-dhcpv6-prefix-length-hint-issue-00 was published.

So, perhaps Ole's suggestion for the authors to propose what they think= should be normative (there was a suggestion that section 2.5 be) is a good= one. And, from that we can see if Standards Track is more appropriate.

BTW: The text about assigning a /48 was in an "e.g." (for example= ) section. And that would not be normative and was never intended to be:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 E.g.=C2=A0 If the delegating router = could only
=C2=A0 =C2=A0provide prefixes of lengths /30, /48, and /56, and the request= ing
=C2=A0 =C2=A0router is requesting for a /50 in the prefix-length hint, then= the
=C2=A0 =C2=A0delegating router should provide the /48 to the requesting rou= ter

- Bernie

-----Original Message-----
From: otroan@empl= oyees.org [mailto:otroan@employees.org]
Sent: Thursday, April 21, 2016 3:00 PM
To: Ted Lemon <mel= lon@fugue.com>
Cc: Bernie Volz (volz) <volz@cisco.com>; dhcwg@ietf.org
Subject: Re: [dhcwg] Follow up from IETF-95 - draft-ietf-dhc-dhcpv6-prefix-= length-hint-issue

Ted,

> Ole, the point is that if the document makes any normative statements,= it's got to be standards-track.=C2=A0 =C2=A0You are quite right that t= he particular statements you call out should not be made normatively, thoug= h!

Agree, one option if we can identify what's normative in the document w= ould be to add that text to the 3315bis and leave this informational.

RFC2119-ifying the text the authors think should be normative would be a go= od start.

cheers,
Ole

>
> On Thu, Apr 21, 2016 at 2:28 PM, <otroan@employees.org> wrote:
> there are some parts that could be made normative, like section 2.5. > but most of the document appears informational in nature.
> paraphrased example: "the server should delegates a /48 if the cl= ient requests it".
> that's clearly policy, and a matter of the possible commercial arr= angement, seems strange if the IETF should try to codify that.
>
> I lean towards informational.
>
> the document also does not say anything about _how_ the client is supp= osed to figure out what sized address block to request.
> if the answer to that is manual configuration, then there are tens of = ways that could be done differently out of band.
>
> cheers,
> Ole
>
>
>
> > On 21 Apr 2016, at 18:45, Bernie Volz (volz) <volz@cisco.com> wrote:
> >
> > Hi:
> >
> > One item that was raised at the IETF-95 DHC WG session was the re= cent change (suggested by me before draft-cui-dhc-dhcpv6-prefix-length-hint= -issue-02 was published) to switch draft-ietf-dhc-dhcpv6-prefix-length-hint= -issue to Informational rather than Standards Track. Marcin Siodelski suggested that the document be Standards Track: > >
> > The brief (draft) minutes for this discuss are:
> >
> > ---
> > 5. DHCPv6 Prefix Length Hint Issues, Bernie Volz (for Tianxiang L= i) - 10 minutes, 14:50
> >=C2=A0 =C2=A0 =C2=A0draft-ietf-dhc-dhcpv6-prefix-length-hint-issue=
> >
> >=C2=A0 =C2=A0 =C2=A0The authors believe work is ready for WGLC. > >
> >=C2=A0 =C2=A0 =C2=A0Ian: Is this now informational? "This is = the suggested way to do it"?
> >=C2=A0 =C2=A0 =C2=A0Bernie: Correct. There were some discussions a= nd the conclusion was to not
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 enforce it.
> >=C2=A0 =C2=A0 =C2=A0Marcin (on jabber): I'd suggest this is st= andards track doc with normative language
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 in. Otherwise implementations will ign= ore hints.
> > ---
> >
> > Once we resolve this open question (and after a possible update t= o the document), we intend to start a WGLC on the document.
> >
> > Please respond with your comments as to whether this document sho= uld be Informational or Standards Track by May 5th, 2016. Of course, any ot= her comments are welcome as well!
> >
> > Thanks!
> >
> > -=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Tomek & Bernie
> > _______________________________________________
> > dhcwg mailing list
> > dhcwg@ietf.or= g
> > https://www.ietf.org/mailman/listinfo/dhcwg
>
>
> _______________________________________________
> dhcwg mailing list
> dhcwg@ietf.org=
> https://www.ietf.org/mailman/listinfo/dhcwg
>
>


--001a1141d82621e57305310915ba-- From nobody Fri Apr 22 02:20:44 2016 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 8AF0F12D7DD for ; Fri, 22 Apr 2016 02:20:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-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 HQSJQarucFs7 for ; Fri, 22 Apr 2016 02:20:38 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4BC8112D6D3 for ; Fri, 22 Apr 2016 02:20:38 -0700 (PDT) Received: from ians-mbp.lan ([62.225.30.138]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0Lq9Ma-1bODF63pr6-00dkHv; Fri, 22 Apr 2016 11:20:28 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Ian Farrer In-Reply-To: <778BB254-D3FF-4FF3-9AC5-CA2B8DF6F04D@employees.org> Date: Fri, 22 Apr 2016 11:20:26 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <4A389729-1344-4F8A-B87E-7937866B97BE@gmx.com> References: <0a8817dba2ea46c88ca67334a11c956d@XCH-ALN-003.cisco.com> <778BB254-D3FF-4FF3-9AC5-CA2B8DF6F04D@employees.org> To: otroan@employees.org X-Mailer: Apple Mail (2.2104) X-Provags-ID: V03:K0:QDyKZnveoTq2Y/fpNCUBhczOVIy7ldTDN9X1faIaTZb1RHof1WY +86H4Rk27elN50qL2Kbru9hidZI3hPa+X+ZAHZIwVzLvTAb4nrOjt3ZuYt+DWRqEs8HDfUu PIaxwPo5WHgMVz8uCd+CxfpRpUUzA+9+J8dPeZH2cO5rxett9QV4vj1BBAtqvaAzI1j+/Ki mpvE2yXrmlvGJ3426yuRQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:62uqo9cxElM=:WAbuxojny9W0RyLCSkU+Jj QYdiOv3OHSSnDdnEQNOLETg42Zlq6sn6B86vuvdqcXwh5P9QYx2NCt1zwDNorXQBekXDMEs1B 0b6PshfKxbl1HuhtGiqPcyfuEFOHnODIboc2iE2qgN1VqTgBnMceNu2U/ZjjUl7VZQhMRmS1Y DDRHxMKWEVtj3dHmJMWpMNtL91XKvX0TaecQFodTX2FFmGOR8sSRkHU6+FDWDCxtJqEb4rdeS sA53wy0VoRZAil0lEMMtJp+NWLKHWPu2Vxey8kxNHtybv5hEkrkrmqgWRzGMUqwZUq0rSn8p2 QEBxpELttkpfgx4FT/h3rPNIg06C5L5G0igCT+hsU9IKH+finSNr3PkGGQJ3bvINx1SCohGrL Bjiwnyq/nXOnR0yXL2x8lSEDyBLiK11vqvoeD9gfkHWGEWp/MSN5AnfL6ufxW2LeWdrlGUA4L e22DXk1pEyPCZA0gDOjNTdKRKc+Lfo03i+ZuSyeg32GQdvTSmUthxrQWGGfln2hX9KVZxwqAF EAdFpJFBiaxK8aTfA3zyLF6aCagWF2nvEBmWga60Ajp/NlZfTFVOcIJA9xa5m9+yCrfe7Bl/F SahaVohgDbZikaSJuHXF7s9m2avS18iHIyY5eABMM0Uzw3kdqLnc07UZ4UxMS/SwfLKXesy8S AarRs9A6TPYtU5hf1kYz0ffiHVdhUQJyVqW6UZGj0TuOS2lba0jVjpcGuJbuLlmGkTSawy8RQ KnyR3c1a5NXOCEL1++sAbrcojdBHEQNl9KWFk8Y2MF6U8OkoIrVbjpJ5x/QYLc4Tc+qF7QUDm 0PCjy30 Archived-At: Cc: "dhcwg@ietf.org" , Ted Lemon , "Bernie Volz \(volz\)" Subject: Re: [dhcwg] Follow up from IETF-95 - draft-ietf-dhc-dhcpv6-prefix-length-hint-issue X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Apr 2016 09:20:43 -0000 Hi, I think seeing the changes that adding normative text would make is the = best way forward. I also would like to see the outcome of this rolled up into the 3315-bis = as it=E2=80=99s directly applicable and one of the motivations for = writing it is that 3633 didn=E2=80=99t cover it. But, publishing this as = informational without normative language and then putting it into = 3315-bis with normative seems a bit like a 'bait-and-switch=E2=80=99:-) So, if it needs normative text in 3315-bis, then it should be progressed = as Standards track in this version. Cheers, Ian > On 21 Apr 2016, at 20:59, otroan@employees.org wrote: >=20 > Ted, >=20 >> Ole, the point is that if the document makes any normative = statements, it's got to be standards-track. You are quite right that = the particular statements you call out should not be made normatively, = though! >=20 > Agree, one option if we can identify what's normative in the document = would be to add that text to the 3315bis and leave this informational. >=20 > RFC2119-ifying the text the authors think should be normative would be = a good start. >=20 > cheers, > Ole >=20 >>=20 >> On Thu, Apr 21, 2016 at 2:28 PM, wrote: >> there are some parts that could be made normative, like section 2.5. >> but most of the document appears informational in nature. >> paraphrased example: "the server should delegates a /48 if the client = requests it". >> that's clearly policy, and a matter of the possible commercial = arrangement, seems strange if the IETF should try to codify that. >>=20 >> I lean towards informational. >>=20 >> the document also does not say anything about _how_ the client is = supposed to figure out what sized address block to request. >> if the answer to that is manual configuration, then there are tens of = ways that could be done differently out of band. >>=20 >> cheers, >> Ole >>=20 >>=20 >>=20 >>> On 21 Apr 2016, at 18:45, Bernie Volz (volz) wrote: >>>=20 >>> Hi: >>>=20 >>> One item that was raised at the IETF-95 DHC WG session was the = recent change (suggested by me before = draft-cui-dhc-dhcpv6-prefix-length-hint-issue-02 was published) to = switch draft-ietf-dhc-dhcpv6-prefix-length-hint-issue to Informational = rather than Standards Track. Marcin Siodelski suggested that the = document be Standards Track: >>>=20 >>> The brief (draft) minutes for this discuss are: >>>=20 >>> --- >>> 5. DHCPv6 Prefix Length Hint Issues, Bernie Volz (for Tianxiang Li) = - 10 minutes, 14:50 >>> draft-ietf-dhc-dhcpv6-prefix-length-hint-issue >>>=20 >>> The authors believe work is ready for WGLC. >>>=20 >>> Ian: Is this now informational? "This is the suggested way to do = it"? >>> Bernie: Correct. There were some discussions and the conclusion = was to not >>> enforce it. >>> Marcin (on jabber): I'd suggest this is standards track doc with = normative language >>> in. Otherwise implementations will ignore hints. >>> --- >>>=20 >>> Once we resolve this open question (and after a possible update to = the document), we intend to start a WGLC on the document. >>>=20 >>> Please respond with your comments as to whether this document should = be Informational or Standards Track by May 5th, 2016. Of course, any = other comments are welcome as well! >>>=20 >>> Thanks! >>>=20 >>> - Tomek & Bernie >>> _______________________________________________ >>> dhcwg mailing list >>> dhcwg@ietf.org >>> https://www.ietf.org/mailman/listinfo/dhcwg >>=20 >>=20 >> _______________________________________________ >> dhcwg mailing list >> dhcwg@ietf.org >> https://www.ietf.org/mailman/listinfo/dhcwg >>=20 >>=20 >=20 > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg From nobody Fri Apr 22 07:48:48 2016 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 3F15012E499 for ; Fri, 22 Apr 2016 07:48:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.516 X-Spam-Level: X-Spam-Status: No, score=-15.516 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_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, 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 C9YzBQD4hlX9 for ; Fri, 22 Apr 2016 07:48:44 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 15E2112E1CF for ; Fri, 22 Apr 2016 07:48:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9740; q=dns/txt; s=iport; t=1461336524; x=1462546124; h=from:to:subject:date:message-id:mime-version; bh=Oz9b8TFypfr8eY0p6g5GOY0zD7XGjygWwcbtN/sOADo=; b=XUqfwcinHvPzYcVbRsMrNrYoMapAqPyNij9Wr5jv0LIpfGJtPJ1PzGRs Vfgb/efqYwc3bPcBcBdPae+Y5mdq2m1ZLvoR7WzlIMyTqdYYbEglDRUqQ MXLnOOwjbNE5tXJlinyVilF0QDSicTNLmQeNRBlfOrTok2RlFSrhKVACc 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0A9AgB/OBpX/5tdJa1egmxMU30GtQ2Ec?= =?us-ascii?q?wENgXMXAQyFaoEpOBQBAQEBAQEBZRwLhEYCHRBeAYEAJgEEG4giDp5JoGIBAQE?= =?us-ascii?q?BAQEEAQEBAQEBFgSMJIM0ghtLgkMFkx6EcQGFeogSgW2ETYhdjy4BHgEBQoI2g?= =?us-ascii?q?TVsAYd3fwEBAQ?= X-IronPort-AV: E=Sophos;i="5.24,517,1454976000"; d="scan'208,217";a="264936759" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 22 Apr 2016 14:48:43 +0000 Received: from XCH-ALN-003.cisco.com (xch-aln-003.cisco.com [173.36.7.13]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id u3MEmg6n004612 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Fri, 22 Apr 2016 14:48:43 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.1104.5; Fri, 22 Apr 2016 09:48:41 -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.1104.009; Fri, 22 Apr 2016 09:48:41 -0500 From: "Bernie Volz (volz)" To: "dhcwg@ietf.org" Thread-Topic: Adoption Call for draft-fang-dhc-dhcpv4-forcerenew-extensions-02 (Ends May 8, 2016) Thread-Index: AdGcpHVug7Y1cq70TAOjWU3uwbIZzQ== Date: Fri, 22 Apr 2016 14:48:41 +0000 Message-ID: <00f1ca4f5ef14b5f9fa2a2cdd587ba25@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_00f1ca4f5ef14b5f9fa2a2cdd587ba25XCHALN003ciscocom_" MIME-Version: 1.0 Archived-At: Subject: [dhcwg] Adoption Call for draft-fang-dhc-dhcpv4-forcerenew-extensions-02 (Ends May 8, 2016) X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Apr 2016 14:48:46 -0000 --_000_00f1ca4f5ef14b5f9fa2a2cdd587ba25XCHALN003ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi: At the IETF-95 DHC WG session, Luyuan Fang gave a presentation on draft-fan= g-dhc-dhcpv4-forcerenew-extensions-02 (Forcerenew Reconfiguration Extension= s for DHCPv4) - see https://www.ietf.org/proceedings/95/slides/slides-95-dh= c-6.pdf. There was a brief discussion about whether there was sufficient interest in= the WG to take on this work and the conclusion was to take it to the list = (which we would have needed to do anyway). So, we are starting an Adoption Call for this draft (https://tools.ietf.org= /html/draft-fang-dhc-dhcpv4-forcerenew-extensions-02). Please respond by May 8, 2016 whether you support having the WG take on thi= s work. Please note that this means YOU need to be involved in resolving op= en issues, reading draft updates, and otherwise actively participating to m= ove this work forward. The abstract from the draft is: This document extends the definition of the DHCPFORCERENEW message for parameter reconfiguration in DHCPv4. This extension makes the DHCPFORCERENEW message more suitable to reconfigure configuration parameters other than IP addresses, and aligns the behavior of the reconfiguration procedure in DHCPv4 to the corresponding behavior in DHCPv6. While not directly on the WG's current charter, we have confirmed with our = AD (Suresh) that this would be acceptable work for us to adopt (no re-chart= ering will be necessary). - Tomek and Bernie --_000_00f1ca4f5ef14b5f9fa2a2cdd587ba25XCHALN003ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi:

 

At the IETF-95 DHC WG session, Luyuan Fang gave a pr= esentation on draft-fang-dhc-dhcpv4-forcerenew-extensions-02 (Forcerenew Re= configuration Extensions for DHCPv4) – see = https://www.ietf.org/proceedings/95/slides/slides-95-dhc-6.pdf.

 

There was a brief discussion about whether there was= sufficient interest in the WG to take on this work and the conclusion was = to take it to the list (which we would have needed to do anyway).

 

So, we are starting an Adoption Call for this draft = (https://tools.ietf.org/html/draft-fang-dhc-dhcpv4-forcerenew-e= xtensions-02).

 

Please respond by May 8, 2016 whether you support ha= ving the WG take on this work. Please note that this means YOU need to be i= nvolved in resolving open issues, reading draft updates, and otherwise acti= vely participating to move this work forward.

 

The abstract from the draft is:

 

   This document extends the definit= ion of the DHCPFORCERENEW message

   for parameter reconfiguration in = DHCPv4. This extension makes the

   DHCPFORCERENEW message more suita= ble to reconfigure configuration

   parameters other than IP addresse= s, and aligns the behavior of the

   reconfiguration procedure in DHCP= v4 to the corresponding behavior in

   DHCPv6.

 

While not directly on the WG’s current charter= , we have confirmed with our AD (Suresh) that this would be acceptable work= for us to adopt (no re-chartering will be necessary).

 

-     &= nbsp;    Tomek and Bernie

 

 

 

--_000_00f1ca4f5ef14b5f9fa2a2cdd587ba25XCHALN003ciscocom_-- From nobody Fri Apr 22 08:01:38 2016 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 E4EC912E8C3 for ; Fri, 22 Apr 2016 08:01:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 Jwvxy_dwwAoP for ; Fri, 22 Apr 2016 08:01:32 -0700 (PDT) Received: from mail-lb0-x233.google.com (mail-lb0-x233.google.com [IPv6:2a00:1450:4010:c04::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8DA1C12DD83 for ; Fri, 22 Apr 2016 08:01:31 -0700 (PDT) Received: by mail-lb0-x233.google.com with SMTP id ys16so45521842lbb.3 for ; Fri, 22 Apr 2016 08:01:31 -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=vkANA8rDvppWRyGj5I8LlXCWyrBqv0KqhPzwSlyDmdc=; b=IvySdGpHsz6lYxPQbeO3ZYQSlvF4rwImrJQ/qCeF+3GL94Uwv8vjgXHpirx85Cv4KO xOyZaJzdetC182G4mdawhY9ydL6hh3Z0TTdC6bB/iTqMLQz9GLrqkybzGGzf+CUF8w9A 4UebZcQ8wq5jWIQiMbihhC5M4EijpTvEBy0zYK/QMk0pe5v0DQkDuIMslq+Xt9OMgMjB bsytXHZVd79kobmhfbOSxRXXlJJL5m5bh3g5xoOUZIQEJ3fX0FcXu1z9M6kzKLXwVOTk xnZy3Xgg8b48ZuOXvVrJZY1lk/Q6dkqyjpHGRK+FuKs+rWPM56Ya0DFpEkMLkwA0i+ot 3MWQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=vkANA8rDvppWRyGj5I8LlXCWyrBqv0KqhPzwSlyDmdc=; b=lRlhprFyQJBmShdebunnX0sWSB1CgP/ggyR6OpdlqTFsCC7lGkVhO7gWPW+nhefUNR Op3q29yMt/MEYDKznMZ5UWjAcoR8uicBYH161ado9CrOszlhZ69Va5dFQvZ/ttvLOxL3 Y/MC+UZGsMY9d8tTx9jhIeWCNDbi2iutToZ/WKlf+vZ1KwmYamWmFatVgUbYGl6nggIh Yt5PSxN8hcKDMLulssgOpQQTbtS6aCW3m/OU/LzSxiVrOQbjx2Rgzu25nFmMfCKVblsg a2T7cqu20PUDf7g/uJYH3vqWY8Cy82uL0tEoDBmsgq4Wg1g1RpRnB7fmIEpatpE/rhgT Uz3w== X-Gm-Message-State: AOPr4FXTlxakSefW4AlVjq1n3Q7Cl+v3bqqyTOAqObs9pBQZKC7LXYwGY6N4khngxSY7uxeD+p1YeeSC3Gr6cg== X-Received: by 10.112.143.40 with SMTP id sb8mr8707298lbb.83.1461337289746; Fri, 22 Apr 2016 08:01:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.34.214 with HTTP; Fri, 22 Apr 2016 08:00:50 -0700 (PDT) X-Originating-IP: [71.233.41.235] In-Reply-To: <00f1ca4f5ef14b5f9fa2a2cdd587ba25@XCH-ALN-003.cisco.com> References: <00f1ca4f5ef14b5f9fa2a2cdd587ba25@XCH-ALN-003.cisco.com> From: Ted Lemon Date: Fri, 22 Apr 2016 11:00:50 -0400 Message-ID: To: "Bernie Volz (volz)" Content-Type: multipart/alternative; boundary=089e011832ba0d87790531141ad1 Archived-At: Cc: "dhcwg@ietf.org" Subject: Re: [dhcwg] Adoption Call for draft-fang-dhc-dhcpv4-forcerenew-extensions-02 (Ends May 8, 2016) X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Apr 2016 15:01:37 -0000 --089e011832ba0d87790531141ad1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable The reasons Luyuan Fang gave for wanting this made sense to me, and it makes sense that if someone is going to do this work, the method they are using be documented. They are going to need code points. This work could be done as an ISE document and get a code point through IESG action, but I think that what is being proposed shouldn't be a lot of work to review, and so it's beneficial to have the working group review it. It's also easier from a process perspective. I am willing to be a reviewer. I am in favor of adopting this as a working group work item. On Fri, Apr 22, 2016 at 10:48 AM, Bernie Volz (volz) wrote= : > Hi: > > > > At the IETF-95 DHC WG session, Luyuan Fang gave a presentation on > draft-fang-dhc-dhcpv4-forcerenew-extensions-02 (Forcerenew Reconfiguratio= n > Extensions for DHCPv4) =E2=80=93 see > https://www.ietf.org/proceedings/95/slides/slides-95-dhc-6.pdf. > > > > There was a brief discussion about whether there was sufficient interest > in the WG to take on this work and the conclusion was to take it to the > list (which we would have needed to do anyway). > > > > So, we are starting an Adoption Call for this draft ( > https://tools.ietf.org/html/draft-fang-dhc-dhcpv4-forcerenew-extensions-0= 2 > ). > > > > Please respond by May 8, 2016 whether you support having the WG take on > this work. Please note that this means YOU need to be involved in resolvi= ng > open issues, reading draft updates, and otherwise actively participating = to > move this work forward. > > > > The abstract from the draft is: > > > > This document extends the definition of the DHCPFORCERENEW message > > for parameter reconfiguration in DHCPv4. This extension makes the > > DHCPFORCERENEW message more suitable to reconfigure configuration > > parameters other than IP addresses, and aligns the behavior of the > > reconfiguration procedure in DHCPv4 to the corresponding behavior in > > DHCPv6. > > > > While not directly on the WG=E2=80=99s current charter, we have confirmed= with our > AD (Suresh) that this would be acceptable work for us to adopt (no > re-chartering will be necessary). > > > > - Tomek and Bernie > > > > > > > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg > > --089e011832ba0d87790531141ad1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
The reasons Luyuan Fang gave for wanting this made sense t= o me, and it makes sense that if someone is going to do this work, the meth= od they are using be documented. =C2=A0 They are going to need code points.= =C2=A0 This work could be done as an ISE document and get a code point thr= ough IESG action, but I think that what is being proposed shouldn't be = a lot of work to review, and so it's beneficial to have the working gro= up review it. =C2=A0 It's also easier from a process perspective. =C2= =A0 I am willing to be a reviewer. =C2=A0 I am in favor of adopting this as= a working group work item.

On Fri, Apr 22, 2016 at 10:48 AM, Bernie Volz (volz) <volz@c= isco.com> wrote:

Hi:

=C2=A0

At the IETF-95 DHC WG session, Luyuan Fang gave a pr= esentation on draft-fang-dhc-dhcpv4-forcerenew-extensions-02 (Forcerenew Re= configuration Extensions for DHCPv4) =E2=80=93 see https://www.ietf.org/proceedings/95/slides/slides-95-dhc-= 6.pdf.

=C2=A0

There was a brief discussion about whether there was= sufficient interest in the WG to take on this work and the conclusion was = to take it to the list (which we would have needed to do anyway).=

=C2=A0

So, we are starting an Adoption Call for this draft = (https://tools.ietf.org/html/draft-fang-dhc-d= hcpv4-forcerenew-extensions-02).

=C2=A0

Please respond by May 8, 2016 whether you support ha= ving the WG take on this work. Please note that this means YOU need to be i= nvolved in resolving open issues, reading draft updates, and otherwise acti= vely participating to move this work forward.

=C2=A0

The abstract from the draft is:

=C2=A0

=C2=A0=C2=A0 This document extends the definit= ion of the DHCPFORCERENEW message

=C2=A0=C2=A0 for parameter reconfiguration in = DHCPv4. This extension makes the

=C2=A0=C2=A0 DHCPFORCERENEW message more suita= ble to reconfigure configuration

=C2=A0=C2=A0 parameters other than IP addresse= s, and aligns the behavior of the

=C2=A0=C2=A0 reconfiguration procedure in DHCP= v4 to the corresponding behavior in

=C2=A0=C2=A0 DHCPv6.

=C2=A0

While not directly on the WG=E2=80=99s current chart= er, we have confirmed with our AD (Suresh) that this would be acceptable wo= rk for us to adopt (no re-chartering will be necessary).

=C2=A0

-=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Tomek and Bernie

=C2=A0

=C2=A0

=C2=A0


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


--089e011832ba0d87790531141ad1-- From nobody Fri Apr 22 08:38:29 2016 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 2B0DC12DC43 for ; Fri, 22 Apr 2016 08:38:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.898 X-Spam-Level: X-Spam-Status: No, score=-2.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.996, 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 s3eEZLVULR6l for ; Fri, 22 Apr 2016 08:38:26 -0700 (PDT) Received: from givry.fdupont.fr (givry.fdupont.fr [IPv6:2001:41d0:1:6d55:211:5bff:fe98:d51e]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D0B3112DB74 for ; Fri, 22 Apr 2016 08:38:25 -0700 (PDT) Received: from givry.fdupont.fr (localhost [IPv6:::1]) by givry.fdupont.fr (8.14.7/8.14.7) with ESMTP id u3MFSE8a014795; Fri, 22 Apr 2016 17:28:14 +0200 (CEST) (envelope-from dupont@givry.fdupont.fr) Message-Id: <201604221528.u3MFSE8a014795@givry.fdupont.fr> From: Francis Dupont To: Ian Farrer In-reply-to: Your message of Fri, 22 Apr 2016 11:20:26 +0200. <4A389729-1344-4F8A-B87E-7937866B97BE@gmx.com> Date: Fri, 22 Apr 2016 17:28:14 +0200 Archived-At: Cc: "dhcwg@ietf.org" , Ted Lemon , "Bernie Volz \(volz\)" Subject: Re: [dhcwg] Follow up from IETF-95 - draft-ietf-dhc-dhcpv6-prefix-length-hint-issue X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Apr 2016 15:38:27 -0000 In your previous mail you wrote: > Hi, > > I think seeing the changes that adding normative text would make is the best > way forward. > > I also would like to see the outcome of this rolled up into the 3315-bis as > it’s directly applicable and one of the motivations for writing it is that 36 > 33 didn’t cover it. But, publishing this as informational without normative l > anguage and then putting it into 3315-bis with normative seems a bit like a > 'bait-and-switch’:-) > > So, if it needs normative text in 3315-bis, then it should be progressed as > Standards track in this version. +1 (with a different (and surely better :-) wording Ian expressed the same idea than me) Regards Francis.Dupont@fdupont.fr From nobody Fri Apr 22 09:58:37 2016 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 72DEB12D967 for ; Fri, 22 Apr 2016 09:58:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] 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 1seW8ID70bpf for ; Fri, 22 Apr 2016 09:58:34 -0700 (PDT) Received: from mail-qk0-x230.google.com (mail-qk0-x230.google.com [IPv6:2607:f8b0:400d:c09::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 4485712DE72 for ; Fri, 22 Apr 2016 09:58:34 -0700 (PDT) Received: by mail-qk0-x230.google.com with SMTP id n63so40558453qkf.0 for ; Fri, 22 Apr 2016 09:58:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=OSPMdUg0VRc+1XaFMJN5VjaUlvZXuhivVb0RjerSygc=; b=hKQE93O6ZZUfkM8K0qz3L/CHmYeeIJb+X3vKpkgG5w95AzbLlfh0VBM9i/SDNEJb7/ FG+TLGfvGmfHRC/wm44uJ2T3lzWmF28N03f18z60TleIB2sofhGtJ1RSs7I7yS/s3C3/ AevFIOXZY0p7AzcQKa0K4uga9NEuGaweqvXHFok1oJ7YlJ4BouJSzvoUingC/BmNWOyD whExTUgFL+PSxt7sGH9/bEAJ0mwgCcobhj297p5nZJchjEh3kFtzQaGDmipa2oexGAIx AeJihGlQDsg1vkRmxnVrRy8EEZ7fGLlVcZXH7TxBnLiPlwrKF75irdEsEuuOWUI1abAE K4Lw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=OSPMdUg0VRc+1XaFMJN5VjaUlvZXuhivVb0RjerSygc=; b=jwRSwwhkIsPFREJlICoSAG/eoInR6RFcOzPKGxCS4DOmbnWprrXtent9tmGjgQyYq5 NxMx+GUOLtI7LhvTxk0nnd/+NW1TuHekt5RGSoGhQL1jlrleExnjEiGhXkoON+dLhmcG CoeoMzPDxIHFp4JYBuKqZ2RmCL5S3sCZmZx0Pt/YHHcmVrbA8T/AxDyzKPOff8nKsVKz hsNTVaY0BsFoVJEWBKAs0beNelsUmuXi1iMuB1QvNoX2Mn7WrB+WIrKhw1V4AlsMALdU Scd80Pt7WDm/dB9sOY7tEPc9/k1atg81am+HmGwhwb4zu0J/cZnLLWXd/XArJjQUHlGx KoTg== X-Gm-Message-State: AOPr4FUj2Idy1VFJnAEZqBrC076vCKWFEqBCaM4XN8RK7tzyA6TijCY62JmJLjgDZTWpP2f+YMxcXM+NogGCHw== MIME-Version: 1.0 X-Received: by 10.55.121.135 with SMTP id u129mr5699223qkc.138.1461344313297; Fri, 22 Apr 2016 09:58:33 -0700 (PDT) Received: by 10.55.185.67 with HTTP; Fri, 22 Apr 2016 09:58:33 -0700 (PDT) In-Reply-To: <201604221528.u3MFSE8a014795@givry.fdupont.fr> References: <4A389729-1344-4F8A-B87E-7937866B97BE@gmx.com> <201604221528.u3MFSE8a014795@givry.fdupont.fr> Date: Fri, 22 Apr 2016 22:28:33 +0530 Message-ID: From: yogendra pal To: Francis Dupont Content-Type: multipart/alternative; boundary=94eb2c063bc8b0546e053115bc15 Archived-At: Cc: "dhcwg@ietf.org" , Ted Lemon , "Bernie Volz \(volz\)" Subject: Re: [dhcwg] Follow up from IETF-95 - draft-ietf-dhc-dhcpv6-prefix-length-hint-issue X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Apr 2016 16:58:36 -0000 --94eb2c063bc8b0546e053115bc15 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hints are meaningful in CPE deployments, I would like to support for Standards Track. Regards, Yogendra Pal Cisco systems, Inc. On Fri, Apr 22, 2016 at 8:58 PM, Francis Dupont wrote: > In your previous mail you wrote: > > > Hi, > > > > I think seeing the changes that adding normative text would make is th= e > best > > way forward. > > > > I also would like to see the outcome of this rolled up into the > 3315-bis as > > it=E2=80=99s directly applicable and one of the motivations for writin= g it is > that 36 > > 33 didn=E2=80=99t cover it. But, publishing this as informational with= out > normative l > > anguage and then putting it into 3315-bis with normative seems a bit > like a > > 'bait-and-switch=E2=80=99:-) > > > > So, if it needs normative text in 3315-bis, then it should be > progressed as > > Standards track in this version. > > +1 (with a different (and surely better :-) wording Ian expressed the > same idea than me) > > Regards > > Francis.Dupont@fdupont.fr > > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg > > --=20 Thanks and Regards, Yogendra Pal +919686202644 --94eb2c063bc8b0546e053115bc15 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hints are meaningful in CPE deployments, I = would like to support for Standards Track.

Regards,
Y= ogendra Pal
Cisco systems, Inc.

<= /div>

On Fri, Apr 22, 2016 at 8:58 PM, Francis Dupont <= ;Francis.Dup= ont@fdupont.fr> wrote:
=C2=A0In your previous mail you wrote:

>=C2=A0 Hi,
>
>=C2=A0 I think seeing the changes that adding normative text would make= is the best
>=C2=A0 =C2=A0way forward.
>
>=C2=A0 I also would like to see the outcome of this rolled up into the = 3315-bis as
>=C2=A0 it=E2=80=99s directly applicable and one of the motivations for = writing it is that 36
>=C2=A0 33 didn=E2=80=99t cover it. But, publishing this as informationa= l without normative l
>=C2=A0 anguage and then putting it into 3315-bis with normative seems a= bit like a
>=C2=A0 'bait-and-switch=E2=80=99:-)
>
>=C2=A0 So, if it needs normative text in 3315-bis, then it should be pr= ogressed as
>=C2=A0 Standards track in this version.

+1 (with a different (and surely better :-) wording Ian expressed th= e
same idea than me)

Regards

Francis.Dupont@fdupont.fr<= br>

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




--
Thanks and Regards,
Yogendra Pal
+919686202644
--94eb2c063bc8b0546e053115bc15-- From nobody Sun Apr 24 07:32:58 2016 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 82C8B120727; Sun, 24 Apr 2016 07:32:56 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.19.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160424143256.6997.7861.idtracker@ietfa.amsl.com> Date: Sun, 24 Apr 2016 07:32:56 -0700 Archived-At: Cc: dhcwg@ietf.org Subject: [dhcwg] I-D Action: draft-ietf-dhc-sedhcpv6-12.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.17 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Apr 2016 14:32:57 -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 : Secure DHCPv6 Authors : Sheng Jiang Lishan Li Yong Cui Tatuya Jinmei Ted Lemon Dacheng Zhang Filename : draft-ietf-dhc-sedhcpv6-12.txt Pages : 28 Date : 2016-04-24 Abstract: The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) enables DHCPv6 servers to pass configuration parameters. It offers configuration flexibility. If not secured, DHCPv6 is vulnerable to various attacks. This document analyzes the security issues of DHCPv6 and specifies the secure DHCPv6 mechanism for authentication and encryption of messages between a DHCPv6 client and a DHCPv6 server. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dhc-sedhcpv6/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-dhc-sedhcpv6-12 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dhc-sedhcpv6-12 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 Sun Apr 24 20:13:00 2016 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 7499112D108 for ; Sun, 24 Apr 2016 20:12:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_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 K74KI82JSiL1 for ; Sun, 24 Apr 2016 20:12:57 -0700 (PDT) Received: from mail-oi0-x235.google.com (mail-oi0-x235.google.com [IPv6:2607:f8b0:4003:c06::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1069612D0C0 for ; Sun, 24 Apr 2016 20:12:57 -0700 (PDT) Received: by mail-oi0-x235.google.com with SMTP id k142so165065766oib.1 for ; Sun, 24 Apr 2016 20:12:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ad2SWX3dV2j0l1+bkjpEaPn5fJ614jUNxNjL7MTYV28=; b=arL+5US4WRkpcazpueisfyOUNElRK65iDCylNKUcyJdQW/JssCZohPj9L8Q7H+MqFe 8bSUtqRHec/OCbFtC8if6u5/JPBYVsDFrdJZveQFWIuucdQapARN8TJzl9nVdEAX9hYP 20mdYwFhYZblZViVMeuVVBnzuzWVTDkSl2I3xUR9JcVtBXBaryZjZEZgVGEuhFFq0hsD 9Dq5lBuMgUkmvFCbjE6WwyvSkM+BhlQVVHQSfEu1nxAFd0/lXhAiGNU6aLYHYeE5wbEE 1brdfQn1yDgVCrXyuR7zar+lky5ftH0ZVG9O1yfi2rD3i0/NDHnEXxgr9AnMpl4vUHT0 M+mA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ad2SWX3dV2j0l1+bkjpEaPn5fJ614jUNxNjL7MTYV28=; b=Y1skXKa08TKQeeC5jqRTGnRqPDdMeZ1IxCrtcWsNvL8onqCeWDcvjk+hOBpbk4nsmF Vpq9LMEhq168ZsCajqi/olSGbWPvy0gEHIMunRPuNSbsQDupkJ6PX6sj+hvMvlotd/of gWq2ynWJ/XYgylGB+ekkfI+ILVgA+ERAIFgzTPQK/N8482IO939zicK8ybkX0F/IGN/B 8rtbBV3ay2PrWDYoJOO49O4skvfzHao7quuaab2OI+Gj5As8PezhEz3IX98D30pWVES5 rlbRh3klvKho1qUwZo2uKjtOAfkm9RbU/a49TfjC6Afqx6VX5+KDwlzWD9hOhvsa7qJ6 XL1w== X-Gm-Message-State: AOPr4FXn/MdTH9l9HOWo+aWbYwyGdeCeJcSknfYe5tph0mkvNxibkuD4VeQH7gHjIq7XYyEk1Rv5We1niUM0ww== X-Received: by 10.157.11.106 with SMTP id p39mr9348239otd.117.1461553976356; Sun, 24 Apr 2016 20:12:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.202.44.79 with HTTP; Sun, 24 Apr 2016 20:12:16 -0700 (PDT) In-Reply-To: <4A389729-1344-4F8A-B87E-7937866B97BE@gmx.com> References: <0a8817dba2ea46c88ca67334a11c956d@XCH-ALN-003.cisco.com> <778BB254-D3FF-4FF3-9AC5-CA2B8DF6F04D@employees.org> <4A389729-1344-4F8A-B87E-7937866B97BE@gmx.com> From: tianxiang li Date: Mon, 25 Apr 2016 11:12:16 +0800 Message-ID: To: Ian Farrer Content-Type: multipart/alternative; boundary=001a113b1b7694b4690531468d03 Archived-At: Cc: dhcwg , mellon@fugue.com, "Bernie Volz \(volz\)" , Ole Troan Subject: Re: [dhcwg] Follow up from IETF-95 - draft-ietf-dhc-dhcpv6-prefix-length-hint-issue X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Apr 2016 03:12:59 -0000 --001a113b1b7694b4690531468d03 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, I think it is a good idea to first add normative text into the document. We will update a new version of the prefix-length hint issues draft soon, and determine which parts should be normative. We really appreciate your comments. Thank you, Tianxiang 2016-04-22 17:20 GMT+08:00 Ian Farrer : > Hi, > > I think seeing the changes that adding normative text would make is the > best way forward. > > I also would like to see the outcome of this rolled up into the 3315-bis > as it=E2=80=99s directly applicable and one of the motivations for writin= g it is > that 3633 didn=E2=80=99t cover it. But, publishing this as informational = without > normative language and then putting it into 3315-bis with normative seems= a > bit like a 'bait-and-switch=E2=80=99:-) > > So, if it needs normative text in 3315-bis, then it should be progressed > as Standards track in this version. > > Cheers, > Ian > > > On 21 Apr 2016, at 20:59, otroan@employees.org wrote: > > > > Ted, > > > >> Ole, the point is that if the document makes any normative statements, > it's got to be standards-track. You are quite right that the particular > statements you call out should not be made normatively, though! > > > > Agree, one option if we can identify what's normative in the document > would be to add that text to the 3315bis and leave this informational. > > > > RFC2119-ifying the text the authors think should be normative would be = a > good start. > > > > cheers, > > Ole > > > >> > >> On Thu, Apr 21, 2016 at 2:28 PM, wrote: > >> there are some parts that could be made normative, like section 2.5. > >> but most of the document appears informational in nature. > >> paraphrased example: "the server should delegates a /48 if the client > requests it". > >> that's clearly policy, and a matter of the possible commercial > arrangement, seems strange if the IETF should try to codify that. > >> > >> I lean towards informational. > >> > >> the document also does not say anything about _how_ the client is > supposed to figure out what sized address block to request. > >> if the answer to that is manual configuration, then there are tens of > ways that could be done differently out of band. > >> > >> cheers, > >> Ole > >> > >> > >> > >>> On 21 Apr 2016, at 18:45, Bernie Volz (volz) wrote: > >>> > >>> Hi: > >>> > >>> One item that was raised at the IETF-95 DHC WG session was the recent > change (suggested by me before > draft-cui-dhc-dhcpv6-prefix-length-hint-issue-02 was published) to switch > draft-ietf-dhc-dhcpv6-prefix-length-hint-issue to Informational rather th= an > Standards Track. Marcin Siodelski suggested that the document be Standard= s > Track: > >>> > >>> The brief (draft) minutes for this discuss are: > >>> > >>> --- > >>> 5. DHCPv6 Prefix Length Hint Issues, Bernie Volz (for Tianxiang Li) - > 10 minutes, 14:50 > >>> draft-ietf-dhc-dhcpv6-prefix-length-hint-issue > >>> > >>> The authors believe work is ready for WGLC. > >>> > >>> Ian: Is this now informational? "This is the suggested way to do > it"? > >>> Bernie: Correct. There were some discussions and the conclusion wa= s > to not > >>> enforce it. > >>> Marcin (on jabber): I'd suggest this is standards track doc with > normative language > >>> in. Otherwise implementations will ignore hints. > >>> --- > >>> > >>> Once we resolve this open question (and after a possible update to th= e > document), we intend to start a WGLC on the document. > >>> > >>> Please respond with your comments as to whether this document should > be Informational or Standards Track by May 5th, 2016. Of course, any othe= r > comments are welcome as well! > >>> > >>> Thanks! > >>> > >>> - Tomek & Bernie > >>> _______________________________________________ > >>> dhcwg mailing list > >>> dhcwg@ietf.org > >>> https://www.ietf.org/mailman/listinfo/dhcwg > >> > >> > >> _______________________________________________ > >> dhcwg mailing list > >> dhcwg@ietf.org > >> https://www.ietf.org/mailman/listinfo/dhcwg > >> > >> > > > > _______________________________________________ > > dhcwg mailing list > > dhcwg@ietf.org > > https://www.ietf.org/mailman/listinfo/dhcwg > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg > --001a113b1b7694b4690531468d03 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

I think it is a good idea to first = add normative text into the document. We will update a new version of the prefix-len= gth hint issues draft soon,=C2=A0and determine which parts should be normat= ive.=C2=A0
We really appreciate your comments.=

Thank you,
Tianxiang

2016-04-22 17:20 GMT+08:00 Ian Farrer <ianfarrer@gmx.com>:
Hi,

I think seeing the changes that adding normative text would make is the bes= t way forward.

I also would like to see the outcome of this rolled up into the 3315-bis as= it=E2=80=99s directly applicable and one of the motivations for writing it= is that 3633 didn=E2=80=99t cover it. But, publishing this as informationa= l without normative language and then putting it into 3315-bis with normati= ve seems a bit like a 'bait-and-switch=E2=80=99:-)

So, if it needs normative text in 3315-bis, then it should be progressed as= Standards track in this version.

Cheers,
Ian

> On 21 Apr 2016, at 20:59, otroan@employees.org wrote:
>
> Ted,
>
>> Ole, the point is that if the document makes any normative stateme= nts, it's got to be standards-track.=C2=A0 =C2=A0You are quite right th= at the particular statements you call out should not be made normatively, t= hough!
>
> Agree, one option if we can identify what's normative in the docum= ent would be to add that text to the 3315bis and leave this informational.<= br> >
> RFC2119-ifying the text the authors think should be normative would be= a good start.
>
> cheers,
> Ole
>
>>
>> On Thu, Apr 21, 2016 at 2:28 PM, <otroan@employees.org> wrote:
>> there are some parts that could be made normative, like section 2.= 5.
>> but most of the document appears informational in nature.
>> paraphrased example: "the server should delegates a /48 if th= e client requests it".
>> that's clearly policy, and a matter of the possible commercial= arrangement, seems strange if the IETF should try to codify that.
>>
>> I lean towards informational.
>>
>> the document also does not say anything about _how_ the client is = supposed to figure out what sized address block to request.
>> if the answer to that is manual configuration, then there are tens= of ways that could be done differently out of band.
>>
>> cheers,
>> Ole
>>
>>
>>
>>> On 21 Apr 2016, at 18:45, Bernie Volz (volz) <volz@cisco.com> wrote:
>>>
>>> Hi:
>>>
>>> One item that was raised at the IETF-95 DHC WG session was the= recent change (suggested by me before draft-cui-dhc-dhcpv6-prefix-length-h= int-issue-02 was published) to switch draft-ietf-dhc-dhcpv6-prefix-length-h= int-issue to Informational rather than Standards Track. Marcin Siodelski su= ggested that the document be Standards Track:
>>>
>>> The brief (draft) minutes for this discuss are:
>>>
>>> ---
>>> 5. DHCPv6 Prefix Length Hint Issues, Bernie Volz (for Tianxian= g Li) - 10 minutes, 14:50
>>>=C2=A0 =C2=A0 draft-ietf-dhc-dhcpv6-prefix-length-hint-issue >>>
>>>=C2=A0 =C2=A0 The authors believe work is ready for WGLC.
>>>
>>>=C2=A0 =C2=A0 Ian: Is this now informational? "This is the= suggested way to do it"?
>>>=C2=A0 =C2=A0 Bernie: Correct. There were some discussions and = the conclusion was to not
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0enforce it.
>>>=C2=A0 =C2=A0 Marcin (on jabber): I'd suggest this is stand= ards track doc with normative language
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0in. Otherwise implementations will i= gnore hints.
>>> ---
>>>
>>> Once we resolve this open question (and after a possible updat= e to the document), we intend to start a WGLC on the document.
>>>
>>> Please respond with your comments as to whether this document = should be Informational or Standards Track by May 5th, 2016. Of course, any= other comments are welcome as well!
>>>
>>> Thanks!
>>>
>>> -=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Tomek & Bernie
>>> _______________________________________________
>>> dhcwg mailing list
>>> dhcwg@ietf= .org
>>> https://www.ietf.org/mailman/listinfo/dhcwg<= /a>
>>
>>
>> _______________________________________________
>> dhcwg mailing list
>> dhcwg@ietf.org=
>> https://www.ietf.org/mailman/listinfo/dhcwg<= br> >>
>>
>
> _______________________________________________
> dhcwg mailing list
> dhcwg@ietf.org=
> https://www.ietf.org/mailman/listinfo/dhcwg

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

--001a113b1b7694b4690531468d03-- From nobody Mon Apr 25 11:12:06 2016 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 7168612D1C8 for ; Mon, 25 Apr 2016 11:12:04 -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 ofBRhP9Q_ydZ for ; Mon, 25 Apr 2016 11:12:02 -0700 (PDT) Received: from mail-ig0-x242.google.com (mail-ig0-x242.google.com [IPv6:2607:f8b0:4001:c05::242]) (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 6B6F312D0EF for ; Mon, 25 Apr 2016 11:12:02 -0700 (PDT) Received: by mail-ig0-x242.google.com with SMTP id g8so11979850igr.0 for ; Mon, 25 Apr 2016 11:12:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc; bh=nBSTtMQPahwNBNGg8BKb+t9Kmp1dIO34/HW0J57f6rA=; b=WQE6z43TnkBk+zbJq/pb6s8MKiTeEoPhhHr63PEi6noK7VKa/HeZFTZF9IqR1zHTYS QibBJgsk8Mqjk7hwz/77+QM+icys0+tULegeH+UUFBvUhfOUIr0Owlp9oHauUCue+zpO wwnws8RhUoJhIYbcPDilt1m9NmYHNj9ExU/LmLwOTN35TPG0T6Ssb1RH3VwZVGWqQheO Er9kx7Ih5T5eYOML/AENQhxgfTgEYJlkYdf7xyWrYnv7WVm+gGjTEs7z8/Z3zJ7IZ5GR 72iIRZ9wpECV9Nk9dovdOJmTv6fi03vF7zsh5CX7erkqby5gC29BJ/DB8r76WuS2r/Lj kVWw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc; bh=nBSTtMQPahwNBNGg8BKb+t9Kmp1dIO34/HW0J57f6rA=; b=ZaXMf/HNah/Ov8Tq/PAtSZdootxK6XyL0Z41VN8iNKVLfeKOvu1bRxfmOz7JkKFose fGVOMDByFxhLAcMFYZG6vFQpCeOzbk3xKCLx5PtdRr9f7QrtgH3+z7EQgktoxiAEVYph MLDxPK8dERMP7BVzPuQfjM1Fmu5BbYNm8lN8TBKJqAoZcwgEWkp/h/cFgjAzm6++3+Ta 2F+HE8LBmYgtkm6oeXRUk9IZivh3awpN5Jp/QHhDkk/dN0WAGWso+PYqBsZHgnVlIH5T eUsLMGoHRA7vhOKMP23Pqo9imztiITbKLE4ZcrAfXOEGLiIKyhHyu4uQ/srUOTkEu5Rx cvQQ== X-Gm-Message-State: AOPr4FXNF1bFu6er+lWp0Y3A0EVqSfG/yeR8glHSuvVvx7bOs5i/STRaKYytmMA2WOc7VDqmnLrCN8TuRIAEzw== MIME-Version: 1.0 X-Received: by 10.50.160.41 with SMTP id xh9mr13633884igb.64.1461607921468; Mon, 25 Apr 2016 11:12:01 -0700 (PDT) Sender: jinmei.tatuya@gmail.com Received: by 10.107.19.218 with HTTP; Mon, 25 Apr 2016 11:12:01 -0700 (PDT) In-Reply-To: <5c300ea84859409a9f619267bf2e92e7@XCH-ALN-003.cisco.com> References: <5c300ea84859409a9f619267bf2e92e7@XCH-ALN-003.cisco.com> Date: Mon, 25 Apr 2016 11:12:01 -0700 X-Google-Sender-Auth: O2LTNvlhB8RpHA5gCb5pYjFPtuk Message-ID: From: =?UTF-8?B?56We5piO6YGU5ZOJ?= To: "Bernie Volz (volz)" Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "dhcwg@ietf.org" Subject: Re: [dhcwg] Submitted draft-volz-dhc-relay-server-security-00.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Apr 2016 18:12:04 -0000 At Wed, 20 Apr 2016 13:11:16 +0000, "Bernie Volz (volz)" wrote: > I just submitted a new (individual submission) Internet-Draft to address relay/server exchanges and pervasive monitoring, as I mentioned at IETF-95 - see https://www.ietf.org/proceedings/95/slides/slides-95-dhc-3.pdf. > > Please look at the draft and comment to the list. It generally looks good to me. One thing I'd suggest is to explain why explicit confidentially is needed for relay-to-relay or relay-to-server in a bit more detail. This point will matter more for DHCPv6 as we are going to introduce end-to-end (i.e., client-to-server possibly via relays) encryption into DHCPv6 (I-D.ietf-dhc-sedhcpv6). volz-dhc-relay-server-security refers to the sedhcpv6 I-D, but it doesn't explain why we still need to introduce relay-to-relay encryption. From slides-95-dhc-3, I guess this is mainly because (among other things like whether sedhcpv6 is ever really deployed) some information that can't be covered in client-to-server confidentiality can still be privacy sensitive, like in the case of access-network-identifier (which makes sense to me). I think it would be better for volz-dhc-relay-server-security to explain this background explicitly. -- JINMEI, Tatuya From nobody Mon Apr 25 12:02:07 2016 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 B5E9A12D67A for ; Mon, 25 Apr 2016 12:02:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.517 X-Spam-Level: X-Spam-Status: No, score=-15.517 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_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, 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 yhPlpacTJPcb for ; Mon, 25 Apr 2016 12:02:04 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C1CC312D680 for ; Mon, 25 Apr 2016 12:02:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3052; q=dns/txt; s=iport; t=1461610923; x=1462820523; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=CI8w6PCnWAmS7XgzwdIzAqq6QKWvwTQvJBGABStE8Jw=; b=A64r3Qm+R5as3L+NMvsLDh/AcTclkHGKCA6FgyQlLA2zR/Prbdam3EDJ jE+FWp2VU89ptYbbgrr/jzQJcBJfMxXg6LMZr5YQYk/aLIqnVP0xxJlbG InyekBo9eprjtZtYw5xwYdqaL/jPkxXmol3BoKhqegO4JUjLWJKJpOFRe M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D6AQDHaB5X/4sNJK1egzhTfQapdoQgi?= =?us-ascii?q?10BDYF1JIVqAhyBHjgUAQEBAQEBAWUnhEEBAQECAQEjEUUFBwQCAQgRBAEBAwI?= =?us-ascii?q?jAwICAh8RFAEICAEBBA4FCIgNAwoIDrEzjCANhFUBAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEVfIlwgkGBZi6CaoJWBZdeMQGMHoFvgW2ETYhdh1CHXgEeAQFCg2tsAYg?= =?us-ascii?q?AfwEBAQ?= X-IronPort-AV: E=Sophos;i="5.24,533,1454976000"; d="scan'208";a="264109895" Received: from alln-core-6.cisco.com ([173.36.13.139]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 25 Apr 2016 19:02:02 +0000 Received: from XCH-RCD-004.cisco.com (xch-rcd-004.cisco.com [173.37.102.14]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id u3PJ22js012735 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 25 Apr 2016 19:02:03 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.1104.5; Mon, 25 Apr 2016 14:02:02 -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.1104.009; Mon, 25 Apr 2016 14:02:02 -0500 From: "Bernie Volz (volz)" To: =?utf-8?B?56We5piO6YGU5ZOJ?= Thread-Topic: [dhcwg] Submitted draft-volz-dhc-relay-server-security-00.txt Thread-Index: AdGbBbNQZAYkAhluToSAVAOkTsobJwEQiwWAAAlIsPA= Date: Mon, 25 Apr 2016 19:02:02 +0000 Message-ID: <870cebff51534a359257727cc017729f@XCH-ALN-003.cisco.com> References: <5c300ea84859409a9f619267bf2e92e7@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: Cc: "dhcwg@ietf.org" Subject: Re: [dhcwg] Submitted draft-volz-dhc-relay-server-security-00.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Apr 2016 19:02:05 -0000 SGkgSmlubWVpOg0KDQpTb3VuZHMgcmVhc29uYWJsZS4gSSdsbCBwbGFuIHRvIGluY29ycG9yYXRl IHRoaXMgY2hhbmdlIGludG8gdGhlIG5leHQgdmVyc2lvbi4NCg0KSG93IGFib3V0IHJlcGxhY2lu ZyB0aGUgIlRoaXMgcmV2aXNlZCB0ZXh0IGVzc2VudGlhbGx5IGFkZHMgZW5jcnlwdGlvbi4iIHNl bnRlbmNlIGluIHNlY3Rpb24gMyB3aXRoOg0KDQoiVGhpcyByZXZpc2VkIHRleHQgZXNzZW50aWFs bHkgYWRkcyBlbmNyeXB0aW9uIGFzIHJlbGF5IGFnZW50cyBtYXkgZm9yd2FyZCB1bmVuY3J5cHRl ZCBjbGllbnQgbWVzc2FnZXMgYXMgd2VsbCBhcyBpbmNsdWRlIGFkZGl0aW9uYWwgaW5mb3JtYXRp b24sIHN1Y2ggYXMgdmVuZG9yLXNwZWNpZmljIGluZm9ybWF0aW9uIChmb3IgZXhhbXBsZSwgW0Nh YmxlTGFic10pIGFuZCBbUkZDNzgzOV0uIg0KDQpOb3RlIHRoYXQgW0NhYmxlTGFic10gcmVmZXJl bmNlIHdvdWxkIGJlIHRvIENhYmxlTGFic+KAmSBESENQIE9wdGlvbnMgUmVnaXN0cnkgKGh0dHA6 Ly93d3cuY2FibGVsYWJzLmNvbS9zcGVjaWZpY2F0aW9uL2NhYmxlbGFicy1kaGNwLW9wdGlvbnMt cmVnaXN0cnktMi8pIGFuZCBbUkZDNzgzOV0gaXMgdGhlIHRvLWJlIGRyYWZ0LWlldGYtZGhjLWFj Y2Vzcy1uZXR3b3JrLWlkZW50aWZpZXItMTMuDQoNCi0gQmVybmllDQoNCi0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tDQpGcm9tOiBqaW5tZWkudGF0dXlhQGdtYWlsLmNvbSBbbWFpbHRvOmppbm1l aS50YXR1eWFAZ21haWwuY29tXSBPbiBCZWhhbGYgT2YgPz8/Pw0KU2VudDogTW9uZGF5LCBBcHJp bCAyNSwgMjAxNiAyOjEyIFBNDQpUbzogQmVybmllIFZvbHogKHZvbHopIDx2b2x6QGNpc2NvLmNv bT4NCkNjOiBkaGN3Z0BpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtkaGN3Z10gU3VibWl0dGVkIGRy YWZ0LXZvbHotZGhjLXJlbGF5LXNlcnZlci1zZWN1cml0eS0wMC50eHQNCg0KQXQgV2VkLCAyMCBB cHIgMjAxNiAxMzoxMToxNiArMDAwMCwNCiJCZXJuaWUgVm9seiAodm9seikiIDx2b2x6QGNpc2Nv LmNvbT4gd3JvdGU6DQoNCj4gSSBqdXN0IHN1Ym1pdHRlZCBhIG5ldyAoaW5kaXZpZHVhbCBzdWJt aXNzaW9uKSBJbnRlcm5ldC1EcmFmdCB0byBhZGRyZXNzIHJlbGF5L3NlcnZlciBleGNoYW5nZXMg YW5kIHBlcnZhc2l2ZSBtb25pdG9yaW5nLCBhcyBJIG1lbnRpb25lZCBhdCBJRVRGLTk1IC0gc2Vl IGh0dHBzOi8vd3d3LmlldGYub3JnL3Byb2NlZWRpbmdzLzk1L3NsaWRlcy9zbGlkZXMtOTUtZGhj LTMucGRmLg0KPg0KPiBQbGVhc2UgbG9vayBhdCB0aGUgZHJhZnQgYW5kIGNvbW1lbnQgdG8gdGhl IGxpc3QuDQoNCkl0IGdlbmVyYWxseSBsb29rcyBnb29kIHRvIG1lLiAgT25lIHRoaW5nIEknZCBz dWdnZXN0IGlzIHRvIGV4cGxhaW4gd2h5IGV4cGxpY2l0IGNvbmZpZGVudGlhbGx5IGlzIG5lZWRl ZCBmb3IgcmVsYXktdG8tcmVsYXkgb3IgcmVsYXktdG8tc2VydmVyIGluIGEgYml0IG1vcmUgZGV0 YWlsLiAgVGhpcyBwb2ludCB3aWxsIG1hdHRlciBtb3JlIGZvcg0KREhDUHY2IGFzIHdlIGFyZSBn b2luZyB0byBpbnRyb2R1Y2UgZW5kLXRvLWVuZCAoaS5lLiwgY2xpZW50LXRvLXNlcnZlciBwb3Nz aWJseSB2aWEgcmVsYXlzKSBlbmNyeXB0aW9uIGludG8gREhDUHY2IChJLUQuaWV0Zi1kaGMtc2Vk aGNwdjYpLg0Kdm9sei1kaGMtcmVsYXktc2VydmVyLXNlY3VyaXR5IHJlZmVycyB0byB0aGUgc2Vk aGNwdjYgSS1ELCBidXQgaXQgZG9lc24ndCBleHBsYWluIHdoeSB3ZSBzdGlsbCBuZWVkIHRvIGlu dHJvZHVjZSByZWxheS10by1yZWxheSBlbmNyeXB0aW9uLiAgRnJvbSBzbGlkZXMtOTUtZGhjLTMs IEkgZ3Vlc3MgdGhpcyBpcyBtYWlubHkgYmVjYXVzZSAoYW1vbmcgb3RoZXIgdGhpbmdzIGxpa2Ug d2hldGhlciBzZWRoY3B2NiBpcyBldmVyIHJlYWxseSBkZXBsb3llZCkgc29tZSBpbmZvcm1hdGlv biB0aGF0IGNhbid0IGJlIGNvdmVyZWQgaW4gY2xpZW50LXRvLXNlcnZlciBjb25maWRlbnRpYWxp dHkgY2FuIHN0aWxsIGJlIHByaXZhY3kgc2Vuc2l0aXZlLCBsaWtlIGluIHRoZSBjYXNlIG9mIGFj Y2Vzcy1uZXR3b3JrLWlkZW50aWZpZXIgKHdoaWNoIG1ha2VzIHNlbnNlIHRvIG1lKS4gIEkgdGhp bmsgaXQgd291bGQgYmUgYmV0dGVyIGZvciB2b2x6LWRoYy1yZWxheS1zZXJ2ZXItc2VjdXJpdHkg dG8gZXhwbGFpbiB0aGlzIGJhY2tncm91bmQgZXhwbGljaXRseS4NCg0KLS0NCkpJTk1FSSwgVGF0 dXlhDQo= From nobody Mon Apr 25 13:28:57 2016 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 1F48E12D0F2 for ; Mon, 25 Apr 2016 13:28:56 -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 Kei_z9jnnMVj for ; Mon, 25 Apr 2016 13:28:54 -0700 (PDT) Received: from mail-io0-x244.google.com (mail-io0-x244.google.com [IPv6:2607:f8b0:4001:c06::244]) (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 4812D12D0C1 for ; Mon, 25 Apr 2016 13:28:54 -0700 (PDT) Received: by mail-io0-x244.google.com with SMTP id d62so13402171iof.1 for ; Mon, 25 Apr 2016 13:28:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc; bh=LCJ3YuDc7ks7Id/bOUqVy6+pXssmNTjZvdhIfVS5jDQ=; b=iGHVyDLB2T+Stj4JZyo5YZg0zCN6eZhC5OsR2NZMfUIQwhWmGKRwYGZn7ST8jGlSNJ 2/a7Jtd325bKKJQR9bEhYRET1Hyq5NXFg+niYZHKRQdxC/TdaIG9JxA5DdU1TI8ajko3 XGKXxDF3G8g8PKtwo6kes7IKK+904E/rSZGjQN19qs5cUHVmmcbaMLUw/lnH5wIu6T1V nRNrrpE2xqCKdI4djkZw/KsPD9YBJLTLnni5xJxwm1cE1k7aGx5wfxh5l+bVlrNB244W N2/ct1hSv6WsHJdzkkRPTriZeePeZRmjqXz63xqVdyHw0XMKYiA0StdHJzH+Jf62Hzu6 7NpA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc; bh=LCJ3YuDc7ks7Id/bOUqVy6+pXssmNTjZvdhIfVS5jDQ=; b=G0wHqyOCYKJ23VQkU40ilH4FEn70FsnIBClLwBWiVYzS0d+qff1n1flF7GRXB4q869 96n2oNb7H/W8Ml7b4inRnghBUal9nsq2etd3xG86+f6Y52CdXZnbR00/w4yFJZaBF6xN 47axvQowQ4mSq9Piw8P/iUop9hnZeKfJeKEKaBUjbwnz+u4ForNN0Sv8I+9MQrwkjp4o tVd9+oXDSlHfN3otYvn6FMZxHn8MyaqPi2yShOzdUqDAoDfEERlkNicgSFYzchxkz0SD PkIUAwN+zHZqNaVUSyrEkPkQ2bJyO/zgJyYi+wZJ+BAjK8vn0s4+oGTUTaPJ0YsVciGr ZIQQ== X-Gm-Message-State: AOPr4FXCVM9rZ0MpNhNoUi3AqFn7QNoPx+2FIaJBnZ33rUEs2CaZUhKbAKwufScuJqw6U93K3S8qYjcXKMBFjQ== MIME-Version: 1.0 X-Received: by 10.107.58.213 with SMTP id h204mr44229856ioa.172.1461616133540; Mon, 25 Apr 2016 13:28:53 -0700 (PDT) Sender: jinmei.tatuya@gmail.com Received: by 10.107.19.218 with HTTP; Mon, 25 Apr 2016 13:28:53 -0700 (PDT) In-Reply-To: <870cebff51534a359257727cc017729f@XCH-ALN-003.cisco.com> References: <5c300ea84859409a9f619267bf2e92e7@XCH-ALN-003.cisco.com> <870cebff51534a359257727cc017729f@XCH-ALN-003.cisco.com> Date: Mon, 25 Apr 2016 13:28:53 -0700 X-Google-Sender-Auth: WRiW8yjrI2Za5cqMmTLJ5hTh8P0 Message-ID: From: =?UTF-8?B?56We5piO6YGU5ZOJ?= To: "Bernie Volz (volz)" Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "dhcwg@ietf.org" Subject: Re: [dhcwg] Submitted draft-volz-dhc-relay-server-security-00.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Apr 2016 20:28:56 -0000 At Mon, 25 Apr 2016 19:02:02 +0000, "Bernie Volz (volz)" wrote: > Sounds reasonable. I'll plan to incorporate this change into the next version. > > How about replacing the "This revised text essentially adds encryption." sentence in section 3 with: > > "This revised text essentially adds encryption as relay agents may forward unencrypted client messages as well as include additional information, such as vendor-specific information (for example, [CableLabs]) and [RFC7839]." Works for me. -- JINMEI, Tatuya From nobody Mon Apr 25 18:11:57 2016 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 19D8D12D0BC; Mon, 25 Apr 2016 18:11:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-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 jyrND_Mbh-uM; Mon, 25 Apr 2016 18:11:55 -0700 (PDT) Received: from usplmg21.ericsson.net (usplmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BEA6212B01E; Mon, 25 Apr 2016 18:11:55 -0700 (PDT) X-AuditID: c6180641-f796f6d000000e1e-25-571ec02e25f7 Received: from EUSAAHC002.ericsson.se (Unknown_Domain [147.117.188.78]) by usplmg21.ericsson.net (Symantec Mail Security) with SMTP id 72.BC.03614.F20CE175; Tue, 26 Apr 2016 03:11:11 +0200 (CEST) Received: from [142.133.113.69] (147.117.188.8) by smtps-am.internal.ericsson.com (147.117.188.78) with Microsoft SMTP Server (TLS) id 14.3.248.2; Mon, 25 Apr 2016 21:11:54 -0400 To: "dhc-chairs@ietf.org" , 'DHC WG' From: Suresh Krishnan Message-ID: <571EC059.8090005@ericsson.com> Date: Mon, 25 Apr 2016 21:11:53 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Originating-IP: [147.117.188.8] X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrBLMWRmVeSWpSXmKPExsUyuXSPn67+Ablwg70vBC3mdO9msrjb0cJo 0Xr0JqsDs8fhC/dZPJYs+ckUwBTFZZOSmpNZllqkb5fAlfHu+XnGgoOsFZMXvmJvYDzI0sXI ySEhYCKx7XELM4QtJnHh3nq2LkYuDiGBo4wSjZ/WsoEkhAS2MUrsuSoHYosIeEks+7YNrJkN qHnDzs9MILawQKrEk2XHGUFsZgF9iYt/9gH1snPwCmhL7E4FibIIqEosnXkdrFNUIELiydyT YNW8AoISJ2c+AYpzAHVqSqzfpQ8xRF5i+9s5zBAHaEpsXfOdFeJKRYkXx38yTWAUmIWkexZC 9ywk3QsYmVcxcpQWF+TkphsZbmIEht8xCTbHHYx7ez0PMQpwMCrx8C7glA0XYk0sK67MPcQo wcGsJMK7eY9cuBBvSmJlVWpRfnxRaU5q8SFGaQ4WJXFe78h/YUIC6YklqdmpqQWpRTBZJg5O qQZG+/bv2fas7R8flX1w7G3sqP4T9pqhbsJLf5sNqdcaH+jFpbhPlfO5OPPOp6PuapdiBW+l Vqewv7u9R8CGYWlhoNneJQJhPFcv/uF+yJ1qoR/UNfXYqqlhb1+fs5Kt+5tY+eyCpbxHUtP9 s1Xn0uMnHljJUXvgjUfjmlPG/2fel/2fkJv68YS5EktxRqKhFnNRcSIAzOpS+zsCAAA= Archived-At: Subject: [dhcwg] Opinion requested: Independent submission of draft-gont-dhcpv6-stable-privacy-addresses-01 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Apr 2016 01:11:57 -0000 Hi all, The draft describing Stable and Opaque IIDs with DHCPv6 available at https://tools.ietf.org/html/draft-gont-dhcpv6-stable-privacy-addresses-01 has been submitted through the Independent stream for publication. The IESG is currently performing a conflict review on the document as described in RFC5742. This document is up for discussion on the 2016-05-05 IESG Telechat. Since this document was discussed earlier in the dhc working group, I would like to solicit the opinion of the WG and the WG chairs on whether publishing the document is in any way harmful to the work of the dhc WG. Please send your opinions either on list or privately to me by 2016-05-03. Thanks Suresh From nobody Tue Apr 26 04:27:35 2016 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 045F112B069 for ; Tue, 26 Apr 2016 04:27:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_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 cjwunIyMcJtF for ; Tue, 26 Apr 2016 04:27:30 -0700 (PDT) Received: from mail-lf0-x229.google.com (mail-lf0-x229.google.com [IPv6:2a00:1450:4010:c07::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 01C3E12B036 for ; Tue, 26 Apr 2016 04:27:30 -0700 (PDT) Received: by mail-lf0-x229.google.com with SMTP id c126so13962585lfb.2 for ; Tue, 26 Apr 2016 04:27:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to; bh=nAbdyw4bQSchUUDWyRAtM9AfRv/yTdtywK8Tc284f5Q=; b=zdDHM3z3GWL0h54a+6Cyg4JT18qdIV1cQFWYd5SwaW2YXK8amNelwd5oiqRbuSWWEu VYXOE1oLjuZagusK4yKfsPQb6MiIykVDdRbvB1Ol21yTQlPH57bKoWQimOE3NYpcBvvc P1idUVc6NQlDt5IhpRYrfk0aI9z/MEAC38+aPMvmYiMS/cOVwLka3qdF3kSXCg2mi0zJ Fjw7EbEV+mHE1J0eC56yqfq260ElsNsOTxo3yTQR2p8hSU4uzNIpZazHf2b9HdjQnkZJ y3fWik2JmyEzCn8AkGCGvDToquTbAmNyZMouWPDFJyCccQH4lXhYaO43tYzYzaEidQci vU9w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to; bh=nAbdyw4bQSchUUDWyRAtM9AfRv/yTdtywK8Tc284f5Q=; b=NcvIOqzfG/hx/K14IMqOgiUgJOxu1D94Lc8ne7Vw/qxbL5yNlu58G1Gg8UHlQZK30R S7wlfYduvkz8GpB4HaGpo67KLHFc6oEcG063JPcUAL1fECC94ZOlB9aDeH2nntoXPOQA foDv1JQV6WrVCNM+DAVnuZWuP9Sjb8FUvW6BnYxreGme3z0VdPwoFjGdTRbLlYNuw1M1 BViuzXoWxMD2l4XoFwJElQ9UJamcX+jNtcMidcoX4id1qpfmvIGTWYXFnu97l98cXuYR 5RnlNZyGSuYmjaJPr9hZVNHjoy0RYe60xuH5ah68IrLjROHGgakh+2n6gg/FovlFllV/ /OLg== X-Gm-Message-State: AOPr4FWIQLN0xyCYIdkqaAuvBQvGfko/YVSuTgQAOEGxTT6lEvPnls+BHMPa/v++A8zJLCCjT4rpfRvlPBArgw== MIME-Version: 1.0 X-Received: by 10.25.168.7 with SMTP id r7mr1061518lfe.157.1461670048149; Tue, 26 Apr 2016 04:27:28 -0700 (PDT) Received: by 10.114.173.71 with HTTP; Tue, 26 Apr 2016 04:27:28 -0700 (PDT) In-Reply-To: <20160424143257.6997.44881.idtracker@ietfa.amsl.com> References: <20160424143257.6997.44881.idtracker@ietfa.amsl.com> Date: Tue, 26 Apr 2016 19:27:28 +0800 Message-ID: From: Lishan Li To: dhcwg Content-Type: multipart/alternative; boundary=001a11411960ffb7f90531619346 Archived-At: Subject: [dhcwg] Fwd: New Version Notification for draft-ietf-dhc-sedhcpv6-12.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Apr 2016 11:27:33 -0000 --001a11411960ffb7f90531619346 Content-Type: text/plain; charset=UTF-8 Dear All, We have submitted a new version of secure DHCPv6. In the new version, we made the following changes: 1. Add the signature and timestamp option during client/server authentication process; 2. Relay agent is RECOMMENDED to cache server announcements to form the list of the available DHCPv6 server certs. In this way, the client can be confident of a quick response, and therefore treat the lack of a quick response as an indication that no authenticated DHCPv6 servers exist; 3. Add the mandatory algorithm risk in security consideration; 4. Add the risk that the server may get a client through enumerating its entire cert list and then learn a lot about a client that way. Could you please review the draft and give us some comments? Thanks in advance. Best Regards, Lishan ---------- Forwarded message ---------- From: Date: 2016-04-24 22:32 GMT+08:00 Subject: New Version Notification for draft-ietf-dhc-sedhcpv6-12.txt To: Ted Lemon , Tatuya Jinmei , Sheng Jiang , Dacheng Zhang , Lishan Li , Yong Cui , Ted Lemon A new version of I-D, draft-ietf-dhc-sedhcpv6-12.txt has been successfully submitted by Lishan Li and posted to the IETF repository. Name: draft-ietf-dhc-sedhcpv6 Revision: 12 Title: Secure DHCPv6 Document date: 2016-04-24 Group: dhc Pages: 28 URL: https://www.ietf.org/internet-drafts/draft-ietf-dhc-sedhcpv6-12.txt Status: https://datatracker.ietf.org/doc/draft-ietf-dhc-sedhcpv6/ Htmlized: https://tools.ietf.org/html/draft-ietf-dhc-sedhcpv6-12 Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-dhc-sedhcpv6-12 Abstract: The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) enables DHCPv6 servers to pass configuration parameters. It offers configuration flexibility. If not secured, DHCPv6 is vulnerable to various attacks. This document analyzes the security issues of DHCPv6 and specifies the secure DHCPv6 mechanism for authentication and encryption of messages between a DHCPv6 client and a DHCPv6 server. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat --001a11411960ffb7f90531619346 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Dear All,=C2=A0

We have subm= itted a new version of secure DHCPv6.
In the new version, we made= the following changes:
1. Add the signature and timestamp option= during client/server authentication process;
2. Relay agent is R= ECOMMENDED to cache server announcements to form the list of the available DHCPv6 server certs. In = this way, the client can be confident of a quick response, and therefore tr= eat the lack of a=C2=A0quick respons= e as an indication that no authenticated DHCPv6 servers exist;
3.= Add the mandatory algorithm risk in security consideration;
4. A= dd the risk that the server may get a client through enumerating its entire=
cert list and then learn a lot about a client that way.

Could you please review the draft and give us some comment= s? Thanks in advance.

Best Regards,
Lish= an
---------- Forwarded message ----------<= br>From: <internet-drafts@ietf.org>
Date: 2016-04-24 22:32 GMT+08:00
Subject: New Version Notification = for draft-ietf-dhc-sedhcpv6-12.txt
To: Ted Lemon <ted.lemon@nominum.com>, Tatuya Jinmei <jinmei@wide.ad.jp>, Sheng Jiang <= ;jiangsheng@huawei.com>, Da= cheng Zhang <dacheng.zhang@gm= ail.com>, Lishan Li <lili= shan48@gmail.com>, Yong Cui <yong@csnet1.cs.tsinghua.edu.cn>, Ted Lemon <Ted.Lemon@nominum.com>


=
A new version of I-D, draft-ietf-dhc-sedhcpv6-12.txt
has been successfully submitted by Lishan Li and posted to the
IETF repository.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-ietf-dhc-sedhcpv6
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A012
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Secure DHCPv6
Document date:=C2=A0 2016-04-24
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 dhc
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 28
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/internet-drafts/draft-ietf-dhc-sedhcpv6-1= 2.txt
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0ht= tps://datatracker.ietf.org/doc/draft-ietf-dhc-sedhcpv6/
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://to= ols.ietf.org/html/draft-ietf-dhc-sedhcpv6-12
Diff:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dhc-sedhcpv6-12<= br>
Abstract:
=C2=A0 =C2=A0The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) enab= les
=C2=A0 =C2=A0DHCPv6 servers to pass configuration parameters.=C2=A0 It offe= rs
=C2=A0 =C2=A0configuration flexibility.=C2=A0 If not secured, DHCPv6 is vul= nerable to
=C2=A0 =C2=A0various attacks.=C2=A0 This document analyzes the security iss= ues of
=C2=A0 =C2=A0DHCPv6 and specifies the secure DHCPv6 mechanism for authentic= ation
=C2=A0 =C2=A0and encryption of messages between a DHCPv6 client and a DHCPv= 6
=C2=A0 =C2=A0server.




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

The IETF Secretariat


--001a11411960ffb7f90531619346-- From nobody Tue Apr 26 05:15:12 2016 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 9996012D18C for ; Tue, 26 Apr 2016 05:15:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_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 CJy-vMOOGkac for ; Tue, 26 Apr 2016 05:15:09 -0700 (PDT) Received: from mail-lf0-x231.google.com (mail-lf0-x231.google.com [IPv6:2a00:1450:4010:c07::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CFC4C12D183 for ; Tue, 26 Apr 2016 05:15:08 -0700 (PDT) Received: by mail-lf0-x231.google.com with SMTP id y84so13675751lfc.0 for ; Tue, 26 Apr 2016 05:15:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to; bh=euQFkxy9XvnKbtIBE6HrqqedryGyt7nN/ip81NJz6io=; b=fxyb0LeZMhiWC+NgCm9IiyMKqOlNTRCBU6b9o4m79/C9VA9PRGEcVdsWpVHKwxGC5c 119mLFiCkb/0Zs/Jmi8dNE5C0EzhO48uYoxiHRuEw1GmZQ4BbeTdSoViTFEsuc7ibGAr 0FrXoNWCW5fN+oGakqgh4dl6oU6wzVHLCr04vZ6RGNY5M3+i/TQQa/FrVh31Oulhr6PZ uoqHgQfsZXS4fYzhOOlixZLbEo3muVJH5OT8Sjk0+fMWFsAMNhkjxYFstzrxn0Z777Rs jR3GhM/lw6iourgrFUg+S5b368oHLuEupE7HgiurnRO0ji+yL7H1msDwpiStDQqnL2aR fovQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to; bh=euQFkxy9XvnKbtIBE6HrqqedryGyt7nN/ip81NJz6io=; b=ImazMcxwcZrvHRNcYlsmVEsT/T1yVrNWNRE2J8N2eiuhv7iV66WshQfFpQEgWLpP7l CBIxZnkKK+vR4IOHhjWYE0p7NZv2+ADQ22Al3PgxHbAixk/BKPep6gnmEAxXH+pDuFW2 3dJhSBYbZRdLtV2CW5cqB4IiylpBgCkV924bx3V6rLFSgb8fNAelQdsJW/qbECy7CiJf sMJq1wh3ux8gSzevwryLfEPWYTeCZ2+S1a7AmDGHfEYLh0YdzN1xck1GvWHh7/goD+tK dL4FkHGWqujQe9gHyK3wFknK7T7uvgt2GKbPLyUdfLxKEuDw6GiYJJWck7mEdmlYfcv/ I5ng== X-Gm-Message-State: AOPr4FWppG+pMQGNKCwS7+YZ3LKHRpYMcDtwHLI0zmJlvKMBjQDXxMRqpU46DNT53cvCyrgQ68Uilf2F6ekk+Q== MIME-Version: 1.0 X-Received: by 10.112.168.194 with SMTP id zy2mr1175079lbb.102.1461672907067; Tue, 26 Apr 2016 05:15:07 -0700 (PDT) Received: by 10.114.173.71 with HTTP; Tue, 26 Apr 2016 05:15:07 -0700 (PDT) Date: Tue, 26 Apr 2016 20:15:07 +0800 Message-ID: From: Lishan Li To: dhcwg Content-Type: multipart/alternative; boundary=001a11c333f2675d690531623e1e Archived-At: Subject: [dhcwg] Open Issues for Secure DHCPv6 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Apr 2016 12:15:11 -0000 --001a11c333f2675d690531623e1e Content-Type: text/plain; charset=UTF-8 Dear All, After the discussion with Ted and Jinmei, there are still some open issues. Regarding these open issues, could you please give us you suggestions? Looking forward to your guidance! The following are the current open issues: 1. A single DHCPv6 server selection for authentication at the beginning. If the two servers share one common certificate with the same public key, then the client should be able to send an encrypted request to both servers, and both the servers can decrypt the encrypted request and letting client select one of them in a compatible way to the original DHCPv6. So in this way, there is no need to contain the Server Identifier option in the Encrypted-Query message. The disadvantage is that the extra decryption cost is caused for the DHCPv6 server not for it. 2. Regarding timestamp, what about a strictly-increasing serial number (with rollover)? The advantage of a strictly increasing number is that the server can just discard messages from the client with lower numbers, and the client can do the same. The disadvantage is that the strictly-increasing number has to be committed to stable storage on the client. 3. For the DHCPv6 client, how about a bare key not a certificate? If the client uses certificate for authentication. The client has to generate a key and then submit it to a certificate authority to be signed. It would make sense for two different companies to trust all certs signed by the same authority. For the client which is no longer authorized, they still have a key signed by the authority. How do we stop that one client from authenticating? The answer is that we have to have a record of every client that is authorized to use the network. There are two ways to do client authentication: first, we can have the certificate authority remember all of the clients, and maintain a certificate revocation list (CRL) for clients whose certificates should no longer grant access to the network. Second, we can simply keep a list of all the client keys that are granted access to the network, and the DHCP server can check that list before granting access. The first one is more easy, so we think a bare key is enough not a certificate. 4. Whether we should mention opportunistic security in secure DHCPv6? 5. For the clients which has multiple certs, whether the transaction-id can work as the identifier of the client's public key for encryption, and server's private key for decryption? 6. The format of Encrypted-Query and Encrypted-Response messages. For the encrypted-query and encrypted-response messages, in the current version, the payload is a series of options, which may cause unnecessary attack. So according to Ted's suggestion, It is better that the payload is encrypted message with some fixed field. But DHCPv6 message's format are a series of options. If the encrypted-query and encrypted-response use the above format, are they still DHCPv6 messages? Best Regards, Lishan --001a11c333f2675d690531623e1e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Dear All,

After the discussi= on with Ted and Jinmei, there are still some open issues. Regarding these o= pen issues, could you please give us you suggestions? Looking forward to yo= ur guidance! The following are the current open issues:

1. A single DHCPv6 server selection for authentication at the beginni= ng.=C2=A0
If the two servers share one common certificate with th= e same public key, then the client should be able to send an encrypted requ= est to both servers, and both the servers can decrypt the encrypted request= and letting client select one of them in a compatible way to the original = DHCPv6.=C2=A0
So in this way, there is no need to contain the Ser= ver Identifier option in the Encrypted-Query message. The disadvantage is t= hat the extra decryption cost is caused for the DHCPv6 server not for it.= =C2=A0

2. Regarding timestamp, what about a strict= ly-increasing serial number (with rollover)?
The advantage of a s= trictly increasing number is that the server can just discard messages from= the client with lower numbers, and the client can do the same.=C2=A0 The d= isadvantage is that the strictly-increasing number has to be committed to s= table storage on the client. =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0

3. For the DHCPv6 client, how ab= out a bare key not a certificate?
If the client uses certificate = for authentication. The client has to generate a key and then submit it to = a certificate authority to be signed. It would make sense for two different= companies to trust all certs signed by the same authority. For the client = which is no longer authorized, they still have a key signed by the authorit= y. =C2=A0 How do we stop that one client from authenticating? The answer is= that we have to have a record of every client that is authorized to use th= e network.

There are two ways to do client authent= ication: first, we can have the certificate authority remember all of the c= lients, and maintain a certificate revocation list (CRL) for clients whose = certificates should no longer grant access to the network. Second, we can s= imply keep a list of all the client keys that are granted access to the net= work, and the DHCP server can check that list before granting access.
=

The first one is more easy, so we think a bare key is e= nough not a certificate.

4. Whether we should ment= ion opportunistic security in secure DHCPv6?

5. Fo= r the clients which has multiple certs, whether the transaction-id can work= as the identifier of the client's public key for encryption, and serve= r's =C2=A0private key for decryption?

6. The f= ormat of Encrypted-Query and Encrypted-Response messages.
For the= encrypted-query and encrypted-response messages, in the current version, t= he payload is a series of options, which may cause unnecessary attack. So a= ccording to Ted's suggestion, It is better that the payload is encrypte= d message with some fixed field. But DHCPv6 message's format are a seri= es of options. If the encrypted-query and encrypted-response use the above = format, are they still DHCPv6 messages?

Best Regar= ds,
Lishan
--001a11c333f2675d690531623e1e-- From nobody Wed Apr 27 09:10:33 2016 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 234BA12D8B2; Wed, 27 Apr 2016 09:10:31 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: , , , X-Test-IDTracker: no X-IETF-IDTracker: 6.19.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160427161031.25137.5289.idtracker@ietfa.amsl.com> Date: Wed, 27 Apr 2016 09:10:31 -0700 Archived-At: Subject: [dhcwg] The DHC WG has placed draft-fang-dhc-dhcpv4-forcerenew-extensions in state "Call For Adoption By WG Issued" X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.17 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Apr 2016 16:10:31 -0000 The DHC WG has placed draft-fang-dhc-dhcpv4-forcerenew-extensions in state Call For Adoption By WG Issued (entered by Bernie Volz) The document is available at https://datatracker.ietf.org/doc/draft-fang-dhc-dhcpv4-forcerenew-extensions/ From nobody Wed Apr 27 10:04:59 2016 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 350FE12D9DC; Wed, 27 Apr 2016 10:04:57 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Meeting Session Request Tool\"" To: X-Test-IDTracker: no X-IETF-IDTracker: 6.19.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160427170457.25205.2898.idtracker@ietfa.amsl.com> Date: Wed, 27 Apr 2016 10:04:57 -0700 Archived-At: Cc: dhc-chairs@ietf.org, tomasz.mrugalski@eti.pg.gda.pl, dhcwg@ietf.org Subject: [dhcwg] dhc - New Meeting Session Request for IETF 96 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.17 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Apr 2016 17:04:57 -0000 A new meeting session request has just been submitted by Tomek Mrugalski, a Chair of the dhc working group. --------------------------------------------------------- Working Group Name: Dynamic Host Configuration Area Name: Internet Area Session Requester: Tomek Mrugalski Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 50 Conflicts to Avoid: First Priority: v6ops 6man mif softwire homenet Second Priority: dnsop dnssd sunset4 pcp abfab curdle dane kitten openpgp tls tokbind trans Third Priority: ace acme cose dots httpauth i2nsf ipsecme jose mile oauth sacm Special Requests: We would be willing to take a 2.5h slot if that helps with the scheduling. We always used full time of 2h slots (except Buenos Aires, when several important members couldn't make it). --------------------------------------------------------- From nobody Wed Apr 27 10:08:02 2016 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 9F85912D52F for ; Wed, 27 Apr 2016 10:08:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.516 X-Spam-Level: X-Spam-Status: No, score=-15.516 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_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, 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 t8fFpCDqq-2d for ; Wed, 27 Apr 2016 10:08:00 -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 1245D12DA24 for ; Wed, 27 Apr 2016 10:07:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8939; q=dns/txt; s=iport; t=1461776832; x=1462986432; h=from:to:subject:date:message-id:mime-version; bh=wNQARWxYYCezqdx3VmyYmI/3LHwjPC1pnpG2dIGI0AM=; b=RIXjnuwf901CbS1VYYg0iW1VnJ4Sb3nhOrNhxbi/yiuSXxnNQ0vbFi8E f+HUiIyUDm3W0QFttEqwp2A1KnCtUN1l/nRDebgONG2dRQfqVtFtxwW0Q YyOF/MV+wkk8JAyZls2M077NH8WRytHBRjsxm8+uqMDjO2OmBI5r1rFzW Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AeAgCP8CBX/5hdJa1egmxMU4EDtHKCZ?= =?us-ascii?q?IIPAQ2BdSKHIDgUAQEBAQEBAWUcC4RILV4BgQAmAQQbiCIOomehDwEBAQEBAQQ?= =?us-ascii?q?BAQEBAQEBFQSNSoc1BZMfhHEBhXuIFIFuhE2IXY8vAR4BAUKDa4kbfwEBAQ?= X-IronPort-AV: E=Sophos;i="5.24,542,1454976000"; d="scan'208,217";a="266886711" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 27 Apr 2016 17:07:11 +0000 Received: from XCH-RCD-002.cisco.com (xch-rcd-002.cisco.com [173.37.102.12]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id u3RH7BRn003017 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Wed, 27 Apr 2016 17:07:11 GMT Received: from xch-aln-003.cisco.com (173.36.7.13) by XCH-RCD-002.cisco.com (173.37.102.12) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 27 Apr 2016 12:07:10 -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.1104.009; Wed, 27 Apr 2016 12:07:10 -0500 From: "Bernie Volz (volz)" To: "dhcwg@ietf.org" Thread-Topic: IETF-96 (Berlin) DHC WG Session - Agenda Requests Thread-Index: AdGgpkH9N7+vCsgeRRapIcMHndhsAA== Date: Wed, 27 Apr 2016 17:07:10 +0000 Message-ID: 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.76.217] Content-Type: multipart/alternative; boundary="_000_b1b9c2b3e38846b2bbd104a01ac24523XCHALN003ciscocom_" MIME-Version: 1.0 Archived-At: Subject: [dhcwg] IETF-96 (Berlin) DHC WG Session - Agenda Requests X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Apr 2016 17:08:01 -0000 --_000_b1b9c2b3e38846b2bbd104a01ac24523XCHALN003ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi: We are planning to request a 2 hour time slot for the DHC WG for IETF-96 (B= erlin). Please submit agenda requests as soon as you can if you do plan to = present at the DHC WG session in Berlin. As in the past, please provide: Title Of Session: Presenter: Related Drafts: Time Required: Purpose of Session: We do want to remind those requesting time that you should focus on discuss= ing key issues that need resolution to move a draft forward. You can view the working agenda at https://github.com/dhcwg/wg/wiki/IETF-96= -(Berlin)-DHC-WG-Agenda. We are now less than 3 months from that next meeting. Thanks! - Tomek & Bernie --_000_b1b9c2b3e38846b2bbd104a01ac24523XCHALN003ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi:

 

We are planning to request a 2 hour time slot for th= e DHC WG for IETF-96 (Berlin). Please submit agenda requests as soon as you= can if you do plan to present at the DHC WG session in Berlin.<= /p>

 

As in the past, please provide:

 

Title Of Session:

Presenter:

Related Drafts:

Time Required:

Purpose of Session:

 

We do want to remind those requesting time that you = should focus on discussing key issues that need resolution to move a draft = forward.

 

You can view the working agenda at https://github.com/dhcwg/wg/wiki/IETF-96-(Berlin)-DHC-WG-Agenda.

 

We are now less than 3 months from that next meeting= .

 

Thanks!

 

-     &= nbsp;    Tomek & Bernie

 

--_000_b1b9c2b3e38846b2bbd104a01ac24523XCHALN003ciscocom_-- From nobody Wed Apr 27 10:11:02 2016 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 E914912DA32; Wed, 27 Apr 2016 10:10:59 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Meeting Session Request Tool\"" To: X-Test-IDTracker: no X-IETF-IDTracker: 6.19.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160427171059.25213.17294.idtracker@ietfa.amsl.com> Date: Wed, 27 Apr 2016 10:10:59 -0700 Archived-At: Cc: dhc-chairs@ietf.org, tomasz.mrugalski@eti.pg.gda.pl, dhcwg@ietf.org Subject: [dhcwg] dhc - Update to a Meeting Session Request for IETF 96 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.17 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Apr 2016 17:11:00 -0000 An update to a meeting session request has just been submitted by Tomek Mrugalski, a Chair of the dhc working group. --------------------------------------------------------- Working Group Name: Dynamic Host Configuration Area Name: Internet Area Session Requester: Tomek Mrugalski Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 50 Conflicts to Avoid: First Priority: v6ops 6man mif softwire homenet Second Priority: dnsop dnssd sunset4 pcp dane Special Requests: We would be willing to take a 2.5h slot if that helps with the scheduling. We always used full time of 2h slots (except Buenos Aires, when several important members couldn't make it). --------------------------------------------------------- From nobody Wed Apr 27 10:12:37 2016 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 AB0FB12D9EF; Wed, 27 Apr 2016 10:12:34 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Meeting Session Request Tool\"" To: X-Test-IDTracker: no X-IETF-IDTracker: 6.19.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160427171234.25289.6476.idtracker@ietfa.amsl.com> Date: Wed, 27 Apr 2016 10:12:34 -0700 Archived-At: Cc: dhc-chairs@ietf.org, tomasz.mrugalski@eti.pg.gda.pl, dhcwg@ietf.org Subject: [dhcwg] dhc - Update to a Meeting Session Request for IETF 96 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.17 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Apr 2016 17:12:34 -0000 An update to a meeting session request has just been submitted by Tomek Mrugalski, a Chair of the dhc working group. --------------------------------------------------------- Working Group Name: Dynamic Host Configuration Area Name: Internet Area Session Requester: Tomek Mrugalski Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 50 Conflicts to Avoid: First Priority: v6ops 6man mif softwire homenet Second Priority: dane pcp sunset4 dnssd dnsop Special Requests: We would be willing to take a 2.5h slot if that helps with the scheduling. We always used full time of 2h slots (except Buenos Aires, when several important members couldn't make it). --------------------------------------------------------- From nobody Wed Apr 27 11:09:08 2016 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 9187812DB7F; Wed, 27 Apr 2016 11:09:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.516 X-Spam-Level: X-Spam-Status: No, score=-15.516 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.996, 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 bmQzU6sfG8d3; Wed, 27 Apr 2016 11:09:05 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E70A012D55E; Wed, 27 Apr 2016 11:09:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=15932; q=dns/txt; s=iport; t=1461780544; x=1462990144; h=from:to:subject:date:message-id:mime-version; bh=xWSnQPgY+HQaGVsJF/B7Wz5IwKRBXsDchv643k1ky1s=; b=cBXvTmGmak0iYHTeRDTaK3G2Me09TsSsEoIzFRby7jfUuOqko1yJbyer yz1qsVZ1WiMLTL1VdqT8wVQG5GA0U9rq0JkaIUh/2sdDA5+6Mgg8t3W59 RZBvBNYH9DP9zOPwOA6jYR6AKeke2ZR7mT8gf6zC4au2zZKgAx6kw3rDf w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AOAgCD/yBX/5hdJa1EGoJsTFN9BrlmA?= =?us-ascii?q?Q2BdSSHHzgUAQEBAQEBAWUnhEYCLV4BGCAMPCYBBAEaiCIOLLZqjCYBAQEBAQE?= =?us-ascii?q?BAQEBAQEBAQEBAQEBF4pshAYhBl6FCAWYEAGFe4gUgW5OjFyGJIkLAQ8PAQFCg?= =?us-ascii?q?gUbFoE1bAGILn8BAQE?= X-IronPort-AV: E=Sophos; i="5.24,542,1454976000"; d="scan'208,217"; a="98537183" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 27 Apr 2016 18:09:03 +0000 Received: from XCH-ALN-005.cisco.com (xch-aln-005.cisco.com [173.36.7.15]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id u3RI93Cl009799 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 27 Apr 2016 18:09:03 GMT Received: from xch-aln-003.cisco.com (173.36.7.13) by XCH-ALN-005.cisco.com (173.36.7.15) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 27 Apr 2016 13:09: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.1104.009; Wed, 27 Apr 2016 13:09:03 -0500 From: "Bernie Volz (volz)" To: "dhcwg@ietf.org" , "'dhcpv6bis@ietf.org'" Thread-Topic: Reminder - Monthly draft-ietf-dhc-rfc3315bis co-authors call (5/4/2016 - 0800-0900 (EDT - USA)) Thread-Index: AdGgrrDV9PQYLaLYS5i24MNOO/hCyQ== Date: Wed, 27 Apr 2016 18:09:03 +0000 Message-ID: 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.76.217] Content-Type: multipart/alternative; boundary="_000_bccdc98a13fc4febb948eb42a266aec7XCHALN003ciscocom_" MIME-Version: 1.0 Archived-At: Subject: [dhcwg] Reminder - Monthly draft-ietf-dhc-rfc3315bis co-authors call (5/4/2016 - 0800-0900 (EDT - USA)) X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Apr 2016 18:09:06 -0000 --_000_bccdc98a13fc4febb948eb42a266aec7XCHALN003ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi: This is to notify the DHC WG that there will be a draft-ietf-dhc-rfc3315bis= co-author meeting at 0800 to 0900 EDT (USA) on Wed May 4, 2016. Those inte= rested in participating may join the discussion. We will use https://jitsi.= tools.ietf.org/dhcpv6 (with a WebEx as backup in case of issues - see below= ). The proposed agenda is to review the in progress (assigned) and unassigned = tickets to meet our proposed schedule presented at IETF-95 (see https://www= .ietf.org/proceedings/95/slides/slides-95-dhc-5.pdf): * Reorganizing client/server sections (#142) by April 15th * Finish most other tickets by May 9th (see http://trac.tools.ietf.= org/group/dhcpv6bis/report). * Apply editor tickets * Republish by May 23 (05) * Complete WGLC before Berlin (IETF-96) - [non-coauthors that volun= teered to review at IETF-95 were: Ted Lemon, Mohammed Boucadair, Tim Winter= s, Ian Farrer, Tim Chown, Francis Dupont, Paul Ebersman] * Discuss any WGLC issues in Berlin and update * Send to IESG in September 2016 While we intend to use jitsi (see above), a WebEx has been scheduled in cas= e of issues with jitsi: JOIN WEBEX MEETING https://cisco.webex.com/ciscosales/j.php?MTID=3Dm22f09f2a39b354becf5825d8b9= d6af37 Meeting number: 206 329 100 Meeting password: dhc Global call-in numbers: https://cisco.webex.com/ciscosales/globalcallin.php?serviceType=3DMC&ED=3D3= 21678407&tollFree=3D1 - Bernie --_000_bccdc98a13fc4febb948eb42a266aec7XCHALN003ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi:

 =

This is to notify the DH= C WG that there will be a draft-ietf-dhc-rfc3315bis co-author meeting at 08= 00 to 0900 EDT (USA) on Wed May 4, 2016. Those interested in participating = may join the discussion. We will use https://jitsi.tools.ietf.org/dhcpv6 (with a WebEx as backup in = case of issues – see below).

 =

The proposed agenda is t= o review the in progress (assigned) and unassigned tickets to meet our prop= osed schedule presented at IETF-95 (see https://www.ietf.org/proceedings/95= /slides/slides-95-dhc-5.pdf):

 =

·         Reorganizing cli= ent/server sections (#142) by April 15th

·         Finish most othe= r tickets by May 9th (see http://trac.tools.ietf.org/group/dhcpv6bis/report).

·         Apply editor tic= kets

·         Republish by May= 23 (05)

·         Complete WGLC be= fore Berlin (IETF-96) – [non-coauthors that volunteered to review at = IETF-95 were: Ted Lemon, Mohammed Boucadair, Tim Winters, Ian Farrer, Tim C= hown, Francis Dupont, Paul Ebersman]

·         Discuss any WGLC= issues in Berlin and update

·         Send to IESG in = September 2016

 =

While we intend to us= e jitsi (see above), a WebEx has been scheduled in case of issues with jits= i:

 

JOIN WEBEX MEETING

https://cisco.webex.com/ciscosales/j.php?MTID=3Dm= 22f09f2a39b354becf5825d8b9d6af37

Meeting number: =   206 329 100

Meeting password: dhc=

 

Global call-in number= s:

https://cisco.webex.com/ci= scosales/globalcallin.php?serviceType=3DMC&ED=3D321678407&tollFree= =3D1

 =

- = ;         Bernie

 

 

--_000_bccdc98a13fc4febb948eb42a266aec7XCHALN003ciscocom_-- From nobody Thu Apr 28 06:48:05 2016 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 7C83D12D14A for ; Thu, 28 Apr 2016 06:48:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.516 X-Spam-Level: X-Spam-Status: No, score=-15.516 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.996, 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 byTiEo_Y6LH1 for ; Thu, 28 Apr 2016 06:48:03 -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 B00BC12D10B for ; Thu, 28 Apr 2016 06:48:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=25448; q=dns/txt; s=iport; t=1461851282; x=1463060882; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=l5Duh+kKYT6YcLmKHbpU/zYAGqXmst+LNk6/PPT0Hik=; b=CLkm1QXqZXdqhnfgQj2y0muws+jDVv11nuDDUIeiFG9njm977Em/y6ZY Jc0X9zzu4pGrDmkrMEW1aHqE3yeunfRxEIjza6xq4H+cRam/dei1pn5bG MQDfD+lQaSTmFCTPUyCXB3VjRDLXFrPjAbN6P2rHKdtjc2vI7DqeQLSnh s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BcAgBKFCJX/5ldJa1egmxMU30GuW8BD?= =?us-ascii?q?YF2hg8CHIELOBQBAQEBAQEBZSeEQQEBAQQjClwCAQgRBAEBKAMCAgIwFAkIAgQ?= =?us-ascii?q?BEgiIIrIVkRQBAQEBAQEBAQEBAQEBAQEBAQEBAQEViWqBAoQnAkqCSoJWBZgQA?= =?us-ascii?q?Y4PgW6ETYhdjy8BHgEBQoIFG4FLbIYrPn8BAQE?= X-IronPort-AV: E=Sophos;i="5.24,546,1454976000"; d="scan'208,217";a="101597897" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 28 Apr 2016 13:48:01 +0000 Received: from XCH-ALN-002.cisco.com (xch-aln-002.cisco.com [173.36.7.12]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id u3SDm1Ks026449 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 28 Apr 2016 13:48:01 GMT Received: from xch-aln-003.cisco.com (173.36.7.13) by XCH-ALN-002.cisco.com (173.36.7.12) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 28 Apr 2016 08:48:01 -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.1104.009; Thu, 28 Apr 2016 08:48:00 -0500 From: "Bernie Volz (volz)" To: Lishan Li , dhcwg Thread-Topic: [dhcwg] Open Issues for Secure DHCPv6 Thread-Index: AQHRn7VOYWVi5D/aP0CPgYl2nwWpKp+fZrEg Date: Thu, 28 Apr 2016 13:48:00 +0000 Message-ID: <25322a5ec897409093e904a7dc4549d3@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.200] Content-Type: multipart/alternative; boundary="_000_25322a5ec897409093e904a7dc4549d3XCHALN003ciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [dhcwg] Open Issues for Secure DHCPv6 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Apr 2016 13:48:04 -0000 --_000_25322a5ec897409093e904a7dc4549d3XCHALN003ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGk6DQoNCkEgZmV3IGNvbW1lbnRzIGJlbG93IChCVj4pLiBGb3IgdGhvc2UgcXVlc3Rpb25zIEkg ZGlkIG5vdCBoYXZlIGEgY29tbWVudCBvbiwgaXQgbWVhbnMgSeKAmW0gbm90IHlldCBzdXJlIHdo YXQgdG8gc2F5Lg0KDQoNCi0gICAgICAgICAgQmVybmllDQoNCkZyb206IGRoY3dnIFttYWlsdG86 ZGhjd2ctYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIExpc2hhbiBMaQ0KU2VudDogVHVl c2RheSwgQXByaWwgMjYsIDIwMTYgODoxNSBBTQ0KVG86IGRoY3dnIDxkaGN3Z0BpZXRmLm9yZz4N ClN1YmplY3Q6IFtkaGN3Z10gT3BlbiBJc3N1ZXMgZm9yIFNlY3VyZSBESENQdjYNCg0KRGVhciBB bGwsDQoNCkFmdGVyIHRoZSBkaXNjdXNzaW9uIHdpdGggVGVkIGFuZCBKaW5tZWksIHRoZXJlIGFy ZSBzdGlsbCBzb21lIG9wZW4gaXNzdWVzLiBSZWdhcmRpbmcgdGhlc2Ugb3BlbiBpc3N1ZXMsIGNv dWxkIHlvdSBwbGVhc2UgZ2l2ZSB1cyB5b3Ugc3VnZ2VzdGlvbnM/IExvb2tpbmcgZm9yd2FyZCB0 byB5b3VyIGd1aWRhbmNlISBUaGUgZm9sbG93aW5nIGFyZSB0aGUgY3VycmVudCBvcGVuIGlzc3Vl czoNCg0KMS4gQSBzaW5nbGUgREhDUHY2IHNlcnZlciBzZWxlY3Rpb24gZm9yIGF1dGhlbnRpY2F0 aW9uIGF0IHRoZSBiZWdpbm5pbmcuDQpJZiB0aGUgdHdvIHNlcnZlcnMgc2hhcmUgb25lIGNvbW1v biBjZXJ0aWZpY2F0ZSB3aXRoIHRoZSBzYW1lIHB1YmxpYyBrZXksIHRoZW4gdGhlIGNsaWVudCBz aG91bGQgYmUgYWJsZSB0byBzZW5kIGFuIGVuY3J5cHRlZCByZXF1ZXN0IHRvIGJvdGggc2VydmVy cywgYW5kIGJvdGggdGhlIHNlcnZlcnMgY2FuIGRlY3J5cHQgdGhlIGVuY3J5cHRlZCByZXF1ZXN0 IGFuZCBsZXR0aW5nIGNsaWVudCBzZWxlY3Qgb25lIG9mIHRoZW0gaW4gYSBjb21wYXRpYmxlIHdh eSB0byB0aGUgb3JpZ2luYWwgREhDUHY2Lg0KU28gaW4gdGhpcyB3YXksIHRoZXJlIGlzIG5vIG5l ZWQgdG8gY29udGFpbiB0aGUgU2VydmVyIElkZW50aWZpZXIgb3B0aW9uIGluIHRoZSBFbmNyeXB0 ZWQtUXVlcnkgbWVzc2FnZS4gVGhlIGRpc2FkdmFudGFnZSBpcyB0aGF0IHRoZSBleHRyYSBkZWNy eXB0aW9uIGNvc3QgaXMgY2F1c2VkIGZvciB0aGUgREhDUHY2IHNlcnZlciBub3QgZm9yIGl0Lg0K DQpCVj4gSG93IGFib3V0IGFkZGluZyB0aGUgc2VydmVyLWlkZW50aWZpZXIgb3B0aW9uIHdoZW4g aXQgaXMgaW4gdGhlIGNsaWVudCBtZXNzYWdlIChpLmUuIFJlcXVlc3QsIFJlbmV3LCBEZWNsaW5l LCBSZWxlYXNlKS4gVGhhdCB3YXksIG9uY2UgYSBzZXJ2ZXIgaXMgc2VsZWN0ZWQgdGhlIG90aGVy IHNlcnZlcnMgY2FuIGlnbm9yZSB3aXRob3V0IG5lZWRpbmcgdG8gZGVjcnlwdD8gVGhhdCByZWR1 Y2VzIHRoZSBsb2FkIGEgYml0Lg0KDQoyLiBSZWdhcmRpbmcgdGltZXN0YW1wLCB3aGF0IGFib3V0 IGEgc3RyaWN0bHktaW5jcmVhc2luZyBzZXJpYWwgbnVtYmVyICh3aXRoIHJvbGxvdmVyKT8NClRo ZSBhZHZhbnRhZ2Ugb2YgYSBzdHJpY3RseSBpbmNyZWFzaW5nIG51bWJlciBpcyB0aGF0IHRoZSBz ZXJ2ZXIgY2FuIGp1c3QgZGlzY2FyZCBtZXNzYWdlcyBmcm9tIHRoZSBjbGllbnQgd2l0aCBsb3dl ciBudW1iZXJzLCBhbmQgdGhlIGNsaWVudCBjYW4gZG8gdGhlIHNhbWUuICBUaGUgZGlzYWR2YW50 YWdlIGlzIHRoYXQgdGhlIHN0cmljdGx5LWluY3JlYXNpbmcgbnVtYmVyIGhhcyB0byBiZSBjb21t aXR0ZWQgdG8gc3RhYmxlIHN0b3JhZ2Ugb24gdGhlIGNsaWVudC4NCg0KQlY+IFRoaXMgc2VlbXMg YSBiaXQgdHJpY2t5LiBXaGF0IGhhcHBlbnMgaWYgdGhlIHN0YWJsZSBzdG9yYWdlIGlzIGxvc3Q/ IEEgdGltZSBiYXNlZCB2YWx1ZSAod2hlbiBwb3NzaWJsZSDigJMgaS5lLiwgY2xpZW50IGhhcyB0 aW1lKSBzZWVtcyBsaWtlIGEgYmV0dGVyIG9wdGlvbiB0byBtZT8gRm9yIGNsaWVudHMgdGhhdCBk b27igJl0IGhhdmUgdGhlIGN1cnJlbnQgdGltZSAoaS5lLiwgbmVlZCBESENQIHRvIGdldCB0aGUg dGltZSksIHBlcmhhcHMgdGhlIHRpbWVzdGFtcCBpcyBvcHRpb25hbCB0byBhY2NvbW1vZGF0ZSB0 aGVtIOKAkyB0aGlzIGRvZXMgbWVhbiB0aGVyZSBpcyB0aGUgcmVwbGF5IHJpc2sgKGF0IGxlYXN0 IHVudGlsIGEgdGltZSBpcyBhdmFpbGFibGUpLiBJIHByZWZlciB3ZSB1c2UgZXhpc3RpbmcgdGVj aG5pcXVlcyBmb3IgdGhpcyBhbmQgSSB0aGluayB0aGV5IGFyZSBnZW5lcmFsbHkgdGltZSBiYXNl ZD8NCg0KMy4gRm9yIHRoZSBESENQdjYgY2xpZW50LCBob3cgYWJvdXQgYSBiYXJlIGtleSBub3Qg YSBjZXJ0aWZpY2F0ZT8NCklmIHRoZSBjbGllbnQgdXNlcyBjZXJ0aWZpY2F0ZSBmb3IgYXV0aGVu dGljYXRpb24uIFRoZSBjbGllbnQgaGFzIHRvIGdlbmVyYXRlIGEga2V5IGFuZCB0aGVuIHN1Ym1p dCBpdCB0byBhIGNlcnRpZmljYXRlIGF1dGhvcml0eSB0byBiZSBzaWduZWQuIEl0IHdvdWxkIG1h a2Ugc2Vuc2UgZm9yIHR3byBkaWZmZXJlbnQgY29tcGFuaWVzIHRvIHRydXN0IGFsbCBjZXJ0cyBz aWduZWQgYnkgdGhlIHNhbWUgYXV0aG9yaXR5LiBGb3IgdGhlIGNsaWVudCB3aGljaCBpcyBubyBs b25nZXIgYXV0aG9yaXplZCwgdGhleSBzdGlsbCBoYXZlIGEga2V5IHNpZ25lZCBieSB0aGUgYXV0 aG9yaXR5LiAgIEhvdyBkbyB3ZSBzdG9wIHRoYXQgb25lIGNsaWVudCBmcm9tIGF1dGhlbnRpY2F0 aW5nPyBUaGUgYW5zd2VyIGlzIHRoYXQgd2UgaGF2ZSB0byBoYXZlIGEgcmVjb3JkIG9mIGV2ZXJ5 IGNsaWVudCB0aGF0IGlzIGF1dGhvcml6ZWQgdG8gdXNlIHRoZSBuZXR3b3JrLg0KDQpUaGVyZSBh cmUgdHdvIHdheXMgdG8gZG8gY2xpZW50IGF1dGhlbnRpY2F0aW9uOiBmaXJzdCwgd2UgY2FuIGhh dmUgdGhlIGNlcnRpZmljYXRlIGF1dGhvcml0eSByZW1lbWJlciBhbGwgb2YgdGhlIGNsaWVudHMs IGFuZCBtYWludGFpbiBhIGNlcnRpZmljYXRlIHJldm9jYXRpb24gbGlzdCAoQ1JMKSBmb3IgY2xp ZW50cyB3aG9zZSBjZXJ0aWZpY2F0ZXMgc2hvdWxkIG5vIGxvbmdlciBncmFudCBhY2Nlc3MgdG8g dGhlIG5ldHdvcmsuIFNlY29uZCwgd2UgY2FuIHNpbXBseSBrZWVwIGEgbGlzdCBvZiBhbGwgdGhl IGNsaWVudCBrZXlzIHRoYXQgYXJlIGdyYW50ZWQgYWNjZXNzIHRvIHRoZSBuZXR3b3JrLCBhbmQg dGhlIERIQ1Agc2VydmVyIGNhbiBjaGVjayB0aGF0IGxpc3QgYmVmb3JlIGdyYW50aW5nIGFjY2Vz cy4NCg0KVGhlIGZpcnN0IG9uZSBpcyBtb3JlIGVhc3ksIHNvIHdlIHRoaW5rIGEgYmFyZSBrZXkg aXMgZW5vdWdoIG5vdCBhIGNlcnRpZmljYXRlLg0KDQo0LiBXaGV0aGVyIHdlIHNob3VsZCBtZW50 aW9uIG9wcG9ydHVuaXN0aWMgc2VjdXJpdHkgaW4gc2VjdXJlIERIQ1B2Nj8NCg0KNS4gRm9yIHRo ZSBjbGllbnRzIHdoaWNoIGhhcyBtdWx0aXBsZSBjZXJ0cywgd2hldGhlciB0aGUgdHJhbnNhY3Rp b24taWQgY2FuIHdvcmsgYXMgdGhlIGlkZW50aWZpZXIgb2YgdGhlIGNsaWVudCdzIHB1YmxpYyBr ZXkgZm9yIGVuY3J5cHRpb24sIGFuZCBzZXJ2ZXIncyAgcHJpdmF0ZSBrZXkgZm9yIGRlY3J5cHRp b24/DQoNCkJWPiBJ4oCZbSBub3Qgc3VyZSBJIHVuZGVyc3RhbmQgdGhpcyBvbmUuDQoNCjYuIFRo ZSBmb3JtYXQgb2YgRW5jcnlwdGVkLVF1ZXJ5IGFuZCBFbmNyeXB0ZWQtUmVzcG9uc2UgbWVzc2Fn ZXMuDQpGb3IgdGhlIGVuY3J5cHRlZC1xdWVyeSBhbmQgZW5jcnlwdGVkLXJlc3BvbnNlIG1lc3Nh Z2VzLCBpbiB0aGUgY3VycmVudCB2ZXJzaW9uLCB0aGUgcGF5bG9hZCBpcyBhIHNlcmllcyBvZiBv cHRpb25zLCB3aGljaCBtYXkgY2F1c2UgdW5uZWNlc3NhcnkgYXR0YWNrLiBTbyBhY2NvcmRpbmcg dG8gVGVkJ3Mgc3VnZ2VzdGlvbiwgSXQgaXMgYmV0dGVyIHRoYXQgdGhlIHBheWxvYWQgaXMgZW5j cnlwdGVkIG1lc3NhZ2Ugd2l0aCBzb21lIGZpeGVkIGZpZWxkLiBCdXQgREhDUHY2IG1lc3NhZ2Un cyBmb3JtYXQgYXJlIGEgc2VyaWVzIG9mIG9wdGlvbnMuIElmIHRoZSBlbmNyeXB0ZWQtcXVlcnkg YW5kIGVuY3J5cHRlZC1yZXNwb25zZSB1c2UgdGhlIGFib3ZlIGZvcm1hdCwgYXJlIHRoZXkgc3Rp bGwgREhDUHY2IG1lc3NhZ2VzPw0KDQpCVj4gSSByZWFsbHkgcHJlZmVyIHdlIGtlZXAgaXQgYXMg YSBzZXJpZXMgb2Ygb3B0aW9ucy4gSSBkb27igJl0IHNlZSB0aGF0IGZpeGVkIGZpZWxkcyBoZWxw IGFueXRoaW5nIChlc3BlY2lhbGx5IGlmIGZpZWxkcyBhcmUgdmFyaWFibGUgbGVuZ3RoLCB3aHkg YXJlIHRoZXkgYW55IGVhc2llciB0byBwYXJzZSB0aGFuIG9wdGlvbnM/KS4gT3B0aW9ucyBhcmUg ZWFzeSBlbm91Z2ggdG8gcGFyc2UuDQoNCkkgZG9u4oCZdCBzZWUgdGhpcyBhcyDigJxhcmUgdGhl c2UgREhDUHY2IG1lc3NhZ2Vz4oCdIG9yIG5vdCBhcmd1bWVudCDigJMgdGhlIFJlbGF5LUZvcncv UmVsYXktUmVwbHkgbWVzc2FnZXMgdXNlIGEgY29tYmluYXRpb24gb2YgZml4ZWQgZmllbGRzIGFu ZCBvcHRpb25zIGFuZCB3ZSBjb25zaWRlciB0aGVzZSBhcyBESENQdjYgbWVzc2FnZXMuDQoNClBl cmhhcHMgaWYgeW91IGNhbiBwcm92aWRlIGFuIGV4YW1wbGUgb2YgaG93IHRoZXNlIG1lc3NhZ2Vz IHdvdWxkIGJlIGZvcm1hdHRlZCB3aXRoIHRoZSBmaXhlZCBmaWVsZHMsIHdlIGNvdWxkIGJldHRl ciBldmFsdWF0ZSBhcyB0byB3aGV0aGVyIHRoaXMgbWF5IG1ha2Ugc2Vuc2Ugb3Igbm90LiAoRm9y IGV4YW1wbGUsIHBlcmhhcHMgeW91IHdhbnQgdG8gYWRkIHNvbWUg4oCcaWRlbnRpZmllcuKAnSBp bnRvIHRoZSBtZXNzYWdlcyB0byBhZGRyZXNzIGlzc3VlICM1IGFib3ZlPykNCg0KQmVzdCBSZWdh cmRzLA0KTGlzaGFuDQo= --_000_25322a5ec897409093e904a7dc4549d3XCHALN003ciscocom_ 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 b25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpAcGFnZSBXb3JkU2Vj dGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEu MGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLyogTGlzdCBE ZWZpbml0aW9ucyAqLw0KQGxpc3QgbDANCgl7bXNvLWxpc3QtaWQ6ODU0MjY5NzY0Ow0KCW1zby1s aXN0LXR5cGU6aHlicmlkOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczotMTg3MzkwMjE0MiAxNzIy ODc1Nzk2IDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4 Njg5IDY3Njk4NjkxIDY3Njk4NjkzO30NCkBsaXN0IGwwOmxldmVsMQ0KCXttc28tbGV2ZWwtc3Rh cnQtYXQ6MDsNCgltc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl eHQ6LTsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz YW5zLXNlcmlmOw0KCW1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OkNhbGlicmk7DQoJbXNvLWJpZGkt Zm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7fQ0KQGxpc3QgbDA6bGV2ZWwyDQoJe21zby1s ZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZl bC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDps ZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0 Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9 DQpAbGlzdCBsMDpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1z by1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5 OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVs bGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250 LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVsNg0KCXttc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWIt c3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNw0KCXtt c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1z by1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN Cgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxl dmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6 bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7 fQ0KQGxpc3QgbDA6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCglt c28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWls eTpXaW5nZGluZ3M7fQ0Kb2wNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KdWwNCgl7bWFyZ2luLWJv dHRvbTowaW47fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBl ZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0t LT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4N CjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1s PjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9IiMwNTYzQzEi IHZsaW5rPSIjOTU0RjcyIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+SGk6PG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMx RjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5BIGZldyBjb21tZW50cyBiZWxvdyAoQlYm Z3Q7KS4gRm9yIHRob3NlIHF1ZXN0aW9ucyBJIGRpZCBub3QgaGF2ZSBhIGNvbW1lbnQgb24sIGl0 IG1lYW5zIEnigJltIG5vdCB5ZXQgc3VyZSB3aGF0IHRvIHNheS48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgi IHN0eWxlPSJ0ZXh0LWluZGVudDotLjI1aW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPjwhW2lm ICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48c3BhbiBzdHls ZT0ibXNvLWxpc3Q6SWdub3JlIj4tPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMg TmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6IzFGNDk3RCI+QmVybmllPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp ZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IGRoY3dnIFttYWlsdG86ZGhjd2ct Ym91bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+TGlzaGFuIExpPGJyPg0KPGI+ U2VudDo8L2I+IFR1ZXNkYXksIEFwcmlsIDI2LCAyMDE2IDg6MTUgQU08YnI+DQo8Yj5Ubzo8L2I+ IGRoY3dnICZsdDtkaGN3Z0BpZXRmLm9yZyZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gW2RoY3dn XSBPcGVuIElzc3VlcyBmb3IgU2VjdXJlIERIQ1B2NjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5EZWFyIEFsbCw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QWZ0ZXIgdGhlIGRpc2N1c3Npb24gd2l0aCBUZWQg YW5kIEppbm1laSwgdGhlcmUgYXJlIHN0aWxsIHNvbWUgb3BlbiBpc3N1ZXMuIFJlZ2FyZGluZyB0 aGVzZSBvcGVuIGlzc3VlcywgY291bGQgeW91IHBsZWFzZSBnaXZlIHVzIHlvdSBzdWdnZXN0aW9u cz8gTG9va2luZyBmb3J3YXJkIHRvIHlvdXIgZ3VpZGFuY2UhIFRoZSBmb2xsb3dpbmcgYXJlIHRo ZSBjdXJyZW50IG9wZW4gaXNzdWVzOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj4xLiBBIHNpbmdsZSBESENQdjYgc2VydmVyIHNlbGVjdGlvbiBm b3IgYXV0aGVudGljYXRpb24gYXQgdGhlIGJlZ2lubmluZy4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPklmIHRoZSB0d28gc2VydmVycyBz aGFyZSBvbmUgY29tbW9uIGNlcnRpZmljYXRlIHdpdGggdGhlIHNhbWUgcHVibGljIGtleSwgdGhl biB0aGUgY2xpZW50IHNob3VsZCBiZSBhYmxlIHRvIHNlbmQgYW4gZW5jcnlwdGVkIHJlcXVlc3Qg dG8gYm90aCBzZXJ2ZXJzLCBhbmQgYm90aCB0aGUgc2VydmVycyBjYW4gZGVjcnlwdCB0aGUgZW5j cnlwdGVkIHJlcXVlc3QgYW5kIGxldHRpbmcgY2xpZW50IHNlbGVjdCBvbmUNCiBvZiB0aGVtIGlu IGEgY29tcGF0aWJsZSB3YXkgdG8gdGhlIG9yaWdpbmFsIERIQ1B2Ni4mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlNvIGluIHRoaXMgd2F5 LCB0aGVyZSBpcyBubyBuZWVkIHRvIGNvbnRhaW4gdGhlIFNlcnZlciBJZGVudGlmaWVyIG9wdGlv biBpbiB0aGUgRW5jcnlwdGVkLVF1ZXJ5IG1lc3NhZ2UuIFRoZSBkaXNhZHZhbnRhZ2UgaXMgdGhh dCB0aGUgZXh0cmEgZGVjcnlwdGlvbiBjb3N0IGlzIGNhdXNlZCBmb3IgdGhlIERIQ1B2NiBzZXJ2 ZXIgbm90IGZvciBpdC4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzFGNDk3RCI+QlYmZ3Q7IEhvdyBhYm91dCBhZGRpbmcgdGhlIHNlcnZlci1pZGVudGlmaWVy IG9wdGlvbiB3aGVuIGl0IGlzIGluIHRoZSBjbGllbnQgbWVzc2FnZSAoaS5lLiBSZXF1ZXN0LCBS ZW5ldywgRGVjbGluZSwgUmVsZWFzZSkuIFRoYXQgd2F5LCBvbmNlIGEgc2VydmVyIGlzIHNlbGVj dGVkDQogdGhlIG90aGVyIHNlcnZlcnMgY2FuIGlnbm9yZSB3aXRob3V0IG5lZWRpbmcgdG8gZGVj cnlwdD8gVGhhdCByZWR1Y2VzIHRoZSBsb2FkIGEgYml0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj4yLiBSZWdhcmRpbmcgdGltZXN0YW1wLCB3aGF0IGFib3V0IGEgc3RyaWN0bHktaW5jcmVh c2luZyBzZXJpYWwgbnVtYmVyICh3aXRoIHJvbGxvdmVyKT88bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZSBhZHZhbnRhZ2Ugb2YgYSBzdHJpY3Rs eSBpbmNyZWFzaW5nIG51bWJlciBpcyB0aGF0IHRoZSBzZXJ2ZXIgY2FuIGp1c3QgZGlzY2FyZCBt ZXNzYWdlcyBmcm9tIHRoZSBjbGllbnQgd2l0aCBsb3dlciBudW1iZXJzLCBhbmQgdGhlIGNsaWVu dCBjYW4gZG8gdGhlIHNhbWUuJm5ic3A7IFRoZSBkaXNhZHZhbnRhZ2UgaXMgdGhhdCB0aGUgc3Ry aWN0bHktaW5jcmVhc2luZyBudW1iZXIgaGFzIHRvIGJlIGNvbW1pdHRlZA0KIHRvIHN0YWJsZSBz dG9yYWdlIG9uIHRoZSBjbGllbnQuICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMxRjQ5N0QiPkJWJmd0OyBUaGlzIHNlZW1zIGEgYml0IHRyaWNreS4gV2hhdCBo YXBwZW5zIGlmIHRoZSBzdGFibGUgc3RvcmFnZSBpcyBsb3N0PyBBIHRpbWUgYmFzZWQgdmFsdWUg KHdoZW4gcG9zc2libGUg4oCTIGkuZS4sIGNsaWVudCBoYXMgdGltZSkgc2VlbXMgbGlrZSBhIGJl dHRlciBvcHRpb24NCiB0byBtZT8gRm9yIGNsaWVudHMgdGhhdCBkb27igJl0IGhhdmUgdGhlIGN1 cnJlbnQgdGltZSAoaS5lLiwgbmVlZCBESENQIHRvIGdldCB0aGUgdGltZSksIHBlcmhhcHMgdGhl IHRpbWVzdGFtcCBpcyBvcHRpb25hbCB0byBhY2NvbW1vZGF0ZSB0aGVtIOKAkyB0aGlzIGRvZXMg bWVhbiB0aGVyZSBpcyB0aGUgcmVwbGF5IHJpc2sgKGF0IGxlYXN0IHVudGlsIGEgdGltZSBpcyBh dmFpbGFibGUpLiBJIHByZWZlciB3ZSB1c2UgZXhpc3RpbmcgdGVjaG5pcXVlcw0KIGZvciB0aGlz IGFuZCBJIHRoaW5rIHRoZXkgYXJlIGdlbmVyYWxseSB0aW1lIGJhc2VkPzxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0 OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj4zLiBGb3IgdGhlIERIQ1B2NiBjbGllbnQsIGhvdyBhYm91dCBhIGJhcmUg a2V5IG5vdCBhIGNlcnRpZmljYXRlPzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+SWYgdGhlIGNsaWVudCB1c2VzIGNlcnRpZmljYXRlIGZvciBhdXRo ZW50aWNhdGlvbi4gVGhlIGNsaWVudCBoYXMgdG8gZ2VuZXJhdGUgYSBrZXkgYW5kIHRoZW4gc3Vi bWl0IGl0IHRvIGEgY2VydGlmaWNhdGUgYXV0aG9yaXR5IHRvIGJlIHNpZ25lZC4gSXQgd291bGQg bWFrZSBzZW5zZSBmb3IgdHdvIGRpZmZlcmVudCBjb21wYW5pZXMgdG8gdHJ1c3QgYWxsIGNlcnRz IHNpZ25lZCBieSB0aGUgc2FtZSBhdXRob3JpdHkuDQogRm9yIHRoZSBjbGllbnQgd2hpY2ggaXMg bm8gbG9uZ2VyIGF1dGhvcml6ZWQsIHRoZXkgc3RpbGwgaGF2ZSBhIGtleSBzaWduZWQgYnkgdGhl IGF1dGhvcml0eS4gJm5ic3A7IEhvdyBkbyB3ZSBzdG9wIHRoYXQgb25lIGNsaWVudCBmcm9tIGF1 dGhlbnRpY2F0aW5nPyBUaGUgYW5zd2VyIGlzIHRoYXQgd2UgaGF2ZSB0byBoYXZlIGEgcmVjb3Jk IG9mIGV2ZXJ5IGNsaWVudCB0aGF0IGlzIGF1dGhvcml6ZWQgdG8gdXNlIHRoZSBuZXR3b3JrLjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGVy ZSBhcmUgdHdvIHdheXMgdG8gZG8gY2xpZW50IGF1dGhlbnRpY2F0aW9uOiBmaXJzdCwgd2UgY2Fu IGhhdmUgdGhlIGNlcnRpZmljYXRlIGF1dGhvcml0eSByZW1lbWJlciBhbGwgb2YgdGhlIGNsaWVu dHMsIGFuZCBtYWludGFpbiBhIGNlcnRpZmljYXRlIHJldm9jYXRpb24gbGlzdCAoQ1JMKSBmb3Ig Y2xpZW50cyB3aG9zZSBjZXJ0aWZpY2F0ZXMgc2hvdWxkIG5vIGxvbmdlciBncmFudCBhY2Nlc3Mg dG8gdGhlDQogbmV0d29yay4gU2Vjb25kLCB3ZSBjYW4gc2ltcGx5IGtlZXAgYSBsaXN0IG9mIGFs bCB0aGUgY2xpZW50IGtleXMgdGhhdCBhcmUgZ3JhbnRlZCBhY2Nlc3MgdG8gdGhlIG5ldHdvcmss IGFuZCB0aGUgREhDUCBzZXJ2ZXIgY2FuIGNoZWNrIHRoYXQgbGlzdCBiZWZvcmUgZ3JhbnRpbmcg YWNjZXNzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5UaGUgZmlyc3Qgb25lIGlzIG1vcmUgZWFzeSwgc28gd2UgdGhpbmsgYSBiYXJlIGtleSBp cyBlbm91Z2ggbm90IGEgY2VydGlmaWNhdGUuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+NC4gV2hldGhlciB3ZSBzaG91bGQgbWVudGlvbiBvcHBvcnR1bmlzdGljIHNlY3VyaXR5IGlu IHNlY3VyZSBESENQdjY/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjUuIEZvciB0aGUgY2xpZW50cyB3aGljaCBoYXMgbXVsdGlwbGUgY2VydHMs IHdoZXRoZXIgdGhlIHRyYW5zYWN0aW9uLWlkIGNhbiB3b3JrIGFzIHRoZSBpZGVudGlmaWVyIG9m IHRoZSBjbGllbnQncyBwdWJsaWMga2V5IGZvciBlbmNyeXB0aW9uLCBhbmQgc2VydmVyJ3MgJm5i c3A7cHJpdmF0ZSBrZXkgZm9yIGRlY3J5cHRpb24/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkJWJmd0OyBJ4oCZbSBub3Qgc3VyZSBJIHVuZGVyc3RhbmQg dGhpcyBvbmUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjYuIFRoZSBmb3JtYXQgb2YgRW5j cnlwdGVkLVF1ZXJ5IGFuZCBFbmNyeXB0ZWQtUmVzcG9uc2UgbWVzc2FnZXMuPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Gb3IgdGhlIGVuY3J5cHRl ZC1xdWVyeSBhbmQgZW5jcnlwdGVkLXJlc3BvbnNlIG1lc3NhZ2VzLCBpbiB0aGUgY3VycmVudCB2 ZXJzaW9uLCB0aGUgcGF5bG9hZCBpcyBhIHNlcmllcyBvZiBvcHRpb25zLCB3aGljaCBtYXkgY2F1 c2UgdW5uZWNlc3NhcnkgYXR0YWNrLiBTbyBhY2NvcmRpbmcgdG8gVGVkJ3Mgc3VnZ2VzdGlvbiwg SXQgaXMgYmV0dGVyIHRoYXQgdGhlIHBheWxvYWQgaXMgZW5jcnlwdGVkIG1lc3NhZ2UNCiB3aXRo IHNvbWUgZml4ZWQgZmllbGQuIEJ1dCBESENQdjYgbWVzc2FnZSdzIGZvcm1hdCBhcmUgYSBzZXJp ZXMgb2Ygb3B0aW9ucy4gSWYgdGhlIGVuY3J5cHRlZC1xdWVyeSBhbmQgZW5jcnlwdGVkLXJlc3Bv bnNlIHVzZSB0aGUgYWJvdmUgZm9ybWF0LCBhcmUgdGhleSBzdGlsbCBESENQdjYgbWVzc2FnZXM/ PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkJWJmd0OyBJ IHJlYWxseSBwcmVmZXIgd2Uga2VlcCBpdCBhcyBhIHNlcmllcyBvZiBvcHRpb25zLiBJIGRvbuKA mXQgc2VlIHRoYXQgZml4ZWQgZmllbGRzIGhlbHAgYW55dGhpbmcgKGVzcGVjaWFsbHkgaWYgZmll bGRzIGFyZSB2YXJpYWJsZSBsZW5ndGgsIHdoeSBhcmUgdGhleSBhbnkNCiBlYXNpZXIgdG8gcGFy c2UgdGhhbiBvcHRpb25zPykuIE9wdGlvbnMgYXJlIGVhc3kgZW5vdWdoIHRvIHBhcnNlLjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+SSBkb27igJl0IHNlZSB0aGlz IGFzIOKAnGFyZSB0aGVzZSBESENQdjYgbWVzc2FnZXPigJ0gb3Igbm90IGFyZ3VtZW50IOKAkyB0 aGUgUmVsYXktRm9ydy9SZWxheS1SZXBseSBtZXNzYWdlcyB1c2UgYSBjb21iaW5hdGlvbiBvZiBm aXhlZCBmaWVsZHMgYW5kIG9wdGlvbnMgYW5kIHdlIGNvbnNpZGVyDQogdGhlc2UgYXMgREhDUHY2 IG1lc3NhZ2VzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+UGVy aGFwcyBpZiB5b3UgY2FuIHByb3ZpZGUgYW4gZXhhbXBsZSBvZiBob3cgdGhlc2UgbWVzc2FnZXMg d291bGQgYmUgZm9ybWF0dGVkIHdpdGggdGhlIGZpeGVkIGZpZWxkcywgd2UgY291bGQgYmV0dGVy IGV2YWx1YXRlIGFzIHRvIHdoZXRoZXIgdGhpcyBtYXkgbWFrZSBzZW5zZQ0KIG9yIG5vdC4gKEZv ciBleGFtcGxlLCBwZXJoYXBzIHlvdSB3YW50IHRvIGFkZCBzb21lIOKAnGlkZW50aWZpZXLigJ0g aW50byB0aGUgbWVzc2FnZXMgdG8gYWRkcmVzcyBpc3N1ZSAjNSBhYm92ZT8pPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMx RjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPkJlc3QgUmVnYXJkcyw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkxpc2hhbjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_25322a5ec897409093e904a7dc4549d3XCHALN003ciscocom_-- From nobody Thu Apr 28 07:49:57 2016 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 2DA3D12D7EF; Thu, 28 Apr 2016 07:49:53 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.19.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160428144953.27758.23095.idtracker@ietfa.amsl.com> Date: Thu, 28 Apr 2016 07:49:53 -0700 Archived-At: Cc: dhcwg@ietf.org Subject: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-prefix-length-hint-issue-01.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.17 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Apr 2016 14:49:53 -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 : DHCPv6 Prefix Length Hint Issues Authors : Yong Cui Tianxiang Li Cong Liu Filename : draft-ietf-dhc-dhcpv6-prefix-length-hint-issue-01.txt Pages : 9 Date : 2016-04-28 Abstract: DHCPv6 Prefix Delegation [RFC3633] allows a requesting router 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 is unclear about how the requesting router and delegating router 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 requesting router and delegating router could do in different situations. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv6-prefix-length-hint-issue/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-prefix-length-hint-issue-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dhc-dhcpv6-prefix-length-hint-issue-01 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 Thu Apr 28 08:01:07 2016 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 2D8D312D803 for ; Thu, 28 Apr 2016 08:01:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_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 N9Jf2P0NLZdo for ; Thu, 28 Apr 2016 08:00:59 -0700 (PDT) Received: from mail-oi0-x234.google.com (mail-oi0-x234.google.com [IPv6:2607:f8b0:4003:c06::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 2CE1112D7E3 for ; Thu, 28 Apr 2016 08:00:59 -0700 (PDT) Received: by mail-oi0-x234.google.com with SMTP id x201so86409270oif.3 for ; Thu, 28 Apr 2016 08:00:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=Ooccu0ZRMjm8VXJV6kELxcQC+rg7yXRTnEeRpCXQldQ=; b=OMQP+mgvPH6F+6rdvtMP0veXMSbbAItLxVzNk6AcxsUgrieFKSrwe7P4UqH1V4f5QJ jNo+/LkUMOY80VxsipGJ5+q/sZEfZJGkfNQmiRiPG+CY+v574Bk7pI/xuWhvpaFnXOxp O4WkooGSDwrns5ZhIYDAbfx/Kj56KKUWUskg2sHrSLFrphTPn3cw/tIuHiseLh7adW9t hsH16zq20kOJykt9RzaGVcFnsRPcOHhXRBPUGFNE6VaTUZ/9QjSBOqayxaL//RLgfZmR knQaiXus7+b9tQ+JGpuX33VrEYynwWDsb6PJm6oh3FM0A/dVw5Q1CIfEYGvW073HL6Jf Jyww== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=Ooccu0ZRMjm8VXJV6kELxcQC+rg7yXRTnEeRpCXQldQ=; b=T6bnKfRhaKO8YbefgdkJ2sdM01NzFwZ3O45wLV62pLiOcun60fNCH7Jdc9nO+aBO1V 9sxJxV7n81HCQlRhaQlLCFPLcjlVa5I3KKv4KzyzwO5cWo/pbMBYlc+5gUJJt2uuKHc6 dhkgGvsnXnqT77fX+xyhCJgjoWqCo3CqYbP5+KdCDGmT2Gti/nK1a1htRsQ8Zf28bqu5 L0AJQbaHCs0UumExRPQj+LphzFFCgMNF97Haj59QjKJC71hjG31fEctRu65Ne9nZNlrU Ti9AVXMW6n7EELATzcptDNMDprs5EXrC+QVpuSyzl2Qe/JkDMlFLsSEX08Gk6FVDT3eY JqKA== X-Gm-Message-State: AOPr4FVmFCZgwBMckU6U32HlEA4oO2Lzo/u/VZebrUivXbzmaF6LoTaHk9U+DrNaiXs/U1mSekWYnEHZeh2gxA== X-Received: by 10.202.90.3 with SMTP id o3mr6285994oib.96.1461855658449; Thu, 28 Apr 2016 08:00:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.202.44.79 with HTTP; Thu, 28 Apr 2016 08:00:19 -0700 (PDT) In-Reply-To: <20160428144953.27758.85913.idtracker@ietfa.amsl.com> References: <20160428144953.27758.85913.idtracker@ietfa.amsl.com> From: tianxiang li Date: Thu, 28 Apr 2016 23:00:19 +0800 Message-ID: To: dhcwg Content-Type: multipart/alternative; boundary=001a113d5edc3c207e05318ccba7 Archived-At: Subject: [dhcwg] Fwd: New Version Notification for draft-ietf-dhc-dhcpv6-prefix-length-hint-issue-01.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Apr 2016 15:01:06 -0000 --001a113d5edc3c207e05318ccba7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi all, We=E2=80=99ve updated a new version of the prefix-length hint issues draft = with normative text added to the solution sections of the document. Even though the delegating routers might ignore the prefix-length hint depending on its policy, we could state something along the lines like: "if the delegating router is configured to honor the prefix-length hint...then=E2=80=A6" etc. Section 3.1 and 3.2(Previously 2.1 and 2.2) clarifies how the requesting router should use the prefix-length hint to express its preference, and how the delegating router should handle the hint sent in a Solicit message. Section 3.3 describes how the client should handle the Advertise messages not containing a prefix matching the hint. Section 3.4 and 3.5 describes how the requesting router should hint for prefixes during Renew/Rebind and how the delegating router should respond. To ensure consistent requesting/delegating router behavior we think normative text might be needed in these sections. We would very much appreciate your comments. Thank you, Tianxiang ---------- Forwarded message ---------- From: Date: 2016-04-28 22:49 GMT+08:00 Subject: New Version Notification for draft-ietf-dhc-dhcpv6-prefix-length-hint-issue-01.txt To: Tianxiang Li , Yong Cui < yong@csnet1.cs.tsinghua.edu.cn>, Cong Liu A new version of I-D, draft-ietf-dhc-dhcpv6-prefix-length-hint-issue-01.txt has been successfully submitted by Tianxiang Li and posted to the IETF repository. Name: draft-ietf-dhc-dhcpv6-prefix-length-hint-issue Revision: 01 Title: DHCPv6 Prefix Length Hint Issues Document date: 2016-04-28 Group: dhc Pages: 9 URL: https://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-prefix-length-hi= nt-issue-01.txt Status: https://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv6-prefix-length-hint-i= ssue/ Htmlized: https://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-prefix-length-hint-issue-= 01 Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dhc-dhcpv6-prefix-length-hin= t-issue-01 Abstract: DHCPv6 Prefix Delegation [RFC3633] allows a requesting router 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 is unclear about how the requesting router and delegating router 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 requesting router and delegating router could do in different situations. Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat --001a113d5edc3c207e05318ccba7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi all,

We=E2=80=99ve up= dated a new version of the prefix-length hint issues draft with normative t= ext added to the solution sections of the document. Even though the delegat= ing routers might ignore the prefix-length hint depending on its policy, we= could state something along the lines like: "if the delegating router= is configured to honor the prefix-length hint...then=E2=80=A6" etc.

Section 3.1 and 3.2(Previously 2.1 and 2.2) cla= rifies how the requesting router should use the prefix-length hint to expre= ss its preference, and how the delegating router should handle the hint sen= t in a Solicit message. Section 3.3 describes how the client should handle = the Advertise messages not containing a prefix matching the hint. Section 3= .4 and 3.5 describes how the requesting router should hint for prefixes dur= ing Renew/Rebind and how the delegating router should respond. To ensure co= nsistent requesting/delegating router behavior we think normative text migh= t be needed in these sections.

We would very m= uch appreciate your comments.=C2=A0

Thank you,=
Tianxiang

---------- Forward= ed message ----------
From: <internet-drafts@ie= tf.org>
Date: 2016-04-28 22:49 GMT+08:00
Subject: New V= ersion Notification for draft-ietf-dhc-dhcpv6-prefix-length-hint-issue-01.t= xt
To: Tianxiang Li <peter41= 6733@gmail.com>, Yong Cui <yong@csnet1.cs.tsinghua.edu.cn>, Cong Liu <gnocuil@gmail.com>



A new version of I-D, draft-ietf-dhc-dhcpv6-prefix-length-hint-issue-01.txt=
has been successfully submitted by Tianxiang Li and posted to the
IETF repository.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-ietf-dhc-dhcpv6-prefix-= length-hint-issue
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A001
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 DHCPv6 Prefix Length Hint Issues Document date:=C2=A0 2016-04-28
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 dhc
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 9
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/internet-drafts/dr= aft-ietf-dhc-dhcpv6-prefix-length-hint-issue-01.txt
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv6= -prefix-length-hint-issue/
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-prefix-lengt= h-hint-issue-01
Diff:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://www.ietf.org/rfcdiff?url2=3Ddraft-ie= tf-dhc-dhcpv6-prefix-length-hint-issue-01

Abstract:
=C2=A0 =C2=A0DHCPv6 Prefix Delegation [RFC3633] allows a requesting router = to
=C2=A0 =C2=A0include a prefix-length hint value in the IA_PD option to indi= cate a
=C2=A0 =C2=A0preference for the size of the prefix to be delegated, but is = unclear
=C2=A0 =C2=A0about how the requesting router and delegating router should a= ct in
=C2=A0 =C2=A0different situations involving the prefix-length hint.=C2=A0 T= his document
=C2=A0 =C2=A0provides a summary of the existing problems with the prefix-le= ngth
=C2=A0 =C2=A0hint and guidance on what the requesting router and delegating= router
=C2=A0 =C2=A0could do in different situations.




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

The IETF Secretariat


--001a113d5edc3c207e05318ccba7-- From nobody Thu Apr 28 11:22:57 2016 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 8160012D0DD for ; Thu, 28 Apr 2016 11:22:55 -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 DgotDxmWy9Tp for ; Thu, 28 Apr 2016 11:22:53 -0700 (PDT) Received: from mail-io0-x235.google.com (mail-io0-x235.google.com [IPv6:2607:f8b0:4001:c06::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A2D5612D144 for ; Thu, 28 Apr 2016 11:22:52 -0700 (PDT) Received: by mail-io0-x235.google.com with SMTP id f89so85284492ioi.0 for ; Thu, 28 Apr 2016 11:22:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc; bh=eu+qLj49305n8vtkgR0/k/ij7eZuuFHBNoYAANSeE5U=; b=XsrthEjGtQ5DSXCKYo5ZqVBisP2JdX5ELvo8wwKqbQAYN3gL2zAO7KvSSj3Of/WAdP 3WOfRs26RFGVcAjdsQMTS9zYexwsSOfJNfxvwZaCgnaO2AUwvuHBSls6Eje3mAVMzwXW Mhk4dScZ4MY4whFUmTigMKWZJJZ5ISmmhdLBiDrXOtNBr18YNo9T/8umfLZ9jdScG7B0 5gSbdx4wOTLaq6sp6LYRJpVgErM0XZW71KC1eNgYT0F6EuKYd3gfDeZp/Cd9RUOGK5Ci xd74CDrifoI8Z0erfApTQUfmJwNEVeW7esHLijWZYSQqnjlObuynTZQfhmKRCYiQctv6 Ic0A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc; bh=eu+qLj49305n8vtkgR0/k/ij7eZuuFHBNoYAANSeE5U=; b=jC2dTZEcq7Jh1X9F+fKz40617iwAinyND4Dz6Rnd2C/+5T/3DpisyPORj9vVnOUrb8 NICrkkZDlW4y9MqypN9nWK8iHomyJTgVHcubjnYvX0S56Z8ecR6L9AP8AUy1QlyertjE 66dKq2LtM072zR0yLm8w2c2aQBqc5zRKE+bm/A9v1ViJen+Uid2QCiGj0CQHuNKYz+hX YTq5f0J/a//4qAea2hPs1cx/SxGW0GocUvk88WD4ZnXmzNvZQSG9vgPVlaFRrdXZqP88 uhpJ3IqKJ7AG81CF5WuxNIh72+V2ehZ/nlupUnPIbQOSDo46uDnhzshLiFvpFEXb5RZb zftg== X-Gm-Message-State: AOPr4FXagafcEXKN2o3sjvStJcP61dnE+npf3DBdxysGmKzzSvXaBdMzWneDzC/T73xSwOXI0fvJknNVPLEE+Q== MIME-Version: 1.0 X-Received: by 10.107.5.9 with SMTP id 9mr21440201iof.4.1461867771471; Thu, 28 Apr 2016 11:22:51 -0700 (PDT) Sender: jinmei.tatuya@gmail.com Received: by 10.107.19.218 with HTTP; Thu, 28 Apr 2016 11:22:51 -0700 (PDT) In-Reply-To: <0a8817dba2ea46c88ca67334a11c956d@XCH-ALN-003.cisco.com> References: <0a8817dba2ea46c88ca67334a11c956d@XCH-ALN-003.cisco.com> Date: Thu, 28 Apr 2016 11:22:51 -0700 X-Google-Sender-Auth: IpWggnNVb0WoCNTLL-cgDXqZOzc Message-ID: From: =?UTF-8?B?56We5piO6YGU5ZOJ?= To: "Bernie Volz (volz)" Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "dhcwg@ietf.org" Subject: Re: [dhcwg] Follow up from IETF-95 - draft-ietf-dhc-dhcpv6-prefix-length-hint-issue X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Apr 2016 18:22:55 -0000 At Thu, 21 Apr 2016 16:45:17 +0000, "Bernie Volz (volz)" wrote: > One item that was raised at the IETF-95 DHC WG session was the > recent change (suggested by me before > draft-cui-dhc-dhcpv6-prefix-length-hint-issue-02 was published) to > switch draft-ietf-dhc-dhcpv6-prefix-length-hint-issue to > Informational rather than Standards Track. Marcin Siodelski > suggested that the document be Standards Track: [...] > Please respond with your comments as to whether this document should > be Informational or Standards Track by May 5th, 2016. Of course, any > other comments are welcome as well! On re-reading dhc-dhcpv6-prefix-length-hint-issue-00 to answer the call (just noticed 01 was submitted today; haven't read it yet), I have even more fundamental question than standards track vs informational: what's the problem/is it worth addressing/solving in the first place? In general, I always thought hints from a client is literary a hint, and the client can't expect anything specific from the server or rely on such an expectation by sending a hint. In my view, if there's such a client implementation, it'd simply be a bug of it and should be fixed. Also, it's not clear to me what's special in the case of prefix length hint. The draft shows an example: If the requesting router is asking for a /56 and the delegating router returns a /64, the functionality of the requesting router might be limited because it might not be able to split the prefix for all its interfaces. It might be a "problem", but it doesn't necessarily seem to me to be a protocol level problem. Realistically, the (minimum) size of the delegated prefix would be determined by some operational policy of the delegating side (such as an ISP) and included in some kind of contract between the delegating side and the requesting side. If the requesting side needs to rely on a wider prefix, it should ensure that it can at least get the necessary size of prefix at that level, rather than hoping that the requirement is met in the protocol level using the hint value. We could also come up with a "problem" for other kind of hints, for example: If a DHCPv6 client is asking for a specific IPv6 address as a hint in IA_NA because the client used that particular address before and some long-standing application relies on it, and the DHCPv6 server returns a different address than that, then the functionality of the client is limited because this long-standing application might not be able to work correctly. Still, we are not trying to introduce a new requirement for the server so that "it should honor the hint whenever possible", right? There might be a special reason in the case the prefix length hint, but at the moment I don't see it in draft-ietf-dhc-dhcpv6-prefix-length-hint-issue beyond some imaginary problem. So, I'd first like to see what's actually the problem and be convinced that's certainly a practical operational problem specific to hints for the prefix length (but not for other types of hints) that has to be solved at the protocol level. Otherwise, I'd not even see the need for publishing this document in the first place, let alone whether it's standards track or informational. -- jinmei From nobody Thu Apr 28 12:25:20 2016 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 7441412D641 for ; Thu, 28 Apr 2016 12:25:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.516 X-Spam-Level: X-Spam-Status: No, score=-15.516 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.996, 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 X6S9JDwEhF3y for ; Thu, 28 Apr 2016 12:25:15 -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 AE4E812D1E4 for ; Thu, 28 Apr 2016 12:25:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4042; q=dns/txt; s=iport; t=1461871515; x=1463081115; h=from:to:subject:date:message-id:mime-version; bh=U46pacz9TWa6F8L4mrpK5Mvs/4r6LYTHLNvDIaT6tb8=; b=beavl1EYhh6/mC7wMz6Xdt+DJo5cH4NiKHssDyBKB38P5MB/VvgXuKKm 0z88WqfS122fMRst+SH9ylZz4dwK9X6vDu8ObsCXgPIlJ7hwIE/ORcN7I Raht7J3zPYPGidNyNcdMj90EH7Usq+AvLL7x7V86hXrkAdqzeMkhBQgif E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ANAgDoYiJX/5ldJa1egmxMU4EDtGeCZ?= =?us-ascii?q?IIPAQ2Bdoc9OBQBAQEBAQEBZRwLhEgtXgEMdCYBBBuIIqJtoH4BAQEBAQUBAQE?= =?us-ascii?q?BAQEajCSIWwWYEAGOD4FuhE2IXY8vAR4BAUKDa4dVfwEBAQ?= X-IronPort-AV: E=Sophos;i="5.24,548,1454976000"; d="scan'208,217";a="101720265" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 28 Apr 2016 19:25:14 +0000 Received: from XCH-ALN-001.cisco.com (xch-aln-001.cisco.com [173.36.7.11]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id u3SJPEui004557 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Thu, 28 Apr 2016 19:25:14 GMT Received: from xch-aln-003.cisco.com (173.36.7.13) by XCH-ALN-001.cisco.com (173.36.7.11) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 28 Apr 2016 14:25:14 -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.1104.009; Thu, 28 Apr 2016 14:25:14 -0500 From: "Bernie Volz (volz)" To: "dhcwg@ietf.org" Thread-Topic: WGLC on draft-ietf-dhc-dhcpv6-failover-protocol-01 - Respond by May 22, 2016 Thread-Index: AdGhg1Ejj94Q3HBsRsqPjKgN2rezJQ== Date: Thu, 28 Apr 2016 19:25:14 +0000 Message-ID: <0a748e2ecef446ad8962a84e275e17c2@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.200] Content-Type: multipart/alternative; boundary="_000_0a748e2ecef446ad8962a84e275e17c2XCHALN003ciscocom_" MIME-Version: 1.0 Archived-At: Subject: [dhcwg] WGLC on draft-ietf-dhc-dhcpv6-failover-protocol-01 - Respond by May 22, 2016 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Apr 2016 19:25:18 -0000 --_000_0a748e2ecef446ad8962a84e275e17c2XCHALN003ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, This message starts the DHC Working Group Last Call to advance draft-ietf-d= hc-dhcpv6-failover-protocol-01, DHCPv6 Failover Protocol. This document's i= ntended status is Proposed Standard. At present, there is no IPR file again= st this document. Please send your comments by May 22, 2016. If you do not feel this documen= t should advance, please state your reasons why. We will need several serious reviews of this document for it to pass WGLC. Bernie Volz is the assigned shepherd (Tomek is a co-author). - Tomek & Bernie --_000_0a748e2ecef446ad8962a84e275e17c2XCHALN003ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,

 

This message starts the DHC Working Group Last Ca= ll to advance draft-ietf-dhc-dhcpv6-failover-protocol-01, DHCPv6 Failover P= rotocol. This document’s intended status is Proposed Standard. At pre= sent, there is no IPR file against this document.

 

Please send your comments by May 22, 2016. If you= do not feel this  document should advance, please state your reasons = why.

 

We will need several serious reviews of this docu= ment for it to pass WGLC.

 

Bernie Volz is the assigned shepherd (Tomek is a = co-author).

 

- Tomek & Bernie

 

--_000_0a748e2ecef446ad8962a84e275e17c2XCHALN003ciscocom_-- From nobody Fri Apr 29 18:51:45 2016 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 B838512D0A8 for ; Fri, 29 Apr 2016 18:51:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_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 K9_fy-sRmkfc for ; Fri, 29 Apr 2016 18:51:42 -0700 (PDT) Received: from mail-oi0-x236.google.com (mail-oi0-x236.google.com [IPv6:2607:f8b0:4003:c06::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 19A3712B00D for ; Fri, 29 Apr 2016 18:51:42 -0700 (PDT) Received: by mail-oi0-x236.google.com with SMTP id v145so104509209oie.0 for ; Fri, 29 Apr 2016 18:51:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=8zDwDCY0PFwKIYWvdiM0Ld4CEJKalVBjOYvwiBa2Qcw=; b=BdeTXLRrRGcLNFqKP9XEr/8hHJPg74BIhfIy4vG2BNYH0HcTvg4oYwU/ZzqXGKwrjR NCWLwrRw548shKKQFqM9UE9FaYmlJZ8F39vYWdh4uUj/eZqHpsn/2Qr8WN6SObZS/RLB cR3UHhE3Eh33yrt6s+kt0JkhpDFJbahRDEe/qmFw0IRbzbYxap5iAD6Ip4fagHs4YBV4 O0TOeT61TbjoeXbCDF9tvl6ar1/iNTEPzUGvm8O4yKa0LKSFFxgYVSmHzMGYVAzN909R jpHBRQ3RR431nur2l974drZXWS5Efhi7HC2BTXbdT82alD2hL26XpwUncHGMpMaYmUfH cgwA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=8zDwDCY0PFwKIYWvdiM0Ld4CEJKalVBjOYvwiBa2Qcw=; b=X/CvjQCYF6/87AdGDlFvsOcJYph/NwO82sHHx4vzDDJNdl3dt6/QxOigaLznXqBXV9 Ga1BrFgwibuO7uAinumiGrgtz8CYw5v49GSWrENntV6gIpwX1ZaUX8jZOA36cmcV4f0r UDd+z+0mGy7cpujWjwWQp6HVRMnainUv4LWWjKEsvKf3EAForZyBa7kIsLW51LH96mim 1h0nce5QD3Pc5m3/Ahm+KztRnhccHvS7oe4iJb2nNfvF8tlw7H+5w8bgZS6SYo20jcEL HzMMIbdOBaWvt9WD2wB18IpoLerPbqsiWIbvQhQfuFc/Dw/pblNJ8NvdkcqykFa1+8pR Pkpg== X-Gm-Message-State: AOPr4FUmA2Mc16XE8jnIm+su9aFUN7/kfA6GQ4qv0QA6Qp2+QG4hFzdf//MTirM3B+pp/xVeKKzNL/h1V4rppw== X-Received: by 10.157.6.166 with SMTP id 35mr9897158otx.181.1461981101512; Fri, 29 Apr 2016 18:51:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.202.44.79 with HTTP; Fri, 29 Apr 2016 18:51:02 -0700 (PDT) In-Reply-To: References: <0a8817dba2ea46c88ca67334a11c956d@XCH-ALN-003.cisco.com> From: tianxiang li Date: Sat, 30 Apr 2016 09:51:02 +0800 Message-ID: To: =?UTF-8?B?56We5piO6YGU5ZOJ?= Content-Type: multipart/alternative; boundary=94eb2c11f260395e090531aa00c6 Archived-At: Cc: dhcwg , "Bernie Volz \(volz\)" Subject: Re: [dhcwg] Follow up from IETF-95 - draft-ietf-dhc-dhcpv6-prefix-length-hint-issue X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Apr 2016 01:51:44 -0000 --94eb2c11f260395e090531aa00c6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi jinmei=EF=BC=8C Thank you reviewing the document and providing your comments. Unlike other hints such as T1 T2 lifetimes, which could be easily ignored by the server, completely ignoring the prefix-length hint would cause some functional issues for the client, how the prefix-length hint should be handled is a bit more complicated, and it should be given more considerations. We believe there is actual requirement for some ISPs to clarify how it should work, and understand the expectations of the client and server. E.g. If a server has an existing binding for a prefix length different from what the client is currently requesting, what should it do? This is the case when the client changed its home router configuration and it needs a shorter prefix. Also, if a client didn=E2=80=99t get the prefix it wanted, should i= t continue to ask for the preferred prefix (during Renew/Rebind)? Or should the server remember what the client originally requested, and assign it a new prefix if it should become available? These are some issues we are trying to clarify in the document, so that servers which DO want to understand the client=E2=80=99s actual prefix requirement, would know how t= he prefix-length hint should be handled, to make it work well. I'm not sure whether there is the same problem for addresses, it might be something worth discussing. Best regards, Tianxiang 2016-04-29 2:22 GMT+08:00 =E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89 : > At Thu, 21 Apr 2016 16:45:17 +0000, > "Bernie Volz (volz)" wrote: > > > One item that was raised at the IETF-95 DHC WG session was the > > recent change (suggested by me before > > draft-cui-dhc-dhcpv6-prefix-length-hint-issue-02 was published) to > > switch draft-ietf-dhc-dhcpv6-prefix-length-hint-issue to > > Informational rather than Standards Track. Marcin Siodelski > > suggested that the document be Standards Track: > > [...] > > > Please respond with your comments as to whether this document should > > be Informational or Standards Track by May 5th, 2016. Of course, any > > other comments are welcome as well! > > On re-reading dhc-dhcpv6-prefix-length-hint-issue-00 to answer the > call (just noticed 01 was submitted today; haven't read it yet), I > have even more fundamental question than standards track vs > informational: what's the problem/is it worth addressing/solving in > the first place? > > In general, I always thought hints from a client is literary a hint, > and the client can't expect anything specific from the server or rely > on such an expectation by sending a hint. In my view, if there's such > a client implementation, it'd simply be a bug of it and should be > fixed. > > Also, it's not clear to me what's special in the case of prefix length > hint. The draft shows an example: > > If the requesting router is asking for a /56 and the delegating > router returns a /64, the functionality of the requesting router > might be limited because it might not be able to split the prefix for > all its interfaces. > > It might be a "problem", but it doesn't necessarily seem to me to be a > protocol level problem. Realistically, the (minimum) size of the > delegated prefix would be determined by some operational policy of the > delegating side (such as an ISP) and included in some kind of contract > between the delegating side and the requesting side. If the > requesting side needs to rely on a wider prefix, it should ensure that > it can at least get the necessary size of prefix at that level, rather > than hoping that the requirement is met in the protocol level using > the hint value. > > We could also come up with a "problem" for other kind of hints, for > example: > > If a DHCPv6 client is asking for a specific IPv6 address as a hint > in IA_NA because the client used that particular address before and > some long-standing application relies on it, and the DHCPv6 server > returns a different address than that, then the functionality of > the client is limited because this long-standing application might > not be able to work correctly. > > Still, we are not trying to introduce a new requirement for the server > so that "it should honor the hint whenever possible", right? There > might be a special reason in the case the prefix length hint, but at > the moment I don't see it in draft-ietf-dhc-dhcpv6-prefix-length-hint-iss= ue > beyond some imaginary problem. > > So, I'd first like to see what's actually the problem and be convinced > that's certainly a practical operational problem specific to hints for > the prefix length (but not for other types of hints) that has to be > solved at the protocol level. Otherwise, I'd not even see the need > for publishing this document in the first place, let alone whether > it's standards track or informational. > > -- > jinmei > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg > --94eb2c11f260395e090531aa00c6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi jinmei=EF=BC=8C

Thank you reviewing = the document and providing your comments. Unlike other hints such as T1 T2 = lifetimes, which could be easily ignored by the server, completely ignoring= the prefix-length hint would cause some functional issues for the client, = how the prefix-length hint should be handled is a bit more complicated, and= it should be given more considerations. We believe there is actual require= ment for some ISPs to clarify how it should work, and understand the expect= ations of the client and server. E.g. If a server has an existing binding f= or a prefix length different from what the client is currently requesting, = what should it do? This is the case when the client changed its home router= configuration and it needs a shorter prefix. Also, if a client didn=E2=80= =99t get the prefix it wanted, should it continue to ask for the preferred = prefix (during Renew/Rebind)? Or should the server remember what the client= originally requested, and assign it a new prefix if it should become avail= able? These are some issues we are trying to clarify in the document, so th= at servers which DO want to understand the client=E2=80=99s actual prefix r= equirement, would know how the prefix-length hint should be handled, to mak= e it work well. I'm not sure whether there is the same problem for addr= esses, it might be something worth discussing.

Best regards,
Tianxiang
2016-04-29 2:22 GMT+08:00 =E7=A5=9E=E6=98=8E= =E9=81=94=E5=93=89 <jinmei@wide.ad.jp>:
At Thu, 21 Apr 2016 16:45:17 +0000,
"Bernie Volz (volz)" <volz@cisco.com> wrote:

> One item that was raised at the IETF-95 DHC WG= session was the
> recent change (suggested by me before
> draft-cui-dhc-dhcpv6-prefix-length-hint-issue-02 was published) to
> switch draft-ietf-dhc-dhcpv6-prefix-length-hint-issue to
> Informational rather than Standards Track. Marcin Siodelski
> suggested that the document be Standards Track:

[...]

> Please respond with your comments as to whether this document should > be Informational or Standards Track by May 5th, 2016. Of course, any > other comments are welcome as well!

On re-reading dhc-dhcpv6-prefix-length-hint-issue-00 to answer the call (just noticed 01 was submitted today; haven't read it yet), I
have even more fundamental question than standards track vs
informational: what's the problem/is it worth addressing/solving in
the first place?

In general, I always thought hints from a client is literary a hint,
and the client can't expect anything specific from the server or rely on such an expectation by sending a hint.=C2=A0 In my view, if there's = such
a client implementation, it'd simply be a bug of it and should be
fixed.

Also, it's not clear to me what's special in the case of prefix len= gth
hint.=C2=A0 The draft shows an example:

=C2=A0 =C2=A0If the requesting router is asking for a /56 and the delegatin= g
=C2=A0 =C2=A0router returns a /64, the functionality of the requesting rout= er
=C2=A0 =C2=A0might be limited because it might not be able to split the pre= fix for
=C2=A0 =C2=A0all its interfaces.

It might be a "problem", but it doesn't necessarily seem to m= e to be a
protocol level problem.=C2=A0 Realistically, the (minimum) size of the
delegated prefix would be determined by some operational policy of the
delegating side (such as an ISP) and included in some kind of contract
between the delegating side and the requesting side.=C2=A0 If the
requesting side needs to rely on a wider prefix, it should ensure that
it can at least get the necessary size of prefix at that level, rather
than hoping that the requirement is met in the protocol level using
the hint value.

We could also come up with a "problem" for other kind of hints, f= or
example:

=C2=A0 =C2=A0If a DHCPv6 client is asking for a specific IPv6 address as a = hint
=C2=A0 =C2=A0in IA_NA because the client used that particular address befor= e and
=C2=A0 =C2=A0some long-standing application relies on it, and the DHCPv6 se= rver
=C2=A0 =C2=A0returns a different address than that, then the functionality = of
=C2=A0 =C2=A0the client is limited because this long-standing application m= ight
=C2=A0 =C2=A0not be able to work correctly.

Still, we are not trying to introduce a new requirement for the server
so that "it should honor the hint whenever possible", right?=C2= =A0 There
might be a special reason in the case the prefix length hint, but at
the moment I don't see it in draft-ietf-dhc-dhcpv6-prefix-length-hint-i= ssue
beyond some imaginary problem.

So, I'd first like to see what's actually the problem and be convin= ced
that's certainly a practical operational problem specific to hints for<= br> the prefix length (but not for other types of hints) that has to be
solved at the protocol level.=C2=A0 Otherwise, I'd not even see the nee= d
for publishing this document in the first place, let alone whether
it's standards track or informational.

--
jinmei

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

--94eb2c11f260395e090531aa00c6-- From nobody Sat Apr 30 17:00:55 2016 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 EA52E12B02F; Sat, 30 Apr 2016 17:00:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.898 X-Spam-Level: X-Spam-Status: No, score=-107.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.996, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 j9Qp_z_RQYS6; Sat, 30 Apr 2016 17:00:51 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1900:3001:11::31]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A6E612B015; Sat, 30 Apr 2016 17:00:51 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id D2754180014; Sat, 30 Apr 2016 17:00:27 -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 Message-Id: <20160501000027.D2754180014@rfc-editor.org> Date: Sat, 30 Apr 2016 17:00:27 -0700 (PDT) Archived-At: Cc: dhcwg@ietf.org, rfc-editor@rfc-editor.org Subject: [dhcwg] RFC 7819 on Privacy Considerations for DHCP X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 May 2016 00:00:55 -0000 A new Request for Comments is now available in online RFC libraries. RFC 7819 Title: Privacy Considerations for DHCP Author: S. Jiang, S. Krishnan, T. Mrugalski Status: Informational Stream: IETF Date: April 2016 Mailbox: jiangsheng@huawei.com, suresh.krishnan@ericsson.com, tomasz.mrugalski@gmail.com Pages: 14 Characters: 32944 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-dhc-dhcp-privacy-05.txt URL: https://www.rfc-editor.org/info/rfc7819 DOI: http://dx.doi.org/10.17487/RFC7819 DHCP is a protocol that is used to provide addressing and configuration information to IPv4 hosts. This document discusses the various identifiers used by DHCP and the potential privacy issues. This document is a product of the Dynamic Host Configuration Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. 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