From tomasz.mrugalski@gmail.com Wed May 1 13:22:45 2013 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 1D7FE21F9A1C for ; Wed, 1 May 2013 13:22:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IWcp1RBL5zyV for ; Wed, 1 May 2013 13:22:44 -0700 (PDT) Received: from mail-ea0-x232.google.com (mail-ea0-x232.google.com [IPv6:2a00:1450:4013:c01::232]) by ietfa.amsl.com (Postfix) with ESMTP id 203D121F99ED for ; Wed, 1 May 2013 13:22:43 -0700 (PDT) Received: by mail-ea0-f178.google.com with SMTP id o10so808289eaj.37 for ; Wed, 01 May 2013 13:22:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=0bdmfZGS9o3ixJWS8RMvi33Vl2bnEsbDOtd8jBLwQbM=; b=gfcyG/bzSvSZebLuZ6dxtKVMNirTZwxo1kEuRy+mKp/xMbx6Um5skaBfeNW6mlvN07 CUjfJmw5Ss0H3uwLpWEqeED4WQ9sBjP5PFwWUhipyauCRnKEABGhF3g3rTp7Op2xcGZ2 5fyShPkJPh5mBamnGfjnzi4JNPtrjzVnzY9/Q35W6ZtySk89mMrHiWIbFcZimh6GT3c4 8qRg8sMKhqBNY/QPKgCG6t2Ko3WyOrnOmVhmEudoDvJXbWz/+lmblxUylpn9J8LZIQGE O6FoYk49gDCP6IeLmaao4oxKObYrYvnlWJIA//AsCAw3MRO4HMOx0N+RUVScXym74/Tn aOXg== X-Received: by 10.14.3.137 with SMTP id 9mr431146eeh.0.1367439763255; Wed, 01 May 2013 13:22:43 -0700 (PDT) Received: from [192.168.1.21] (78-3-25-113.adsl.net.t-com.hr. [78.3.25.113]) by mx.google.com with ESMTPSA id n7sm5606705eeo.0.2013.05.01.13.22.41 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 01 May 2013 13:22:42 -0700 (PDT) Message-ID: <51817984.7020101@gmail.com> Date: Wed, 01 May 2013 22:22:28 +0200 From: Tomek Mrugalski User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; pl; rv:1.9.2.28) Gecko/20120306 Thunderbird/3.1.20 MIME-Version: 1.0 To: dhcwg@ietf.org References: <489D13FBFA9B3E41812EA89F188F018E1850BFB8@xmb-rcd-x04.cisco.com> In-Reply-To: <489D13FBFA9B3E41812EA89F188F018E1850BFB8@xmb-rcd-x04.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [dhcwg] WG Adoption Call - draft-lemon-dhc-topo-conf - Ends May 2, 2013 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 May 2013 20:22:45 -0000 W dniu 2013-04-17 15:47, Bernie Volz (volz) pisze: > The author has requested a call for adoption by the WG for > draft-lemon-dhc-topo-conf-01. > > This call is being initiated to confirm whether there is WG consensus to > adopt this work as DHC WG draft. Please state whether or not you're in > favor of the adoption by replying to this mail. I'm in favor of adopting this work. I have some technical comments on the draft itself. I'll post them when I get back home. Nothing serious, just several ideas about additional topics this draft should cover and couple minor mistakes. Greetings from Dubrovnik, Croatia, Tomek From volz@cisco.com Wed May 1 20:16:11 2013 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 13E0B21F9A22 for ; Wed, 1 May 2013 20:16:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.732 X-Spam-Level: X-Spam-Status: No, score=-9.732 tagged_above=-999 required=5 tests=[AWL=0.867, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MCDqZXV9Tp9Q for ; Wed, 1 May 2013 20:16:06 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 3D54721F9A2F for ; Wed, 1 May 2013 20:16:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1618; q=dns/txt; s=iport; t=1367464566; x=1368674166; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=GpWaHGePRsCuz6FGJIHebGyJGsC3cU7eBft9aOVZV24=; b=XBOrozCsrzgQrq7lXZDZGRCWhhWH35npiJ407eYn06dVJ2V1XNnWGT6z 81OVmHfZk6VuFF1sUUf9x51NIPlZIveyvqHQi4AOoVzvCBK2AU61fVJD3 N0avZcr5X5LXcZQXs3gfPQqAZZ1gsyealQGvxHy3TfqTL2V1k84csOhG3 g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqsGAJjZgVGtJV2c/2dsb2JhbABSgwc3vyOBARZtB4IfAQEBBAEBATcxAxcGAQgRBAEBCxQJLgsUCQkBBBMIiAQMoAqfJo5xPoJrYQOYT5ALgw2CJw X-IronPort-AV: E=Sophos;i="4.87,593,1363132800"; d="scan'208";a="205436217" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-6.cisco.com with ESMTP; 02 May 2013 03:16:05 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id r423G5En027083 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 2 May 2013 03:16:05 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.31]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.02.0318.004; Wed, 1 May 2013 22:16:05 -0500 From: "Bernie Volz (volz)" To: "dhcwg@ietf.org" Thread-Topic: [dhcwg] WGLC Results - draft-ietf-dhc-option-guidelines-11 Thread-Index: Ac5G4p8Neo9K8LU5RnKFIZVRS2n7gA== Date: Thu, 2 May 2013 03:16:05 +0000 Message-ID: <489D13FBFA9B3E41812EA89F188F018E18523006@xmb-rcd-x04.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.243.46] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dhcwg] WGLC Results - draft-ietf-dhc-option-guidelines-11 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 May 2013 03:16:11 -0000 Thanks to all of those that responded with support for moving this document= forward. In my opinion, this document does have consensus to move forward. However, = there were several extensive reviews which raised some points that will nee= d to be addressed. Once those are incorporated into a -12, we will do anoth= er (perhaps shorter last call) to confirm those changes and make a final de= termination. - Bernie -----Original Message----- From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of B= ernie Volz (volz) Sent: Tuesday, April 09, 2013 11:06 AM To: dhcwg@ietf.org Subject: [dhcwg] WGLC - draft-ietf-dhc-option-guidelines-11 - Respond by Ap= ril 24 Folks, the authors of draft-ietf-dhc-option-guidelines-11, http://tools.ietf.org/html/draft-ietf-dhc-option-guidelines-11, feel it's r= eady for a WGLC. There's been discussion and comment already, but more eye= s on and a "final" review of this work are required to advance it. This document is critical as it provides guidance to others in the IETF tha= t may not be DHCP "experts" when they need to write a DHCP option internet-= draft. At the time of this writing, there is no IPR reported against this draft. Please review the draft and indicate whether or not you feel it is ready to= be published. Your response matters to the process, so please do respond. As Tomek is an author, I will evaluate consensus after April 24, 2013. Thanks! - Bernie _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From Branimir.Rajtar@t.ht.hr Thu May 2 06:11:39 2013 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 BE36D21F896E for ; Thu, 2 May 2013 06:11:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KorTiICEyRUv for ; Thu, 2 May 2013 06:11:35 -0700 (PDT) Received: from mx02.t.ht.hr (mx02.t.ht.hr [195.29.161.89]) by ietfa.amsl.com (Postfix) with SMTP id D8A8321F8935 for ; Thu, 2 May 2013 06:11:33 -0700 (PDT) Received: from no.name.available by mx02.t.ht.hr via smtpd (for mail.ietf.org [12.22.58.30]) with ESMTP; Thu, 2 May 2013 14:39:25 +0200 Received: from (unknown [172.17.66.76]) by scmg2.t.ht.hr with smtp id 4f92_1cd7_cdcb4b32_b329_11e2_a585_00219b931f47; Thu, 02 May 2013 15:11:29 +0200 Received: (private information removed) Thu, 2 May 2013 15:11:30 +0200 Received: (private information removed) S2010EXCHCA1.ad.local ([::1]) with mapi id 14.03.0123.003; Thu, 2 May 2013 15:11:29 +0200 From: Branimir Rajtar To: Marcin Siodelski , "dhcwg@ietf.org" Thread-Topic: [dhcwg] Adoption call on draft-scskf-dhc-dhcpv4-over-dhcpv6 Thread-Index: AQHOQpFIXERfo9xEs0qXIeXwcjIGCpjx5vXw Date: Thu, 2 May 2013 13:11:29 +0000 Message-ID: <786F13AA11E69F4DB2CCA23F7400C2FB0142A39F@S2010EXCH1.ad.local> References: <1365009642.19971.22.camel@marcin-lenovo> <515C69A4.7000903@gmail.com> <515D592B.4040609@viagenie.ca> <5170DE2C.4010200@gmail.com> <1366989482.20228.10.camel@marcin-lenovo> In-Reply-To: <1366989482.20228.10.camel@marcin-lenovo> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.17.5.13] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginalArrivalTime: 02 May 2013 13:11:30.0313 (UTC) FILETIME=[8F966F90:01CE4736] X-NAIMIME-Disclaimer: 1 X-NAIMIME-Modified: 1 Subject: Re: [dhcwg] Adoption call on draft-scskf-dhc-dhcpv4-over-dhcpv6 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 May 2013 13:11:39 -0000 SGksCgpJIHdvdWxkIGFjdHVhbGx5IGxpa2UgdG8gc2VlIGluIHRoZSBkb2N1bWVudCBhbiBvcHRp b24gdG8gdXNlIERIQ1B2NC1vdmVyLURIQ1B2NiBpbiB1bmljYXN0IG1vZGUsIHJhdGhlciB0aGFu IGluIG5hdGl2ZSBtdWx0aWNhc3QuIEluIHRoYXQgd2F5IHdlIGNvdWxkIGJlIGFibGUgdG8gbWFr ZSBhIHNlcGFyYXRpb24gb2YgSVB2NiBhbmQgSVB2NCBpbmZyYXN0cnVjdHVyZSwgd2hpY2ggaXMg aW4gYWNjb3JkYW5jZSB3aXRoIHRoZSBkcmFmdCBJJ20gd29ya2luZyBvbiBhbmQgd2hpY2ggaXMg Y3VycmVudGx5IGluIGNhbGwgZm9yIGFkb3B0aW9uIChkcmFmdC1yYWp0YXItZGhjLXY0Y29uZmln dXJhdGlvbi0wMikuCgpCUiwKQnJhbmltaXIKCgotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQpG cm9tOiBkaGN3Zy1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86ZGhjd2ctYm91bmNlc0BpZXRmLm9y Z10gT24gQmVoYWxmIE9mIE1hcmNpbiBTaW9kZWxza2kKU2VudDogRnJpZGF5LCBBcHJpbCAyNiwg MjAxMyA1OjE4IFBNClRvOiBkaGN3Z0BpZXRmLm9yZwpTdWJqZWN0OiBSZTogW2RoY3dnXSBBZG9w dGlvbiBjYWxsIG9uIGRyYWZ0LXNjc2tmLWRoYy1kaGNwdjQtb3Zlci1kaGNwdjYKCk9uIFRodSwg MjAxMy0wNC0xOCBhdCAyMzowMyAtMDcwMCwgVG9tZWsgTXJ1Z2Fsc2tpIHdyb3RlOgo+IFRoaXMg YWRvcHRpb24gY2FsbCBkZWFkbGluZSBoYXMgcGFzc2VkLiBJJ20gdmVyeSBoYXBweSB0aGF0IHdl IGhhZCBhCj4gaGVhbHRoeSBkaXNjdXNzaW9uIHdpdGggbWFueSB1c2VmdWwgY29tbWVudHMgcG9z dGVkLiBNb3N0IGNvbW1lbnRzIHdlcmUKPiBzdXBwb3J0aW5nIGFkb3B0aW9uLiBUaGVyZSB3ZXJl IHR3byBvYmplY3Rpb25zIChvbmUgd2FzIGxhdGVyCj4gd2l0aGRyYXduKS4gVGhpcyBtZWFucyB0 aGF0IHRoZSBXRyBoYXMgcmVhY2hlZCBhIHN0cm9uZyBjb25zZW5zdXMgdG8KPiBhZG9wdCB0aGlz IHdvcmsuCj4gCj4gQXV0aG9ycywgcGxlYXNlIHVwbG9hZCB0aGlzIHdvcmsgYXMgZHJhZnQtaWV0 Zi1kaGMtZGhjcHY0LW92ZXItZGhjcHY2LTAwCj4gb25jZSB5b3UgYWRkcmVzcyBhbGwgcmVjZWl2 ZWQgY29tbWVudHMuCgpUaGFua3MgdG8gZXZlcnlib2R5IHdobyBoYXZlIHRha2VuIHRpbWUgdG8g cmV2aWV3IHRoaXMgZG9jdW1lbnQgYW5kCnNoYXJlZCBjb21tZW50cy4gV2UgdHJpZWQgdG8gYWRk cmVzcyBjb21tZW50cyBmcm9tIHRoZSBhZG9wdGlvbiBjYWxsCnBlcmlvZCBhbmQgdGhlIHVwbG9h ZGVkIC0wMCB2ZXJzaW9uIGluY2x1ZGVzIHJlbGV2YW50IGNoYW5nZXMuIEluCnBhcnRpY3VsYXI6 CgoxKSBSZW5hbWUgdGhlIGRvY3VtZW50IGRyYWZ0LWlldGYtZGhjLWRoY3B2NC1vdmVyLWRoY3B2 Ni0wMAoyKSBBZGQgc29tZSB0ZXh0IGluIEludHJvZHVjdGlvbiBzZWN0aW9uIGFib3V0IHRoZSBt b3RpdmF0aW9uIGFuZCBzY29wZQozKSBBZGQgYSBwYXJhZ3JhcGggaW4gU2VjdGlvbiA2IGFib3V0 IHRoZSB1c2Ugb2YgSVB2NiBpbnRlcmZhY2UKNCkgQWRkIHNvbWUgdGV4dCBpbiBTZWN0aW9uIDgg dG8gY2xhcmlmeSB3aGF0IGEgJ0RIQ1B2NCBzZXJ2ZXIgZW5naW5lJwppcywgYW5kIHNwZWNpZnkg dGhlIHJlbGF0ZWQgZGlzY3Vzc2lvbnMgYXJlIG91dCBvZiBzY29wZS4KNSkgUmV3cml0ZSBTZWN0 aW9uIDkgKFNlY3VyaXR5IENvbnNpZGVyYXRpb25zKQo2KSBNb3ZlIFJGQzIxMTkgdG8gdGhlIGxp c3Qgb2YgTm9ybWF0aXZlIFJlZmVyZW5jZXMKCkFsbCBmdXJ0aGVyIGNvbW1lbnRzIHJlZ2FyZGlu ZyB0aGUgbGF0ZXN0IHZlcnNpb24gb2YgdGhpcyBkb2N1bWVudCBhcmUKYXBwcmVjaWF0ZWQuCgpM aW5rczoKClRoZSBJRVRGIGRhdGF0cmFja2VyIHN0YXR1cyBwYWdlIGZvciB0aGlzIGRyYWZ0IGlz OgpodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLWRoYy1kaGNwdjQt b3Zlci1kaGNwdjYKClRoZXJlJ3MgYWxzbyBhIGh0bWxpemVkIHZlcnNpb24gYXZhaWxhYmxlIGF0 OgpodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWRoYy1kaGNwdjQtb3Zlci1k aGNwdjYtMDAKCkNoZWVycywKTWFyY2luCgoKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fCmRoY3dnIG1haWxpbmcgbGlzdApkaGN3Z0BpZXRmLm9yZwpodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RoY3dnCgoKPEhUTUw+PFA+PEZPTlQg ZmFjZT1BcmlhbCBjb2xvcj0jOTk5OTk5IHNpemU9MT4NCg0KSVpKQVZBIE8gT0RSSUNBTkpVIE9E R09WT1JOT1NUSTogU2FkcsW+YWogb3ZlIHBvcnVrZSBpIGV2ZW50dWFsbm8gcHJpbG/FvmVuaWgg ZGF0b3Rla2EgamUgcG92amVybGppdiBpIG5hbWlqZW5qZW4gamUgc2FtbyBvc29iYW1hIGlsaSBz dWJqZWt0aW1hIGtvamkgc3UgbmF2ZWRlbmkgdSBhZHJlc2kuIFVrb2xpa28gc3RlIHByaW1pbGkg b3Z1IHBvcnVrdSBncmXFoWtvbSwgbW9saW1vIFZhcywgb2JhdmlqZXN0aXRlIHBvxaFpbGphdGVs amEsIGEgcG9ydWt1IGkgc3ZlIG5qZW5lIHByaXZpdGtlIG9kbWFoLCBiZXogxI1pdGFuamEsIHRy YWpubyB1a2xvbml0ZSBzIHJhxI11bmFsYS4gQmlsbyBrYWt2byBwcmVub8WhZW5qZSwga29waXJh bmplIGlsaSBkaXN0cmlidWNpamEgaW5mb3JtYWNpamEgc2FkcsW+YW5paCB1IHBvcnVjaSB0cmXE h2ltIG9zb2JhbWEgamUgemFicmFuamVubyBpIG1vxb5lIGJpdGkgemFrb25za2kga2HFvm5qaXZv LiBTYWRyxb5haiwgc3Rhdm92aSBpIG1pxaFsamVuamEgaXpuZXNlbmkgdSBwb3J1Y2kgc3UgYXV0 b3JvdmkgaSBuZSBwcmVkc3RhdmxqYWp1IG51xb5ubyBzdGF2b3ZlIEhUIC0gSHJ2YXRza2loIHRl bGVrb211bmlrYWNpamEgZC5kLiBIVCBuZSBwcmlodmHEh2EgbmlrYWt2dSBvZGdvdm9ybm9zdCB6 YSBldmVudHVhbG51IMWhdGV0dSBuYXN0YWx1IHByaW1pdGtvbSBvdmUgcG9ydWtlIGkgcHJpbG9n YSBzYWRyxb5hbmloIHUgcG9ydWNpLg0KDQo8L0ZPTlQ+PC9QPjxQPjxGT05UIGZhY2U9QXJpYWwg Y29sb3I9Izk5OTk5OSBzaXplPTE+DQoNCiBESVNDTEFJTUVSOlRoZSBjb250ZW50cyBvZiB0aGlz IGVtYWlsIGFzIHdlbGwgYXMgYW55IGZpbGVzIGF0dGFjaGVkIHRvIGl0IGFyZSBjb25maWRlbnRp YWwgYW5kIGludGVuZGVkIHNvbGVseSBmb3IgaW5kaXZpZHVhbHMgb3IgZW50aXRpZXMgd2hpY2gg dGhleSBhcmUgYWRkcmVzc2VkIHRvLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIG1l c3NhZ2UgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBhbmQgcGVybWFuZW50bHkg cmVtb3ZlIHRoZSBtZXNzYWdlIGFuZCBhbGwgYXR0YWNoZWQgZmlsZXMgZnJvbSB0aGUgY29tcHV0 ZXIuIEFueSBkaXNjbG9zdXJlLCBjb3B5aW5nIG9yIGRpc3RyaWJ1dGlvbiBvZiBhbGwgb3IgYSBw YXJ0IG9mIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBoZXJlaW4gdG8gb3IgYnkgdGhpcmQgcGFydGll cyBpcyBwcm9oaWJpdGVkIGFuZCBtYXkgYmUgdW5sYXdmdWwuIFBsZWFzZSBub3RlIHRoYXQgYW55 IHZpZXdzIG9yIG9waW5pb25zIHByZXNlbnRlZCBpbiB0aGlzIG1lc3NhZ2UgYXJlIHNvbGVseSB0 aG9zZSBvZiB0aGUgYXV0aG9yIGFuZCBkbyBub3QgbmVjZXNzYXJpbHkgcmVwcmVzZW50IHRoZSB2 aWV3cyBhbmQgb3BpbmlvbnMgb2YgQ3JvYXRpYW4gVGVsZWNvbSBJbmMuIENyb2F0aWFuIFRlbGVj b20gSW5jLiBhY2NlcHRzIG5vIGxpYWJpbGl0eSBmb3IgYW55IHBvdGVudGlhbCBkYW1hZ2UgY2F1 c2VkIGJ5IHRoaXMgbWVzc2FnZSBhbmQgZmlsZXMgYXR0YWNoZWQgdG8gaXQuDQoNCjwvRk9OVD48 L1A+PC9IVE1MPgo= From volz@cisco.com Thu May 2 10:24:33 2013 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 2F67621F85EE for ; Thu, 2 May 2013 10:24:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.949 X-Spam-Level: X-Spam-Status: No, score=-9.949 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9+6bdx3b-LWr for ; Thu, 2 May 2013 10:24:27 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 1229B21F890F for ; Thu, 2 May 2013 10:24:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5370; q=dns/txt; s=iport; t=1367515467; x=1368725067; h=from:to:cc:subject:date:message-id: content-transfer-encoding:mime-version; bh=atHBon/bQ1oL+JCm9BxbyKAq8ldVZoj3XRLVyQjdZQ8=; b=LiXQeUOfsEDplKuCyn3zS4MTosduI5/OfnJkw00TcTyJExVf52EEeTj1 2L+wOx7i2fjK/8kX2cr4ZQc0XBBxgDq3bMkXCL4aDdqUR5PYEpEIX0txW rmKDhKb3MopEPsnbokRn3Rz/UG31TUBLyYb+mqF4Lrw0olj7/DzxwSFXD Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjUHAOafglGtJV2a/2dsb2JhbABSgweDbrtxDXIWbQeCIQEEIxE+BxIBIgIGIAIEMBURAQQODYgEsE+QaIEjjVIxgkcyYQOoXYMNgic X-IronPort-AV: E=Sophos;i="4.87,597,1363132800"; d="scan'208";a="205538234" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-1.cisco.com with ESMTP; 02 May 2013 17:24:23 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r42HON3v009924 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 2 May 2013 17:24:23 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.31]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.02.0318.004; Thu, 2 May 2013 12:24:22 -0500 From: "Bernie Volz (volz)" To: "dhcwg@ietf.org" Thread-Topic: draft-scskf-dhc-dhcpv4-over-dhcpv6-01 comments Thread-Index: Ac5HVOF6YqHXqP/DR3yTmXTJl1Dy6g== Date: Thu, 2 May 2013 17:24:22 +0000 Message-ID: <489D13FBFA9B3E41812EA89F188F018E18524452@xmb-rcd-x04.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.243.46] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "sunqi@csnet1.cs.tsinghua.edu.cn" , "yong@csnet1.cs.tsinghua.edu.cn" Subject: [dhcwg] draft-scskf-dhc-dhcpv4-over-dhcpv6-01 comments X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 May 2013 17:24:33 -0000 SGk6DQoNClNvbWUgY29tbWVudHMgb24gdGhlIDAxIGRyYWZ0Og0KDQotIEluIDEuIEludHJvZHVj dGlvbjoNCg0KICAgU2V2ZXJhbCBhcHByb2FjaGVzIGZvciBwcm92aXNpb25pbmcgc3VjaCBpbmZv cm1hdGlvbiBoYXZlIGJlZW4NCiAgIGFscmVhZHkgYmVlbiBwcm9wb3NlZC4gIFRoaXMgZG9jdW1l bnQgZGVzY3JpYmVzIG9uZSBzdWNoIGFwcHJvYWNoDQoNCklzIHRoaXMgcmVhbGx5IHdvcnRoIGFk ZGluZz8gRXNwZWNpYWxseSB3aXRob3V0IHByb3ZpZGluZyByZWZlcmVuY2VzPyBBbHNvLCBpZiB3 ZSBhcmUgdG8gYWJhbmRvbiB0aG9zZSBvdGhlciBhcHByb2FjaGVzLCB3aHkgd291bGQgd2Ugd2Fu dCB0aGUgUkZDIChhc3N1bWluZyB0aGlzIGJlY29tZXMgb25lKSB0byBjb25mdXNlIHBlb3BsZSBp bnRvIHRoaW5raW5nIHRoZXkgbWF5IGhhdmUgYWx0ZXJuYXRpdmVzPw0KDQotIEluIDMuIFRlcm1p bm9sb2d5DQoNClRoaXMgc2VlbXMgYW4gb2RkIHNlY3Rpb24gdGl0bGUgdG8gZGVmaW5lIG5ldyBt ZXNzYWdlcz8gQ291bGQgdGhpcyBub3QganVzdCBiZSAiTmV3IE1lc3NhZ2VzIiBvciBzb21ldGhp bmcgbGlrZSB0aGF0PyBJdCBtYXkgYWxzbyBtYWtlIHNlbnNlIHRvIG1vdmUgdGhpcyB0byBhZnRl ciBjdXJyZW50IHNlY3Rpb24gND8NCg0KSSBhbHNvIHRoaW5rIGl0IHdvdWxkIGJlIGJlc3QgdG8g Y2xlYXJseSBpbmRpY2F0ZSB0aGF0IHRoZXNlIG1lc3NhZ2VzIGFyZSBmb3JtYXR0ZWQgYXMgc2hv dyBpbiBTZWN0aW9uNiBvZiBSRkMgMzMxNSAoeWVzLCB0aGF0IG1heSBiZSBvYnZpb3VzIHRvIHVz LCBidXQgYmVzdCB0byBiZSBleHBsaWNpdCkuDQoNClRoaXMgd291bGQgYWxzbyBtZWFuIHlvdSBj b3VsZCByZW1vdmUgdGhlICJBIG5ldyB0eXBlIG9mIC4uLiIgaW4gdGhlIGRlZmluaXRpb24uDQoN CkFuZCwgIkVhY2ggQk9PVFAgTWVzc2FnZSBPcHRpb24iIG1ha2VzIGl0IGFwcGVhciB0aGVyZSBj b3VsZCBiZSBtb3JlIHRoYW4gb25lIGluIGEgbWVzc2FnZSwgd2hpY2ggaXMgbm90IHNvbWV0aGlu ZyBJIHRoaW5rIHdlIHdhbnQuDQoNClNvLCBob3cgYWJvdXQ6DQoNCjMuIE5ldyBESENQdjYgTWVz c2FnZXMNCg0KVGhlIGZvbGxvd2luZyBuZXcgREhDUHY2IENsaWVudC9TZXJ2ZXIgbWVzc2FnZXMg YXJlIGRlZmluZWQgYnkgdGhpcyBkb2N1bWVudC4gVGhlc2UgYXJlIGZvcm1hdHRlZCBhcyBzcGVj aWZpZWQgaW4gU2VjdGlvbiA2IG9mIFtSRkMgMzMxNV0uDQoNCiAgIEJPT1RSRVFVRVNUVjYgKFRC RCk6ICBBIGNsaWVudCBzZW5kcyBhDQogICAgICAgICAgICAgICAgICAgICAgICAgQk9PVFJFUVVF U1RWNiBtZXNzYWdlIHRvIGEgc2VydmVyLCB3aGljaA0KICAgICAgICAgICAgICAgICAgICAgICAg IGNvbnRhaW5zIGEgQk9PVFAgTWVzc2FnZSBPcHRpb24uICBUaGUgQk9PVFANCiAgICAgICAgICAg ICAgICAgICAgICAgICBNZXNzYWdlIE9wdGlvbiBjb250YWlucyBhIEJPT1RSRVFVRVNUIG1lc3Nh Z2UNCiAgICAgICAgICAgICAgICAgICAgICAgICB0aGF0IHRoZSBjbGllbnQgdXNlcyB0byByZXF1 ZXN0IElQdjQNCiAgICAgICAgICAgICAgICAgICAgICAgICBjb25maWd1cmF0aW9uIHBhcmFtZXRl cnMgZnJvbSB0aGUgc2VydmVyLg0KDQogICBCT09UUkVQTFlWNiAoVEJEKTogICAgQSBzZXJ2ZXIg c2VuZHMgYQ0KICAgICAgICAgICAgICAgICAgICAgICAgIEJPT1RSRVBMWVY2IG1lc3NhZ2UgY29u dGFpbmluZyBhIEJPT1RQIE1lc3NhZ2UNCiAgICAgICAgICAgICAgICAgICAgICAgICBPcHRpb24g aW4gcmVzcG9uc2UgdG8gYSBjbGllbnQncyBCT09UUkVRVUVTVFY2DQogICAgICAgICAgICAgICAg ICAgICAgICAgbWVzc2FnZS4gIFRoZSBCT09UUCBNZXNzYWdlIE9wdGlvbiBjb250YWlucyBhIEJP T1RSRVBMWQ0KICAgICAgICAgICAgICAgICAgICAgICAgIG1lc3NhZ2UgaW4gcmVzcG9uc2UgdG8g YSBCT09UUkVRVUVTVCByZWNlaXZlZCBieSB0aGUNCiAgICAgICAgICAgICAgICAgICAgICAgICBz ZXJ2ZXIgaW4gdGhlIEJPT1RQIE1lc3NhZ2UgT3B0aW9uIG9mIGEgIEJPT1RSRVFVRVNUVjYNCiAg ICAgICAgICAgICAgICAgICAgICAgICBtZXNzYWdlLg0KDQotLSBFbmQgLS0NCg0KLSBJbiBzZWN0 aW9uIDYsIENsaWVudCBCZWhhdmlvcjoNCg0KSSdkIHN1Z2dlc3QgY2hhbmdpbmcgIiBUaGUgQ2xp ZW50IHNlbmRzIG91dCB0aGUgQk9PVFJFUVVFU1RWNiBtZXNzYWdlIHRvIHRoZSBXZWxsLUtub3du IG11bHRpY2FzdCBhZGRyZXNzLCBpLmUuICBBbGxfREhDUF9SZWxheV9BZ2VudHNfYW5kX1NlcnZl cnMgb24gbXVsdGljYXN0IGFkZHJlc3MgZGVmaW5lZCBpbiBbUkZDMzMxNV0uIiBUbyAiVGhlIENs aWVudCB0cmFuc21pdHMgdGhlIEJPT1RSRVFVRVNUVjYgbWVzc2FnZSBhcyBzcGVjaWZpZWQgaW4g U2VjdGlvbiAxMyBvZiBbUkZDMzMxNV0uIg0KDQpJIHRoaW5rIGl0IGlzIGFsc28gaW1wb3J0YW50 IHRvIGFkZCBoZXJlIHRoYXQgdGhlcmUgYXJlIG5vIGV4cGxpY2l0IHRyYW5zbWlzc2lvbiBwYXJh bWV0ZXJzIGFzc29jaWF0ZWQgd2l0aCBhIEJPT1RQUkVRVUVTVFY2IG1lc3NhZ2UgKHNlZSBTZWN0 aW9uIDE0IG9mIFtSRkMgMzMxNV0pIGFzIHRoZSBjbGllbnQgU0hPVUxEIGZvbGxvdyB0aGUgbm9y bWFsIERIQ1B2NCByZXRyYW5zbWlzc2lvbiByZXF1aXJlbWVudHMgYXMgYXBwcm9wcmlhdGUgZm9y IHRoZSBtZXNzYWdlKHMpIGl0IGlzIHNlbmRpbmcuDQoNCk9uZSB0aGluZyB3ZSBNSUdIVCB3YW50 IHRvIHRoaW5rIGFib3V0IGluIHJlbGF0aW9uIHRvIHJlcXVpcmluZyBSRkMgNDM2MSBpcyB3aGV0 aGVyIHRoZSBCT09UUkVRVUVTVFY2IG1lc3NhZ2UgbWF5IGNvbnRhaW5zIGEgREhDUHY2IGNsaWVu dC1pZGVudGlmaWVyIG9wdGlvbj8gVGhpcyBtaWdodCBiZSB1c2VmdWwgYW5kIHRoZW4gY291bGQg cmVsYXggdGhlIG5lZWQgZm9yIHVzaW5nIFJGQyA0MzYxIChhcyB0aGF0IG1pZ2h0IHJlcXVpcmUg bW9yZSBvZiBhIGNoYW5nZSB0byB0aGUgREhDUHY0IGNsaWVudCAtLSBhcyBpdCBtYXkgYmUgcG9z c2libGUgdG8gYXZvaWQgYW55IGNoYW5nZXMgdG8gdGhlIERIQ1B2NCBjbGllbnQgYnkgaW50ZXJj ZXB0aW5nIHRoZSBwYWNrZXRzIC8gaW5qZWN0aW5nIHRoZSBwYWNrZXRzKS4NCg0KLSBJbiBzZWN0 aW9uIDcsIFJlbGF5IEFnZW50IEJlaGF2aW9yDQoNCiAgIFRoZSBhYm92ZSBsb2dpYyBvbmx5IGFs bG93cyBmb3Igc2VwYXJhdGUgcmVsYXkgZGVzdGluYXRpb25zDQogICBjb25maWd1cmVkIG9uIHRo ZSByZWxheSBhZ2VudCBjbG9zZXN0IHRvIHRoZSBjbGllbnQgKHNpbmdsZSByZWxheQ0KICAgaG9w KS4gIE11bHRpcGxlIHJlbGF5aW5nIGhvcHMgYXJlIG5vdCBjb25zaWRlcmVkIGluIHRoaXMgZG9j dW1lbnQuDQoNCldoeSBub3Q/IFNlZW1zIHRoYXQgdGhlIGxvZ2ljIGp1c3QgcmVxdWlyZXMgZGVl cGVyIGluc3BlY3Rpb24gLSBmb2xsb3dpbmcgdGhlIFJlbGF5IE1lc3NhZ2Ugb3B0aW9ucyB1bnRp bCB0aGUgZW5jYXBzdWxhdGVkIG1lc3NhZ2UgaXNuJ3QgYSBSZWxheS1Gb3J3IGFuZCBtYWtpbmcg dGhlIGRlY2lzaW9uIG9uIHRoYXQgbWVzc2FnZSdzIG1lc3NhZ2UgdHlwZT8gSXQgbWF5IGJlIHdv cnRoIGluZGljYXRpbmcgdGhhdCBhIHJlbGF5IG1heSB3YW50IHRvIGxpbWl0cyB0aGUgZGVwdGgg b2YgaXRzIGluc3BlY3Rpb24uDQoNCi0gSW4gc2VjdGlvbiA4LCBmb3IgdGhlIGxhc3QgcGFyYWdy YXBoLCB3aHkgbm90IGp1c3QgcmVmZXIgdG8gU2VjdGlvbiAyMC4zIG9mIFtSRkMgMzMxNV0uDQoN CiAgICBJZiB0aGUgQk9PVFJFUVVFU1RWNiBtZXNzYWdlIHdhcyByZWNlaXZlZCBpbiBhIFJlbGF5 LWZvcndhcmQgbWVzc2FnZSwNCiAgICB0aGUgc2VydmVyIHJlc3BvbmRzIGFzIGRlc2NyaWJlZCBp biBzZWN0aW9uIDIwLjMgb2YgW1JGQyAzMzE1XS4NCg0KLSBCZXJuaWUNCg0KDQo= From volz@cisco.com Fri May 3 05:47:12 2013 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 8E83C21F960C for ; Fri, 3 May 2013 05:47:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.078 X-Spam-Level: X-Spam-Status: No, score=-10.078 tagged_above=-999 required=5 tests=[AWL=0.519, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pWtA4CIzsKtf for ; Fri, 3 May 2013 05:47:07 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 54FE921F9609 for ; Fri, 3 May 2013 05:47:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13099; q=dns/txt; s=iport; t=1367585227; x=1368794827; h=from:to:cc:subject:date:message-id:mime-version; bh=MXcmCtOmhg2WZCJ+V9kXCRGIaPjuwyfrMIEbBhlQ8PI=; b=F2jWutpfD4dgrIckjNu2vV4UmNPmmIMa7jkzWyLZA+mO0zs8HuEKYQCC 9Dg6/Q5FEnPjWHbbHVVEj1yIeaAC2FT8U2iXRQRfqOam1GpLx5vuKXqcu MufK+TyiroqbiIWiQOBacHP58bjqUPec2HB6AhlWRUaEydW2WKNCwGSet A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsoGAAaxg1GtJXG9/2dsb2JhbABQgkNEN7Z4AYg2ehZtB4IfAQEBBB0QTBIBCBEEAQELHTkUCQkBBA4FCAGIAwzBQo52LQQGgnNhA5hRkAyBVYE4gic X-IronPort-AV: E=Sophos;i="4.87,604,1363132800"; d="scan'208,217";a="206068273" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-7.cisco.com with ESMTP; 03 May 2013 12:47:06 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id r43Cl6YL017101 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 3 May 2013 12:47:06 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.96]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.02.0318.004; Fri, 3 May 2013 07:47:05 -0500 From: "Bernie Volz (volz)" To: "dhcwg@ietf.org" Thread-Topic: [dhcwg] WGLC Results for draft-ietf-dhc-dhcpv6-radius-opt-11 because of late IPR notice Thread-Index: Ac5H+87D7eLA86IeSTafsZYTnMut8A== Date: Fri, 3 May 2013 12:47:04 +0000 Message-ID: <489D13FBFA9B3E41812EA89F188F018E185381C6@xmb-rcd-x04.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.249.158] Content-Type: multipart/alternative; boundary="_000_489D13FBFA9B3E41812EA89F188F018E185381C6xmbrcdx04ciscoc_" MIME-Version: 1.0 Cc: "int-ads@tools.ietf.org" Subject: Re: [dhcwg] WGLC Results for draft-ietf-dhc-dhcpv6-radius-opt-11 because of late IPR notice X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 May 2013 12:47:12 -0000 --_000_489D13FBFA9B3E41812EA89F188F018E185381C6xmbrcdx04ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi: As no one raised any concerns regarding the late IPR notice, we will let th= e original WGLC result of having reached rough consensus stand and the draf= t will continue to advance to RFC publication. - Bernie & Tomek From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of B= ernie Volz (volz) Sent: Friday, April 19, 2013 9:55 AM To: dhcwg@ietf.org Subject: [dhcwg] Re-Issued WG Last Call for draft-ietf-dhc-dhcpv6-radius-op= t-11 because of late IPR notice - ends May 2, 2013 Hello: Because of a late IPR notice, we are re-issuing the WG Last Call for draft-= ietf-dhc-dhcpv6-radius-opt-11. This last call will end May 2nd, 2013. However, as this document has already passed WG Last Call, for this Last Ca= ll we are primarily focused on whether the IPR notice changes your position= as to whether the draft should advance. If you have no issues because of t= he IPR, you do not need to respond. If you do have concerns because of the = IPR notice, please let the working group know. For details on the IPR notice, see https://datatracker.ietf.org/ipr/2052/. For the draft, see http://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-radius-= opt. I will also send a separate notice, but please note that the obligation to = disclose IPR regarding an IETF document exists as soon as the author knows = a patent application will be filed or intends to file for one, not at the t= ime the patent is issued, and not at some later date when the company decid= es what sort of terms they want to ask for. If the patent is not granted, = or a decision is made on licensing terms, the company can amend the IPR dis= closure. These rules are described in BCP79 and can be referenced through http://www= .ietf.org/ipr/policy.html. In addition, online tools for filing IPR disclo= sures can be found at http://www.ietf.org/ipr/file-disclosure. Finally, ex= isting disclosures can be searched online at https://datatracker.ietf.org/i= pr/search/. - Bernie & Tomek --_000_489D13FBFA9B3E41812EA89F188F018E185381C6xmbrcdx04ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi:<= /p>

 

As no one raised any c= oncerns regarding the late IPR notice, we will let the original WGLC result= of having reached rough consensus stand and the draft will continue to adv= ance to RFC publication.

 

-&nb= sp;         Bernie & T= omek

 

From: dhcwg-bo= unces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of Bernie Volz (volz)
Sent: Friday, April 19, 2013 9:55 AM
To: dhcwg@ietf.org
Subject: [dhcwg] Re-Issued WG Last Call for draft-ietf-dhc-dhcpv6-ra= dius-opt-11 because of late IPR notice - ends May 2, 2013=

 

Hello:

 

Because of a late IPR notice, we are re-issuing the = WG Last Call for draft-ietf-dhc-dhcpv6-radius-opt-11. This last call will e= nd May 2nd, 2013.

 

However, as this document has already passed WG Last= Call, for this Last Call we are primarily focused on whether the IPR notic= e changes your position as to whether the draft should advance. If you have= no issues because of the IPR, you do not need to respond. If you do have concerns because of the IPR notice,= please let the working group know.

 

For details on the IPR notice, see https://datatracker.ietf.org/ipr/2052/.

 

For the draft, see http://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-radius-opt.=

 

I will also send a separate notice, but please note = that the obligation to disclose IPR regarding an IETF document exists as soon= as the author knows a patent application will be filed or intends to file = for one, not at the time the patent is issued, and not at some later da= te when the company decides what sort of terms they want to ask for.  If the patent is not granted, or= a decision is made on licensing terms, the company can amend the IPR discl= osure.

 

These rules are described in BCP79 and can be r= eferenced through http= ://www.ietf.org/ipr/policy.html.  In addition, online tools for&nb= sp;filing IPR disclosures can be found at http://www.ietf.org/ipr/file-disclosure.  Finally, existing disclosures can be searched online at https://datatracker.ietf.org/= ipr/search/.

 

-     &= nbsp;    Bernie & Tomek

 

--_000_489D13FBFA9B3E41812EA89F188F018E185381C6xmbrcdx04ciscoc_-- From internet-drafts@ietf.org Mon May 6 00:56:01 2013 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 D399821F8EBF; Mon, 6 May 2013 00:56:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.496 X-Spam-Level: X-Spam-Status: No, score=-102.496 tagged_above=-999 required=5 tests=[AWL=0.104, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i8qbszFJvMJx; Mon, 6 May 2013 00:56:01 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0398121F8ECA; Mon, 6 May 2013 00:55:58 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.44.p5 Message-ID: <20130506075557.9609.48412.idtracker@ietfa.amsl.com> Date: Mon, 06 May 2013 00:55:57 -0700 Cc: dhcwg@ietf.org Subject: [dhcwg] I-D Action: draft-ietf-dhc-triggered-reconfigure-06.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 May 2013 07:56:01 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Dynamic Host Configuration Working Group = of the IETF. Title : Reconfigure Triggered by DHCPv6 Relay Agents Author(s) : Mohamed Boucadair Xavier Pougnard Filename : draft-ietf-dhc-triggered-reconfigure-06.txt Pages : 13 Date : 2013-05-06 Abstract: This document defines new DHCPv6 messages: Reconfigure-Request and Reconfigure-Reply. Reconfigure-Request message is sent by a DHCPv6 relay agent to notify a DHCPv6 server about a configuration information change, so that the DHCPv6 server can send a Reconfigure message accordingly. Reconfigure-Reply message is used by the server to acknowledge the receipt of Reconfigure-Request. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dhc-triggered-reconfigure There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-dhc-triggered-reconfigure-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dhc-triggered-reconfigure-06 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From mohamed.boucadair@orange.com Mon May 6 01:03:08 2013 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 8E09821F8EEC; Mon, 6 May 2013 01:03:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vbPB6HRThSQk; Mon, 6 May 2013 01:02:57 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id A216921F8952; Mon, 6 May 2013 01:02:56 -0700 (PDT) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm11.si.francetelecom.fr (ESMTP service) with ESMTP id 37FD93B424A; Mon, 6 May 2013 10:02:55 +0200 (CEST) Received: from PUEXCH81.nanterre.francetelecom.fr (unknown [10.101.44.34]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 14F5F23804B; Mon, 6 May 2013 10:02:55 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.7]) by PUEXCH81.nanterre.francetelecom.fr ([10.101.44.34]) with mapi; Mon, 6 May 2013 10:02:55 +0200 From: To: Robert Sparks , "dhcwg@ietf.org" , "ietf@ietf.org" , General Area Review Team , "draft-ietf-dhc-triggered-reconfigure@tools.ietf.org" Date: Mon, 6 May 2013 10:02:53 +0200 Thread-Topic: [dhcwg] Gen-art review: draft-ietf-dhc-triggered-reconfigure-05 Thread-Index: Ac5ClKF6HmqJ6RojQf+w5CK04H/aHwHmyPIg Message-ID: <94C682931C08B048B7A8645303FDC9F36ECC240570@PUEXCB1B.nanterre.francetelecom.fr> References: <517AA051.8080506@nostrum.com> In-Reply-To: <517AA051.8080506@nostrum.com> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: multipart/alternative; boundary="_000_94C682931C08B048B7A8645303FDC9F36ECC240570PUEXCB1Bnante_" MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.5.6.65415 Subject: Re: [dhcwg] Gen-art review: draft-ietf-dhc-triggered-reconfigure-05 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 May 2013 08:03:08 -0000 --_000_94C682931C08B048B7A8645303FDC9F36ECC240570PUEXCB1Bnante_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear Robert, I updated the document to cover the comments you raised. You can check the = diff available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dhc-trigge= red-reconfigure-06 Cheers, Med De : dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] De la part de R= obert Sparks Envoy=E9 : vendredi 26 avril 2013 17:42 =C0 : dhcwg@ietf.org; ietf@ietf.org; General Area Review Team; draft-ietf-d= hc-triggered-reconfigure@tools.ietf.org Objet : [dhcwg] Gen-art review: draft-ietf-dhc-triggered-reconfigure-05 I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at . Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-dhc-triggered-reconfigure-05 Reviewer: Robert Sparks Review Date: April 26, 2013 IETF LC End Date: May 6, 2013 IESG Telechat date: May 16, 2013 Summary: This draft is on the right track but has open issues, described in the review. Major issues: Overall, this document is solid, but I think there is a bug in section 6.3. I could be wrong, but If I'm right, this paragraph: When retransmission is required, the relay may decide to correct the conten= t of RECONFIGURE-REQUEST message it issues (e.g., update the Client Identif= ier list). This decision is local to the relay (e.g., it may be based on o= bserved events such as one or more clients were reconfigured on their own). introduces a race-condition that could lead to an erroneous state. If a rel= ay's first message included client A, then the retransmission included clie= nts A and B, but that retransmission crosses with a success RECONFIGURE-REP= LY to the request that only included client A, the relay will think it succ= eeded in asking A and B to be reconfigured. Minor issues: This sentence: Furthermore, means to recover state in failure events must be supported, bu= t are not discussed in this document. places a requirement on a relay (even though it's not using a 2119 MUST). I= s there some other document that defines this requirement that you can refe= rence? If not, the requirement should be discussed in this document. Altern= atively, you could change the sentence to talk about the consequences of no= t having a proprietary means for recovering state. Nits/editorial comments: --_000_94C682931C08B048B7A8645303FDC9F36ECC240570PUEXCB1Bnante_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Dear = Robert,

 

I updated the document to cover the commen= ts you raised. You can check the diff available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dhc-triggered-= reconfigure-06

 

Cheers,

Med

 

De=  : dhcwg-bounces@ietf.org [mailto:dhc= wg-bounces@ietf.org] De la part de Robert Sparks
Envoy=E9 = ;: vendredi 26 avril 2013 17:42
=C0 : dhcwg@ietf.org; ie= tf@ietf.org; General Area Review Team; draft-ietf-dhc-triggered-reconfigure= @tools.ietf.org
Objet : [dhcwg] Gen-art review: draft-ietf-d= hc-triggered-reconfigure-05

 

I am the assigned Gen-ART reviewer for this = draft. For background on
Gen-ART, please see the FAQ at

<http://wik= i.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Please resol= ve these comments along with any other Last Call comments
you may recei= ve.

Document: draft-ietf-dhc-triggered-reconfigure-05
Reviewer:&= nbsp; Robert Sparks
Review Date: April 26, 2013
IETF LC End Date: May= 6, 2013
IESG Telechat date: May 16, 2013

Summary: This draft is = on the right track but has open issues, described in
   &= nbsp;  the review.

Major issues:

Overall, this document= is solid, but I think there is a bug in section 6.3.
I could be wrong,= but If I'm right, this paragraph:

When = retransmission is required, the relay may decide to correct the content of = RECONFIGURE-REQUEST message it issues (e.g., update the Client Identifier l= ist).  This decision is local to the relay (e.g., it may be based on o= bserved events such as one or more clients were reconfigured on their own).=


intr= oduces a race-condition that could lead to an erroneous state. If a relay's= first message included client A, then the retransmission included clients = A and B, but that retransmission crosses with a success RECONFIGURE-REPLY t= o the request that only included client A, the relay will think it succeede= d in asking A and B to be reconfigured.

Minor issues:

This s= entence:

Furthermore, means to recover s= tate in failure events must be supported, but are not discussed in this doc= ument.

places a requirement on a relay (= even though it's not using a 2119 MUST). Is there some other document that = defines this requirement that you can reference? If not, the requirement sh= ould be discussed in this document. Alternatively, you could change the sen= tence to talk about the consequences of not having a proprietary means for = recovering state.

Nits/editorial comments:

= --_000_94C682931C08B048B7A8645303FDC9F36ECC240570PUEXCB1Bnante_-- From bharat_joshi@infosys.com Mon May 6 01:35:34 2013 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 8F23421F8F6C for ; Mon, 6 May 2013 01:35:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CFw6rBEiw2Yj for ; Mon, 6 May 2013 01:35:30 -0700 (PDT) Received: from kecgate02.infosys.com (kecgate02.infosys.com [122.98.14.32]) by ietfa.amsl.com (Postfix) with ESMTP id 8310C21F8F53 for ; Mon, 6 May 2013 01:35:29 -0700 (PDT) X-TM-IMSS-Message-ID: <5c2cd8d8000c85d8@infosys.com> Received: from blrkechub03.ad.infosys.com ([10.66.236.43]) by infosys.com ([122.98.14.32]) with ESMTP (TREND IMSS SMTP Service 7.1) id 5c2cd8d8000c85d8 ; Mon, 6 May 2013 14:03:52 +0530 Received: from BLRKECHUB09.ad.infosys.com (10.66.236.139) by blrkechub03.ad.infosys.com (10.66.236.43) with Microsoft SMTP Server (TLS) id 8.2.176.0; Mon, 6 May 2013 14:04:47 +0530 Received: from BLRKECMBX13.ad.infosys.com ([fe80::c43d:ba67:abc0:11c3]) by Blrkechub09.ad.infosys.com ([::1]) with mapi id 14.02.0318.004; Mon, 6 May 2013 14:04:46 +0530 From: Bharat Joshi To: Simon Hobson , "dhcwg@ietf.org" Thread-Topic: [dhcwg] RFC 6925 on The DHCPv4 Relay Agent Identifier Sub-Option Thread-Index: AQHORZFvZIAPFB8z6U210hYYmgnMzJj33IER Date: Mon, 6 May 2013 08:34:46 +0000 Message-ID: <35347FBF2796F94E936EE76C0E6047ED32E4D68B@BLRKECMBX13.ad.infosys.com> References: <0D6E16088A9D7EBF474768B814221EB3E@thehobsons.co.uk> In-Reply-To: <0D6E16088A9D7EBF474768B814221EB3E@thehobsons.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.200.132] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dhcwg] RFC 6925 on The DHCPv4 Relay Agent Identifier Sub-Option X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 May 2013 08:35:34 -0000 Dear Simon, Sorry for a delayed reply. This RFC creates a single unique identifier to identify Relay Agen= t in a network. Before RFC 6925, no such unique identifier existed for re= lay agents. Note that a single relay agent may use multiple Giaddrs. Rela= y-id is especially useful for bulk lease query (RFC 6926). Please refer S= ection 3.1 for more details. Please note that Relay-ID itself is not expected to uniquely identif= y DHCP client. For that as mentioned in Section 3.2: "A straightforward way to form identifier information is to combine something that is unique within the scope of the network element, such as a port/slot value, with something that uniquely identifies that network element, such as a Relay Agent Identifier." In case of factory floor network, we are suggesting that relay-id = option should be used if the DHCP server policies require to identify the= relay agent device during allocation. A relay agent might have multiple = 'Giaddr'. In such a case, a DHCP server may end up having as many similar= policies as the number of Giaddrs in a relay agent. Also, if factory floor networks uses relay-id, relay agents can us= e Bulk lease query when they reboots to learn back all the leases. Regards, Bharat ________________________________________ From: dhcwg-bounces@ietf.org [dhcwg-bounces@ietf.org] on behalf of Simon = Hobson [linux@thehobsons.co.uk] Sent: Tuesday, April 30, 2013 4:26 PM To: dhcwg@ietf.org Subject: Re: [dhcwg] RFC 6925 on The DHCPv4 Relay Agent Identifier Sub-Op= tion >This document defines a new Relay Agent Identifier sub-option for the >Dynamic Host Configuration Protocol (DHCP) Relay Agent Information >option. The sub-option carries a value that uniquely identifies the >relay agent device within the administrative domain. I'm not clear what problem this is trying to solve, and how it's going to= do it. In the case of the factory floor network, I can't see what this identifie= r provides that's not already provided by the GI-Addr field. In the gener= al case knowing the relay agent identifier won't narrow down the location= of the client any further than GI-Addr. In the case where the relay agen= t serves multiple remote networks, it would appear that the agent identif= ier will be less specific than the GI-Addr. If the clients are connected to a switch, and so multiple clients can be = served by one interface, then only the switch would know the locations - = and could insert Option-82 into client requests. The relay agent will not= know the location (switch port) unless the switch informs it by (eg) ins= erting something like Option-82. Or have I missed something ? _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg **************** CAUTION - Disclaimer ***************** This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended sol= ely for the use of the addressee(s). If you are not the intended recipient, p= lease notify the sender by e-mail and delete the original message. Further, you= are not to copy, disclose, or distribute this e-mail or its contents to any other= person and any such actions are unlawful. This e-mail may contain viruses. Infosys h= as taken every reasonable precaution to minimize this risk, but is not liable for = any damage you may sustain as a result of any virus in this e-mail. You should carry= out your own virus checks before opening the e-mail or attachment. Infosys reserve= s the right to monitor and review the content of all messages sent to or from t= his e-mail address. Messages sent to or from this e-mail address may be stored on th= e Infosys e-mail system. ***INFOSYS******** End of Disclaimer ********INFOSYS*** From Olaf.Bonness@telekom.de Mon May 6 05:28:30 2013 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 77C2221F8E8F for ; Mon, 6 May 2013 05:28:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9vGIyo1iDlIv for ; Mon, 6 May 2013 05:28:26 -0700 (PDT) Received: from tcmail33.telekom.de (tcmail33.telekom.de [80.149.113.247]) by ietfa.amsl.com (Postfix) with ESMTP id 2230221F8E93 for ; Mon, 6 May 2013 05:28:25 -0700 (PDT) Received: from he111527.emea1.cds.t-internal.com ([10.125.90.86]) by tcmail31.telekom.de with ESMTP/TLS/AES128-SHA; 06 May 2013 14:28:22 +0200 Received: from HE113605.emea1.cds.t-internal.com ([169.254.1.230]) by HE111527.EMEA1.CDS.T-INTERNAL.COM ([::1]) with mapi; Mon, 6 May 2013 14:28:21 +0200 From: To: Date: Mon, 6 May 2013 14:28:19 +0200 Thread-Topic: [dhcwg] Adoption call for draft-rajtar-dhc-v4configuration-02 - respond by May 8th Thread-Index: Ac5BCflEiW36bbX1SkWAB4CQmsrEpgJSe1gw Message-ID: References: <8A1B81989BCFAE44A22B2B86BF2B7631898DB0232B@HE111643.EMEA1.CDS.T-INTERNAL.COM> <51780A17.8010503@gmail.com> In-Reply-To: <51780A17.8010503@gmail.com> Accept-Language: de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dhcwg] Adoption call for draft-rajtar-dhc-v4configuration-02 - respond by May 8th X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 May 2013 12:28:30 -0000 Nearly missed that. I'm in favor to adopt this I-D as a WG item. If I remember right, there has been a large discussion at last IETF about d= ifferent approaches to provide IPv4 parameters over IPv6-only capable acces= s networks and my feeling was that - this topic has been of huge interest for the DHCP community and is target= ed to real world scenarios - this I-D provides a good evaluation of the existing mechanisms for DHCP p= rovisioning of IPv4 parameters in IPv6 only networks - there is still some work to do regarding the conclusions and recommendati= ons. What else is needed to become a WG item? Regards=09 Olaf -----Urspr=FCngliche Nachricht----- Von: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] Im Auftrag von = Tomek Mrugalski Gesendet: Mittwoch, 24. April 2013 18:37 An: dhcwg@ietf.org Betreff: [dhcwg] Adoption call for draft-rajtar-dhc-v4configuration-02 - re= spond by May 8th Hi all, This draft is an attempt to summarize the alternatives regarding IPv4 hosts= configuration in IPv6-only network. If adopted, it will eventually documen= t DHC recommendation for the stated problem. Currently there is no conclusi= on stated in the text. The plan is to first see if the WG wants to work on = this issue. If the answer is yes, then we will try to reach a consensus on = what should the recommendation be. That will be done only after this draft = is adopted. As requested by the authors, we are announcing adoption call on draft-rajta= r-dhc-v4configuration-02. This call is being initiated to confirm whether t= here is WG consensus to adopt this work as DHC WG draft. Please state wheth= er or not you're in favour of the adoption by replying to this mail. If you= are not in favour, please also state your objections in your response. Thi= s adoption call will conclude after 2013-05-08. This adoption call is about whether we as a working group want to work on t= his problem and ultimately make a recommendation. It is not about picking s= pecific technology for IPv4 hosts configuration in IPv6 networks at that ti= me. Background info: This issue was extensively discussed during Orlando meeting. Couple useful = things came out of it: DHCPv4-over-DHCPv6 draft that documents what looked = like a consensus in the meeting room (adopted couple days ago), a new draft= that documents relay behaviour when receiving unknown messages (also adopt= ed recently), and draft-rajtar-dhc-v4configuration received an update to re= flect the latest developments. This draft went through an adoption call couple months ago, but it then had= a conclusion that pointed out toward a solution that was undefined at that= time. The (somewhat premature) conclusion was promptly removed, but it was= too late to stop a heated discussion. Regards, Bernie & Tomek _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From tomasz.mrugalski@gmail.com Mon May 6 06:36:18 2013 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 7E2E221F8F26 for ; Mon, 6 May 2013 06:36:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FsUq75zazn08 for ; Mon, 6 May 2013 06:36:17 -0700 (PDT) Received: from mail-ea0-x22d.google.com (mail-ea0-x22d.google.com [IPv6:2a00:1450:4013:c01::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 0972621F8EF2 for ; Mon, 6 May 2013 06:36:11 -0700 (PDT) Received: by mail-ea0-f173.google.com with SMTP id d10so1700637eaj.18 for ; Mon, 06 May 2013 06:36:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:cc :subject:references:in-reply-to:x-tagtoolbar-keys:content-type :content-transfer-encoding; bh=jMHw5Nj1FftalwXkdYj5jOhLgL415fiNwiLjecjpJ/k=; b=LnCmPSmHXKJYb9oyCvv+OnpLUSdCLMIDXG3+4Rn9UPXqByJz/aKRl9dMnlFoL6BtIv /QKVGqPXoXTHnm+6QzDEXybDYenPwwIJWQswkQxUIZZ2WyBhjXNJDJA2MHjte2Fm8Zah SttOsQIsUWqjUo4vaQ2yRUuwFCaTbvdEoOkS8ths1+qo+52vyvJpuxrmyT+YliwWNt25 7bUABRJQH3e78Y0qAu04Lh9F4E4H7c6f142e/U+XACt7x2+VBPtVCvGc0q+p4MsctPC0 r3bDObswlrNtGYR8Bdt7kwqqscLOoNI1qk1+iIMA1GdlcuvV7HaxVChYWxH8PsZNhq0z 1CZg== X-Received: by 10.14.108.1 with SMTP id p1mr11551163eeg.31.1367847371168; Mon, 06 May 2013 06:36:11 -0700 (PDT) Received: from [10.0.0.100] (host-109-107-11-157.ip.jarsat.pl. [109.107.11.157]) by mx.google.com with ESMTPSA id t9sm20878765eeo.11.2013.05.06.06.36.09 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 06 May 2013 06:36:10 -0700 (PDT) Message-ID: <5187B1C3.3040609@gmail.com> Date: Mon, 06 May 2013 15:36:03 +0200 From: Tomek Mrugalski User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130329 Thunderbird/17.0.5 MIME-Version: 1.0 To: Olaf.Bonness@telekom.de References: <8A1B81989BCFAE44A22B2B86BF2B7631898DB0232B@HE111643.EMEA1.CDS.T-INTERNAL.COM> <51780A17.8010503@gmail.com> In-Reply-To: X-TagToolbar-Keys: D20130506153603655 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: dhcwg@ietf.org Subject: Re: [dhcwg] Adoption call for draft-rajtar-dhc-v4configuration-02 - respond by May 8th X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 May 2013 13:36:18 -0000 On 06.05.2013 14:28, Olaf.Bonness@telekom.de wrote: > Nearly missed that. I'm in favor to adopt this I-D as a WG item. > > If I remember right, there has been a large discussion at last IETF about different approaches to provide IPv4 parameters over IPv6-only capable access networks and my feeling was that > - this topic has been of huge interest for the DHCP community and is targeted to real world scenarios > - this I-D provides a good evaluation of the existing mechanisms for DHCP provisioning of IPv4 parameters in IPv6 only networks > - there is still some work to do regarding the conclusions and recommendations. > What else is needed to become a WG item? Support from members of the WG as a response to the adoption call. So far we have only a single support voice - yours (+ mine, see below). Please keep in mind that while you may have raised your support for this work before (during previous discussions on perhaps in WG meeting), you need to explicitly state in adoption call. I'm supporting adoption of this I-D as a WG item. Ok, so there are 2 in favor now. That's still not enough. Tomek p.s. This adoption call was announced on April 24th and was planned to last 2 weeks (until May 8th). This time has already passed. Olaf (and myself) are the only support voices so far. That is not nearly enough to have this work adopted. If you want this work to be adopted, please say so! A simple "I favor adoption" is sufficient. If you don't support adoption, please also say so and explain your objections. From Ted.Lemon@nominum.com Mon May 6 06:51:50 2013 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 2FE1621F8972 for ; Mon, 6 May 2013 06:51:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4-MIBktAOV9S for ; Mon, 6 May 2013 06:51:43 -0700 (PDT) Received: from exprod7og104.obsmtp.com (exprod7og104.obsmtp.com [64.18.2.161]) by ietfa.amsl.com (Postfix) with ESMTP id BADFF21F905B for ; Mon, 6 May 2013 06:51:32 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob104.postini.com ([64.18.6.12]) with SMTP ID DSNKUYe1ZHq2Ir6N1Lh+assRAGZ8l/bfH02L@postini.com; Mon, 06 May 2013 06:51:32 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 31E701B813D for ; Mon, 6 May 2013 06:51:32 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 278EA190060; Mon, 6 May 2013 06:51:32 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.02.0318.004; Mon, 6 May 2013 06:51:32 -0700 From: Ted Lemon To: Tomek Mrugalski Thread-Topic: [dhcwg] Adoption call for draft-rajtar-dhc-v4configuration-02 - respond by May 8th Thread-Index: AQHOQQn2rWT+B356mkCxPv7PZBKlsZj4naaAgAAS7ICAAARQgA== Date: Mon, 6 May 2013 13:51:31 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B630775172496@mbx-01.win.nominum.com> References: <8A1B81989BCFAE44A22B2B86BF2B7631898DB0232B@HE111643.EMEA1.CDS.T-INTERNAL.COM> <51780A17.8010503@gmail.com> <5187B1C3.3040609@gmail.com> In-Reply-To: <5187B1C3.3040609@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="us-ascii" Content-ID: <913E319CC6CA794EAAC2D07BBBEC8FA2@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [dhcwg] Adoption call for draft-rajtar-dhc-v4configuration-02 - respond by May 8th X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 May 2013 13:51:50 -0000 On May 6, 2013, at 2:36 PM, Tomek Mrugalski wr= ote: > Ok, so there are 2 in favor now. That's still not enough. AD hat off, I support this document. From ian.farrer@telekom.de Mon May 6 07:01:42 2013 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 8361D21F85A2 for ; Mon, 6 May 2013 07:01:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CWeO459664pX for ; Mon, 6 May 2013 07:01:38 -0700 (PDT) Received: from tcmail33.telekom.de (tcmail33.telekom.de [80.149.113.247]) by ietfa.amsl.com (Postfix) with ESMTP id 2890821F9173 for ; Mon, 6 May 2013 07:01:37 -0700 (PDT) Received: from he113675.emea1.cds.t-internal.com ([10.134.99.28]) by tcmail31.telekom.de with ESMTP/TLS/AES128-SHA; 06 May 2013 16:01:22 +0200 Received: from HE111643.EMEA1.CDS.T-INTERNAL.COM ([10.134.93.12]) by HE113675.emea1.cds.t-internal.com ([::1]) with mapi; Mon, 6 May 2013 16:01:22 +0200 From: To: , Date: Mon, 6 May 2013 16:01:22 +0200 Thread-Topic: [dhcwg] Adoption call for draft-rajtar-dhc-v4configuration-02 - respond by May 8th Thread-Index: Ac5KYjBlmx8hLJJkQ6KtE2JUTKsjqQ== Message-ID: In-Reply-To: Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.2.130206 acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dhcwg] Adoption call for draft-rajtar-dhc-v4configuration-02 - respond by May 8th X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 May 2013 14:01:42 -0000 +1 support. Ian On 06/05/2013 14:28, "Bonne=DF, Olaf" wrote: >Nearly missed that. I'm in favor to adopt this I-D as a WG item. > >If I remember right, there has been a large discussion at last IETF about >different approaches to provide IPv4 parameters over IPv6-only capable >access networks and my feeling was that >- this topic has been of huge interest for the DHCP community and is >targeted to real world scenarios >- this I-D provides a good evaluation of the existing mechanisms for DHCP >provisioning of IPv4 parameters in IPv6 only networks >- there is still some work to do regarding the conclusions and >recommendations. >What else is needed to become a WG item? > >Regards=09 > Olaf > >-----Urspr=FCngliche Nachricht----- >Von: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] Im Auftrag >von Tomek Mrugalski >Gesendet: Mittwoch, 24. April 2013 18:37 >An: dhcwg@ietf.org >Betreff: [dhcwg] Adoption call for draft-rajtar-dhc-v4configuration-02 - >respond by May 8th > >Hi all, > >This draft is an attempt to summarize the alternatives regarding IPv4 >hosts configuration in IPv6-only network. If adopted, it will eventually >document DHC recommendation for the stated problem. Currently there is no >conclusion stated in the text. The plan is to first see if the WG wants >to work on this issue. If the answer is yes, then we will try to reach a >consensus on what should the recommendation be. That will be done only >after this draft is adopted. > >As requested by the authors, we are announcing adoption call on >draft-rajtar-dhc-v4configuration-02. This call is being initiated to >confirm whether there is WG consensus to adopt this work as DHC WG draft. >Please state whether or not you're in favour of the adoption by replying >to this mail. If you are not in favour, please also state your objections >in your response. This adoption call will conclude after 2013-05-08. > >This adoption call is about whether we as a working group want to work on >this problem and ultimately make a recommendation. It is not about >picking specific technology for IPv4 hosts configuration in IPv6 networks >at that time. > >Background info: > >This issue was extensively discussed during Orlando meeting. Couple >useful things came out of it: DHCPv4-over-DHCPv6 draft that documents >what looked like a consensus in the meeting room (adopted couple days >ago), a new draft that documents relay behaviour when receiving unknown >messages (also adopted recently), and draft-rajtar-dhc-v4configuration >received an update to reflect the latest developments. > >This draft went through an adoption call couple months ago, but it then >had a conclusion that pointed out toward a solution that was undefined at >that time. The (somewhat premature) conclusion was promptly removed, but >it was too late to stop a heated discussion. > >Regards, >Bernie & Tomek >_______________________________________________ >dhcwg mailing list >dhcwg@ietf.org >https://www.ietf.org/mailman/listinfo/dhcwg >_______________________________________________ >dhcwg mailing list >dhcwg@ietf.org >https://www.ietf.org/mailman/listinfo/dhcwg From bingxuere@gmail.com Mon May 6 07:04:24 2013 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 AF3EE21F9154 for ; Mon, 6 May 2013 07:04:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.203 X-Spam-Level: X-Spam-Status: No, score=-1.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U2voB5CH0uzL for ; Mon, 6 May 2013 07:04:20 -0700 (PDT) Received: from mail-pd0-f182.google.com (mail-pd0-f182.google.com [209.85.192.182]) by ietfa.amsl.com (Postfix) with ESMTP id 96EC421F91F1 for ; Mon, 6 May 2013 07:04:16 -0700 (PDT) Received: by mail-pd0-f182.google.com with SMTP id 3so2027010pdj.27 for ; Mon, 06 May 2013 07:04:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:x-mailer:from:subject:date :to; bh=o6aSyjfQt6J6ud0PF5NhcWVMDLmxGpfsrkN1+etVw4g=; b=e0dWACZ+qqbEVPpbCPkx0KPi3jbqoac+d6WLySgQnitk0CA3PZuX6zE0BRp2AjOi7J GLq23jU1BAFGQkcmMFMnTpkla7YnePxehFAu0zitxtOuZlljAHlRqsNh1/VRSBobeej7 YxchdjE/Czd2F+abA1C2YmJE7iwG0/cAqURPtuGT7gAqunwJBnIIm4pLZDBnFUXuXZyS Ugrb+LVVVsBemoU/Rno2WHCj35h/koF4XUmkMHnQPbiazVRmW0mDbkuFjp4Q0AgtTP1u SUuzuEqu0xQ61zavu1Hfbj4l/SDnE/jMiHKWdEJ3Pp98PCOANyZEbCqFJ4Iiu1F7w8PN ogCQ== X-Received: by 10.66.144.5 with SMTP id si5mr27078860pab.6.1367849056317; Mon, 06 May 2013 07:04:16 -0700 (PDT) Received: from [172.27.77.193] ([114.247.10.74]) by mx.google.com with ESMTPSA id pa2sm25931795pac.9.2013.05.06.07.04.14 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 06 May 2013 07:04:15 -0700 (PDT) References: Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: X-Mailer: iPad Mail (10A8500) From: "bingxuere@gmail.com" Date: Mon, 6 May 2013 22:04:09 +0800 To: "" Cc: "" Subject: Re: [dhcwg] Adoption call for draft-rajtar-dhc-v4configuration-02 - respond by May 8th X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 May 2013 14:04:24 -0000 I also support this adoption. Qiong Sent from my iPad On 2013-5-6, at 22:01, wrote: > +1 support. >=20 > Ian >=20 >=20 >=20 >=20 >=20 > On 06/05/2013 14:28, "Bonne=C3=9F, Olaf" wrote: >=20 >> Nearly missed that. I'm in favor to adopt this I-D as a WG item. >>=20 >> If I remember right, there has been a large discussion at last IETF about= >> different approaches to provide IPv4 parameters over IPv6-only capable >> access networks and my feeling was that >> - this topic has been of huge interest for the DHCP community and is >> targeted to real world scenarios >> - this I-D provides a good evaluation of the existing mechanisms for DHCP= >> provisioning of IPv4 parameters in IPv6 only networks >> - there is still some work to do regarding the conclusions and >> recommendations. >> What else is needed to become a WG item? >>=20 >> Regards =20 >> Olaf >>=20 >> -----Urspr=C3=BCngliche Nachricht----- >> Von: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] Im Auftrag >> von Tomek Mrugalski >> Gesendet: Mittwoch, 24. April 2013 18:37 >> An: dhcwg@ietf.org >> Betreff: [dhcwg] Adoption call for draft-rajtar-dhc-v4configuration-02 - >> respond by May 8th >>=20 >> Hi all, >>=20 >> This draft is an attempt to summarize the alternatives regarding IPv4 >> hosts configuration in IPv6-only network. If adopted, it will eventually >> document DHC recommendation for the stated problem. Currently there is no= >> conclusion stated in the text. The plan is to first see if the WG wants >> to work on this issue. If the answer is yes, then we will try to reach a >> consensus on what should the recommendation be. That will be done only >> after this draft is adopted. >>=20 >> As requested by the authors, we are announcing adoption call on >> draft-rajtar-dhc-v4configuration-02. This call is being initiated to >> confirm whether there is WG consensus to adopt this work as DHC WG draft.= >> Please state whether or not you're in favour of the adoption by replying >> to this mail. If you are not in favour, please also state your objections= >> in your response. This adoption call will conclude after 2013-05-08. >>=20 >> This adoption call is about whether we as a working group want to work on= >> this problem and ultimately make a recommendation. It is not about >> picking specific technology for IPv4 hosts configuration in IPv6 networks= >> at that time. >>=20 >> Background info: >>=20 >> This issue was extensively discussed during Orlando meeting. Couple >> useful things came out of it: DHCPv4-over-DHCPv6 draft that documents >> what looked like a consensus in the meeting room (adopted couple days >> ago), a new draft that documents relay behaviour when receiving unknown >> messages (also adopted recently), and draft-rajtar-dhc-v4configuration >> received an update to reflect the latest developments. >>=20 >> This draft went through an adoption call couple months ago, but it then >> had a conclusion that pointed out toward a solution that was undefined at= >> that time. The (somewhat premature) conclusion was promptly removed, but >> it was too late to stop a heated discussion. >>=20 >> Regards, >> Bernie & Tomek >> _______________________________________________ >> 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 >=20 > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg From sunqi.thu@gmail.com Mon May 6 07:02:45 2013 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 89C9221F90FC for ; Mon, 6 May 2013 07:02:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZLm8+tG49pTT for ; Mon, 6 May 2013 07:02:40 -0700 (PDT) Received: from mail-pd0-f171.google.com (mail-pd0-f171.google.com [209.85.192.171]) by ietfa.amsl.com (Postfix) with ESMTP id DA40721F8EB2 for ; Mon, 6 May 2013 07:02:40 -0700 (PDT) Received: by mail-pd0-f171.google.com with SMTP id r11so2036371pdi.2 for ; Mon, 06 May 2013 07:02:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:subject:mime-version:content-type:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer; bh=TtHabdXpvJMNSESAQw+URHq76Lh8UkrEVqZhvNrLm5c=; b=gITiRj+/9kA8+pJqRYxwz8ggoR1Tmk0PUBkV8RU0Pvbh6sxRYzTqDhB1bAs6rvxp4R SMkUTkyFw9dPRg6HsddPsb2FvWc5aHP5N/xXsGl7Juv1AwbIW8BO8IB04wtHnFLCin9u 7+g6urzyrXjyRZYaXCgy1j9QPo6GtBHDraJuDuZ+4qTfQOjRvXt+hcmPhGhDmITZT4Lo Ng5CwLvP42nYA1Ux+7eSF3ggUBKtbpW6q/BxTZA2UxgJf1PBacdqS8XXo78smIhGGtf7 tm9gP+CtL59j3xEJsU+/KVaBfFAZ9n5anpsDfRiGsoMr+ZXVGTlwoeWPM5dkpyD82EsR 8m1w== X-Received: by 10.68.200.10 with SMTP id jo10mr26131948pbc.53.1367848960642; Mon, 06 May 2013 07:02:40 -0700 (PDT) Received: from [192.168.1.170] ([166.111.68.233]) by mx.google.com with ESMTPSA id em2sm24059971pbb.0.2013.05.06.07.02.37 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 06 May 2013 07:02:39 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=utf-8 From: Qi Sun In-Reply-To: <51780A17.8010503@gmail.com> Date: Mon, 6 May 2013 22:02:33 +0800 Content-Transfer-Encoding: quoted-printable Message-Id: <1E23D786-4A55-47D4-B0F5-716AA5254687@gmail.com> References: <8A1B81989BCFAE44A22B2B86BF2B7631898DB0232B@HE111643.EMEA1.CDS.T-INTERNAL.COM> <51780A17.8010503@gmail.com> To: Tomek Mrugalski X-Mailer: Apple Mail (2.1084) X-Mailman-Approved-At: Mon, 06 May 2013 07:12:58 -0700 Cc: dhcwg@ietf.org Subject: Re: [dhcwg] Adoption call for draft-rajtar-dhc-v4configuration-02 - respond by May 8th X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 May 2013 14:02:45 -0000 Dear all, I support the adoption of the document. Best Regards, Qi On 2013-4-25, at =E4=B8=8A=E5=8D=8812:36, Tomek Mrugalski wrote: > Hi all, >=20 > This draft is an attempt to summarize the alternatives regarding IPv4 > hosts configuration in IPv6-only network. If adopted, it will = eventually > document DHC recommendation for the stated problem. Currently there is > no conclusion stated in the text. The plan is to first see if the WG > wants to work on this issue. If the answer is yes, then we will try to > reach a consensus on what should the recommendation be. That will be > done only after this draft is adopted. >=20 > As requested by the authors, we are announcing adoption call on > draft-rajtar-dhc-v4configuration-02. This call is being initiated to > confirm whether there is WG consensus to adopt this work as DHC WG > draft. Please state whether or not you're in favour of the adoption by > replying to this mail. If you are not in favour, please also state = your > objections in your response. This adoption call will conclude after > 2013-05-08. >=20 > This adoption call is about whether we as a working group want to work > on this problem and ultimately make a recommendation. It is not about > picking specific technology for IPv4 hosts configuration in IPv6 > networks at that time. >=20 > Background info: >=20 > This issue was extensively discussed during Orlando meeting. Couple > useful things came out of it: DHCPv4-over-DHCPv6 draft that documents > what looked like a consensus in the meeting room (adopted couple days > ago), a new draft that documents relay behaviour when receiving = unknown > messages (also adopted recently), and draft-rajtar-dhc-v4configuration > received an update to reflect the latest developments. >=20 > This draft went through an adoption call couple months ago, but it = then > had a conclusion that pointed out toward a solution that was undefined > at that time. The (somewhat premature) conclusion was promptly = removed, > but it was too late to stop a heated discussion. >=20 > Regards, > Bernie & Tomek >=20 > On 23.04.2013 23:23, ian.farrer@telekom.de wrote: >> Just in case you missed it, a new version of >> draft-rajtar-dhc-v4configuration (02) was recently posted. >>=20 >> As this version incorporates the new DCHPv4 over DHCPv6 model = described >> in the recently adopted draft-scskf-dhcpv4-over-dhcpv6 and other = changes >> based on the discussions in Orlando, the authors would like request = that >> the WG chairs make a call for adoption based. >>=20 >> Cheers, >> Ian >>=20 >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> 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 From kkinnear@cisco.com Mon May 6 07:19:24 2013 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 72C5E21F9311 for ; Mon, 6 May 2013 07:19:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LgVKbr4opGu4 for ; Mon, 6 May 2013 07:19:19 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 6659021F91A5 for ; Mon, 6 May 2013 07:19:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2882; q=dns/txt; s=iport; t=1367849959; x=1369059559; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=VsCSdljGVFBeyiFSrE/ZM+F23QBkFWNVzXBHX1nfzA4=; b=H4BrCSTZr/g7keeIqfgRawLciCsXryphtZ4/i/8JX06WcuzL1rJBbIVy S3axZux6yL6UOGtudcHGJneRDJZ1EVtkINbZ0PVFO2fsWlLvHD80kta56 /3MUsP1364OQz/p29m2kvIPKl9ae/nnGYPGj9rPbnEFZ0ndoMCorXwbeD A=; X-IronPort-AV: E=Sophos;i="4.87,622,1363132800"; d="scan'208";a="206914499" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-5.cisco.com with ESMTP; 06 May 2013 14:19:14 +0000 Received: from [161.44.65.111] ([161.44.65.111]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id r46EJDLi000502; Mon, 6 May 2013 14:19:13 GMT Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Kim Kinnear In-Reply-To: <51780A17.8010503@gmail.com> Date: Mon, 6 May 2013 10:19:13 -0400 Content-Transfer-Encoding: 7bit Message-Id: <719431C3-614D-4407-9FA5-20A5EFFA0579@cisco.com> References: <8A1B81989BCFAE44A22B2B86BF2B7631898DB0232B@HE111643.EMEA1.CDS.T-INTERNAL.COM> <51780A17.8010503@gmail.com> To: Tomek Mrugalski X-Mailer: Apple Mail (2.1278) Cc: dhcwg@ietf.org, Kim Kinnear Subject: Re: [dhcwg] Adoption call for draft-rajtar-dhc-v4configuration-02 - respond by May 8th X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 May 2013 14:19:24 -0000 I am in favor of adopting this draft as a work item. Regards -- Kim On Apr 24, 2013, at 12:36 PM, Tomek Mrugalski wrote: > Hi all, > > This draft is an attempt to summarize the alternatives regarding IPv4 > hosts configuration in IPv6-only network. If adopted, it will eventually > document DHC recommendation for the stated problem. Currently there is > no conclusion stated in the text. The plan is to first see if the WG > wants to work on this issue. If the answer is yes, then we will try to > reach a consensus on what should the recommendation be. That will be > done only after this draft is adopted. > > As requested by the authors, we are announcing adoption call on > draft-rajtar-dhc-v4configuration-02. This call is being initiated to > confirm whether there is WG consensus to adopt this work as DHC WG > draft. Please state whether or not you're in favour of the adoption by > replying to this mail. If you are not in favour, please also state your > objections in your response. This adoption call will conclude after > 2013-05-08. > > This adoption call is about whether we as a working group want to work > on this problem and ultimately make a recommendation. It is not about > picking specific technology for IPv4 hosts configuration in IPv6 > networks at that time. > > Background info: > > This issue was extensively discussed during Orlando meeting. Couple > useful things came out of it: DHCPv4-over-DHCPv6 draft that documents > what looked like a consensus in the meeting room (adopted couple days > ago), a new draft that documents relay behaviour when receiving unknown > messages (also adopted recently), and draft-rajtar-dhc-v4configuration > received an update to reflect the latest developments. > > This draft went through an adoption call couple months ago, but it then > had a conclusion that pointed out toward a solution that was undefined > at that time. The (somewhat premature) conclusion was promptly removed, > but it was too late to stop a heated discussion. > > Regards, > Bernie & Tomek > > On 23.04.2013 23:23, ian.farrer@telekom.de wrote: >> Just in case you missed it, a new version of >> draft-rajtar-dhc-v4configuration (02) was recently posted. >> >> As this version incorporates the new DCHPv4 over DHCPv6 model described >> in the recently adopted draft-scskf-dhcpv4-over-dhcpv6 and other changes >> based on the discussions in Orlando, the authors would like request that >> the WG chairs make a call for adoption based. >> >> Cheers, >> Ian >> >> >> >> >> >> _______________________________________________ >> dhcwg mailing list >> dhcwg@ietf.org >> https://www.ietf.org/mailman/listinfo/dhcwg >> > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg From Branimir.Rajtar@t.ht.hr Mon May 6 07:21:35 2013 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 8ECDB21F936C for ; Mon, 6 May 2013 07:21:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rt83gKuGSxth for ; Mon, 6 May 2013 07:21:30 -0700 (PDT) Received: from mx02.t.ht.hr (mx02.t.ht.hr [195.29.161.89]) by ietfa.amsl.com (Postfix) with SMTP id D20F921F920B for ; Mon, 6 May 2013 07:21:28 -0700 (PDT) Received: from no.name.available by mx02.t.ht.hr via smtpd (for mail.ietf.org [12.22.58.30]) with ESMTP; Mon, 6 May 2013 15:49:20 +0200 Received: from (unknown [172.17.66.76]) by scmg2.t.ht.hr with smtp id 0973_d82c_3d0638b4_b658_11e2_8ad5_00219b931f47; Mon, 06 May 2013 16:21:26 +0200 Received: (private information removed) Mon, 6 May 2013 16:21:27 +0200 Received: (private information removed) S2010EXCHCA2.ad.local ([::1]) with mapi id 14.03.0123.003; Mon, 6 May 2013 16:21:26 +0200 From: Branimir Rajtar To: Tomek Mrugalski Thread-Topic: [dhcwg] Adoption call for draft-rajtar-dhc-v4configuration-02 - respond by May 8th Thread-Index: AQHOSmSumorn/s8Z5U+XrcOSHGGGiZj4NQPA Date: Mon, 6 May 2013 14:21:26 +0000 Message-ID: <786F13AA11E69F4DB2CCA23F7400C2FB0142B1F9@S2010EXCH1.ad.local> References: <8A1B81989BCFAE44A22B2B86BF2B7631898DB0232B@HE111643.EMEA1.CDS.T-INTERNAL.COM> <51780A17.8010503@gmail.com> <719431C3-614D-4407-9FA5-20A5EFFA0579@cisco.com> In-Reply-To: <719431C3-614D-4407-9FA5-20A5EFFA0579@cisco.com> Accept-Language: en-US, hr-HR Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.17.5.13] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginalArrivalTime: 06 May 2013 14:21:27.0212 (UTC) FILETIME=[FEC966C0:01CE4A64] X-NAIMIME-Disclaimer: 1 X-NAIMIME-Modified: 1 Cc: "dhcwg@ietf.org" Subject: Re: [dhcwg] Adoption call for draft-rajtar-dhc-v4configuration-02 - respond by May 8th X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 May 2013 14:21:35 -0000 SSBhbHNvIHN1cHBvcnQgdGhlIGRvY3VtZW50LgoKQnJhbmltaXIKCgpPbiBBcHIgMjQsIDIwMTMs IGF0IDEyOjM2IFBNLCBUb21layBNcnVnYWxza2kgd3JvdGU6Cgo+IEhpIGFsbCwKPiAKPiBUaGlz IGRyYWZ0IGlzIGFuIGF0dGVtcHQgdG8gc3VtbWFyaXplIHRoZSBhbHRlcm5hdGl2ZXMgcmVnYXJk aW5nIElQdjQKPiBob3N0cyBjb25maWd1cmF0aW9uIGluIElQdjYtb25seSBuZXR3b3JrLiBJZiBh ZG9wdGVkLCBpdCB3aWxsIGV2ZW50dWFsbHkKPiBkb2N1bWVudCBESEMgcmVjb21tZW5kYXRpb24g Zm9yIHRoZSBzdGF0ZWQgcHJvYmxlbS4gQ3VycmVudGx5IHRoZXJlIGlzCj4gbm8gY29uY2x1c2lv biBzdGF0ZWQgaW4gdGhlIHRleHQuIFRoZSBwbGFuIGlzIHRvIGZpcnN0IHNlZSBpZiB0aGUgV0cK PiB3YW50cyB0byB3b3JrIG9uIHRoaXMgaXNzdWUuIElmIHRoZSBhbnN3ZXIgaXMgeWVzLCB0aGVu IHdlIHdpbGwgdHJ5IHRvCj4gcmVhY2ggYSBjb25zZW5zdXMgb24gd2hhdCBzaG91bGQgdGhlIHJl Y29tbWVuZGF0aW9uIGJlLiBUaGF0IHdpbGwgYmUKPiBkb25lIG9ubHkgYWZ0ZXIgdGhpcyBkcmFm dCBpcyBhZG9wdGVkLgo+IAo+IEFzIHJlcXVlc3RlZCBieSB0aGUgYXV0aG9ycywgd2UgYXJlIGFu bm91bmNpbmcgYWRvcHRpb24gY2FsbCBvbgo+IGRyYWZ0LXJhanRhci1kaGMtdjRjb25maWd1cmF0 aW9uLTAyLiBUaGlzIGNhbGwgaXMgYmVpbmcgaW5pdGlhdGVkIHRvCj4gY29uZmlybSB3aGV0aGVy IHRoZXJlIGlzIFdHIGNvbnNlbnN1cyB0byBhZG9wdCB0aGlzIHdvcmsgYXMgREhDIFdHCj4gZHJh ZnQuIFBsZWFzZSBzdGF0ZSB3aGV0aGVyIG9yIG5vdCB5b3UncmUgaW4gZmF2b3VyIG9mIHRoZSBh ZG9wdGlvbiBieQo+IHJlcGx5aW5nIHRvIHRoaXMgbWFpbC4gSWYgeW91IGFyZSBub3QgaW4gZmF2 b3VyLCBwbGVhc2UgYWxzbyBzdGF0ZSB5b3VyCj4gb2JqZWN0aW9ucyBpbiB5b3VyIHJlc3BvbnNl LiBUaGlzIGFkb3B0aW9uIGNhbGwgd2lsbCBjb25jbHVkZSBhZnRlcgo+IDIwMTMtMDUtMDguCj4g Cj4gVGhpcyBhZG9wdGlvbiBjYWxsIGlzIGFib3V0IHdoZXRoZXIgd2UgYXMgYSB3b3JraW5nIGdy b3VwIHdhbnQgdG8gd29yawo+IG9uIHRoaXMgcHJvYmxlbSBhbmQgdWx0aW1hdGVseSBtYWtlIGEg cmVjb21tZW5kYXRpb24uIEl0IGlzIG5vdCBhYm91dAo+IHBpY2tpbmcgc3BlY2lmaWMgdGVjaG5v bG9neSBmb3IgSVB2NCBob3N0cyBjb25maWd1cmF0aW9uIGluIElQdjYKPiBuZXR3b3JrcyBhdCB0 aGF0IHRpbWUuCj4gCj4gQmFja2dyb3VuZCBpbmZvOgo+IAo+IFRoaXMgaXNzdWUgd2FzIGV4dGVu c2l2ZWx5IGRpc2N1c3NlZCBkdXJpbmcgT3JsYW5kbyBtZWV0aW5nLiBDb3VwbGUKPiB1c2VmdWwg dGhpbmdzIGNhbWUgb3V0IG9mIGl0OiBESENQdjQtb3Zlci1ESENQdjYgZHJhZnQgdGhhdCBkb2N1 bWVudHMKPiB3aGF0IGxvb2tlZCBsaWtlIGEgY29uc2Vuc3VzIGluIHRoZSBtZWV0aW5nIHJvb20g KGFkb3B0ZWQgY291cGxlIGRheXMKPiBhZ28pLCBhIG5ldyBkcmFmdCB0aGF0IGRvY3VtZW50cyBy ZWxheSBiZWhhdmlvdXIgd2hlbiByZWNlaXZpbmcgdW5rbm93bgo+IG1lc3NhZ2VzIChhbHNvIGFk b3B0ZWQgcmVjZW50bHkpLCBhbmQgZHJhZnQtcmFqdGFyLWRoYy12NGNvbmZpZ3VyYXRpb24KPiBy ZWNlaXZlZCBhbiB1cGRhdGUgdG8gcmVmbGVjdCB0aGUgbGF0ZXN0IGRldmVsb3BtZW50cy4KPiAK PiBUaGlzIGRyYWZ0IHdlbnQgdGhyb3VnaCBhbiBhZG9wdGlvbiBjYWxsIGNvdXBsZSBtb250aHMg YWdvLCBidXQgaXQgdGhlbgo+IGhhZCBhIGNvbmNsdXNpb24gdGhhdCBwb2ludGVkIG91dCB0b3dh cmQgYSBzb2x1dGlvbiB0aGF0IHdhcyB1bmRlZmluZWQKPiBhdCB0aGF0IHRpbWUuIFRoZSAoc29t ZXdoYXQgcHJlbWF0dXJlKSBjb25jbHVzaW9uIHdhcyBwcm9tcHRseSByZW1vdmVkLAo+IGJ1dCBp dCB3YXMgdG9vIGxhdGUgdG8gc3RvcCBhIGhlYXRlZCBkaXNjdXNzaW9uLgo+IAo+IFJlZ2FyZHMs Cj4gQmVybmllICYgVG9tZWsKPiAKPiBPbiAyMy4wNC4yMDEzIDIzOjIzLCBpYW4uZmFycmVyQHRl bGVrb20uZGUgd3JvdGU6Cj4+IEp1c3QgaW4gY2FzZSB5b3UgbWlzc2VkIGl0LCBhIG5ldyB2ZXJz aW9uIG9mCj4+IGRyYWZ0LXJhanRhci1kaGMtdjRjb25maWd1cmF0aW9uICgwMikgd2FzIHJlY2Vu dGx5IHBvc3RlZC4KPj4gCj4+IEFzIHRoaXMgdmVyc2lvbiBpbmNvcnBvcmF0ZXMgdGhlIG5ldyBE Q0hQdjQgb3ZlciBESENQdjYgbW9kZWwgZGVzY3JpYmVkCj4+IGluIHRoZSByZWNlbnRseSBhZG9w dGVkIGRyYWZ0LXNjc2tmLWRoY3B2NC1vdmVyLWRoY3B2NiBhbmQgb3RoZXIgY2hhbmdlcwo+PiBi YXNlZCBvbiB0aGUgZGlzY3Vzc2lvbnMgaW4gT3JsYW5kbywgdGhlIGF1dGhvcnMgd291bGQgbGlr ZSByZXF1ZXN0IHRoYXQKPj4gdGhlIFdHIGNoYWlycyBtYWtlIGEgY2FsbCBmb3IgYWRvcHRpb24g YmFzZWQuCj4+IAo+PiBDaGVlcnMsCj4+IElhbgo+PiAKPj4gCj4+IAo+PiAKPj4gCj4+IF9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCj4+IGRoY3dnIG1haWxp bmcgbGlzdAo+PiBkaGN3Z0BpZXRmLm9yZwo+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL2RoY3dnCj4+IAo+IAo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fCj4gZGhjd2cgbWFpbGluZyBsaXN0Cj4gZGhjd2dAaWV0Zi5vcmcKPiBo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RoY3dnCgpfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpkaGN3ZyBtYWlsaW5nIGxpc3QKZGhj d2dAaWV0Zi5vcmcKaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kaGN3ZwoK CjxIVE1MPjxQPjxGT05UIGZhY2U9QXJpYWwgY29sb3I9Izk5OTk5OSBzaXplPTE+DQoNCklaSkFW QSBPIE9EUklDQU5KVSBPREdPVk9STk9TVEk6IFNhZHLFvmFqIG92ZSBwb3J1a2UgaSBldmVudHVh bG5vIHByaWxvxb5lbmloIGRhdG90ZWthIGplIHBvdmplcmxqaXYgaSBuYW1pamVuamVuIGplIHNh bW8gb3NvYmFtYSBpbGkgc3ViamVrdGltYSBrb2ppIHN1IG5hdmVkZW5pIHUgYWRyZXNpLiBVa29s aWtvIHN0ZSBwcmltaWxpIG92dSBwb3J1a3UgZ3JlxaFrb20sIG1vbGltbyBWYXMsIG9iYXZpamVz dGl0ZSBwb8WhaWxqYXRlbGphLCBhIHBvcnVrdSBpIHN2ZSBuamVuZSBwcml2aXRrZSBvZG1haCwg YmV6IMSNaXRhbmphLCB0cmFqbm8gdWtsb25pdGUgcyByYcSNdW5hbGEuIEJpbG8ga2Frdm8gcHJl bm/FoWVuamUsIGtvcGlyYW5qZSBpbGkgZGlzdHJpYnVjaWphIGluZm9ybWFjaWphIHNhZHLFvmFu aWggdSBwb3J1Y2kgdHJlxIdpbSBvc29iYW1hIGplIHphYnJhbmplbm8gaSBtb8W+ZSBiaXRpIHph a29uc2tpIGthxb5uaml2by4gU2FkcsW+YWosIHN0YXZvdmkgaSBtacWhbGplbmphIGl6bmVzZW5p IHUgcG9ydWNpIHN1IGF1dG9yb3ZpIGkgbmUgcHJlZHN0YXZsamFqdSBudcW+bm8gc3Rhdm92ZSBI VCAtIEhydmF0c2tpaCB0ZWxla29tdW5pa2FjaWphIGQuZC4gSFQgbmUgcHJpaHZhxIdhIG5pa2Fr dnUgb2Rnb3Zvcm5vc3QgemEgZXZlbnR1YWxudSDFoXRldHUgbmFzdGFsdSBwcmltaXRrb20gb3Zl IHBvcnVrZSBpIHByaWxvZ2Egc2FkcsW+YW5paCB1IHBvcnVjaS4NCg0KPC9GT05UPjwvUD48UD48 Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPSM5OTk5OTkgc2l6ZT0xPg0KDQogRElTQ0xBSU1FUjpUaGUg Y29udGVudHMgb2YgdGhpcyBlbWFpbCBhcyB3ZWxsIGFzIGFueSBmaWxlcyBhdHRhY2hlZCB0byBp dCBhcmUgY29uZmlkZW50aWFsIGFuZCBpbnRlbmRlZCBzb2xlbHkgZm9yIGluZGl2aWR1YWxzIG9y IGVudGl0aWVzIHdoaWNoIHRoZXkgYXJlIGFkZHJlc3NlZCB0by4gSWYgeW91IGhhdmUgcmVjZWl2 ZWQgdGhpcyBlbWFpbCBtZXNzYWdlIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIg YW5kIHBlcm1hbmVudGx5IHJlbW92ZSB0aGUgbWVzc2FnZSBhbmQgYWxsIGF0dGFjaGVkIGZpbGVz IGZyb20gdGhlIGNvbXB1dGVyLiBBbnkgZGlzY2xvc3VyZSwgY29weWluZyBvciBkaXN0cmlidXRp b24gb2YgYWxsIG9yIGEgcGFydCBvZiBpbmZvcm1hdGlvbiBjb250YWluZWQgaGVyZWluIHRvIG9y IGJ5IHRoaXJkIHBhcnRpZXMgaXMgcHJvaGliaXRlZCBhbmQgbWF5IGJlIHVubGF3ZnVsLiBQbGVh c2Ugbm90ZSB0aGF0IGFueSB2aWV3cyBvciBvcGluaW9ucyBwcmVzZW50ZWQgaW4gdGhpcyBtZXNz YWdlIGFyZSBzb2xlbHkgdGhvc2Ugb2YgdGhlIGF1dGhvciBhbmQgZG8gbm90IG5lY2Vzc2FyaWx5 IHJlcHJlc2VudCB0aGUgdmlld3MgYW5kIG9waW5pb25zIG9mIENyb2F0aWFuIFRlbGVjb20gSW5j LiBDcm9hdGlhbiBUZWxlY29tIEluYy4gYWNjZXB0cyBubyBsaWFiaWxpdHkgZm9yIGFueSBwb3Rl bnRpYWwgZGFtYWdlIGNhdXNlZCBieSB0aGlzIG1lc3NhZ2UgYW5kIGZpbGVzIGF0dGFjaGVkIHRv IGl0Lg0KDQo8L0ZPTlQ+PC9QPjwvSFRNTD4K From rjsparks@nostrum.com Mon May 6 09:09:47 2013 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 2D2CC21F8FF5; Mon, 6 May 2013 09:09:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NceC5ZgUTWW0; Mon, 6 May 2013 09:09:46 -0700 (PDT) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id D402121F8F12; Mon, 6 May 2013 09:09:45 -0700 (PDT) Received: from unnumerable.local (mobile-166-147-079-070.mycingular.net [166.147.79.70]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r46G9fvr027267 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=OK); Mon, 6 May 2013 11:09:45 -0500 (CDT) (envelope-from rjsparks@nostrum.com) Message-ID: <5187D5C8.5000902@nostrum.com> Date: Mon, 06 May 2013 11:09:44 -0500 From: Robert Sparks User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: mohamed.boucadair@orange.com References: <517AA051.8080506@nostrum.com> <94C682931C08B048B7A8645303FDC9F36ECC240570@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <94C682931C08B048B7A8645303FDC9F36ECC240570@PUEXCB1B.nanterre.francetelecom.fr> Content-Type: multipart/alternative; boundary="------------010407040103010500050401" Received-SPF: pass (shaman.nostrum.com: 166.147.79.70 is authenticated by a trusted mechanism) Cc: "dhcwg@ietf.org" , General Area Review Team , "ietf@ietf.org" , "draft-ietf-dhc-triggered-reconfigure@tools.ietf.org" Subject: Re: [dhcwg] Gen-art review: draft-ietf-dhc-triggered-reconfigure-05 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 May 2013 16:09:47 -0000 This is a multi-part message in MIME format. --------------010407040103010500050401 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Looks good to me. Thanks! RjS On 5/6/13 3:02 AM, mohamed.boucadair@orange.com wrote: > > Dear Robert, > > I updated the document to cover the comments you raised. You can check > the diff available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-dhc-triggered-reconfigure-06 > > Cheers, > > Med > > *De :*dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] *De la > part de* Robert Sparks > *Envoyé :* vendredi 26 avril 2013 17:42 > *À :* dhcwg@ietf.org; ietf@ietf.org; General Area Review Team; > draft-ietf-dhc-triggered-reconfigure@tools.ietf.org > *Objet :* [dhcwg] Gen-art review: draft-ietf-dhc-triggered-reconfigure-05 > > I am the assigned Gen-ART reviewer for this draft. For background on > Gen-ART, please see the FAQ at > > > . > > Please resolve these comments along with any other Last Call comments > you may receive. > > Document: draft-ietf-dhc-triggered-reconfigure-05 > Reviewer: Robert Sparks > Review Date: April 26, 2013 > IETF LC End Date: May 6, 2013 > IESG Telechat date: May 16, 2013 > > Summary: This draft is on the right track but has open issues, > described in > the review. > > Major issues: > > Overall, this document is solid, but I think there is a bug in section > 6.3. > I could be wrong, but If I'm right, this paragraph: > > When retransmission is required, the relay may decide to correct the > content of RECONFIGURE-REQUEST message it issues (e.g., update the > Client Identifier list). This decision is local to the relay (e.g., > it may be based on observed events such as one or more clients were > reconfigured on their own). > > > introduces a race-condition that could lead to an erroneous state. If > a relay's first message included client A, then the retransmission > included clients A and B, but that retransmission crosses with a > success RECONFIGURE-REPLY to the request that only included client A, > the relay will think it succeeded in asking A and B to be reconfigured. > > Minor issues: > > This sentence: > > Furthermore, means to recover state in failure events must be > supported, but are not discussed in this document. > > places a requirement on a relay (even though it's not using a 2119 > MUST). Is there some other document that defines this requirement that > you can reference? If not, the requirement should be discussed in this > document. Alternatively, you could change the sentence to talk about > the consequences of not having a proprietary means for recovering state. > > Nits/editorial comments: > --------------010407040103010500050401 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Looks good to me. Thanks!
RjS

On 5/6/13 3:02 AM, mohamed.boucadair@orange.com wrote:

Dear Robert,

 

I updated the document to cover the comments you raised. You can check the diff available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-dhc-triggered-reconfigure-06

 

Cheers,

Med

 

De : dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] De la part de Robert Sparks
Envoyé : vendredi 26 avril 2013 17:42
À : dhcwg@ietf.org; ietf@ietf.org; General Area Review Team; draft-ietf-dhc-triggered-reconfigure@tools.ietf.org
Objet : [dhcwg] Gen-art review: draft-ietf-dhc-triggered-reconfigure-05

 

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at

<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Please resolve these comments along with any other Last Call comments
you may receive.

Document: draft-ietf-dhc-triggered-reconfigure-05
Reviewer:  Robert Sparks
Review Date: April 26, 2013
IETF LC End Date: May 6, 2013
IESG Telechat date: May 16, 2013

Summary: This draft is on the right track but has open issues, described in
      the review.

Major issues:

Overall, this document is solid, but I think there is a bug in section 6.3.
I could be wrong, but If I'm right, this paragraph:

When retransmission is required, the relay may decide to correct the content of RECONFIGURE-REQUEST message it issues (e.g., update the Client Identifier list).  This decision is local to the relay (e.g., it may be based on observed events such as one or more clients were reconfigured on their own).


introduces a race-condition that could lead to an erroneous state. If a relay's first message included client A, then the retransmission included clients A and B, but that retransmission crosses with a success RECONFIGURE-REPLY to the request that only included client A, the relay will think it succeeded in asking A and B to be reconfigured.

Minor issues:

This sentence:

Furthermore, means to recover state in failure events must be supported, but are not discussed in this document.

places a requirement on a relay (even though it's not using a 2119 MUST). Is there some other document that defines this requirement that you can reference? If not, the requirement should be discussed in this document. Alternatively, you could change the sentence to talk about the consequences of not having a proprietary means for recovering state.

Nits/editorial comments:


--------------010407040103010500050401-- From volz@cisco.com Mon May 6 09:18:21 2013 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 ED85E21F914C for ; Mon, 6 May 2013 09:18:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WE-UqxSbjRb0 for ; Mon, 6 May 2013 09:17:51 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 06A2821F912C for ; Mon, 6 May 2013 09:17:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10944; q=dns/txt; s=iport; t=1367857071; x=1369066671; h=from:to:subject:date:message-id:mime-version; bh=nQMjBvxXO5MTCfb9/Fn8UgptZ6tjPZK15BRuRrdeDBQ=; b=Fld1/LoHZSKfA44oc0KmkuKwE8kr6+M27f0guWNYwV1WfAL1J8+1yGYU JyCGAyn532ijoXHJsvCu1YoYKj05Zzz/W3LxYZfjxNJPrKdlx+tAj/wlk J8vFFGTffsZpgeJSkhqYy2S/dX046cILEQzUZOxnjR58t3ambuH2bjjiG 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjMFALjWh1GtJV2a/2dsb2JhbABQgkNEN7ZMiDCBAhZtB4IfAQEBBB0QPgMdAQgRBAEBCx05FAkJAQQTCIgEDKEinlGNbxCBATeCc2EDmFSQDoMNgXI1 X-IronPort-AV: E=Sophos;i="4.87,622,1363132800"; d="scan'208,217";a="206976613" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-3.cisco.com with ESMTP; 06 May 2013 16:17:12 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r46GHC7g031308 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 6 May 2013 16:17:12 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.77]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.02.0318.004; Mon, 6 May 2013 11:17:11 -0500 From: "Bernie Volz (volz)" To: "dhcwg@ietf.org" Thread-Topic: [dhcwg] WG Adoption Call Result - draft-lemon-dhc-topo-conf Thread-Index: Ac5KdFlCgUtmltw3TiCGG0qL/YU3gA== Date: Mon, 6 May 2013 16:17:11 +0000 Message-ID: <489D13FBFA9B3E41812EA89F188F018E1854F8C4@xmb-rcd-x04.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.242.203] Content-Type: multipart/alternative; boundary="_000_489D13FBFA9B3E41812EA89F188F018E1854F8C4xmbrcdx04ciscoc_" MIME-Version: 1.0 Subject: Re: [dhcwg] WG Adoption Call Result - draft-lemon-dhc-topo-conf X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 May 2013 16:18:21 -0000 --_000_489D13FBFA9B3E41812EA89F188F018E1854F8C4xmbrcdx04ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi: The chairs feel this document has sufficient support to adopt as a Working = Group item. Thus we will adopt this document. - Tomek & Bernie PS: (WG hat off) While I didn't respond during the call period, I support t= his work as mentioned in an email I sent on 4/15 - Bernie. From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of B= ernie Volz (volz) Sent: Wednesday, April 17, 2013 9:48 AM To: dhcwg@ietf.org Subject: [dhcwg] WG Adoption Call - draft-lemon-dhc-topo-conf - Ends May 2,= 2013 Hi all: The author has requested a call for adoption by the WG for draft-lemon-dhc-= topo-conf-01. This call is being initiated to confirm whether there is WG consensus to ad= opt this work as DHC WG draft. Please state whether or not you're in favor = of the adoption by replying to this mail. If you are not in favor, please a= lso state your objections in your response. This adoption call will complet= e on May 2nd, 2013. Note that when Ted first published this draft, he posted the following to t= he DHC WG list: I just submitted a new document to the tracker that attempts to document ex= isting practice with respect to how DHCP options are derived and sent to cl= ients in modern DHCP servers. This is a first draft, and probably needs s= ome new examples. People on this mailing list will, I suspect, find it di= fficult to remain awake while reading it because it is such old hat to us, = but it's been brought to my attention recently that not everybody in the IE= TF is an expert on DHCP server configuration; this document is an attempt t= o provide a short, pithy tutorial for IETF document writers who are interes= ted in understanding how DHCP is used in practice. The HTML version of the document can be viewed at http://tools.ietf.org/htm= l/draft-lemon-dhc-topo-conf Regards, Tomek & Bernie --_000_489D13FBFA9B3E41812EA89F188F018E1854F8C4xmbrcdx04ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi:<= /p>

 

The chairs feel this d= ocument has sufficient support to adopt as a Working Group item. Thus we wi= ll adopt this document.

 

-&nb= sp;         Tomek & Be= rnie

 

PS: (WG hat off) While= I didn’t respond during the call period, I support this work as ment= ioned in an email I sent on 4/15 – Bernie.

 

From: dhcwg-bo= unces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of Bernie Volz (volz)
Sent: Wednesday, April 17, 2013 9:48 AM
To: dhcwg@ietf.org
Subject: [dhcwg] WG Adoption Call - draft-lemon-dhc-topo-conf - Ends= May 2, 2013

 

Hi all:

 

The author has requested a call for adoption by t= he WG for draft-lemon-dhc-topo-conf-01.

 

This call is being initiated to confirm whether t= here is WG consensus to adopt this work as DHC WG draft. Please state wheth= er or not you're in favor of the adoption by replying to this mail. If you = are not in favor, please also state your objections in your response. This adoption call will complete on May = 2nd, 2013.

 

Note that when Ted first published this draft, he= posted the following to the DHC WG list:

 

I just submitted a new= document to the tracker that attempts to document existing practice with r= espect to how DHCP options are derived and sent to clients in modern DHCP s= ervers.   This is a first draft, and probably needs some new examples.   People on this mailing list = will, I suspect, find it difficult to remain awake while reading it because= it is such old hat to us, but it's been brought to my attention recently t= hat not everybody in the IETF is an expert on DHCP server configuration; this document is an attempt to provide a sho= rt, pithy tutorial for IETF document writers who are interested in understa= nding how DHCP is used in practice.

 

The HTML version of the document can be viewed at= http://tools.ietf.org/html/draft-lemon-dhc-topo-conf

 

Regards,

Tomek & Bernie

 

--_000_489D13FBFA9B3E41812EA89F188F018E1854F8C4xmbrcdx04ciscoc_-- From ales.vizdal@t-mobile.cz Mon May 6 14:00:02 2013 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 1AA7221F8FEC for ; Mon, 6 May 2013 14:00:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.649 X-Spam-Level: X-Spam-Status: No, score=0.649 tagged_above=-999 required=5 tests=[HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sZcWX6q21ZRM for ; Mon, 6 May 2013 13:59:58 -0700 (PDT) Received: from rztmailhub.t-mobile.cz (rztmailhub.t-mobile.cz [93.153.104.86]) by ietfa.amsl.com (Postfix) with ESMTP id B7AE321F85DB for ; Mon, 6 May 2013 13:59:56 -0700 (PDT) Received: from srvhk504.rdm.cz (unknown [10.254.92.81]) by rztmailhub.t-mobile.cz (Postfix) with ESMTP id 4E6842E07D2; Mon, 6 May 2013 22:59:42 +0200 (CEST) Received: from SRVHKE02.rdm.cz ([fe80::2cec:9ace:94f2:601a]) by srvhk504.rdm.cz ([::1]) with mapi; Mon, 6 May 2013 22:59:54 +0200 From: =?iso-8859-2?Q?V=EDzdal_Ale=B9?= To: Tomek Mrugalski , "dhcwg@ietf.org" Date: Mon, 6 May 2013 22:59:51 +0200 Thread-Topic: [dhcwg] Adoption call for draft-rajtar-dhc-v4configuration-02 - respond by May 8th Thread-Index: Ac5BCfxeHqmu5GWPTBCphvk675Hq5QJkpvNA Message-ID: <1808340F7EC362469DDFFB112B37E2FCC895C70CE7@SRVHKE02.rdm.cz> References: <8A1B81989BCFAE44A22B2B86BF2B7631898DB0232B@HE111643.EMEA1.CDS.T-INTERNAL.COM> <51780A17.8010503@gmail.com> In-Reply-To: <51780A17.8010503@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Forwarded Subject: Re: [dhcwg] Adoption call for draft-rajtar-dhc-v4configuration-02 - respond by May 8th X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 May 2013 21:00:02 -0000 +1 to support adoption of this document. Cheers, Ales > -----Original Message----- > From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of= Tomek > Mrugalski > Sent: Wednesday, April 24, 2013 6:37 PM > To: dhcwg@ietf.org > Subject: [dhcwg] Adoption call for draft-rajtar-dhc-v4configuration-02 - = respond by > May 8th >=20 > Hi all, >=20 > This draft is an attempt to summarize the alternatives regarding IPv4 hos= ts > configuration in IPv6-only network. If adopted, it will eventually docume= nt DHC > recommendation for the stated problem. Currently there is no conclusion s= tated in the > text. The plan is to first see if the WG wants to work on this issue. If = the answer is > yes, then we will try to reach a consensus on what should the recommendat= ion be. > That will be done only after this draft is adopted. >=20 > As requested by the authors, we are announcing adoption call on draft-raj= tar-dhc- > v4configuration-02. This call is being initiated to confirm whether there= is WG > consensus to adopt this work as DHC WG draft. Please state whether or not= you're in > favour of the adoption by replying to this mail. If you are not in favour= , please also > state your objections in your response. This adoption call will conclude = after 2013-05- > 08. >=20 > This adoption call is about whether we as a working group want to work on= this > problem and ultimately make a recommendation. It is not about picking spe= cific > technology for IPv4 hosts configuration in IPv6 networks at that time. >=20 > Background info: >=20 > This issue was extensively discussed during Orlando meeting. Couple usefu= l things came > out of it: DHCPv4-over-DHCPv6 draft that documents what looked like a con= sensus in > the meeting room (adopted couple days ago), a new draft that documents re= lay > behaviour when receiving unknown messages (also adopted recently), and dr= aft-rajtar- > dhc-v4configuration received an update to reflect the latest developments= . >=20 > This draft went through an adoption call couple months ago, but it then h= ad a > conclusion that pointed out toward a solution that was undefined at that = time. The > (somewhat premature) conclusion was promptly removed, but it was too late= to stop a > heated discussion. >=20 > Regards, > Bernie & Tomek >=20 > On 23.04.2013 23:23, ian.farrer@telekom.de wrote: > > Just in case you missed it, a new version of > > draft-rajtar-dhc-v4configuration (02) was recently posted. > > > > As this version incorporates the new DCHPv4 over DHCPv6 model > > described in the recently adopted draft-scskf-dhcpv4-over-dhcpv6 and > > other changes based on the discussions in Orlando, the authors would > > like request that the WG chairs make a call for adoption based. > > > > Cheers, > > Ian > > > > > > > > > > > > _______________________________________________ > > dhcwg mailing list > > dhcwg@ietf.org > > https://www.ietf.org/mailman/listinfo/dhcwg > > >=20 > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg From Tina.Tsou.Zouting@huawei.com Mon May 6 23:13:21 2013 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 E1FB121F93B4 for ; Mon, 6 May 2013 23:13:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nn0Y9Nhorka0 for ; Mon, 6 May 2013 23:13:17 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 49F7021F8FB2 for ; Mon, 6 May 2013 23:13:17 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ASM89432; Tue, 07 May 2013 06:13:10 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.7; Tue, 7 May 2013 07:12:59 +0100 Received: from DFWEML407-HUB.china.huawei.com (10.193.5.132) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.1.323.7; Tue, 7 May 2013 07:13:06 +0100 Received: from DFWEML513-MBS.china.huawei.com ([169.254.4.156]) by dfweml407-hub.china.huawei.com ([10.193.5.132]) with mapi id 14.01.0323.007; Mon, 6 May 2013 23:13:00 -0700 From: Tina TSOU To: =?Windows-1252?Q?V=EDzdal_Ale=9A?= Thread-Topic: [dhcwg] Adoption call for draft-rajtar-dhc-v4configuration-02 - respond by May 8th Thread-Index: AQHOQQn5pWkAT+i/IkWDSnskiYyV0Zj5LJGAgAAlNZo= Date: Tue, 7 May 2013 06:12:59 +0000 Message-ID: <797E2D1E-41C9-4BE0-B87D-58BF2D9C7CD4@huawei.com> References: <8A1B81989BCFAE44A22B2B86BF2B7631898DB0232B@HE111643.EMEA1.CDS.T-INTERNAL.COM> <51780A17.8010503@gmail.com>, <1808340F7EC362469DDFFB112B37E2FCC895C70CE7@SRVHKE02.rdm.cz> In-Reply-To: <1808340F7EC362469DDFFB112B37E2FCC895C70CE7@SRVHKE02.rdm.cz> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "dhcwg@ietf.org" Subject: Re: [dhcwg] Adoption call for draft-rajtar-dhc-v4configuration-02 - respond by May 8th X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 May 2013 06:13:22 -0000 Dear all, I support the adoption. Thank you, Tina On May 6, 2013, at 2:00 PM, "V=EDzdal Ale=9A" wro= te: > +1 to support adoption of this document. >=20 > Cheers, > Ales >=20 >> -----Original Message----- >> From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf O= f Tomek >> Mrugalski >> Sent: Wednesday, April 24, 2013 6:37 PM >> To: dhcwg@ietf.org >> Subject: [dhcwg] Adoption call for draft-rajtar-dhc-v4configuration-02 -= respond by >> May 8th >>=20 >> Hi all, >>=20 >> This draft is an attempt to summarize the alternatives regarding IPv4 ho= sts >> configuration in IPv6-only network. If adopted, it will eventually docum= ent DHC >> recommendation for the stated problem. Currently there is no conclusion = stated in the >> text. The plan is to first see if the WG wants to work on this issue. If= the answer is >> yes, then we will try to reach a consensus on what should the recommenda= tion be. >> That will be done only after this draft is adopted. >>=20 >> As requested by the authors, we are announcing adoption call on draft-ra= jtar-dhc- >> v4configuration-02. This call is being initiated to confirm whether ther= e is WG >> consensus to adopt this work as DHC WG draft. Please state whether or no= t you're in >> favour of the adoption by replying to this mail. If you are not in favou= r, please also >> state your objections in your response. This adoption call will conclude= after 2013-05- >> 08. >>=20 >> This adoption call is about whether we as a working group want to work o= n this >> problem and ultimately make a recommendation. It is not about picking sp= ecific >> technology for IPv4 hosts configuration in IPv6 networks at that time. >>=20 >> Background info: >>=20 >> This issue was extensively discussed during Orlando meeting. Couple usef= ul things came >> out of it: DHCPv4-over-DHCPv6 draft that documents what looked like a co= nsensus in >> the meeting room (adopted couple days ago), a new draft that documents r= elay >> behaviour when receiving unknown messages (also adopted recently), and d= raft-rajtar- >> dhc-v4configuration received an update to reflect the latest development= s. >>=20 >> This draft went through an adoption call couple months ago, but it then = had a >> conclusion that pointed out toward a solution that was undefined at that= time. The >> (somewhat premature) conclusion was promptly removed, but it was too lat= e to stop a >> heated discussion. >>=20 >> Regards, >> Bernie & Tomek >>=20 >> On 23.04.2013 23:23, ian.farrer@telekom.de wrote: >>> Just in case you missed it, a new version of >>> draft-rajtar-dhc-v4configuration (02) was recently posted. >>>=20 >>> As this version incorporates the new DCHPv4 over DHCPv6 model >>> described in the recently adopted draft-scskf-dhcpv4-over-dhcpv6 and >>> other changes based on the discussions in Orlando, the authors would >>> like request that the WG chairs make a call for adoption based. >>>=20 >>> Cheers, >>> Ian >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> 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 > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg From msiodelski@gmail.com Tue May 7 05:46:05 2013 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 783C721F853A for ; Tue, 7 May 2013 05:46:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id embDc9AXnaYR for ; Tue, 7 May 2013 05:46:04 -0700 (PDT) Received: from mail-ea0-x233.google.com (mail-ea0-x233.google.com [IPv6:2a00:1450:4013:c01::233]) by ietfa.amsl.com (Postfix) with ESMTP id 2579B21F869A for ; Tue, 7 May 2013 05:46:03 -0700 (PDT) Received: by mail-ea0-f179.google.com with SMTP id h14so280037eaj.24 for ; Tue, 07 May 2013 05:46:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:subject:from:to:cc:date:in-reply-to :references:content-type:x-mailer:mime-version :content-transfer-encoding; bh=ahuNlMH6eqmthlCD2BSzrvgtEtPeDTMcBxaDHSzywVc=; b=G9fOZx3RD9BYG7hspYFVLD9vk0E0fdU6++cDAlZPNVjXrTnDDiDJ3KXviatUvvOEwu xMiSgJUj+kRaXmwNr1M7AJAyD7CswevetYaGZpqWtXDs1bmAdkC2YPr9mjPs6J8GNnfL 2zZcfw0A/lf/ovVjm22m/huzGmgAufC+EzBxJHu744znxTGqj6mb6ZA9envEwzFA577v 2GEPC5lh/kigk+jtOzuT12P3doKxM2qGyGk/KEPzaQvUWVzaMsyjy2VyxXuWgv7kf46g LzixIM2e6l7SrEfzdyxHIZtzp6bkrkEmd9AA2oBPa/Uu+GlfeAmKwV8yg3w1C1lIKfjQ Exwg== X-Received: by 10.14.38.198 with SMTP id a46mr5191876eeb.11.1367930763282; Tue, 07 May 2013 05:46:03 -0700 (PDT) Received: from [192.168.0.193] (89-75-115-194.dynamic.chello.pl. [89.75.115.194]) by mx.google.com with ESMTPSA id t45sm18622943eev.6.2013.05.07.05.46.01 for (version=SSLv3 cipher=RC4-SHA bits=128/128); Tue, 07 May 2013 05:46:02 -0700 (PDT) Message-ID: <1367930761.18565.67.camel@marcin-lenovo> From: Marcin Siodelski To: Tomek Mrugalski Date: Tue, 07 May 2013 14:46:01 +0200 In-Reply-To: <51780A17.8010503@gmail.com> References: <8A1B81989BCFAE44A22B2B86BF2B7631898DB0232B@HE111643.EMEA1.CDS.T-INTERNAL.COM> <51780A17.8010503@gmail.com> Content-Type: text/plain; charset="ISO-8859-15" X-Mailer: Evolution 3.6.4 (3.6.4-2.fc18) Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Cc: dhcwg@ietf.org Subject: Re: [dhcwg] Adoption call for draft-rajtar-dhc-v4configuration-02 - respond by May 8th X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 May 2013 12:46:05 -0000 I support adoption of this document. Marcin On Wed, 2013-04-24 at 18:36 +0200, Tomek Mrugalski wrote: > Hi all, > > This draft is an attempt to summarize the alternatives regarding IPv4 > hosts configuration in IPv6-only network. If adopted, it will eventually > document DHC recommendation for the stated problem. Currently there is > no conclusion stated in the text. The plan is to first see if the WG > wants to work on this issue. If the answer is yes, then we will try to > reach a consensus on what should the recommendation be. That will be > done only after this draft is adopted. > > As requested by the authors, we are announcing adoption call on > draft-rajtar-dhc-v4configuration-02. This call is being initiated to > confirm whether there is WG consensus to adopt this work as DHC WG > draft. Please state whether or not you're in favour of the adoption by > replying to this mail. If you are not in favour, please also state your > objections in your response. This adoption call will conclude after > 2013-05-08. > > This adoption call is about whether we as a working group want to work > on this problem and ultimately make a recommendation. It is not about > picking specific technology for IPv4 hosts configuration in IPv6 > networks at that time. > > Background info: > > This issue was extensively discussed during Orlando meeting. Couple > useful things came out of it: DHCPv4-over-DHCPv6 draft that documents > what looked like a consensus in the meeting room (adopted couple days > ago), a new draft that documents relay behaviour when receiving unknown > messages (also adopted recently), and draft-rajtar-dhc-v4configuration > received an update to reflect the latest developments. > > This draft went through an adoption call couple months ago, but it then > had a conclusion that pointed out toward a solution that was undefined > at that time. The (somewhat premature) conclusion was promptly removed, > but it was too late to stop a heated discussion. > > Regards, > Bernie & Tomek > > On 23.04.2013 23:23, ian.farrer@telekom.de wrote: > > Just in case you missed it, a new version of > > draft-rajtar-dhc-v4configuration (02) was recently posted. > > > > As this version incorporates the new DCHPv4 over DHCPv6 model described > > in the recently adopted draft-scskf-dhcpv4-over-dhcpv6 and other changes > > based on the discussions in Orlando, the authors would like request that > > the WG chairs make a call for adoption based. > > > > Cheers, > > Ian > > > > > > > > > > > > _______________________________________________ > > dhcwg mailing list > > dhcwg@ietf.org > > https://www.ietf.org/mailman/listinfo/dhcwg > > > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg From volz@cisco.com Wed May 8 06:52:04 2013 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 E789E21F9130 for ; Wed, 8 May 2013 06:52:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JT7sArUkWlza for ; Wed, 8 May 2013 06:51:57 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 8E1B421F8F41 for ; Wed, 8 May 2013 06:51:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=239; q=dns/txt; s=iport; t=1368021117; x=1369230717; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=e91kZa08PZPn5pMtd8qSlUns8p6pY7U0b6g1NH9wO2k=; b=GZCH/dn73ax6BpgZ+/7Swj4AqkjJzlkhojBVuS4fGdqyWFXVs9Pkuggi JQGncvAFMphXdM+kFtARBs7FBBg6JXMoNFbsx8DGYXPrG3gITVHcQnurD 4vwRjEACnaTT9Aq7XdawQby4dNw96SQ97rtX+7okV3hov9ij7IOo7WOg3 M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkcFAFhXilGtJV2c/2dsb2JhbABRgwe/SnsWbQeCIAEBBB0dTwIBCCIUEDIlAgQbiATBeI53OIJ0YQOoX4FWgTiCJw X-IronPort-AV: E=Sophos;i="4.87,635,1363132800"; d="scan'208";a="207834648" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-2.cisco.com with ESMTP; 08 May 2013 13:51:57 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id r48Dpu5K019500 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 8 May 2013 13:51:56 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.77]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.02.0318.004; Wed, 8 May 2013 08:51:56 -0500 From: "Bernie Volz (volz)" To: "dhcwg@ietf.org" Thread-Topic: [dhcwg] Adoption call for draft-rajtar-dhc-v4configuration-02 - respond by May 8th Thread-Index: AQHOQQn3i29FT/o/ZEWyk0lX7iZkw5j7Y9rw Date: Wed, 8 May 2013 13:51:55 +0000 Message-ID: <489D13FBFA9B3E41812EA89F188F018E18552B99@xmb-rcd-x04.cisco.com> References: <8A1B81989BCFAE44A22B2B86BF2B7631898DB0232B@HE111643.EMEA1.CDS.T-INTERNAL.COM> <51780A17.8010503@gmail.com> In-Reply-To: <51780A17.8010503@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.131.33.90] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dhcwg] Adoption call for draft-rajtar-dhc-v4configuration-02 - respond by May 8th X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 May 2013 13:52:04 -0000 Hi: 1. (WG co-chair hat off:) I support adopting this document as a working gro= up work item. 2. (WG co-chair hat on): If you have not expressed support or opposition fo= r adopting this work, the call expires today! - Bernie From wwwrun@rfc-editor.org Wed May 8 21:16:49 2013 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 9EF1F21F9253 for ; Wed, 8 May 2013 21:16:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.84 X-Spam-Level: X-Spam-Status: No, score=-101.84 tagged_above=-999 required=5 tests=[AWL=0.760, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NrnGRIKCxEjP for ; Wed, 8 May 2013 21:16:49 -0700 (PDT) Received: from rfc-editor.org (unknown [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 2E8CA21F8E56 for ; Wed, 8 May 2013 21:16:49 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id CE54D62101; Wed, 8 May 2013 21:16:39 -0700 (PDT) To: raj@cisco.com, kkinnear@cisco.com, mjs@cisco.com, brian@innovationslab.net, ted.lemon@nominum.com, volz@cisco.com, tomasz.mrugalski@gmail.com From: RFC Errata System Message-Id: <20130509041639.CE54D62101@rfc-editor.org> Date: Wed, 8 May 2013 21:16:39 -0700 (PDT) X-Mailman-Approved-At: Thu, 09 May 2013 01:43:24 -0700 Cc: dhcwg@ietf.org, draghuva@cisco.com, rfc-editor@rfc-editor.org Subject: [dhcwg] [Technical Errata Reported] RFC6656 (3617) X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 May 2013 04:16:49 -0000 The following errata report has been submitted for RFC6656, "Description of Cisco Systems' Subnet Allocation Option for DHCPv4". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6656&eid=3617 -------------------------------------- Type: Technical Reported by: Dushyant Raghuvanshi Section: 3.2 Original Text ------------- Len = Length of the suboption (min. length of 8) (1 octet) Corrected Text -------------- Len = Length of the suboption (min. length of 1) (1 octet) Notes ----- RFC 6656 suggests that a DHCP Client MAY request list of previously allocated subnets from the DHCP Server in case of recovering from a restart if the Client does not have local storage in order to retain the information itself. But there will be cases when Server does not have any information to send back (this could be a new Client or this Client never spoke to this Server before). In this case, DHCP Server may decide to remain silent and discard the request. This approach will make it difficult for DHCP Client to decide if request could not reach to Server or Server did not have any information to send back. A possible approach could be to send the OFFER back to Client with Subnet-Information Suboption (without Subnet Prefix Information Block) in it. So that Client can proceed by making a request to allocate new subnets. This would require to reduce the minimum length of Subnet-Information Suboption to 1 (just include flags). Section 6 would require to be updated as well t o reflect the new behavior (to respond). Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC6656 (draft-ietf-dhc-subnet-alloc-13) -------------------------------------- Title : Description of Cisco Systems' Subnet Allocation Option for DHCPv4 Publication Date : July 2012 Author(s) : R. Johnson, K. Kinnear, M. Stapp Category : INFORMATIONAL Source : Dynamic Host Configuration Area : Internet Stream : IETF Verifying Party : IESG From tomasz.mrugalski@gmail.com Thu May 9 03:10:59 2013 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 C88E421F854E for ; Thu, 9 May 2013 03:10:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Pb+GEJvlnuv for ; Thu, 9 May 2013 03:10:59 -0700 (PDT) Received: from mail-ea0-x230.google.com (mail-ea0-x230.google.com [IPv6:2a00:1450:4013:c01::230]) by ietfa.amsl.com (Postfix) with ESMTP id 1EAA121F8519 for ; Thu, 9 May 2013 03:10:58 -0700 (PDT) Received: by mail-ea0-f176.google.com with SMTP id h14so1497247eak.35 for ; Thu, 09 May 2013 03:10:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; bh=EoihIQSzdd9lQyPXVHWbB7hqY6ggUntpimB6ClkdA+Q=; b=Nxht8t49qX47CX1DXTobcA6ymv1uA/axlxWpb504+kloKHBA2QaDi/KluNhGi9C4BI CtrEfuoOD7BE2IP/u9jTHxCLJefQ8V/NrirepJvYL9MCYykwm0qBbSOcCbvuqSRwwn7C 6BhKKqvChEg4e+mQzgPFGw2et4qcIC01sTUdHx3ZZhhNwuYzvs7Il7/twFPAtPPgBMcH eN8H9RiXMcYI9ikiJ95yw2ZCmKsT21LRfeUKkjPFbLbVPxr3+DFoHZ3ofbPi3yN+2L6i viDSx3JNhhJZGxJ2WcqDS4RhQGD6tN34xntc22DKWUTsUG3Iek0xjuY7PC9QArSvvwFT ylRw== X-Received: by 10.14.205.194 with SMTP id j42mr27566319eeo.41.1368094258243; Thu, 09 May 2013 03:10:58 -0700 (PDT) Received: from thomson-osx.local (host-109-107-11-157.ip.jarsat.pl. [109.107.11.157]) by mx.google.com with ESMTPSA id t9sm3149795eeo.11.2013.05.09.03.10.53 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 09 May 2013 03:10:57 -0700 (PDT) Message-ID: <518B7628.3020309@gmail.com> Date: Thu, 09 May 2013 12:10:48 +0200 From: Tomek Mrugalski User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: dhcwg@ietf.org References: <8A1B81989BCFAE44A22B2B86BF2B7631898DB0232B@HE111643.EMEA1.CDS.T-INTERNAL.COM> <51780A17.8010503@gmail.com> <489D13FBFA9B3E41812EA89F188F018E18552B99@xmb-rcd-x04.cisco.com> In-Reply-To: <489D13FBFA9B3E41812EA89F188F018E18552B99@xmb-rcd-x04.cisco.com> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [dhcwg] Adoption call for draft-rajtar-dhc-v4configuration-02 - adopted! X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 May 2013 10:10:59 -0000 On 13-05-08 15:51, Bernie Volz (volz) wrote: > 2. (WG co-chair hat on): If you have not expressed support or opposition for adopting this work, the call expires today! Hi, Although this adoption call looked a bit grim for the first 10 days, large support voiced in the last couple days saved the day. We have around a dozen support voices, which means that this I-D was adopted. Authors, please upload it as draft-ietf-dhc-v4configuration-00. Once that is done, I encourage authors to start a discussion about recommendation that the WG wants to offer. It is a pleasure to see such a strong consensus. Let's hope that the discussion about writing Conclusion section will have equally strong consensus. Bernie & Tomek From internet-drafts@ietf.org Thu May 9 14:56:09 2013 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 3755121F8605; Thu, 9 May 2013 14:56:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.378 X-Spam-Level: X-Spam-Status: No, score=-102.378 tagged_above=-999 required=5 tests=[AWL=0.222, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4BaBTD9az91X; Thu, 9 May 2013 14:56:08 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AF43C21F853A; Thu, 9 May 2013 14:56:08 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.44.p7 Message-ID: <20130509215608.9119.3341.idtracker@ietfa.amsl.com> Date: Thu, 09 May 2013 14:56:08 -0700 Cc: dhcwg@ietf.org Subject: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-failover-requirements-04.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 May 2013 21:56:09 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Dynamic Host Configuration Working Group = of the IETF. Title : DHCPv6 Failover Requirements Author(s) : Tomek Mrugalski Kim Kinnear Filename : draft-ietf-dhc-dhcpv6-failover-requirements-04.txt Pages : 20 Date : 2013-05-09 Abstract: The DHCPv6 protocol, defined in [RFC3315] allows for multiple servers to operate on a single network, however it does not define any way the servers could share information about currently active clients and their leases. Some sites are interested in running multiple servers in such a way as to provide increased availability in case of server failure. In order for this to work reliably, the cooperating primary and secondary servers must maintain a consistent database of the lease information. [RFC3315] allows for but does not define any redundancy or failover mechanisms. This document outlines requirements for DHCPv6 failover, enumerates related problems, and discusses the proposed scope of work to be conducted. This document does not define a DHCPv6 failover protocol. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv6-failover-requirements There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-failover-requirements-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dhc-dhcpv6-failover-requireme= nts-04 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From tomasz.mrugalski@gmail.com Thu May 9 15:05:53 2013 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 BBD1B21F89CF for ; Thu, 9 May 2013 15:05:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fEYb+7KpoErv for ; Thu, 9 May 2013 15:05:53 -0700 (PDT) Received: from mail-ea0-x229.google.com (mail-ea0-x229.google.com [IPv6:2a00:1450:4013:c01::229]) by ietfa.amsl.com (Postfix) with ESMTP id DFC7D21F882A for ; Thu, 9 May 2013 15:05:52 -0700 (PDT) Received: by mail-ea0-f169.google.com with SMTP id n15so1901148ead.28 for ; Thu, 09 May 2013 15:05:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:x-enigmail-version:x-tagtoolbar-keys :content-type:content-transfer-encoding; bh=ZRsLOP1P5D2b9JfhNxVJnhTPd797rl3TrZHYy4jieR4=; b=LMKBXy+5//gvOiEmU+Tag2wpFYCXg9z0bejhUhl7t/gX1p3d2Mxbc61cqpnf8sSW08 z1hJiFybP+n1LoKLRqyYol6qHSTEkStNqiu3eaDOKtc+AZnVY+9bAFcQ/Jonb6Bsovqt E4jl7i6gDCJghCiQNciZ6Q/FqXUAIWpuhEpUlYYADta4emHDCeNmFF1xiiYh3PUoHugw 7wsPa0jrQSK5nui7QSoesTXe1tOfudMBTOFAhlF5olaxMi/VARnMOGc5y/njAVgGE+pX f6a/ZKVI1LE9KHZZzHfPNT4L9Nr9sWNhfhokGEUsoNEYYNbn8JuSSqZA/VW1UZWgkaLo C5dw== X-Received: by 10.15.26.6 with SMTP id m6mr34261174eeu.4.1368137152010; Thu, 09 May 2013 15:05:52 -0700 (PDT) Received: from [10.0.0.100] (host-109-107-11-157.ip.jarsat.pl. [109.107.11.157]) by mx.google.com with ESMTPSA id n7sm6836191eeo.0.2013.05.09.15.05.50 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 09 May 2013 15:05:51 -0700 (PDT) Message-ID: <518C1DBB.20902@gmail.com> Date: Fri, 10 May 2013 00:05:47 +0200 From: Tomek Mrugalski User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130329 Thunderbird/17.0.5 MIME-Version: 1.0 To: dhcwg@ietf.org References: <20130509215608.9119.3341.idtracker@ietfa.amsl.com> In-Reply-To: <20130509215608.9119.3341.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.4.6 X-TagToolbar-Keys: D20130510000547857 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-failover-requirements-04.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 May 2013 22:05:53 -0000 Hi, A new version has been uploaded with comments received during WGLC. Fortunately, the changes were only editorial in nature, except one mistake in MCLT example. You can see all changes here: http://tools.ietf.org/rfcdiff?url2=draft-ietf-dhc-dhcpv6-failover-requirements-04.txt Since this document passed WGLC, is idnits clean and there are no IPR claims to it, the authors believe it is ready for submission to IESG. I'm not aware of any IPR claims regarding this document. Tomek On 09.05.2013 23:56, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Dynamic Host Configuration Working Group of the IETF. > > Title : DHCPv6 Failover Requirements > Author(s) : Tomek Mrugalski > Kim Kinnear > Filename : draft-ietf-dhc-dhcpv6-failover-requirements-04.txt > Pages : 20 > Date : 2013-05-09 > > Abstract: > The DHCPv6 protocol, defined in [RFC3315] allows for multiple servers > to operate on a single network, however it does not define any way > the servers could share information about currently active clients > and their leases. Some sites are interested in running multiple > servers in such a way as to provide increased availability in case of > server failure. In order for this to work reliably, the cooperating > primary and secondary servers must maintain a consistent database of > the lease information. [RFC3315] allows for but does not define any > redundancy or failover mechanisms. This document outlines > requirements for DHCPv6 failover, enumerates related problems, and > discusses the proposed scope of work to be conducted. This document > does not define a DHCPv6 failover protocol. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv6-failover-requirements > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-failover-requirements-04 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-dhc-dhcpv6-failover-requirements-04 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg > From achaldhir@gmail.com Sat May 11 19:05:20 2013 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 4522921F89FD for ; Sat, 11 May 2013 19:05:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0WwEZ29i4wCy for ; Sat, 11 May 2013 19:05:19 -0700 (PDT) Received: from mail-ve0-x231.google.com (mail-ve0-x231.google.com [IPv6:2607:f8b0:400c:c01::231]) by ietfa.amsl.com (Postfix) with ESMTP id 2564B21F898A for ; Sat, 11 May 2013 19:05:19 -0700 (PDT) Received: by mail-ve0-f177.google.com with SMTP id jw11so4836111veb.22 for ; Sat, 11 May 2013 19:05:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=zhnfW2qWc1sAREpjh/udiKV14tgG6IbL52udlBXiYtE=; b=GH06MgU/4cjQlbyFcauUgEOUQHFeFy1zkp1y26OEu617SAkfrAYfFtpi0e9zs7AhEF 8hzUJvR8C4sWo0KQmnStp7CQgxKIcjy8CxOiiEPx4gOyCUNga8vEwRnX1IC1U5hkByLW g9SrDRA+ZnxrYwA4vDwShG7EMRBKlMGRVZcqfFE2u7EMKZvNucvXLeTe88D2DE10HVym k69/2YHbe0+2xPXsUdDyauKsFAJLXCP1bVdKfrpfcWp5LNgK6/ghoAShCilye1qH4lOZ QkIlS7AQ5g6NozHy+uNtSL00/LKAWZfEPedScJASP7g1E0P77Ox1DwuX5zLiiF6Mctof 6iUQ== MIME-Version: 1.0 X-Received: by 10.220.228.74 with SMTP id jd10mr14918268vcb.65.1368324318281; Sat, 11 May 2013 19:05:18 -0700 (PDT) Received: by 10.58.74.36 with HTTP; Sat, 11 May 2013 19:05:18 -0700 (PDT) In-Reply-To: <518C1DBB.20902@gmail.com> References: <20130509215608.9119.3341.idtracker@ietfa.amsl.com> <518C1DBB.20902@gmail.com> Date: Sat, 11 May 2013 22:05:18 -0400 Message-ID: From: Achal Dhir To: Tomek Mrugalski Content-Type: multipart/alternative; boundary=14dae9ccd516edc84a04dc7bd4ce Cc: dhcwg@ietf.org Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-failover-requirements-04.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 May 2013 02:05:20 -0000 --14dae9ccd516edc84a04dc7bd4ce Content-Type: text/plain; charset=ISO-8859-1 Open DHCP Server and Dual DHCP DNS Server uses special unicast DHCPINFORM messages to keep both Primary and Secondary Server databases in Synch. On Thu, May 9, 2013 at 6:05 PM, Tomek Mrugalski wrote: > Hi, > > A new version has been uploaded with comments received during WGLC. > Fortunately, the changes were only editorial in nature, except one > mistake in MCLT example. You can see all changes here: > > > http://tools.ietf.org/rfcdiff?url2=draft-ietf-dhc-dhcpv6-failover-requirements-04.txt > > > Since this document passed WGLC, is idnits clean and there are no IPR > claims to it, the authors believe it is ready for submission to IESG. > > I'm not aware of any IPR claims regarding this document. > > Tomek > > On 09.05.2013 23:56, internet-drafts@ietf.org wrote: > > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > This draft is a work item of the Dynamic Host Configuration Working > Group of the IETF. > > > > Title : DHCPv6 Failover Requirements > > Author(s) : Tomek Mrugalski > > Kim Kinnear > > Filename : > draft-ietf-dhc-dhcpv6-failover-requirements-04.txt > > Pages : 20 > > Date : 2013-05-09 > > > > Abstract: > > The DHCPv6 protocol, defined in [RFC3315] allows for multiple servers > > to operate on a single network, however it does not define any way > > the servers could share information about currently active clients > > and their leases. Some sites are interested in running multiple > > servers in such a way as to provide increased availability in case of > > server failure. In order for this to work reliably, the cooperating > > primary and secondary servers must maintain a consistent database of > > the lease information. [RFC3315] allows for but does not define any > > redundancy or failover mechanisms. This document outlines > > requirements for DHCPv6 failover, enumerates related problems, and > > discusses the proposed scope of work to be conducted. This document > > does not define a DHCPv6 failover protocol. > > > > > > The IETF datatracker status page for this draft is: > > > https://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv6-failover-requirements > > > > There's also a htmlized version available at: > > > http://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-failover-requirements-04 > > > > A diff from the previous version is available at: > > > http://www.ietf.org/rfcdiff?url2=draft-ietf-dhc-dhcpv6-failover-requirements-04 > > > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > _______________________________________________ > > 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 > --14dae9ccd516edc84a04dc7bd4ce Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Open DHCP Server and Dual DHCP DNS Server uses special uni= cast DHCPINFORM messages to keep both Primary and Secondary Server database= s in Synch.


On Thu, May 9, 2013 at 6:05 PM, Tomek Mrugalski <tomasz.mrugalski= @gmail.com> wrote:
Hi,

A new version has been uploaded with comments received during WGLC.
Fortunately, the changes were only editorial in nature, except one
mistake in MCLT example. You can see all changes here:

http://tools.ietf.org/rfcdiff?ur= l2=3Ddraft-ietf-dhc-dhcpv6-failover-requirements-04.txt

<chair hat off>
Since this document passed WGLC, is idnits clean and there are no IPR
claims to it, the authors believe it is ready for submission to IESG.

I'm not aware of any IPR claims regarding this document.

Tomek

On 09.05.2013 23:56, internet-d= rafts@ietf.org wrote:
>
> A New Internet-Draft is available from the on-line Internet-Drafts dir= ectories.
> =A0This draft is a work item of the Dynamic Host Configuration Working= Group of the IETF.
>
> =A0 =A0 =A0 Title =A0 =A0 =A0 =A0 =A0 : DHCPv6 Failover Requirements > =A0 =A0 =A0 Author(s) =A0 =A0 =A0 : Tomek Mrugalski
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Kim Kinnear
> =A0 =A0 =A0 Filename =A0 =A0 =A0 =A0: draft-ietf-dhc-dhcpv6-failover-r= equirements-04.txt
> =A0 =A0 =A0 Pages =A0 =A0 =A0 =A0 =A0 : 20
> =A0 =A0 =A0 Date =A0 =A0 =A0 =A0 =A0 =A0: 2013-05-09
>
> Abstract:
> =A0 =A0The DHCPv6 protocol, defined in [RFC3315] allows for multiple s= ervers
> =A0 =A0to operate on a single network, however it does not define any = way
> =A0 =A0the servers could share information about currently active clie= nts
> =A0 =A0and their leases. =A0Some sites are interested in running multi= ple
> =A0 =A0servers in such a way as to provide increased availability in c= ase of
> =A0 =A0server failure. =A0In order for this to work reliably, the coop= erating
> =A0 =A0primary and secondary servers must maintain a consistent databa= se of
> =A0 =A0the lease information. =A0[RFC3315] allows for but does not def= ine any
> =A0 =A0redundancy or failover mechanisms. =A0This document outlines > =A0 =A0requirements for DHCPv6 failover, enumerates related problems, = and
> =A0 =A0discusses the proposed scope of work to be conducted. =A0This d= ocument
> =A0 =A0does not define a DHCPv6 failover protocol.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft= -ietf-dhc-dhcpv6-failover-requirements
>
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-ietf-dhc= -dhcpv6-failover-requirements-04
>
> A diff from the previous version is available at:
> http://www.ietf.org/rfcdiff?url2= =3Ddraft-ietf-dhc-dhcpv6-failover-requirements-04
>
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp:= //ftp.ietf.org/internet-drafts/
>
> _______________________________________________
> dhcwg mailing list
> dhcwg@ietf.org
> https://www.ietf.org/mailman/listinfo/dhcwg
>

_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/dhcwg

--14dae9ccd516edc84a04dc7bd4ce-- From volz@cisco.com Sat May 11 20:50:43 2013 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 88EE521F8976 for ; Sat, 11 May 2013 20:50:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PaEi0PhBpHd6 for ; Sat, 11 May 2013 20:50:38 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id A100721F898A for ; Sat, 11 May 2013 20:50:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10078; q=dns/txt; s=iport; t=1368330637; x=1369540237; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=teHvBj5KU0JN3oqrEFS0nQIp39MggOBG0fcwoYBppb4=; b=OG+6VHQCA1sFd/ecmuZtp3S417oRSM7Kr7DpTP7cldc5lhdI/svGoT3L /1wBONMDSnZhb30OrxQWZDK5Oh0nyTQttN0pjrgqs1IF0R9lGKcWaFq+s 021igGu/pdoXRLr1+dWFvJEaDxqQuXHtHhCFlFb15QMlWOfiFVIkriaIr s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjwFACgRj1GtJXG9/2dsb2JhbABagwc3t2SIPoEAFnSCHwEBAQQBAQFrCxACAQgYJwchBgsUEQIEDgUJh3EDDwyzDQ2IKIxSgjQeBAeCdGEDk12Ba4FkgSaKbYUigw8 X-IronPort-AV: E=Sophos;i="4.87,654,1363132800"; d="scan'208,217";a="209342789" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-3.cisco.com with ESMTP; 12 May 2013 03:50:05 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id r4C3o5eh025859 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 12 May 2013 03:50:05 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.77]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.02.0318.004; Sat, 11 May 2013 22:50:04 -0500 From: "Bernie Volz (volz)" To: Achal Dhir Thread-Topic: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-failover-requirements-04.txt Thread-Index: AQHOTQAeXF0lIf+JbEG0/Ot0hebM4pj9vIiAgANnlgD//8lzog== Date: Sun, 12 May 2013 03:50:03 +0000 Message-ID: <6A9B8E72-37F4-48E1-B955-98936EFFCB87@cisco.com> References: <20130509215608.9119.3341.idtracker@ietfa.amsl.com> <518C1DBB.20902@gmail.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_6A9B8E7237F448E1B95598936EFFCB87ciscocom_" MIME-Version: 1.0 Cc: "dhcwg@ietf.org" Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-failover-requirements-04.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 May 2013 03:50:43 -0000 --_000_6A9B8E7237F448E1B95598936EFFCB87ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Well that's nice but why is that significant. This is DHCPv6 - do these ser= vers even support DHCPv6 (DHCPINFORM is a DHCPv4 message). There are severa= l v4 servers that support the DHCPv4 failover draft (draft-ietf-dhc-failove= r-12). - Bernie On May 11, 2013, at 10:05 PM, "Achal Dhir" > wrote: Open DHCP Server and Dual DHCP DNS Server uses special unicast DHCPINFORM m= essages to keep both Primary and Secondary Server databases in Synch. On Thu, May 9, 2013 at 6:05 PM, Tomek Mrugalski > wrote: Hi, A new version has been uploaded with comments received during WGLC. Fortunately, the changes were only editorial in nature, except one mistake in MCLT example. You can see all changes here: http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-dhc-dhcpv6-failover-require= ments-04.txt Since this document passed WGLC, is idnits clean and there are no IPR claims to it, the authors believe it is ready for submission to IESG. I'm not aware of any IPR claims regarding this document. Tomek On 09.05.2013 23:56, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the Dynamic Host Configuration Working Grou= p of the IETF. > > Title : DHCPv6 Failover Requirements > Author(s) : Tomek Mrugalski > Kim Kinnear > Filename : draft-ietf-dhc-dhcpv6-failover-requirements-04.tx= t > Pages : 20 > Date : 2013-05-09 > > Abstract: > The DHCPv6 protocol, defined in [RFC3315] allows for multiple servers > to operate on a single network, however it does not define any way > the servers could share information about currently active clients > and their leases. Some sites are interested in running multiple > servers in such a way as to provide increased availability in case of > server failure. In order for this to work reliably, the cooperating > primary and secondary servers must maintain a consistent database of > the lease information. [RFC3315] allows for but does not define any > redundancy or failover mechanisms. This document outlines > requirements for DHCPv6 failover, enumerates related problems, and > discusses the proposed scope of work to be conducted. This document > does not define a DHCPv6 failover protocol. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv6-failover-requireme= nts > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-failover-requirements-04 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dhc-dhcpv6-failover-require= ments-04 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > 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 --_000_6A9B8E7237F448E1B95598936EFFCB87ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Well that's nice but why is that significant. This is DHCPv6 - do thes= e servers even support DHCPv6 (DHCPINFORM is a DHCPv4 message). There are s= everal v4 servers that support the DHCPv4 failover draft (draft-ietf-dhc-fa= ilover-12).

- Bernie

On May 11, 2013, at 10:05 PM, "Achal Dhir" <achaldhir@gmail.com> wrote:

Open DHCP Server and Dual DHCP DNS Server uses special uni= cast DHCPINFORM messages to keep both Primary and Secondary Server database= s in Synch.


On Thu, May 9, 2013 at 6:05 PM, Tomek Mrugalski = <tomasz.= mrugalski@gmail.com> wrote:
Hi,

A new version has been uploaded with comments received during WGLC.
Fortunately, the changes were only editorial in nature, except one
mistake in MCLT example. You can see all changes here:

http://tools.ietf.org/rfcdiff?ur= l2=3Ddraft-ietf-dhc-dhcpv6-failover-requirements-04.txt

<chair hat off>
Since this document passed WGLC, is idnits clean and there are no IPR
claims to it, the authors believe it is ready for submission to IESG.

I'm not aware of any IPR claims regarding this document.

Tomek

On 09.05.2013 23:56, internet-d= rafts@ietf.org wrote:
>
> A New Internet-Draft is available from the on-line Internet-Drafts dir= ectories.
>  This draft is a work item of the Dynamic Host Configuration Work= ing Group of the IETF.
>
>       Title           : DHCPv6= Failover Requirements
>       Author(s)       : Tomek Mrugalski<= br> >                     =       Kim Kinnear
>       Filename        : draft-ietf-= dhc-dhcpv6-failover-requirements-04.txt
>       Pages           : 20
>       Date            : 2= 013-05-09
>
> Abstract:
>    The DHCPv6 protocol, defined in [RFC3315] allows for mult= iple servers
>    to operate on a single network, however it does not defin= e any way
>    the servers could share information about currently activ= e clients
>    and their leases.  Some sites are interested in runn= ing multiple
>    servers in such a way as to provide increased availabilit= y in case of
>    server failure.  In order for this to work reliably,= the cooperating
>    primary and secondary servers must maintain a consistent = database of
>    the lease information.  [RFC3315] allows for but doe= s not define any
>    redundancy or failover mechanisms.  This document ou= tlines
>    requirements for DHCPv6 failover, enumerates related prob= lems, and
>    discusses the proposed scope of work to be conducted. &nb= sp;This document
>    does not define a DHCPv6 failover protocol.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv6-failover-requirement= s
>
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-failover-requirements-04
>
> A diff from the previous version is available at:
> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dhc-dhcpv6-failover-requireme= nts-04
>
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp:= //ftp.ietf.org/internet-drafts/
>
> _______________________________________________
> dhcwg mailing list
> dhcwg@ietf.org
> https://www.ietf.org/mailman/listinfo/dhcwg
>

_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/dhcwg

_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www.i= etf.org/mailman/listinfo/dhcwg
--_000_6A9B8E7237F448E1B95598936EFFCB87ciscocom_-- From internet-drafts@ietf.org Mon May 13 01:39:18 2013 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 081B621F8F3E; Mon, 13 May 2013 01:39:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.301 X-Spam-Level: X-Spam-Status: No, score=-101.301 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id anJGp7cFnWIH; Mon, 13 May 2013 01:39:17 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A3AA721F85CE; Mon, 13 May 2013 01:39:17 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.44.p7 Message-ID: <20130513083917.5952.38723.idtracker@ietfa.amsl.com> Date: Mon, 13 May 2013 01:39:17 -0700 Cc: dhcwg@ietf.org Subject: [dhcwg] I-D Action: draft-ietf-dhc-v4configuration-00.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 May 2013 08:39:18 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Dynamic Host Configuration Working Group = of the IETF. Title : Provisioning IPv4 Configuration Over IPv6 Only Networks Author(s) : Branimir Rajtar Ian Farrer Filename : draft-ietf-dhc-v4configuration-00.txt Pages : 13 Date : 2013-05-13 Abstract: As IPv6 becomes more widely adopted, some service providers are taking the approach of deploying IPv6 only networks, without dual- stack functionality for IPv4. However, access to IPv4 based services is still an ongoing requirement and approaches such as IPv4-in-IPv6 softwire tunnels are being developed to meet this need. In order to provision end-user's hosts with the necessary IPv4 configuration, a number of different mechanisms have been proposed. This memo discusses the benefits and drawbacks of each, with the aim of recommending a single approach as the basis for future work. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dhc-v4configuration There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-dhc-v4configuration-00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Mon May 13 10:55:50 2013 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 149D821F939E; Mon, 13 May 2013 10:55:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.293 X-Spam-Level: X-Spam-Status: No, score=-102.293 tagged_above=-999 required=5 tests=[AWL=0.307, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mERm17y4yZFV; Mon, 13 May 2013 10:55:48 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EEF321F92EC; Mon, 13 May 2013 10:55:48 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.44.p7 Message-ID: <20130513175548.31347.2940.idtracker@ietfa.amsl.com> Date: Mon, 13 May 2013 10:55:48 -0700 Cc: dhcwg@ietf.org Subject: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-stateful-issues-04.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 May 2013 17:55:50 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Dynamic Host Configuration Working Group = of the IETF. Title : Issues with multiple stateful DHCPv6 options Author(s) : Ole Troan Bernie Volz Filename : draft-ietf-dhc-dhcpv6-stateful-issues-04.txt Pages : 10 Date : 2013-05-13 Abstract: Dynamic Host Configuration Protocol for IPv6 (DHCPv6) was not written with the expectation that additional stateful DHCPv6 options would be developed. IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6 shoe-horned the new options for Prefix Delegation into DHCPv6. Implementation experience of the CPE model described in [RFC6204] has shown multiple issues with the DHCPv6 protocol in supporting multiple stateful options. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv6-stateful-issues There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-stateful-issues-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dhc-dhcpv6-stateful-issues-04 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From volz@cisco.com Mon May 13 11:04:28 2013 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 96DC921F8733 for ; Mon, 13 May 2013 11:04:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aF+acR5EjpKL for ; Mon, 13 May 2013 11:04:23 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 4892721F854E for ; Mon, 13 May 2013 11:04:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8118; q=dns/txt; s=iport; t=1368468262; x=1369677862; h=from:to:subject:date:message-id:mime-version; bh=fyW0V/71dIQirZFUYeCcBi+StRiBUjm0lzV/+W/4gRw=; b=YUBK1m5VOTr6pYeilQNAyiyoemurZFC4nsRbfvcOzVe8a5w3ERVJfPlX ITSq+RX7q0fx0yj6mmBa3n4vezk8LQiYI82wq1E02nkPac7pQi5qOGXqU 3K9lRnY2AOv4B4UEIw9ThgCTt7cLhbuxDOUErP/E40ywIIEkOGgnGF3kK M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiEFAPspkVGtJXG9/2dsb2JhbABagkNEN8AtgQoWbQeCIQEELV4BKlYmAQQbiASce58FjneDLGEDqGGDD4In X-IronPort-AV: E=Sophos;i="4.87,663,1363132800"; d="scan'208,217";a="209852821" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-7.cisco.com with ESMTP; 13 May 2013 18:04:18 +0000 Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id r4DI4IW9016036 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 13 May 2013 18:04:18 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.77]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.02.0318.004; Mon, 13 May 2013 13:04:18 -0500 From: "Bernie Volz (volz)" To: "dhcwg@ietf.org" Thread-Topic: draft-ietf-dhc-dhcpv6-stateful-issues-04.txt Thread-Index: Ac5QAvUDsFRrksIIRV+zpvPNaflc4A== Date: Mon, 13 May 2013 18:04:17 +0000 Message-ID: <489D13FBFA9B3E41812EA89F188F018E18558444@xmb-rcd-x04.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.255.11] Content-Type: multipart/alternative; boundary="_000_489D13FBFA9B3E41812EA89F188F018E18558444xmbrcdx04ciscoc_" MIME-Version: 1.0 Subject: [dhcwg] draft-ietf-dhc-dhcpv6-stateful-issues-04.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 May 2013 18:04:28 -0000 --_000_489D13FBFA9B3E41812EA89F188F018E18558444xmbrcdx04ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi: This is an updated version of this document. It includes a few minor change= s from the WG last call and is there mostly to restore this document as it = has expired a few days ago. I still have a bunch of the comments from the WG Last Call in January/Febru= ary to address. There is also one key issue that will need some discussion from the WG. In = particular, handling of Rebind requests. One major flaw with respect to the Rebind message handling in RFC 3315 and = this draft is that as the client has sent the Rebind to multiple servers, a= ll of which could respond, there is no way for a particular server to know = whether its Reply will be accepted by the client. This is essentially the s= ame issue with using Rapid Commit in a Solicit when there are multiple serv= ers available. I think the Rebind processing should essentially be changed so that a serve= r will either return everything the client requested to be rebound (and not= hing more) or nothing (in which case it returns NoBinding status for all bi= ndings). If the server is willing to extend (or grant) the existing leases, the Rebi= nd is fine. If the server is unwilling or unable, then it should force the = client back into a Request phase as described in RFC 3315 section 18.1.8. = That 18.1.8 section is also the only place a NoBinding status appears to be= mentioned in terms of the Rebind. - Bernie --_000_489D13FBFA9B3E41812EA89F188F018E18558444xmbrcdx04ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi:

 

This is an updated version of this document. It incl= udes a few minor changes from the WG last call and is there mostly to resto= re this document as it has expired a few days ago.

 

I still have a bunch of the comments from the WG Las= t Call in January/February to address.

 

There is also one key issue that will need some disc= ussion from the WG. In particular, handling of Rebind requests.<= /p>

 

One major flaw with respect to the Rebind message ha= ndling in RFC 3315 and this draft is that as the client has sent the Rebind= to multiple servers, all of which could respond, there is no way for a par= ticular server to know whether its Reply will be accepted by the client. This is essentially the same issue w= ith using Rapid Commit in a Solicit when there are multiple servers availab= le.

 

I think the Rebind processing should essentially be = changed so that a server will either return everything the client requested= to be rebound (and nothing more) or nothing (in which case it returns NoBi= nding status for all bindings).

 

If the server is willing to extend (or grant) the ex= isting leases, the Rebind is fine. If the server is unwilling or unable, th= en it should force the client back into a Request phase as described in RFC= 3315 section  18.1.8. That 18.1.8 section is also the only place a NoBinding status appears to be mentioned = in terms of the Rebind.

 

-     &= nbsp;    Bernie

--_000_489D13FBFA9B3E41812EA89F188F018E18558444xmbrcdx04ciscoc_-- From volz@cisco.com Mon May 13 14:31:36 2013 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 E63C021F942D for ; Mon, 13 May 2013 14:31:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NjXU+ojIK2f0 for ; Mon, 13 May 2013 14:31:31 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 40A1621F944C for ; Mon, 13 May 2013 14:31:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9688; q=dns/txt; s=iport; t=1368480689; x=1369690289; h=from:to:subject:date:message-id:mime-version; bh=Gd+jcrFcdeW7fwgKY5I+6I4C2NIMlVPTuzR2rdqltZ0=; b=cCvZ8Y567hl602XsG13nrm4S3qgzWSZ0EsuqhrYXr8wDZ+g8Fd6xqnoY KTgTRvFbe6m5Xbz67PaX4R6s9UuuYYXocpVtxczzmluZiGzIyh4HEJ+l2 VRpMtcG9Sm460bXdVW9csBXny4qYAPjcgTKevNJq1J6VMEOi2bruyMRgq k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjoFAChbkVGtJXG8/2dsb2JhbABagkNEN7dziD6BDBZtB4IfAQEBBB0QXgEIEQQBAQsdORQJCQEEEwiIBAycdp8kjXaBATeCdWEDmFKQD4FXgTiBcjU X-IronPort-AV: E=Sophos;i="4.87,665,1363132800"; d="scan'208,217";a="209768769" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-1.cisco.com with ESMTP; 13 May 2013 21:31:28 +0000 Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id r4DLVSWD024603 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 13 May 2013 21:31:28 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.77]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.02.0318.004; Mon, 13 May 2013 16:31:28 -0500 From: "Bernie Volz (volz)" To: "dhcwg@ietf.org" Thread-Topic: [dhcwg] WG Adoption Call RESULT - draft-bhandari-dhc-access-network-identifier-04 Thread-Index: Ac5QIQGg6F25xpQjTEGwhs6KYiQewg== Date: Mon, 13 May 2013 21:31:27 +0000 Message-ID: <489D13FBFA9B3E41812EA89F188F018E185588B5@xmb-rcd-x04.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.255.11] Content-Type: multipart/alternative; boundary="_000_489D13FBFA9B3E41812EA89F188F018E185588B5xmbrcdx04ciscoc_" MIME-Version: 1.0 Subject: Re: [dhcwg] WG Adoption Call RESULT - draft-bhandari-dhc-access-network-identifier-04 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 May 2013 21:31:36 -0000 --_000_489D13FBFA9B3E41812EA89F188F018E185588B5xmbrcdx04ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi: Sorry for the delay in announcing the result ... we feel that this document= has sufficient support to adopt in the working group. And, as there isn't = another home for this work within the IETF, it is appropriate for the DHC W= G to take it on. Authors, please publish a WG document as soon as you can. - Tomek & Bernie From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of B= ernie Volz (volz) Sent: Wednesday, April 17, 2013 9:33 AM To: dhcwg@ietf.org Subject: [dhcwg] WG Adoption Call - draft-bhandari-dhc-access-network-ident= ifier-04 - Ends May 2, 2013 Hi all: The authors have requested a call for adoption by the WG for draft-bhandari= -dhc-access-network-identifier-04. This call is being initiated to confirm whether there is WG consensus to ad= opt this work as DHC WG draft. Please state whether or not you're in favor = of the adoption by replying to this mail. If you are not in favor, please a= lso state your objections in your response. This adoption call will complet= e on May 2nd, 2013. Note that the 04 draft was just published and has redesigned options to bet= ter follow the option guidelines. The HTML version of the document can be viewed at http://tools.ietf.org/htm= l/draft-bhandari-dhc-access-network-identifier-04. Regards, Tomek & Bernie --_000_489D13FBFA9B3E41812EA89F188F018E185588B5xmbrcdx04ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi:<= /p>

 

Sorry for the delay in= announcing the result … we feel that this document has sufficient su= pport to adopt in the working group. And, as there isn’t another home= for this work within the IETF, it is appropriate for the DHC WG to take it on.

 

Authors, please publis= h a WG document as soon as you can.

 

-&nb= sp;         Tomek & Be= rnie

 

From: dhcwg-bo= unces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of Bernie Volz (volz)
Sent: Wednesday, April 17, 2013 9:33 AM
To: dhcwg@ietf.org
Subject: [dhcwg] WG Adoption Call - draft-bhandari-dhc-access-networ= k-identifier-04 - Ends May 2, 2013

 

Hi all:

 

The authors have requested a call for adoption by= the WG for draft-bhandari-dhc-access-network-identifier-04.

 

This call is being initiated to confirm whether t= here is WG consensus to adopt this work as DHC WG draft. Please state wheth= er or not you're in favor of the adoption by replying to this mail. If you = are not in favor, please also state your objections in your response. This adoption call will complete on May = 2nd, 2013.

 

Note that the 04 draft was just published and has= redesigned options to better follow the option guidelines.

 

The HTML version of the document can be viewed at= http://tools.ietf.org/html/draft-bhandari-dhc-access-network-identifier-04<= /a>.

 

Regards,

Tomek & Bernie

 

--_000_489D13FBFA9B3E41812EA89F188F018E185588B5xmbrcdx04ciscoc_-- From wwwrun@rfc-editor.org Tue May 14 14:12:25 2013 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 A555721F8F0F; Tue, 14 May 2013 14:12:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.72 X-Spam-Level: X-Spam-Status: No, score=-101.72 tagged_above=-999 required=5 tests=[AWL=0.280, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I8AfnDUA3s6s; Tue, 14 May 2013 14:12:25 -0700 (PDT) Received: from rfc-editor.org (unknown [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 361CD21F918C; Tue, 14 May 2013 14:12:25 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 282BD72E15E; Tue, 14 May 2013 14:12:20 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20130514211220.282BD72E15E@rfc-editor.org> Date: Tue, 14 May 2013 14:12:20 -0700 (PDT) Cc: dhcwg@ietf.org, rfc-editor@rfc-editor.org Subject: [dhcwg] RFC 6939 on Client Link-Layer Address Option in DHCPv6 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 May 2013 21:12:25 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6939 Title: Client Link-Layer Address Option in DHCPv6 Author: G. Halwasia, S. Bhandari, W. Dec Status: Standards Track Stream: IETF Date: May 2013 Mailbox: ghalwasi@cisco.com, shwethab@cisco.com, wdec@cisco.com Pages: 7 Characters: 14739 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt-05.txt URL: http://www.rfc-editor.org/rfc/rfc6939.txt This document specifies the format and mechanism that is to be used for encoding the client link-layer address in DHCPv6 Relay-Forward messages by defining a new DHCPv6 Client Link-Layer Address option. This document is a product of the Dynamic Host Configuration Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. 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 From internet-drafts@ietf.org Tue May 14 23:32:39 2013 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 0699421F8E8F; Tue, 14 May 2013 23:32:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.47 X-Spam-Level: X-Spam-Status: No, score=-102.47 tagged_above=-999 required=5 tests=[AWL=0.130, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JTEnW27Ev5c7; Tue, 14 May 2013 23:32:37 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E8E621F89FD; Tue, 14 May 2013 23:32:37 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.45 Message-ID: <20130515063208.19345.26747.idtracker@ietfa.amsl.com> Date: Tue, 14 May 2013 23:32:08 -0700 Cc: dhcwg@ietf.org Subject: [dhcwg] I-D Action: draft-ietf-dhc-access-network-identifier-00.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 May 2013 06:32:39 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Dynamic Host Configuration Working Group = of the IETF. Title : Access-Network-Identifier Option in DHCP Author(s) : Shwetha Bhandari Sri Gundavelli Jouni Korhonen Mark Grayson Filename : draft-ietf-dhc-access-network-identifier-00.txt Pages : 16 Date : 2013-05-14 Abstract: This document specifies the format and mechanism that is to be used for encoding access network identifiers in DHCPv4 and DHCPv6 messages by defining new access network identifier options and sub-options. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dhc-access-network-identifier There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-dhc-access-network-identifier-00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From Branimir.Rajtar@t.ht.hr Wed May 15 02:26:21 2013 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 9880B21F8C69 for ; Wed, 15 May 2013 02:26:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_53=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xjadZaBnnkn8 for ; Wed, 15 May 2013 02:26:17 -0700 (PDT) Received: from mx02.t.ht.hr (mx02.t.ht.hr [195.29.161.89]) by ietfa.amsl.com (Postfix) with SMTP id D7D8B21F84E3 for ; Wed, 15 May 2013 02:26:16 -0700 (PDT) Received: from no.name.available by mx02.t.ht.hr via smtpd (for mail.ietf.org [12.22.58.30]) with ESMTP; Wed, 15 May 2013 10:54:08 +0200 Received: from (unknown [172.17.66.76]) by scmg2.t.ht.hr with smtp id 4b5d_0a6c_7d8aae7a_bd41_11e2_a9cb_00219b931f47; Wed, 15 May 2013 11:26:14 +0200 Received: (private information removed) Wed, 15 May 2013 11:26:15 +0200 Received: (private information removed) S2010EXCHCA1.ad.local ([::1]) with mapi id 14.03.0123.003; Wed, 15 May 2013 11:26:14 +0200 From: Branimir Rajtar To: "dhcwg@ietf.org" Thread-Topic: [dhcwg] Conclusion for draft-ietf-dhc-v4configuration-00 Thread-Index: AQHOTJ2H64FCJbHVAUivUsccszBjPJkGAXhQ Date: Wed, 15 May 2013 09:26:13 +0000 Message-ID: <786F13AA11E69F4DB2CCA23F7400C2FB0142D318@S2010EXCH1.ad.local> References: <8A1B81989BCFAE44A22B2B86BF2B7631898DB0232B@HE111643.EMEA1.CDS.T-INTERNAL.COM> <51780A17.8010503@gmail.com> <489D13FBFA9B3E41812EA89F188F018E18552B99@xmb-rcd-x04.cisco.com> <518B7628.3020309@gmail.com> In-Reply-To: <518B7628.3020309@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.17.5.13] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginalArrivalTime: 15 May 2013 09:26:15.0163 (UTC) FILETIME=[3F4CF4B0:01CE514E] X-NAIMIME-Disclaimer: 1 X-NAIMIME-Modified: 1 Subject: [dhcwg] Conclusion for draft-ietf-dhc-v4configuration-00 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 May 2013 09:26:22 -0000 SGkgYWxsLCAKCkZvbGxvd2luZyBvbiBUb21laydzIGUtbWFpbCBhbmQgdGhlIHVwbG9hZCBvZiBk cmFmdC1pZXRmLWRoYy12NGNvbmZpZ3VyYXRpb24tMDAsIHRoZSBhdXRob3JzIHdvdWxkIGxpa2Ug dG8gc3RhcnQgdGhlIGRpc2N1c3Npb24gb24gaXQncyBjb25jbHVzaW9uLiBGb2xsb3dpbmcgdGhl IHRhbGsgb24gdGhlIG1haWxpbmcgbGlzdCwgb3VyIHByb3Bvc2FsIGlzIGFzIGZvbGxvd3M6Cgoi V2hpbHN0IGFsbCBvZiB0aGUgYXBwcm9hY2hlcyBkZXNjcmliZWQgaGVyZSB3aWxsIHJlcXVpcmUg c29tZSBkZXZlbG9wbWVudCB3b3JrIGluIG9yZGVyIHRvIHJlYWxpemUsIGl0IGlzIGNsZWFyIGZy b20gdGhlIGFib3ZlIGFuYWx5c2lzIHRoYXQgdGhlIG1vc3Qgc3VzdGFpbmFibGUgYXBwcm9hY2gg Y2FwaXRhbGl6ZXMgb24gZXhpc3RpbmcgREhDUHY0IGltcGxlbWVudGF0aW9ucyBhbmQgaW5jbHVk ZSB0aGVtIGFzIG5ldyBESENQdjYgbWVzc2FnZSB0eXBlcy4gIFRoZSBtYWluIHJhdGlvbmFsZSBm b3IgdGhpcyBpcyB0aGF0IGl0IGVuYWJsZXMgYWxsIG9mIERIQ1B2NCdzIGV4aXN0aW5nIG9wdGlv bnMgdG8gYmUgbWlncmF0ZWQgZm9yIHVzZSBvdmVyIElQdjYgaW4gYSBzaW5nbGUgc3RlcC4KClBv cnRpbmcgb2YgYWxsIG5lY2Vzc2FyeSBESENQdjQgb3B0aW9ucyB0byBESENQdjYgd291bGQgcmVx dWlyZSBvbmdvaW5nIGRldmVsb3BtZW50IHdvcmssIHJlLWltcGxlbWVudGluZyBleGlzdGluZyBE SENQdjQgZnVuY3Rpb25hbGl0eSBpbiBESENQdjYuICBUaGlzIHdpbGwgcmVzdWx0IGluIGhhdmlu ZyBsZWdhY3kgREhDUHY0IG9wdGlvbnMgaW4gREhDUHY2LCB3aGljaCB3aWxsIG5vIGxvbmdlciBi ZSB1c2VmdWwgb25jZSBJUHY0IGlzIGNvbXBsZXRlbHkgYWJhbmRvbmVkLgogClRoZXJlZm9yZSwg dGhlIERIQ1B2NiBhcHByb2FjaCBpcyBub3Qgc3VpdGFibGUgZm9yIGRlbGl2ZXJpbmcgSVB2NCBj b25maWd1cmF0aW9uIHBhcmFtZXRlcnMgaW4gYW4gZWZmaWNpZW50LCBvbmdvaW5nIG1hbm5lci4K IApUaGUgZHluYW1pY2FsIGxlYXNpbmcgb2YgSVB2NCBhZGRyZXNzZXMgaXMgZnVuZGFtZW50YWwg dG8gdGhlIGVmZmljaWVudCB1c2Ugb2YgcmVtYWluaW5nIElQdjQgcmVzb3VyY2VzLiBUaGlzIHdp bGwgYmVjb21lIGluY3JlYXNpbmdseSBpbXBvcnRhbnQgaW4gdGhlIGZ1dHVyZSwgc28gYSBtZWNo YW5pc20gd2hpY2ggc3VwcG9ydHMgdGhpcyBpcyBuZWNlc3NhcnkuIERIQ1B2NG9TVyBkb2VzIG5v dCBwcm92aWRlIHRoaXMgZnVuY3Rpb24gYW5kIHNvIGlzIG5vdCByZWNvbW1lbmRlZC4KClRoZSBE SENQdjRvNiBhcHByb2FjaCByZXF1aXJlcyBhIERIQ1B2NCBzZXJ2ZXIgKHdpdGggREhDUHY0bzYg ZnVuY3Rpb25hbGl0eSkgZm9yIGFsbCBkZXBsb3ltZW50IHNjZW5hcmlvcywgZXZlbiB3aGVuIERI Q1B2NCBzcGVjaWZpYyBmdW5jdGlvbmFsaXR5IGlzIG5vdCByZXF1aXJlZCBieSB0aGUgb3BlcmF0 b3IuCgpUaGVyZWZvcmUsIHRoaXMgbWVtbyByZWNvbW1lbmRzIERIQ1B2NG9ESENQdjYgPEktRC5p ZXRmLWRoYy1kaGNwdjQtb3Zlci1kaGNwdjY+IGFzIHRoZSBiZXN0IHVuZGVybHlpbmcgYXBwcm9h Y2ggZm9yIHByb3Zpc2lvbmluZyBJUHY0IHBhcmFtZXRlcnMgb3ZlciBhbiBJUHY2IG9ubHkgbmV0 d29yay4iCgpBbHNvLCB3ZSBwcm9wb3NlIHR3byBjaGFuZ2VzIHRvIHRoZSBkb2N1bWVudCBpdHNl bGYgd2hpY2ggd2UgZmluZCBzaG91bGQgYmV0dGVyIHJlZmxlY3QgdGhlIG92ZXJ2aWV3IG9mIGFs bCBwcm9wb3NhbHM6CjEuIFNlY3Rpb24gMywgcmVxdWlyZW1lbnQgbm8uIDYgLSBzaG91bGQgYmUg Ik5vIiBmb3IgREhDUHY0bzYgCjEuIFNlY3Rpb24gMywgcmVxdWlyZW1lbnQgbm8uIDEgLSBzaG91 bGQgYmUgIk5vIiBmb3IgREhDUHY0b1NXCgpCUiwKQnJhbmltaXIKCgotLS0tLU9yaWdpbmFsIE1l c3NhZ2UtLS0tLQpGcm9tOiBkaGN3Zy1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86ZGhjd2ctYm91 bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFRvbWVrIE1ydWdhbHNraQpTZW50OiBUaHVyc2Rh eSwgTWF5IDA5LCAyMDEzIDEyOjExIFBNClRvOiBkaGN3Z0BpZXRmLm9yZwpTdWJqZWN0OiBSZTog W2RoY3dnXSBBZG9wdGlvbiBjYWxsIGZvciBkcmFmdC1yYWp0YXItZGhjLXY0Y29uZmlndXJhdGlv bi0wMiAtIGFkb3B0ZWQhCgpPbiAxMy0wNS0wOCAxNTo1MSwgQmVybmllIFZvbHogKHZvbHopIHdy b3RlOgo+IDIuIChXRyBjby1jaGFpciBoYXQgb24pOiBJZiB5b3UgaGF2ZSBub3QgZXhwcmVzc2Vk IHN1cHBvcnQgb3Igb3Bwb3NpdGlvbiBmb3IgYWRvcHRpbmcgdGhpcyB3b3JrLCB0aGUgY2FsbCBl eHBpcmVzIHRvZGF5IQpIaSwKCkFsdGhvdWdoIHRoaXMgYWRvcHRpb24gY2FsbCBsb29rZWQgYSBi aXQgZ3JpbSBmb3IgdGhlIGZpcnN0IDEwIGRheXMsCmxhcmdlIHN1cHBvcnQgdm9pY2VkIGluIHRo ZSBsYXN0IGNvdXBsZSBkYXlzIHNhdmVkIHRoZSBkYXkuIFdlIGhhdmUKYXJvdW5kIGEgZG96ZW4g c3VwcG9ydCB2b2ljZXMsIHdoaWNoIG1lYW5zIHRoYXQgdGhpcyBJLUQgd2FzIGFkb3B0ZWQuCgpB dXRob3JzLCBwbGVhc2UgdXBsb2FkIGl0IGFzIGRyYWZ0LWlldGYtZGhjLXY0Y29uZmlndXJhdGlv bi0wMC4gT25jZQp0aGF0IGlzIGRvbmUsIEkgZW5jb3VyYWdlIGF1dGhvcnMgdG8gc3RhcnQgYSBk aXNjdXNzaW9uIGFib3V0CnJlY29tbWVuZGF0aW9uIHRoYXQgdGhlIFdHIHdhbnRzIHRvIG9mZmVy LgoKSXQgaXMgYSBwbGVhc3VyZSB0byBzZWUgc3VjaCBhIHN0cm9uZyBjb25zZW5zdXMuIExldCdz IGhvcGUgdGhhdCB0aGUKZGlzY3Vzc2lvbiBhYm91dCB3cml0aW5nIENvbmNsdXNpb24gc2VjdGlv biB3aWxsIGhhdmUgZXF1YWxseSBzdHJvbmcKY29uc2Vuc3VzLgoKQmVybmllICYgVG9tZWsKCl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCmRoY3dnIG1haWxp bmcgbGlzdApkaGN3Z0BpZXRmLm9yZwpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL2RoY3dnCgoKPEhUTUw+PFA+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj0jOTk5OTk5IHNpemU9 MT4NCg0KSVpKQVZBIE8gT0RSSUNBTkpVIE9ER09WT1JOT1NUSTogU2FkcsW+YWogb3ZlIHBvcnVr ZSBpIGV2ZW50dWFsbm8gcHJpbG/FvmVuaWggZGF0b3Rla2EgamUgcG92amVybGppdiBpIG5hbWlq ZW5qZW4gamUgc2FtbyBvc29iYW1hIGlsaSBzdWJqZWt0aW1hIGtvamkgc3UgbmF2ZWRlbmkgdSBh ZHJlc2kuIFVrb2xpa28gc3RlIHByaW1pbGkgb3Z1IHBvcnVrdSBncmXFoWtvbSwgbW9saW1vIFZh cywgb2JhdmlqZXN0aXRlIHBvxaFpbGphdGVsamEsIGEgcG9ydWt1IGkgc3ZlIG5qZW5lIHByaXZp dGtlIG9kbWFoLCBiZXogxI1pdGFuamEsIHRyYWpubyB1a2xvbml0ZSBzIHJhxI11bmFsYS4gQmls byBrYWt2byBwcmVub8WhZW5qZSwga29waXJhbmplIGlsaSBkaXN0cmlidWNpamEgaW5mb3JtYWNp amEgc2FkcsW+YW5paCB1IHBvcnVjaSB0cmXEh2ltIG9zb2JhbWEgamUgemFicmFuamVubyBpIG1v xb5lIGJpdGkgemFrb25za2kga2HFvm5qaXZvLiBTYWRyxb5haiwgc3Rhdm92aSBpIG1pxaFsamVu amEgaXpuZXNlbmkgdSBwb3J1Y2kgc3UgYXV0b3JvdmkgaSBuZSBwcmVkc3RhdmxqYWp1IG51xb5u byBzdGF2b3ZlIEhUIC0gSHJ2YXRza2loIHRlbGVrb211bmlrYWNpamEgZC5kLiBIVCBuZSBwcmlo dmHEh2EgbmlrYWt2dSBvZGdvdm9ybm9zdCB6YSBldmVudHVhbG51IMWhdGV0dSBuYXN0YWx1IHBy aW1pdGtvbSBvdmUgcG9ydWtlIGkgcHJpbG9nYSBzYWRyxb5hbmloIHUgcG9ydWNpLg0KDQo8L0ZP TlQ+PC9QPjxQPjxGT05UIGZhY2U9QXJpYWwgY29sb3I9Izk5OTk5OSBzaXplPTE+DQoNCiBESVND TEFJTUVSOlRoZSBjb250ZW50cyBvZiB0aGlzIGVtYWlsIGFzIHdlbGwgYXMgYW55IGZpbGVzIGF0 dGFjaGVkIHRvIGl0IGFyZSBjb25maWRlbnRpYWwgYW5kIGludGVuZGVkIHNvbGVseSBmb3IgaW5k aXZpZHVhbHMgb3IgZW50aXRpZXMgd2hpY2ggdGhleSBhcmUgYWRkcmVzc2VkIHRvLiBJZiB5b3Ug aGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIG1lc3NhZ2UgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkg dGhlIHNlbmRlciBhbmQgcGVybWFuZW50bHkgcmVtb3ZlIHRoZSBtZXNzYWdlIGFuZCBhbGwgYXR0 YWNoZWQgZmlsZXMgZnJvbSB0aGUgY29tcHV0ZXIuIEFueSBkaXNjbG9zdXJlLCBjb3B5aW5nIG9y IGRpc3RyaWJ1dGlvbiBvZiBhbGwgb3IgYSBwYXJ0IG9mIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBo ZXJlaW4gdG8gb3IgYnkgdGhpcmQgcGFydGllcyBpcyBwcm9oaWJpdGVkIGFuZCBtYXkgYmUgdW5s YXdmdWwuIFBsZWFzZSBub3RlIHRoYXQgYW55IHZpZXdzIG9yIG9waW5pb25zIHByZXNlbnRlZCBp biB0aGlzIG1lc3NhZ2UgYXJlIHNvbGVseSB0aG9zZSBvZiB0aGUgYXV0aG9yIGFuZCBkbyBub3Qg bmVjZXNzYXJpbHkgcmVwcmVzZW50IHRoZSB2aWV3cyBhbmQgb3BpbmlvbnMgb2YgQ3JvYXRpYW4g VGVsZWNvbSBJbmMuIENyb2F0aWFuIFRlbGVjb20gSW5jLiBhY2NlcHRzIG5vIGxpYWJpbGl0eSBm b3IgYW55IHBvdGVudGlhbCBkYW1hZ2UgY2F1c2VkIGJ5IHRoaXMgbWVzc2FnZSBhbmQgZmlsZXMg YXR0YWNoZWQgdG8gaXQuDQoNCjwvRk9OVD48L1A+PC9IVE1MPgo= From internet-drafts@ietf.org Wed May 15 04:28:41 2013 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 89BB821F8F32; Wed, 15 May 2013 04:28:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.479 X-Spam-Level: X-Spam-Status: No, score=-102.479 tagged_above=-999 required=5 tests=[AWL=0.121, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ykTntmbbJp94; Wed, 15 May 2013 04:28:41 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E76521F8EBE; Wed, 15 May 2013 04:28:41 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.45 Message-ID: <20130515112841.8270.77231.idtracker@ietfa.amsl.com> Date: Wed, 15 May 2013 04:28:41 -0700 Cc: dhcwg@ietf.org Subject: [dhcwg] I-D Action: draft-ietf-dhc-triggered-reconfigure-07.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 May 2013 11:28:41 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Dynamic Host Configuration Working Group = of the IETF. Title : Reconfigure Triggered by DHCPv6 Relay Agents Author(s) : Mohamed Boucadair Xavier Pougnard Filename : draft-ietf-dhc-triggered-reconfigure-07.txt Pages : 13 Date : 2013-05-15 Abstract: This document defines new DHCPv6 messages: Reconfigure-Request and Reconfigure-Reply. Reconfigure-Request message is sent by a DHCPv6 relay agent to notify a DHCPv6 server about a configuration information change, so that the DHCPv6 server can send a Reconfigure message accordingly. Reconfigure-Reply message is used by the server to acknowledge the receipt of Reconfigure-Request. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dhc-triggered-reconfigure There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-dhc-triggered-reconfigure-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dhc-triggered-reconfigure-07 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From Ted.Lemon@nominum.com Wed May 15 05:28:07 2013 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 9B06221F8F4D for ; Wed, 15 May 2013 05:28:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.287 X-Spam-Level: X-Spam-Status: No, score=-106.287 tagged_above=-999 required=5 tests=[AWL=-0.288, BAYES_00=-2.599, J_CHICKENPOX_31=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KOilo6SlAreZ for ; Wed, 15 May 2013 05:28:01 -0700 (PDT) Received: from exprod7og119.obsmtp.com (exprod7og119.obsmtp.com [64.18.2.16]) by ietfa.amsl.com (Postfix) with ESMTP id E740B21F89FD for ; Wed, 15 May 2013 05:28:00 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob119.postini.com ([64.18.6.12]) with SMTP ID DSNKUZN/UO93ltW6R/tU4FK3E4YWbU08gYUw@postini.com; Wed, 15 May 2013 05:28:00 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 876B21B818A for ; Wed, 15 May 2013 05:28:00 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 8104A19005D; Wed, 15 May 2013 05:28:00 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0318.004; Wed, 15 May 2013 05:27:54 -0700 From: Ted Lemon To: Branimir Rajtar Thread-Topic: [dhcwg] Conclusion for draft-ietf-dhc-v4configuration-00 Thread-Index: AQHOUU5GI1iD2yMrG0Kn8R4NGE3+oJkGofqA Date: Wed, 15 May 2013 12:27:53 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B63077519C2C9@mbx-01.win.nominum.com> References: <8A1B81989BCFAE44A22B2B86BF2B7631898DB0232B@HE111643.EMEA1.CDS.T-INTERNAL.COM> <51780A17.8010503@gmail.com> <489D13FBFA9B3E41812EA89F188F018E18552B99@xmb-rcd-x04.cisco.com> <518B7628.3020309@gmail.com> <786F13AA11E69F4DB2CCA23F7400C2FB0142D318@S2010EXCH1.ad.local> In-Reply-To: <786F13AA11E69F4DB2CCA23F7400C2FB0142D318@S2010EXCH1.ad.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dhcwg@ietf.org" Subject: Re: [dhcwg] Conclusion for draft-ietf-dhc-v4configuration-00 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 May 2013 12:28:07 -0000 I think this text is good. From gvithal@gmail.com Wed May 15 06:00:26 2013 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 9441A21F85DC for ; Wed, 15 May 2013 06:00:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8l23fM3JTzw5 for ; Wed, 15 May 2013 06:00:26 -0700 (PDT) Received: from mail-ve0-x234.google.com (mail-ve0-x234.google.com [IPv6:2607:f8b0:400c:c01::234]) by ietfa.amsl.com (Postfix) with ESMTP id 418D821F84B1 for ; Wed, 15 May 2013 06:00:25 -0700 (PDT) Received: by mail-ve0-f180.google.com with SMTP id pa12so1902487veb.39 for ; Wed, 15 May 2013 06:00:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=VcNlZRZxH3HAvxTjPWRlmXHjiYXBBnVFecrAfb2D6lE=; b=GcX7xrl1l4+LKu/AtkEeAmkVq3dhxZZeyrDzqSNGhBrB7IE8SJbQkmRiQKwY9GbK+i DrpRu2zjFO68c+bCGAvm6hu56qIYLLQvBv1fjiyCj8DCjZH38xwLaowB6ah+h17WUHY0 vaGBlKSFQ6BW5OrcrfcVJcGbnGN4xCWCVag/t5a/5ZH25xce0ASDMJPoEJW/DHCSmuRn KvCZht3WORD4gRx99ynNT6a3TCnMikdq2JFgSzWyXFDt8EpFLIthYqgSRk48c9B6u6a6 24sb+93tez03BWSBgNii2D4yMND6QA9zyeGqFvCjR9z9/gJr+td08t3bbAkAV5wgtvjm G0bA== MIME-Version: 1.0 X-Received: by 10.220.73.199 with SMTP id r7mr16845912vcj.67.1368622824684; Wed, 15 May 2013 06:00:24 -0700 (PDT) Received: by 10.58.171.106 with HTTP; Wed, 15 May 2013 06:00:24 -0700 (PDT) Date: Wed, 15 May 2013 18:30:24 +0530 Message-ID: From: "gvithal ." To: "" Content-Type: multipart/alternative; boundary=001a11c2abf84c006a04dcc1552e Subject: [dhcwg] Echoing back options in server response X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 May 2013 13:00:26 -0000 --001a11c2abf84c006a04dcc1552e Content-Type: text/plain; charset=ISO-8859-1 Does RFC 3315 mandate that DHCPv6 server should echo back all options in the client request message in its response even if the server does not support a specific option. For example, if the client message contains vendor-specific information option (section 22.17 rfc 3315), does the server need to echo back the same option in its response even if does not support that option. Thanks, Prasad --001a11c2abf84c006a04dcc1552e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Does RFC 3315 mandate that DHCPv6 server should echo back = all options in the client request message in its response even if the serve= r does not support a specific option.
For example, if the client = message contains vendor-specific information option (section 22.17 rfc 3315= ), does the server need to echo back the same option in its response even i= f does not support that option.

Thanks,
Prasad
--001a11c2abf84c006a04dcc1552e-- From volz@cisco.com Wed May 15 06:05:04 2013 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 23E9721F8FF1 for ; Wed, 15 May 2013 06:05:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.299 X-Spam-Level: X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_31=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EAHWPhdc3oWC for ; Wed, 15 May 2013 06:04:59 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 4E1C421F85EF for ; Wed, 15 May 2013 06:04:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=907; q=dns/txt; s=iport; t=1368623099; x=1369832699; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=4ynnsX/czTdGEYpkPH69kTp9oZeeX8SGvPGoWTa+vHk=; b=SVH/Tg7p3HdIQCZVCjEhClXU0Mdak1THMbyTwJmIYiQoJfRjf1f2uNsx /8XZLBJSYLpcEAuOUoWg0CrioxsTt7lWObEW9Hy5UgiUt7YpZNuMM20is d/PSnJRvQW64W3RAfinwq4jXek8e8Yq+3ndZj9jtpJFMEXDWrQ7lixEYc 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjgFALSGk1GtJXG+/2dsb2JhbABbgwc3gnW9XXkWdIIgAQEEAQEBNzQLEAIBCDYQJwslAgQOBYgMDLx5BI5rMweCdGEDlzSRPYMP X-IronPort-AV: E=Sophos;i="4.87,677,1363132800"; d="scan'208";a="210761846" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-8.cisco.com with ESMTP; 15 May 2013 13:04:58 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id r4FD4wej005217 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 15 May 2013 13:04:58 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.77]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.02.0318.004; Wed, 15 May 2013 08:04:58 -0500 From: "Bernie Volz (volz)" To: Ted Lemon Thread-Topic: [dhcwg] Conclusion for draft-ietf-dhc-v4configuration-00 Thread-Index: AQHOUWer9Ia2wAOKBEeecA8Xo7LWYZkGNslt Date: Wed, 15 May 2013 13:04:57 +0000 Message-ID: References: <8A1B81989BCFAE44A22B2B86BF2B7631898DB0232B@HE111643.EMEA1.CDS.T-INTERNAL.COM> <51780A17.8010503@gmail.com> <489D13FBFA9B3E41812EA89F188F018E18552B99@xmb-rcd-x04.cisco.com> <518B7628.3020309@gmail.com> <786F13AA11E69F4DB2CCA23F7400C2FB0142D318@S2010EXCH1.ad.local>, <8D23D4052ABE7A4490E77B1A012B63077519C2C9@mbx-01.win.nominum.com> In-Reply-To: <8D23D4052ABE7A4490E77B1A012B63077519C2C9@mbx-01.win.nominum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dhcwg@ietf.org" , "sunqi@csnet1.cs.tsinghua.edu.cn" Subject: Re: [dhcwg] Conclusion for draft-ietf-dhc-v4configuration-00 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 May 2013 13:05:04 -0000 Yes, I concur (with dhc co-chair hat off). I think section 3.3.2 has mistakes ... It misses changing relays to relay t= he new messages (but perhaps it assumes that the unknown messages draft has= already been implemented). And it is really the dhcpv4 client that needs t= o change to send / receive the new messages (#2 says dhcpv6 clients). One issue which is more for the actual draft on this method is how does dhc= pv4 client determine to do this (send over v6) rather than attempt normal d= hcpv4 - or perhaps client tries both methods at same time? But that's likel= y an issue for all if the techiques. - Bernie On May 15, 2013, at 8:28 AM, "Ted Lemon" wrote: > I think this text is good. >=20 > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg From Ted.Lemon@nominum.com Wed May 15 06:07:16 2013 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 3CB7E21F899E for ; Wed, 15 May 2013 06:07:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.578 X-Spam-Level: X-Spam-Status: No, score=-106.578 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VAqUGih2x+1C for ; Wed, 15 May 2013 06:07:05 -0700 (PDT) Received: from exprod7og116.obsmtp.com (exprod7og116.obsmtp.com [64.18.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 79C2C21F85EF for ; Wed, 15 May 2013 06:07:05 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob116.postini.com ([64.18.6.12]) with SMTP ID DSNKUZOIeVXueOdhHZKrlBUzfEN/q2f3b2cF@postini.com; Wed, 15 May 2013 06:07:05 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id D62871B818F for ; Wed, 15 May 2013 06:07:04 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id CD3FC19005D; Wed, 15 May 2013 06:07:04 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.02.0318.004; Wed, 15 May 2013 06:06:59 -0700 From: Ted Lemon To: "gvithal ." Thread-Topic: [dhcwg] Echoing back options in server response Thread-Index: AQHOUWwuQ6YTCZdyVEuzg09X4WcfnJkGrKkA Date: Wed, 15 May 2013 13:06:57 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B63077519C4C4@mbx-01.win.nominum.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: multipart/alternative; boundary="_000_8D23D4052ABE7A4490E77B1A012B63077519C4C4mbx01winnominum_" MIME-Version: 1.0 Cc: "" Subject: Re: [dhcwg] Echoing back options in server response X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 May 2013 13:07:17 -0000 --_000_8D23D4052ABE7A4490E77B1A012B63077519C4C4mbx01winnominum_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable On May 15, 2013, at 9:00 AM, gvithal . > wrote: Does RFC 3315 mandate that DHCPv6 server should echo back all options in th= e client request message in its response even if the server does not suppor= t a specific option. For example, if the client message contains vendor-specific information opt= ion (section 22.17 rfc 3315), does the server need to echo back the same op= tion in its response even if does not support that option. No. There is a provision in RFC3315 that servers MAY do this, which is ac= tually an echo of the ancient provision in RFC2131 that servers MAY do it, = but I've never heard of anyone implementing this in a server, much less usi= ng it in a client. I argued against putting this into 3315, but found mys= elf on the rough side of consensus... :} --_000_8D23D4052ABE7A4490E77B1A012B63077519C4C4mbx01winnominum_ Content-Type: text/html; charset="iso-8859-1" Content-ID: <18AF167E5D3B5342BF493A0BDBFE5DFA@nominum.com> Content-Transfer-Encoding: quoted-printable
Does RFC 3315 mandate that DHCPv6 server should echo back all options in the cl= ient request message in its response even if the server does not support a = specific option.
For example, if the client message contains vendor-specific information opt= ion (section 22.17 rfc 3315), does the server need to echo back the same op= tion in its response even if does not support that option.

No.   There is a provision in RFC3315 that servers MAY do this, w= hich is actually an echo of the ancient provision in RFC2131 that servers M= AY do it, but I've never heard of anyone implementing this in a server, muc= h less using it in a client.   I argued against putting this into 3315, but found myself on the rough side of cons= ensus... :}

--_000_8D23D4052ABE7A4490E77B1A012B63077519C4C4mbx01winnominum_-- From Ted.Lemon@nominum.com Wed May 15 06:14:14 2013 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 84D8E21F901B for ; Wed, 15 May 2013 06:14:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.579 X-Spam-Level: X-Spam-Status: No, score=-106.579 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LMxixLnKE0ZC for ; Wed, 15 May 2013 06:14:07 -0700 (PDT) Received: from exprod7og123.obsmtp.com (exprod7og123.obsmtp.com [64.18.2.24]) by ietfa.amsl.com (Postfix) with ESMTP id 4BCD621F8FF1 for ; Wed, 15 May 2013 06:13:57 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob123.postini.com ([64.18.6.12]) with SMTP ID DSNKUZOKFGhFduVxsQLSJJsZIEWhbJECucOe@postini.com; Wed, 15 May 2013 06:13:57 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id C2F541B807E for ; Wed, 15 May 2013 06:13:56 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id B9A5D19005D; Wed, 15 May 2013 06:13:56 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.02.0318.004; Wed, 15 May 2013 06:13:56 -0700 From: Ted Lemon To: "Bernie Volz (volz)" Thread-Topic: [dhcwg] Conclusion for draft-ietf-dhc-v4configuration-00 Thread-Index: AQHOUWzOksvS2kVeK0CojhlacokdApkGrpoA Date: Wed, 15 May 2013 13:13:55 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B63077519C539@mbx-01.win.nominum.com> References: <8A1B81989BCFAE44A22B2B86BF2B7631898DB0232B@HE111643.EMEA1.CDS.T-INTERNAL.COM> <51780A17.8010503@gmail.com> <489D13FBFA9B3E41812EA89F188F018E18552B99@xmb-rcd-x04.cisco.com> <518B7628.3020309@gmail.com> <786F13AA11E69F4DB2CCA23F7400C2FB0142D318@S2010EXCH1.ad.local>, <8D23D4052ABE7A4490E77B1A012B63077519C2C9@mbx-01.win.nominum.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="Windows-1252" Content-ID: <55C27A8D7EFED141B054FD4A2F7EF62F@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dhcwg@ietf.org" , "sunqi@csnet1.cs.tsinghua.edu.cn" Subject: Re: [dhcwg] Conclusion for draft-ietf-dhc-v4configuration-00 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 May 2013 13:14:14 -0000 On May 15, 2013, at 9:04 AM, Bernie Volz (volz) wrote: > One issue which is more for the actual draft on this method is how does d= hcpv4 client determine to do this (send over v6) rather than attempt normal= dhcpv4 - or perhaps client tries both methods at same time? But that's lik= ely an issue for all if the techiques. This is worth documenting, if it's not clear in the draft: the DHCPv4 clien= t knows to do this because it's not a DHCPv4 client=97it's a DHCPv4-over-DH= CPv6 client. So it just assumes that DHCPv4-over-DHCPv6 is available and = tries to use it; if it succeeds, it is available, and if it fails, it's not= . It might additionally be worth talking about when it decides to try: wh= en it notices a device on the homenet trying to use IPv4 to access an off-n= etwork service, or does it do it as soon as it comes up? I guess we really haven't talked about how this works=97with DHCPv4-over-IP= v6, we'd intended to add a DHCPv6 option with the IP address of the DHCPv4-= over-IPv6 server, but with DHCPv4-over-DHCPv6 that's not necessary. From volz@cisco.com Wed May 15 06:15:44 2013 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 D101721F9017 for ; Wed, 15 May 2013 06:15:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pmJl8sOkCMT3 for ; Wed, 15 May 2013 06:15:40 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id D373A21F87CD for ; Wed, 15 May 2013 06:15:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4939; q=dns/txt; s=iport; t=1368623740; x=1369833340; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=NqybrQ5Unuhj7sTEHwW03CWl6SIcYAXPhma3oUNyOVo=; b=c07itQN3eXOVqHJ5Yf2OYCFM7yFLs1WOtKHJzHG0khMlcDrwtKQ5QMzh 91ZAk+I4B+NzLdcCBq3t2XhGmh4Qhhje1jotXBpabGb4EhyWmnxwdzg7u wYfXGZ5YqIC/dwSA/8aqtp/JAHWt66ozkd2jKRPKiW9qkVssIMtnOFEcz E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkcUABCJk1GtJXHA/2dsb2JhbAAYQ4MHN8BTeRZ0giABAQQBAQFrCxACAQgEOwchBgsUEQIEDgWHegMPDIlRqkYNiFsEjEiCKycEBwKCcmEDlU+BZYwahSODDw X-IronPort-AV: E=Sophos;i="4.87,677,1363132800"; d="scan'208,217";a="210766754" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-8.cisco.com with ESMTP; 15 May 2013 13:15:38 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id r4FDFcBM003348 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 15 May 2013 13:15:38 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.77]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.02.0318.004; Wed, 15 May 2013 08:15:38 -0500 From: "Bernie Volz (volz)" To: Ted Lemon Thread-Topic: [dhcwg] Echoing back options in server response Thread-Index: AQHOUWwvSvhVtzfTPEe7jpBRMbHQvJkGiyGA//+um+Y= Date: Wed, 15 May 2013 13:15:37 +0000 Message-ID: <0290A4EF-9D4F-4421-99C0-0E214ED88C83@cisco.com> References: , <8D23D4052ABE7A4490E77B1A012B63077519C4C4@mbx-01.win.nominum.com> In-Reply-To: <8D23D4052ABE7A4490E77B1A012B63077519C4C4@mbx-01.win.nominum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_0290A4EF9D4F442199C00E214ED88C83ciscocom_" MIME-Version: 1.0 Cc: "" Subject: Re: [dhcwg] Echoing back options in server response X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 May 2013 13:15:44 -0000 --_000_0290A4EF9D4F442199C00E214ED88C83ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Confirm Ted's answer. Not sure why a client would need this information bac= k as it can just save it? If server supports vendor option, it would do wha= t is required for that option ... Such as echoing back parts (or all) if th= at is needed. Servers also also don't echo back anything the Relay sent except the interf= ace-id option. Though we did define the ERO (echo reply option) to allow re= lay to request the server to echo back options. - Bernie On May 15, 2013, at 9:07 AM, "Ted Lemon" > wrote: On May 15, 2013, at 9:00 AM, gvithal . > wrote: Does RFC 3315 mandate that DHCPv6 server should echo back all options in th= e client request message in its response even if the server does not suppor= t a specific option. For example, if the client message contains vendor-specific information opt= ion (section 22.17 rfc 3315), does the server need to echo back the same op= tion in its response even if does not support that option. No. There is a provision in RFC3315 that servers MAY do this, which is ac= tually an echo of the ancient provision in RFC2131 that servers MAY do it, = but I've never heard of anyone implementing this in a server, much less usi= ng it in a client. I argued against putting this into 3315, but found mys= elf on the rough side of consensus... :} _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg --_000_0290A4EF9D4F442199C00E214ED88C83ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Confirm Ted's answer. Not sure why a client would need this informatio= n back as it can just save it? If server supports vendor option, it would d= o what is required for that option ... Such as echoing back parts (or all) = if that is needed.

Servers also also don't echo back anything the Relay sent except the i= nterface-id option. Though we did define the ERO (echo reply option) to all= ow relay to request the server to echo back options.

- Bernie

On May 15, 2013, at 9:07 AM, "Ted Lemon" <Ted.Lemon@nominum.com> wrote:

On May 15, 2013, at 9:00 AM, gvithal . <gvithal@gmail.com> wrote:
Does RFC 3315 mandate that DHCPv6 server should echo back all options in the cl= ient request message in its response even if the server does not support a = specific option.
For example, if the client message contains vendor-specific information opt= ion (section 22.17 rfc 3315), does the server need to echo back the same op= tion in its response even if does not support that option.

No.   There is a provision in RFC3315 that servers MAY do this, w= hich is actually an echo of the ancient provision in RFC2131 that servers M= AY do it, but I've never heard of anyone implementing this in a server, muc= h less using it in a client.   I argued against putting this into 3315, but found myself on the rough side of cons= ensus... :}

_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www.i= etf.org/mailman/listinfo/dhcwg
--_000_0290A4EF9D4F442199C00E214ED88C83ciscocom_-- From kristian.poscic@alcatel-lucent.com Wed May 15 06:53:14 2013 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 6215A21F8FF1 for ; Wed, 15 May 2013 06:53:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id txUuLyMnX-kb for ; Wed, 15 May 2013 06:53:08 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id CA8F621F8F43 for ; Wed, 15 May 2013 06:53:08 -0700 (PDT) Received: from us70tusmtp1.zam.alcatel-lucent.com (h135-5-2-63.lucent.com [135.5.2.63]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id r4FDr59d006320 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 15 May 2013 08:53:05 -0500 (CDT) Received: from US70TWXCHHUB04.zam.alcatel-lucent.com (us70twxchhub04.zam.alcatel-lucent.com [135.5.2.36]) by us70tusmtp1.zam.alcatel-lucent.com (GMO) with ESMTP id r4FDr0MO013273 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 15 May 2013 09:53:03 -0400 Received: from US70UWXCHMBA05.zam.alcatel-lucent.com ([169.254.10.44]) by US70TWXCHHUB04.zam.alcatel-lucent.com ([135.5.2.36]) with mapi id 14.02.0247.003; Wed, 15 May 2013 09:53:02 -0400 From: "Poscic, Kristian (Kristian)" To: "Bernie Volz (volz)" , Ted Lemon Thread-Topic: [dhcwg] Echoing back options in server response Thread-Index: AQHOUWw2rnil6YxWNEmlJy99MHuuE5kGel2AgAACbID//8CK4A== Date: Wed, 15 May 2013 13:53:01 +0000 Message-ID: <7921F977B17D5B49B8DCC955A339D2F02AB0F5DB@US70UWXCHMBA05.zam.alcatel-lucent.com> References: , <8D23D4052ABE7A4490E77B1A012B63077519C4C4@mbx-01.win.nominum.com> <0290A4EF-9D4F-4421-99C0-0E214ED88C83@cisco.com> In-Reply-To: <0290A4EF-9D4F-4421-99C0-0E214ED88C83@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.16] Content-Type: multipart/alternative; boundary="_000_7921F977B17D5B49B8DCC955A339D2F02AB0F5DBUS70UWXCHMBA05z_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 Cc: "" Subject: Re: [dhcwg] Echoing back options in server response X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 May 2013 13:53:14 -0000 --_000_7921F977B17D5B49B8DCC955A339D2F02AB0F5DBUS70UWXCHMBA05z_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Sorry for intruding on the thread but I have a scenario that resembles this= one below so will use the opportunity to ask a question. What would be the best way to deal with this scenario below? DHCP v4/v6 client ------- relay-agent--------BNG-------DHCP Serverv4/6 The BNG needs to extract information in various DHCP options arriving from = the client side. BNG needs this in order to identify and instantiate the su= bscriber. Say on BNG there is a RegExp tool that can parse DHCP options, look at them= and then take internal actions based on them (assign service level to the = client when the client is instantiated in the BNG). The problem is that BNG needs this information (to instantiate subscriber) = at the end of the DHCP process when receiving DHCP ACK/Reply . The BNG looks into various options (relay-agent and client options). Some o= f them will not be available when the ACK/Reply arrives since DHCP4/6 serve= r will not echo them. So the idea is that the BNG looks in upstream DHCP packets (arriving from t= he client side - , ), extracts informati= on that it needs and inserts this information in an option that it know th= at the server will return. So, my idea for DHCPv4 is that this is inserted in Option (82,9) -vendor sp= ecific relay suboption. For DHCPv6 I would use Option 17 (Vendor-Specific Information Option). For DHCPv6 case this should work since we would add Relay Agent Echo Reques= t Option. But for DHCPv4 I'm not sure what would be needed since RFC3046 says (it may= return it or may not): RFC 3046 DHCP servers unaware of the Relay Agent Information option will ignore the option upon receive and will not echo it back on responses. This is the specified server behavior for unknown options. DHCP servers claiming to support the Relay Agent Information option SHALL echo the entire contents of the Relay Agent Information option in all replies. Servers SHOULD copy the Relay Agent Information option as the last DHCP option in the response. Any suggestion? From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of B= ernie Volz (volz) Sent: Wednesday, May 15, 2013 6:16 AM To: Ted Lemon Cc: Subject: Re: [dhcwg] Echoing back options in server response Confirm Ted's answer. Not sure why a client would need this information bac= k as it can just save it? If server supports vendor option, it would do wha= t is required for that option ... Such as echoing back parts (or all) if th= at is needed. Servers also also don't echo back anything the Relay sent except the interf= ace-id option. Though we did define the ERO (echo reply option) to allow re= lay to request the server to echo back options. - Bernie On May 15, 2013, at 9:07 AM, "Ted Lemon" > wrote: On May 15, 2013, at 9:00 AM, gvithal . > wrote: Does RFC 3315 mandate that DHCPv6 server should echo back all options in th= e client request message in its response even if the server does not suppor= t a specific option. For example, if the client message contains vendor-specific information opt= ion (section 22.17 rfc 3315), does the server need to echo back the same op= tion in its response even if does not support that option. No. There is a provision in RFC3315 that servers MAY do this, which is ac= tually an echo of the ancient provision in RFC2131 that servers MAY do it, = but I've never heard of anyone implementing this in a server, much less usi= ng it in a client. I argued against putting this into 3315, but found mys= elf on the rough side of consensus... :} _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg --_000_7921F977B17D5B49B8DCC955A339D2F02AB0F5DBUS70UWXCHMBA05z_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Sorry for intruding on th= e thread but I have a scenario that resembles this one below so will use th= e opportunity to ask a question.

What would be the best wa= y to deal with this scenario below?

 <= /p>

DHCP v4/v6 client -------= relay-agent--------BNG-------DHCP Serverv4/6

 <= /p>

The BNG needs to extract = information in various DHCP options arriving from the client side. BNG need= s this in order to identify and instantiate the subscriber.

Say on BNG there is a Reg= Exp tool that can parse DHCP options, look at them and then take internal a= ctions based on them (assign service level to the client when the client is instantiated in the BNG).

The problem is that BNG n= eeds this information (to instantiate subscriber) at the end of the DHCP pr= ocess when receiving DHCP ACK/Reply .

The BNG looks into variou= s options (relay-agent and client options). Some of them will not be availa= ble when the ACK/Reply arrives since DHCP4/6 server will not echo them.

 <= /p>

So the idea is that the B= NG looks in upstream DHCP packets (arriving from the client side – &l= t;Discover,Request>, <Solicit,Request>), extracts information that it needs and  inserts this information in an option that it know that= the server will return.

 <= /p>

So, my idea for DHCPv4 is= that this is inserted in Option (82,9) –vendor specific relay subopt= ion.

For DHCPv6 I would use Op= tion 17 (Vendor-Specific Information Option).

 <= /p>

For DHCPv6 case this shou= ld work since we would add Relay Agent Echo Request Option.

 <= /p>

But for DHCPv4 I’m = not sure what would be needed since RFC3046 says (it may return it or may n= ot):

RFC 3046

DHCP servers unaware of the Relay Agent Information option= will

ignore the option upon receive and will not echo it back o= n

responses.  This is the specified server behavior for= unknown

options.

DHCP servers claiming to support the Relay Agent Informati= on option

SHALL echo the entire contents of the Relay Agent Informat= ion option

in all replies.  Servers SHOULD copy the Relay Agent = Information

option as the last DHCP option in the response.=

 <= /p>

Any suggestion?

 <= /p>

 <= /p>

From: dhcwg-bo= unces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of Bernie Volz (volz)
Sent: Wednesday, May 15, 2013 6:16 AM
To: Ted Lemon
Cc: <dhcwg@ietf.org>
Subject: Re: [dhcwg] Echoing back options in server response

 

Confirm Ted's answer. Not sure why a client would ne= ed this information back as it can just save it? If server supports vendor = option, it would do what is required for that option ... Such as echoing ba= ck parts (or all) if that is needed.

 

Servers also also don't echo back anything the Relay= sent except the interface-id option. Though we did define the ERO (echo re= ply option) to allow relay to request the server to echo back options.

- Bernie


On May 15, 2013, at 9:07 AM, "Ted Lemon" <Ted.Lemon@nominum.com> wrote:

On May 15, 2013, at 9:00 AM, gvithal . <gvithal@gmail.com> wrote:

Does RFC 3315 mandate that DHCPv6 server shou= ld echo back all options in the client request message in its response even= if the server does not support a specific option.

For example, if the client message contains v= endor-specific information option (section 22.17 rfc 3315), does the server= need to echo back the same option in its response even if does not support that option.

 

No.   There is a provision in RFC3315 that serv= ers MAY do this, which is actually an echo of the ancient provision in RFC2= 131 that servers MAY do it, but I've never heard of anyone implementing thi= s in a server, much less using it in a client.   I argued against putting this into 3315, but found myself o= n the rough side of consensus... :}

 

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

--_000_7921F977B17D5B49B8DCC955A339D2F02AB0F5DBUS70UWXCHMBA05z_-- From volz@cisco.com Wed May 15 07:06:13 2013 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 8936D21F8F69 for ; Wed, 15 May 2013 07:06:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.498 X-Spam-Level: X-Spam-Status: No, score=-10.498 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4KltAykUipuo for ; Wed, 15 May 2013 07:06:08 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id EFDF821F8709 for ; Wed, 15 May 2013 07:05:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=17674; q=dns/txt; s=iport; t=1368626760; x=1369836360; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=1cABx1eoCFBueM8n3XaFulcYTWvycRBsWcwQWyKID88=; b=CO0ra05GKbruNwm20RlkBnwHrDnuuCHnCldG/aFmk063VfKDGI5JhP50 I0iAHyVbK+iWzMTdQF64S25rSM+WTmqgQHp0cis7/uk6vbOTBH6F7iQPT aKJ/nt990y9gn6uO0tcmWl7DVmVx+keYanvOwHD38BjhzC60o1ncM8b3c 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjQFADCVk1GtJV2a/2dsb2JhbABRCoJDRDfAU3gWdIIfAQEBBAEBASpBCxACAQgRBAEBKAchBgsUCQgCBA4Fh3oDDwy0Fg2IWwSMSIEagREHIAQGAQIEgm5hA5NkgWuBZYwahSODDw X-IronPort-AV: E=Sophos;i="4.87,677,1363132800"; d="scan'208,217";a="207822604" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-9.cisco.com with ESMTP; 15 May 2013 14:05:59 +0000 Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r4FE5x9e017794 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 15 May 2013 14:05:59 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.77]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.02.0318.004; Wed, 15 May 2013 09:05:58 -0500 From: "Bernie Volz (volz)" To: "Poscic, Kristian (Kristian)" Thread-Topic: [dhcwg] Echoing back options in server response Thread-Index: AQHOUWwvSvhVtzfTPEe7jpBRMbHQvJkGiyGA//+um+aAAF5EgP//r82+ Date: Wed, 15 May 2013 14:05:58 +0000 Message-ID: References: , <8D23D4052ABE7A4490E77B1A012B63077519C4C4@mbx-01.win.nominum.com> <0290A4EF-9D4F-4421-99C0-0E214ED88C83@cisco.com>, <7921F977B17D5B49B8DCC955A339D2F02AB0F5DB@US70UWXCHMBA05.zam.alcatel-lucent.com> In-Reply-To: <7921F977B17D5B49B8DCC955A339D2F02AB0F5DB@US70UWXCHMBA05.zam.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_FBAD2BF456FB4506B7878FFC1B602692ciscocom_" MIME-Version: 1.0 Cc: "" , Ted Lemon Subject: Re: [dhcwg] Echoing back options in server response X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 May 2013 14:06:13 -0000 --_000_FBAD2BF456FB4506B7878FFC1B602692ciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable I don't think it is safe to assume option 17 will be echoed back ... The pr= ocessing for this option is complex as there could be several instances, so= me of which have special processing. Section 5.a., if taken literally, coul= d mean a server would not echo back all instances of option 17 (and 16) if = the server processing already added one. Servers ideally would factor in th= e enterprise id number when echoing back these, but the document was not ex= plicit with respect to this. If the BNG needs state, it should just keep that state. Timers can be used = to remove stale data. Memory isn't that expensive now adays. - Bernie On May 15, 2013, at 9:53 AM, "Poscic, Kristian (Kristian)" > wrote: Sorry for intruding on the thread but I have a scenario that resembles this= one below so will use the opportunity to ask a question. What would be the best way to deal with this scenario below? DHCP v4/v6 client ------- relay-agent--------BNG-------DHCP Serverv4/6 The BNG needs to extract information in various DHCP options arriving from = the client side. BNG needs this in order to identify and instantiate the su= bscriber. Say on BNG there is a RegExp tool that can parse DHCP options, look at them= and then take internal actions based on them (assign service level to the = client when the client is instantiated in the BNG). The problem is that BNG needs this information (to instantiate subscriber) = at the end of the DHCP process when receiving DHCP ACK/Reply . The BNG looks into various options (relay-agent and client options). Some o= f them will not be available when the ACK/Reply arrives since DHCP4/6 serve= r will not echo them. So the idea is that the BNG looks in upstream DHCP packets (arriving from t= he client side =96 , ), extracts informa= tion that it needs and inserts this information in an option that it know = that the server will return. So, my idea for DHCPv4 is that this is inserted in Option (82,9) =96vendor = specific relay suboption. For DHCPv6 I would use Option 17 (Vendor-Specific Information Option). For DHCPv6 case this should work since we would add Relay Agent Echo Reques= t Option. But for DHCPv4 I=92m not sure what would be needed since RFC3046 says (it m= ay return it or may not): RFC 3046 DHCP servers unaware of the Relay Agent Information option will ignore the option upon receive and will not echo it back on responses. This is the specified server behavior for unknown options. DHCP servers claiming to support the Relay Agent Information option SHALL echo the entire contents of the Relay Agent Information option in all replies. Servers SHOULD copy the Relay Agent Information option as the last DHCP option in the response. Any suggestion? From: dhcwg-bounces@ietf.org [mailto:dhcwg-b= ounces@ietf.org] On Behalf Of Bernie Volz (volz) Sent: Wednesday, May 15, 2013 6:16 AM To: Ted Lemon Cc: > Subject: Re: [dhcwg] Echoing back options in server response Confirm Ted's answer. Not sure why a client would need this information bac= k as it can just save it? If server supports vendor option, it would do wha= t is required for that option ... Such as echoing back parts (or all) if th= at is needed. Servers also also don't echo back anything the Relay sent except the interf= ace-id option. Though we did define the ERO (echo reply option) to allow re= lay to request the server to echo back options. - Bernie On May 15, 2013, at 9:07 AM, "Ted Lemon" > wrote: On May 15, 2013, at 9:00 AM, gvithal . > wrote: Does RFC 3315 mandate that DHCPv6 server should echo back all options in th= e client request message in its response even if the server does not suppor= t a specific option. For example, if the client message contains vendor-specific information opt= ion (section 22.17 rfc 3315), does the server need to echo back the same op= tion in its response even if does not support that option. No. There is a provision in RFC3315 that servers MAY do this, which is ac= tually an echo of the ancient provision in RFC2131 that servers MAY do it, = but I've never heard of anyone implementing this in a server, much less usi= ng it in a client. I argued against putting this into 3315, but found mys= elf on the rough side of consensus... :} _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg --_000_FBAD2BF456FB4506B7878FFC1B602692ciscocom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
I don't think it is safe to assume option 17 will be echoed back ... T= he processing for this option is complex as there could be several instance= s, some of which have special processing. Section 5.a., if taken literally,= could mean a server would not echo back all instances of option 17 (and 16) if the server processing already = added one. Servers ideally would factor in the enterprise id number when ec= hoing back these, but the document was not explicit with respect to this.
If the BNG needs state, it should just keep that state. Timers can be used = to remove stale data. Memory isn't that expensive now adays.

- Bernie

On May 15, 2013, at 9:53 AM, "Poscic, Kristian (Kristian)" <kristian.poscic@alcatel= -lucent.com> wrote:

Sorry for intruding on th= e thread but I have a scenario that resembles this one below so will use th= e opportunity to ask a question.

What would be the best wa= y to deal with this scenario below?

 <= /p>

DHCP v4/v6 client -------= relay-agent--------BNG-------DHCP Serverv4/6

 <= /p>

The BNG needs to extract = information in various DHCP options arriving from the client side. BNG need= s this in order to identify and instantiate the subscriber.

Say on BNG there is a Reg= Exp tool that can parse DHCP options, look at them and then take internal a= ctions based on them (assign service level to the client when the client is instantiated in the BNG).

The problem is that BNG n= eeds this information (to instantiate subscriber) at the end of the DHCP pr= ocess when receiving DHCP ACK/Reply .

The BNG looks into variou= s options (relay-agent and client options). Some of them will not be availa= ble when the ACK/Reply arrives since DHCP4/6 server will not echo them.

 <= /p>

So the idea is that the B= NG looks in upstream DHCP packets (arriving from the client side =96 <Di= scover,Request>, <Solicit,Request>), extracts information that it needs and  inserts this information in an option that it know that= the server will return.

 <= /p>

So, my idea for DHCPv4 is= that this is inserted in Option (82,9) =96vendor specific relay suboption.=

For DHCPv6 I would use Op= tion 17 (Vendor-Specific Information Option).

 <= /p>

For DHCPv6 case this shou= ld work since we would add Relay Agent Echo Request Option.

 <= /p>

But for DHCPv4 I=92m not = sure what would be needed since RFC3046 says (it may return it or may not):=

RFC 3046

DHCP servers unaware of the Relay Agent Information option= will

ignore the option upon receive and will not echo it back o= n

responses.  This is the specified server behavior for= unknown

options.

DHCP servers claiming to support the Relay Agent Informati= on option

SHALL echo the entire contents of the Relay Agent Informat= ion option

in all replies.  Servers SHOULD copy the Relay Agent = Information

option as the last DHCP option in the response.=

 <= /p>

Any suggestion?

 <= /p>

 <= /p>

From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of Bernie Volz (volz)
Sent: Wednesday, May 15, 2013 6:16 AM
To: Ted Lemon
Cc: <dhcwg@ietf.org>
Subject: Re: [dhcwg] Echoing back options in server response

 

Confirm Ted's answer. Not sure why a client would ne= ed this information back as it can just save it? If server supports vendor = option, it would do what is required for that option ... Such as echoing ba= ck parts (or all) if that is needed.

 

Servers also also don't echo back anything the Relay= sent except the interface-id option. Though we did define the ERO (echo re= ply option) to allow relay to request the server to echo back options.

- Bernie


On May 15, 2013, at 9:07 AM, "Ted Lemon" <Ted.Lemon@nominum.com> wrote:

On May 15, 2013, at 9:00 AM, gvithal . <gvithal@gmail.com> wrote:

Does RFC 3315 mandate that DHCPv6 server shou= ld echo back all options in the client request message in its response even= if the server does not support a specific option.

For example, if the client message contains v= endor-specific information option (section 22.17 rfc 3315), does the server= need to echo back the same option in its response even if does not support that option.

 

No.   There is a provision in RFC3315 that serv= ers MAY do this, which is actually an echo of the ancient provision in RFC2= 131 that servers MAY do it, but I've never heard of anyone implementing thi= s in a server, much less using it in a client.   I argued against putting this into 3315, but found myself o= n the rough side of consensus... :}

 

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

--_000_FBAD2BF456FB4506B7878FFC1B602692ciscocom_-- From Ted.Lemon@nominum.com Wed May 15 07:07:34 2013 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 3865621F86C1 for ; Wed, 15 May 2013 07:07:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.579 X-Spam-Level: X-Spam-Status: No, score=-106.579 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2+QrQECJPSIz for ; Wed, 15 May 2013 07:07:27 -0700 (PDT) Received: from exprod7og114.obsmtp.com (exprod7og114.obsmtp.com [64.18.2.215]) by ietfa.amsl.com (Postfix) with ESMTP id 6C52E21F8616 for ; Wed, 15 May 2013 07:07:27 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob114.postini.com ([64.18.6.12]) with SMTP ID DSNKUZOWn6AGHWyeZ52aMU7ghoiP4cZVRfZM@postini.com; Wed, 15 May 2013 07:07:27 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id E3DF91B809C for ; Wed, 15 May 2013 07:07:26 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id DB5A1190061; Wed, 15 May 2013 07:07:26 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0318.004; Wed, 15 May 2013 07:07:26 -0700 From: Ted Lemon To: "Poscic, Kristian (Kristian)" Thread-Topic: [dhcwg] Echoing back options in server response Thread-Index: AQHOUWwuQ6YTCZdyVEuzg09X4WcfnJkGrKkAgAACa4CAAApzgIAABAaA Date: Wed, 15 May 2013 14:07:25 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B63077519C684@mbx-01.win.nominum.com> References: , <8D23D4052ABE7A4490E77B1A012B63077519C4C4@mbx-01.win.nominum.com> <0290A4EF-9D4F-4421-99C0-0E214ED88C83@cisco.com> <7921F977B17D5B49B8DCC955A339D2F02AB0F5DB@US70UWXCHMBA05.zam.alcatel-lucent.com> In-Reply-To: <7921F977B17D5B49B8DCC955A339D2F02AB0F5DB@US70UWXCHMBA05.zam.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: multipart/alternative; boundary="_000_8D23D4052ABE7A4490E77B1A012B63077519C684mbx01winnominum_" MIME-Version: 1.0 Cc: "" , "Bernie Volz \(volz\)" Subject: Re: [dhcwg] Echoing back options in server response X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 May 2013 14:07:34 -0000 --_000_8D23D4052ABE7A4490E77B1A012B63077519C684mbx01winnominum_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable On May 15, 2013, at 9:53 AM, "Poscic, Kristian (Kristian)" > wrote: But for DHCPv4 I=92m not sure what would be needed since RFC3046 says (it m= ay return it or may not): No server you are likely to use in a BNG scenario will fail to support RFC = 3046. --_000_8D23D4052ABE7A4490E77B1A012B63077519C684mbx01winnominum_ Content-Type: text/html; charset="Windows-1252" Content-ID: <5D39F791FF277447B2614F84403B8CD5@nominum.com> Content-Transfer-Encoding: quoted-printable
On May 15, 2013, at 9:53 AM, "Poscic, Kristian (Kristian)" &= lt;kristian.poscic@al= catel-lucent.com> wrote:
But for DHCPv4 I=92m not sure what would be needed since = RFC3046 says (it may return it or may not):

No server you are likely to use in a BNG scenario will fail to support= RFC 3046.


--_000_8D23D4052ABE7A4490E77B1A012B63077519C684mbx01winnominum_-- From tomasz.mrugalski@gmail.com Wed May 15 08:42:52 2013 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 4ACF821F90B9 for ; Wed, 15 May 2013 08:42:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_31=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H+Vm80-VhHu0 for ; Wed, 15 May 2013 08:42:51 -0700 (PDT) Received: from mail-wg0-x22b.google.com (mail-wg0-x22b.google.com [IPv6:2a00:1450:400c:c00::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 9894321F9049 for ; Wed, 15 May 2013 08:42:51 -0700 (PDT) Received: by mail-wg0-f43.google.com with SMTP id c11so1688361wgh.34 for ; Wed, 15 May 2013 08:42:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; bh=u9F0jegkymd9SfhYCaZLjQQZxlW+6motgP+tNIGHxig=; b=usR5V5KkncCId9gCDEL9w33Z3Vv6uIZGtlCpiFcy103wx/sfXTJwRNoX1hd0IYs9Pb snfcQuVEoCpz8FcQpBlboSXlkZbIWN0UclF9t553Rgcd+9jIV+u3Kb+YVPDpaQmCUwUS ocsucuo3pZOpUX52OWHu1nKeefxxHlJ7zZuwDfUHGFc5xrakP4iIrkzbWjYYL0Sx+VXJ M6qDqo9NSXKOZ3V1G+QN2VhH72Xr1qUCums2h+9heaLwsivh4Q3+ngLnXL313YoTXWL+ ay3e8S7/VItLpEclh5ZT0bWjQEZ8x1LsybIoLddQ1LgWDM1oWVp++RIsr5O4sjUXLfhB W3Iw== X-Received: by 10.194.92.20 with SMTP id ci20mr5204848wjb.1.1368632567462; Wed, 15 May 2013 08:42:47 -0700 (PDT) Received: from dhcp-25-30.ripemtg.ripe.net ([2001:67c:64:42:cabc:c8ff:fedf:daff]) by mx.google.com with ESMTPSA id d5sm18364820wic.1.2013.05.15.08.42.45 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 15 May 2013 08:42:46 -0700 (PDT) Message-ID: <5193ACF4.9020907@gmail.com> Date: Wed, 15 May 2013 16:42:44 +0100 From: Tomek Mrugalski User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: dhcwg@ietf.org References: <8A1B81989BCFAE44A22B2B86BF2B7631898DB0232B@HE111643.EMEA1.CDS.T-INTERNAL.COM> <51780A17.8010503@gmail.com> <489D13FBFA9B3E41812EA89F188F018E18552B99@xmb-rcd-x04.cisco.com> <518B7628.3020309@gmail.com> <786F13AA11E69F4DB2CCA23F7400C2FB0142D318@S2010EXCH1.ad.local> <8D23D4052ABE7A4490E77B1A012B63077519C2C9@mbx-01.win.nominum.com> In-Reply-To: <8D23D4052ABE7A4490E77B1A012B63077519C2C9@mbx-01.win.nominum.com> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [dhcwg] Conclusion for draft-ietf-dhc-v4configuration-00 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 May 2013 15:42:52 -0000 On 13-05-15 13:27, Ted Lemon wrote: > I think this text is good. +1 (with my chair hat off) From tomasz.mrugalski@gmail.com Wed May 15 08:51:42 2013 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 6F3DC11E80CC for ; Wed, 15 May 2013 08:51:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.3 X-Spam-Level: X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FzW5SlOee00b for ; Wed, 15 May 2013 08:51:42 -0700 (PDT) Received: from mail-wg0-x235.google.com (mail-wg0-x235.google.com [IPv6:2a00:1450:400c:c00::235]) by ietfa.amsl.com (Postfix) with ESMTP id 89F1111E80D7 for ; Wed, 15 May 2013 08:51:08 -0700 (PDT) Received: by mail-wg0-f53.google.com with SMTP id y10so1831214wgg.32 for ; Wed, 15 May 2013 08:51:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; bh=FsXY/sEuQPFbGUPbKUIRcvR1JAe9p7XzfB26OeVUcrw=; b=TZj6ASSQLdYo12CYESVo/hr4M3U/PXmiysjqDs4sUfiZs5FmI506GEexnen7EhtXPq 9eNpES/qM8MUF7sg2oK9KzCTNIujmSb0+XQYJl6kLLBPGlPUHV3/YpZkLnxXirG7mLfO Hov1ayCoCCw3hx9vkXhj7BJgADnf/wqmKdugAfJPj3m12ZlT6PMAtMOlUw1hMJGR4KOy mmgFCUc9JTS0POOujHthXhaQEiI+aJ4O5zT26FwAVx6xDtwj/cXlRFy+36j5eWP7x1yN z5coVSPuNqqWNr042L0IrUHlZc/nY4LpPe/yCBUu7ef1eoy78YZqBmUCtQW66VgWGfd2 mBFw== X-Received: by 10.194.24.167 with SMTP id v7mr5259271wjf.46.1368633067627; Wed, 15 May 2013 08:51:07 -0700 (PDT) Received: from dhcp-25-30.ripemtg.ripe.net ([2001:67c:64:42:cabc:c8ff:fedf:daff]) by mx.google.com with ESMTPSA id e5sm3162674wiy.5.2013.05.15.08.51.06 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 15 May 2013 08:51:06 -0700 (PDT) Message-ID: <5193AEE9.8050509@gmail.com> Date: Wed, 15 May 2013 16:51:05 +0100 From: Tomek Mrugalski User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: dhcwg@ietf.org References: <8A1B81989BCFAE44A22B2B86BF2B7631898DB0232B@HE111643.EMEA1.CDS.T-INTERNAL.COM> <51780A17.8010503@gmail.com> <489D13FBFA9B3E41812EA89F188F018E18552B99@xmb-rcd-x04.cisco.com> <518B7628.3020309@gmail.com> <786F13AA11E69F4DB2CCA23F7400C2FB0142D318@S2010EXCH1.ad.local>, <8D23D4052ABE7A4490E77B1A012B63077519C2C9@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B63077519C539@mbx-01.win.nominum.com> In-Reply-To: <8D23D4052ABE7A4490E77B1A012B63077519C539@mbx-01.win.nominum.com> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Subject: Re: [dhcwg] Conclusion for draft-ietf-dhc-v4configuration-00 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 May 2013 15:51:42 -0000 On 13-05-15 14:13, Ted Lemon wrote: > I guess we really haven't talked about how this works—with > DHCPv4-over-IPv6, we'd intended to add a DHCPv6 option with the IP > address of the DHCPv4-over-IPv6 server, There was a draft about providing IPv6 address of the DHCPv4-over-IPv6 server that I wrote together with Peng Wu. Since the DHCPv4-over-IPv6 is no longer the recommended solution, I let it expire. There is currently no plan to revive that work. > but with DHCPv4-over-DHCPv6 that's not necessary. That's another advantage of DHCPv4-over-DHCPv6 compared to DHCPv4-over-IPv6. Tomek From volz@cisco.com Wed May 15 10:55:00 2013 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 66FA021F8CEC for ; Wed, 15 May 2013 10:55:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ECVRwNT-DUs0 for ; Wed, 15 May 2013 10:54:54 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 4673821F8D31 for ; Wed, 15 May 2013 10:54:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1315; q=dns/txt; s=iport; t=1368640493; x=1369850093; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=Hx+aX11E682Ky+MLY5CyMrTb1MQVVs3g8xvFimOEJp8=; b=h2SpnF8OVh3irMutFtBdAWegvQ93cQSE9DcNizjRZalkS/Sv0WoSVIpQ zY6izMDqc8NbtWp8hw+0otPiMBEY7QQoDMBunyjPgFyfbgIBqU195kkpF ixZi9M/5m7pS2eP6k2+HO7c4dRO9lMKQJDHY/jSyxfSAIE/MuvypSSt4I I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiYFANbKk1GtJXG//2dsb2JhbABbgwfBDn0WdIIfAQEBAwF5BQsCAQgYLjIlAgQOBYgGBr1ZjmszB4J0YQOXNJE9gxA X-IronPort-AV: E=Sophos;i="4.87,678,1363132800"; d="scan'208";a="210926261" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-3.cisco.com with ESMTP; 15 May 2013 17:54:51 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id r4FHspJV018570 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 15 May 2013 17:54:51 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.77]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.02.0318.004; Wed, 15 May 2013 12:54:51 -0500 From: "Bernie Volz (volz)" To: Ted Lemon Thread-Topic: [dhcwg] Conclusion for draft-ietf-dhc-v4configuration-00 Thread-Index: AQHOUWer9Ia2wAOKBEeecA8Xo7LWYZkGNsltgABWU4D///qscQ== Date: Wed, 15 May 2013 17:54:50 +0000 Message-ID: <1775E640-867C-41E3-8EAC-2554D80D4DF6@cisco.com> References: <8A1B81989BCFAE44A22B2B86BF2B7631898DB0232B@HE111643.EMEA1.CDS.T-INTERNAL.COM> <51780A17.8010503@gmail.com> <489D13FBFA9B3E41812EA89F188F018E18552B99@xmb-rcd-x04.cisco.com> <518B7628.3020309@gmail.com> <786F13AA11E69F4DB2CCA23F7400C2FB0142D318@S2010EXCH1.ad.local>, <8D23D4052ABE7A4490E77B1A012B63077519C2C9@mbx-01.win.nominum.com> , <8D23D4052ABE7A4490E77B1A012B63077519C539@mbx-01.win.nominum.com> In-Reply-To: <8D23D4052ABE7A4490E77B1A012B63077519C539@mbx-01.win.nominum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dhcwg@ietf.org" , "sunqi@csnet1.cs.tsinghua.edu.cn" Subject: Re: [dhcwg] Conclusion for draft-ietf-dhc-v4configuration-00 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 May 2013 17:55:00 -0000 Maybe this relates to the sunset4 discussion ... A dhcpv6 option could say = use dhcpv4-over-dhcpv6. - Bernie On May 15, 2013, at 9:14 AM, "Ted Lemon" wrote: > On May 15, 2013, at 9:04 AM, Bernie Volz (volz) wrote: >> One issue which is more for the actual draft on this method is how does = dhcpv4 client determine to do this (send over v6) rather than attempt norma= l dhcpv4 - or perhaps client tries both methods at same time? But that's li= kely an issue for all if the techiques. >=20 > This is worth documenting, if it's not clear in the draft: the DHCPv4 cli= ent knows to do this because it's not a DHCPv4 client=97it's a DHCPv4-over-= DHCPv6 client. So it just assumes that DHCPv4-over-DHCPv6 is available an= d tries to use it; if it succeeds, it is available, and if it fails, it's n= ot. It might additionally be worth talking about when it decides to try: = when it notices a device on the homenet trying to use IPv4 to access an off= -network service, or does it do it as soon as it comes up? >=20 > I guess we really haven't talked about how this works=97with DHCPv4-over-= IPv6, we'd intended to add a DHCPv6 option with the IP address of the DHCPv= 4-over-IPv6 server, but with DHCPv4-over-DHCPv6 that's not necessary. >=20 From Ted.Lemon@nominum.com Wed May 15 11:10:00 2013 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 35FA321F9021 for ; Wed, 15 May 2013 11:10:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.582 X-Spam-Level: X-Spam-Status: No, score=-106.582 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dl5+rAA0RjAk for ; Wed, 15 May 2013 11:09:53 -0700 (PDT) Received: from exprod7og121.obsmtp.com (exprod7og121.obsmtp.com [64.18.2.20]) by ietfa.amsl.com (Postfix) with ESMTP id 6FAF721F9029 for ; Wed, 15 May 2013 11:09:53 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob121.postini.com ([64.18.6.12]) with SMTP ID DSNKUZPPcfOCsilJwlwbIBcEtSLBDEKtWWKM@postini.com; Wed, 15 May 2013 11:09:53 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 21AE31B80D2 for ; Wed, 15 May 2013 11:09:53 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 1AA9A19005D; Wed, 15 May 2013 11:09:53 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0318.004; Wed, 15 May 2013 11:09:46 -0700 From: Ted Lemon To: "Bernie Volz (volz)" Thread-Topic: [dhcwg] Conclusion for draft-ietf-dhc-v4configuration-00 Thread-Index: AQHOUWzOksvS2kVeK0CojhlacokdApkGrpoAgABOfACAAAQpAA== Date: Wed, 15 May 2013 18:09:45 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B63077519CEFE@mbx-01.win.nominum.com> References: <8A1B81989BCFAE44A22B2B86BF2B7631898DB0232B@HE111643.EMEA1.CDS.T-INTERNAL.COM> <51780A17.8010503@gmail.com> <489D13FBFA9B3E41812EA89F188F018E18552B99@xmb-rcd-x04.cisco.com> <518B7628.3020309@gmail.com> <786F13AA11E69F4DB2CCA23F7400C2FB0142D318@S2010EXCH1.ad.local>, <8D23D4052ABE7A4490E77B1A012B63077519C2C9@mbx-01.win.nominum.com> , <8D23D4052ABE7A4490E77B1A012B63077519C539@mbx-01.win.nominum.com> <1775E640-867C-41E3-8EAC-2554D80D4DF6@cisco.com> In-Reply-To: <1775E640-867C-41E3-8EAC-2554D80D4DF6@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dhcwg@ietf.org" , "sunqi@csnet1.cs.tsinghua.edu.cn" Subject: Re: [dhcwg] Conclusion for draft-ietf-dhc-v4configuration-00 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 May 2013 18:10:00 -0000 On May 15, 2013, at 1:54 PM, "Bernie Volz (volz)" wrote: > Maybe this relates to the sunset4 discussion ... A dhcpv6 option could sa= y use dhcpv4-over-dhcpv6. Yup, or a DHCPv4 option could say "DHCPv4 not supported." From jari.arkko@piuha.net Wed May 15 13:36:42 2013 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 CF8BB21F86F4; Wed, 15 May 2013 13:36:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.439 X-Spam-Level: X-Spam-Status: No, score=-102.439 tagged_above=-999 required=5 tests=[AWL=0.160, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C6Wto6E2vsme; Wed, 15 May 2013 13:36:38 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by ietfa.amsl.com (Postfix) with ESMTP id 2F18511E80DE; Wed, 15 May 2013 13:36:37 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 4A7D32CC64; Wed, 15 May 2013 23:36:31 +0300 (EEST) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZFw8QVAO1ybd; Wed, 15 May 2013 23:36:29 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id 72FF62CC56; Wed, 15 May 2013 23:36:29 +0300 (EEST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Jari Arkko In-Reply-To: <5187D5C8.5000902@nostrum.com> Date: Wed, 15 May 2013 23:36:28 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <819807F5-1881-4499-9CF5-61D7DA69D895@piuha.net> References: <517AA051.8080506@nostrum.com> <94C682931C08B048B7A8645303FDC9F36ECC240570@PUEXCB1B.nanterre.francetelecom.fr> <5187D5C8.5000902@nostrum.com> To: Robert Sparks X-Mailer: Apple Mail (2.1503) Cc: dhcwg@ietf.org, General Area Review Team , draft-ietf-dhc-triggered-reconfigure@tools.ietf.org Subject: Re: [dhcwg] Gen-art review: draft-ietf-dhc-triggered-reconfigure-05 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 May 2013 20:36:43 -0000 Robert,=20 Thank you very much for your review. A big part of my document approval = decisions are the Gen-ART reviews, and they help me greatly. Thank you Mohamed for the revision! I plan to support the approval of = this document in the IESG call tomorrow. Jari On May 6, 2013, at 7:09 PM, Robert Sparks wrote: > Looks good to me. Thanks! > RjS >=20 > On 5/6/13 3:02 AM, mohamed.boucadair@orange.com wrote: >> Dear Robert, >> =20 >> I updated the document to cover the comments you raised. You can = check the diff available at: = http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dhc-triggered-reconfigure-06= >> =20 >> Cheers, >> Med >> =20 >> De : dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] De la = part de Robert Sparks >> Envoy=E9 : vendredi 26 avril 2013 17:42 >> =C0 : dhcwg@ietf.org; ietf@ietf.org; General Area Review Team; = draft-ietf-dhc-triggered-reconfigure@tools.ietf.org >> Objet : [dhcwg] Gen-art review: = draft-ietf-dhc-triggered-reconfigure-05 >> =20 >> I am the assigned Gen-ART reviewer for this draft. For background on=20= >> Gen-ART, please see the FAQ at=20 >>=20 >> .=20 >>=20 >> Please resolve these comments along with any other Last Call comments=20= >> you may receive.=20 >>=20 >> Document: draft-ietf-dhc-triggered-reconfigure-05 >> Reviewer: Robert Sparks >> Review Date: April 26, 2013 >> IETF LC End Date: May 6, 2013 >> IESG Telechat date: May 16, 2013 >>=20 >> Summary: This draft is on the right track but has open issues, = described in >> the review. >>=20 >> Major issues:=20 >>=20 >> Overall, this document is solid, but I think there is a bug in = section 6.3.=20 >> I could be wrong, but If I'm right, this paragraph: >>=20 >> When retransmission is required, the relay may decide to correct the = content of RECONFIGURE-REQUEST message it issues (e.g., update the = Client Identifier list). This decision is local to the relay (e.g., it = may be based on observed events such as one or more clients were = reconfigured on their own). >>=20 >> introduces a race-condition that could lead to an erroneous state. If = a relay's first message included client A, then the retransmission = included clients A and B, but that retransmission crosses with a success = RECONFIGURE-REPLY to the request that only included client A, the relay = will think it succeeded in asking A and B to be reconfigured. >>=20 >> Minor issues:=20 >>=20 >> This sentence: >>=20 >> Furthermore, means to recover state in failure events must be = supported, but are not discussed in this document. >> places a requirement on a relay (even though it's not using a 2119 = MUST). Is there some other document that defines this requirement that = you can reference? If not, the requirement should be discussed in this = document. Alternatively, you could change the sentence to talk about the = consequences of not having a proprietary means for recovering state. >>=20 >> Nits/editorial comments: >=20 > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg From ian.farrer@telekom.de Wed May 15 23:54:29 2013 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 4AE3721F924A for ; Wed, 15 May 2013 23:54:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.816 X-Spam-Level: X-Spam-Status: No, score=-2.816 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id drCmGEcnAfHz for ; Wed, 15 May 2013 23:54:25 -0700 (PDT) Received: from tcmail43.telekom.de (tcmail43.telekom.de [80.149.113.173]) by ietfa.amsl.com (Postfix) with ESMTP id BA63721F926E for ; Wed, 15 May 2013 23:54:24 -0700 (PDT) Received: from he113470.emea1.cds.t-internal.com ([10.134.93.128]) by tcmail41.telekom.de with ESMTP/TLS/AES128-SHA; 16 May 2013 08:54:21 +0200 Received: from HE111643.EMEA1.CDS.T-INTERNAL.COM ([10.134.93.12]) by HE113470.emea1.cds.t-internal.com ([::1]) with mapi; Thu, 16 May 2013 08:54:20 +0200 From: To: , , Date: Thu, 16 May 2013 08:54:22 +0200 Thread-Topic: [dhcwg] Conclusion for draft-ietf-dhc-v4configuration-00 Thread-Index: Ac5SAjDCgkO7l9szT6CO9i4VG6G0yQ== Message-ID: In-Reply-To: <1775E640-867C-41E3-8EAC-2554D80D4DF6@cisco.com> Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.4.130416 acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: dhcwg@ietf.org, sunqi@csnet1.cs.tsinghua.edu.cn Subject: Re: [dhcwg] Conclusion for draft-ietf-dhc-v4configuration-00 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 May 2013 06:54:29 -0000 Hi, Having thought about this a bit over the last few days, specifically in relation to softwire, this is where I'Ve got to. There are 3 possible options for a softwire client's IPv4 configuration: 1) Static IPv4 address & ports obtained from DHCPv6 (OPTION_MAP etc) 2) Dynamic IPv4 & ports (+ optional addition DHCPv4 conf.) obtained from DHCPv4overDHCPv6 3) Static IPv4 address & ports obtained from DHCPv6 (OPTION_MAP etc) + additional DHCPv4 config. obtained from DHCPv4overDHCP6 Therefore, if we used a separate DHCPv6 option to convey that DHCPv4overDHCPv6 configuration should be attempted, the client logic can work out what it's meant to be doing by whether it receives its IPv4 config from an OPTION_MAP sub-option only (1), gets the DHCPv4overDHCPv6 config option only (2) or gets both (3). This also means that a non-softwire DHCPv4overDHCPv6 client (should one appear in the future) can just use the DCHPv4overDHCPv6 without needing any OPTION_MAP logic. As for the what such a DHCPv4overDHCPv6 option could contain, I think that there could be some advantages in being able to (optionally) provision the client with a /128 address for the DHCPv4overDHCPv6 server (as the old Tomek/Peng draft described). This could work as follows: * If the /128 field for the DHCPv4over6 server is empty, then the client uses multicast configuration is used as normal * If the prefix is present, then the client uses this address as unicast The reason for this is around the separation of DHCPv4 and DHCPv6 configuration. At the moment the DHCPv4 over DHCPv6 draft uses an update to DHCPv6 relays so messages can be relayed to a different DHCP server. As the client needs to be updated to implement the function anyway (and the relay is not adding anything useful in the configuration process), having the possibility of letting the client make the decision (and a way of provisioning the client with what to do) seems like it could be a good idea. It also means that DHCPv6 relays don't need to be updated, which seems cleaner. Cheers, Ian On 15/05/2013 19:54, "Bernie Volz (volz)" wrote: >Maybe this relates to the sunset4 discussion ... A dhcpv6 option could >say use dhcpv4-over-dhcpv6. > >- Bernie > >On May 15, 2013, at 9:14 AM, "Ted Lemon" wrote: > >> On May 15, 2013, at 9:04 AM, Bernie Volz (volz) wrote: >>> One issue which is more for the actual draft on this method is how >>>does dhcpv4 client determine to do this (send over v6) rather than >>>attempt normal dhcpv4 - or perhaps client tries both methods at same >>>time? But that's likely an issue for all if the techiques. >>=20 >> This is worth documenting, if it's not clear in the draft: the DHCPv4 >>client knows to do this because it's not a DHCPv4 client=8Bit's a >>DHCPv4-over-DHCPv6 client. So it just assumes that DHCPv4-over-DHCPv6 >>is available and tries to use it; if it succeeds, it is available, and >>if it fails, it's not. It might additionally be worth talking about >>when it decides to try: when it notices a device on the homenet trying >>to use IPv4 to access an off-network service, or does it do it as soon >>as it comes up? >>=20 >> I guess we really haven't talked about how this works=8Bwith >>DHCPv4-over-IPv6, we'd intended to add a DHCPv6 option with the IP >>address of the DHCPv4-over-IPv6 server, but with DHCPv4-over-DHCPv6 >>that's not necessary. >>=20 >_______________________________________________ >dhcwg mailing list >dhcwg@ietf.org >https://www.ietf.org/mailman/listinfo/dhcwg From Branimir.Rajtar@t.ht.hr Thu May 16 00:27:25 2013 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 9727B21F8AA6 for ; Thu, 16 May 2013 00:27:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_54=0.6, J_CHICKENPOX_62=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sF-W8bs4g6RJ for ; Thu, 16 May 2013 00:27:21 -0700 (PDT) Received: from mx02.t.ht.hr (mx02.t.ht.hr [195.29.161.89]) by ietfa.amsl.com (Postfix) with SMTP id D231721F86CA for ; Thu, 16 May 2013 00:27:19 -0700 (PDT) Received: from no.name.available by mx02.t.ht.hr via smtpd (for mail.ietf.org [12.22.58.30]) with ESMTP; Thu, 16 May 2013 08:55:11 +0200 Received: from (unknown [172.17.66.76]) by scmg2.t.ht.hr with smtp id 124d_24c2_09efd71a_bdfa_11e2_bc63_00219b931f47; Thu, 16 May 2013 09:27:17 +0200 Received: (private information removed) Thu, 16 May 2013 09:27:18 +0200 Received: (private information removed) S2010EXCHCA1.ad.local ([::1]) with mapi id 14.03.0123.003; Thu, 16 May 2013 09:27:17 +0200 From: Branimir Rajtar To: "ian.farrer@telekom.de" , "volz@cisco.com" , "Ted.Lemon@nominum.com" , "tomasz.mrugalski@gmail.com" Thread-Topic: [dhcwg] Conclusion for draft-ietf-dhc-v4configuration-00 Thread-Index: AQHOUWer64FCJbHVAUivUsccszBjPJkGNsltgABWU4D///qscYAAuEUAgAApTjA= Date: Thu, 16 May 2013 07:27:17 +0000 Message-ID: <786F13AA11E69F4DB2CCA23F7400C2FB0142D776@S2010EXCH1.ad.local> References: <1775E640-867C-41E3-8EAC-2554D80D4DF6@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.17.5.13] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginalArrivalTime: 16 May 2013 07:27:18.0041 (UTC) FILETIME=[CBA85090:01CE5206] X-NAIMIME-Disclaimer: 1 X-NAIMIME-Modified: 1 Cc: "dhcwg@ietf.org" , "sunqi@csnet1.cs.tsinghua.edu.cn" Subject: Re: [dhcwg] Conclusion for draft-ietf-dhc-v4configuration-00 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 May 2013 07:27:25 -0000 Pkl0IGFsc28gbWVhbnMgdGhhdCBESENQdjYgcmVsYXlzIGRvbid0IG5lZWQgdG8gYmUgdXBkYXRl ZCwgd2hpY2gKc2VlbXMgY2xlYW5lci4KClRoaXMgd291bGQgYWxzbyByZXNvbHZlIEJlcm5pZSdz IGNvbW1lbnQgYWJvdXQgdGhlIG5lZWQgdG8gaW5jbHVkZSBhICJjb24iIGZvciBESENQdjQtb3Zl ci1ESENQdjYgc2F5aW5nIHRoYXQgcmVsYXlzIGhhdmUgdG8gYmUgdXBkYXRlZCBhcyB3ZWxsLgoK QWxzbywgSSB0aGluayBoaXMgY29tbWVudCB0aGF0IERIQ1B2NiBjbGllbnRzIGFyZSBub3QgdGhl IG9uZXMgdGhhdCBzaG91bGQgY2hhbmdlLCBidXQgREhDUHY0IGNsaWVudHMsIGlzIHZhbGlkIGFu ZCBJIHByb3Bvc2UgdG8gY2hhbmdlIGl0IHRoZSBuZXh0IHZlcnNpb24gb2YgdGhlIGRyYWZ0LgoK QnJhbmltaXIKCk9uIDE1LzA1LzIwMTMgMTk6NTQsICJCZXJuaWUgVm9seiAodm9seikiIDx2b2x6 QGNpc2NvLmNvbT4gd3JvdGU6Cgo+TWF5YmUgdGhpcyByZWxhdGVzIHRvIHRoZSBzdW5zZXQ0IGRp c2N1c3Npb24gLi4uIEEgZGhjcHY2IG9wdGlvbiBjb3VsZAo+c2F5IHVzZSBkaGNwdjQtb3Zlci1k aGNwdjYuCj4KPi0gQmVybmllCj4KPk9uIE1heSAxNSwgMjAxMywgYXQgOToxNCBBTSwgIlRlZCBM ZW1vbiIgPFRlZC5MZW1vbkBub21pbnVtLmNvbT4gd3JvdGU6Cj4KPj4gT24gTWF5IDE1LCAyMDEz LCBhdCA5OjA0IEFNLCBCZXJuaWUgVm9seiAodm9seikgPHZvbHpAY2lzY28uY29tPiB3cm90ZToK Pj4+IE9uZSBpc3N1ZSB3aGljaCBpcyBtb3JlIGZvciB0aGUgYWN0dWFsIGRyYWZ0IG9uIHRoaXMg bWV0aG9kIGlzIGhvdwo+Pj5kb2VzIGRoY3B2NCBjbGllbnQgZGV0ZXJtaW5lIHRvIGRvIHRoaXMg KHNlbmQgb3ZlciB2NikgcmF0aGVyIHRoYW4KPj4+YXR0ZW1wdCBub3JtYWwgZGhjcHY0IC0gb3Ig cGVyaGFwcyBjbGllbnQgdHJpZXMgYm90aCBtZXRob2RzIGF0IHNhbWUKPj4+dGltZT8gQnV0IHRo YXQncyBsaWtlbHkgYW4gaXNzdWUgZm9yIGFsbCBpZiB0aGUgdGVjaGlxdWVzLgo+PiAKPj4gVGhp cyBpcyB3b3J0aCBkb2N1bWVudGluZywgaWYgaXQncyBub3QgY2xlYXIgaW4gdGhlIGRyYWZ0OiB0 aGUgREhDUHY0Cj4+Y2xpZW50IGtub3dzIHRvIGRvIHRoaXMgYmVjYXVzZSBpdCdzIG5vdCBhIERI Q1B2NCBjbGllbnQ8aXQncyBhCj4+REhDUHY0LW92ZXItREhDUHY2IGNsaWVudC4gICBTbyBpdCBq dXN0IGFzc3VtZXMgdGhhdCBESENQdjQtb3Zlci1ESENQdjYKPj5pcyBhdmFpbGFibGUgYW5kIHRy aWVzIHRvIHVzZSBpdDsgaWYgaXQgc3VjY2VlZHMsIGl0IGlzIGF2YWlsYWJsZSwgYW5kCj4+aWYg aXQgZmFpbHMsIGl0J3Mgbm90LiAgIEl0IG1pZ2h0IGFkZGl0aW9uYWxseSBiZSB3b3J0aCB0YWxr aW5nIGFib3V0Cj4+d2hlbiBpdCBkZWNpZGVzIHRvIHRyeTogd2hlbiBpdCBub3RpY2VzIGEgZGV2 aWNlIG9uIHRoZSBob21lbmV0IHRyeWluZwo+PnRvIHVzZSBJUHY0IHRvIGFjY2VzcyBhbiBvZmYt bmV0d29yayBzZXJ2aWNlLCBvciBkb2VzIGl0IGRvIGl0IGFzIHNvb24KPj5hcyBpdCBjb21lcyB1 cD8KPj4gCj4+IEkgZ3Vlc3Mgd2UgcmVhbGx5IGhhdmVuJ3QgdGFsa2VkIGFib3V0IGhvdyB0aGlz IHdvcmtzPHdpdGgKPj5ESENQdjQtb3Zlci1JUHY2LCB3ZSdkIGludGVuZGVkIHRvIGFkZCBhIERI Q1B2NiBvcHRpb24gd2l0aCB0aGUgSVAKPj5hZGRyZXNzIG9mIHRoZSBESENQdjQtb3Zlci1JUHY2 IHNlcnZlciwgYnV0IHdpdGggREhDUHY0LW92ZXItREhDUHY2Cj4+dGhhdCdzIG5vdCBuZWNlc3Nh cnkuCj4+IAo+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18K PmRoY3dnIG1haWxpbmcgbGlzdAo+ZGhjd2dAaWV0Zi5vcmcKPmh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vZGhjd2cKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fCmRoY3dnIG1haWxpbmcgbGlzdApkaGN3Z0BpZXRmLm9yZwpodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RoY3dnCgoKPEhUTUw+PFA+PEZPTlQgZmFj ZT1BcmlhbCBjb2xvcj0jOTk5OTk5IHNpemU9MT4NCg0KSVpKQVZBIE8gT0RSSUNBTkpVIE9ER09W T1JOT1NUSTogU2FkcsW+YWogb3ZlIHBvcnVrZSBpIGV2ZW50dWFsbm8gcHJpbG/FvmVuaWggZGF0 b3Rla2EgamUgcG92amVybGppdiBpIG5hbWlqZW5qZW4gamUgc2FtbyBvc29iYW1hIGlsaSBzdWJq ZWt0aW1hIGtvamkgc3UgbmF2ZWRlbmkgdSBhZHJlc2kuIFVrb2xpa28gc3RlIHByaW1pbGkgb3Z1 IHBvcnVrdSBncmXFoWtvbSwgbW9saW1vIFZhcywgb2JhdmlqZXN0aXRlIHBvxaFpbGphdGVsamEs IGEgcG9ydWt1IGkgc3ZlIG5qZW5lIHByaXZpdGtlIG9kbWFoLCBiZXogxI1pdGFuamEsIHRyYWpu byB1a2xvbml0ZSBzIHJhxI11bmFsYS4gQmlsbyBrYWt2byBwcmVub8WhZW5qZSwga29waXJhbmpl IGlsaSBkaXN0cmlidWNpamEgaW5mb3JtYWNpamEgc2FkcsW+YW5paCB1IHBvcnVjaSB0cmXEh2lt IG9zb2JhbWEgamUgemFicmFuamVubyBpIG1vxb5lIGJpdGkgemFrb25za2kga2HFvm5qaXZvLiBT YWRyxb5haiwgc3Rhdm92aSBpIG1pxaFsamVuamEgaXpuZXNlbmkgdSBwb3J1Y2kgc3UgYXV0b3Jv dmkgaSBuZSBwcmVkc3RhdmxqYWp1IG51xb5ubyBzdGF2b3ZlIEhUIC0gSHJ2YXRza2loIHRlbGVr b211bmlrYWNpamEgZC5kLiBIVCBuZSBwcmlodmHEh2EgbmlrYWt2dSBvZGdvdm9ybm9zdCB6YSBl dmVudHVhbG51IMWhdGV0dSBuYXN0YWx1IHByaW1pdGtvbSBvdmUgcG9ydWtlIGkgcHJpbG9nYSBz YWRyxb5hbmloIHUgcG9ydWNpLg0KDQo8L0ZPTlQ+PC9QPjxQPjxGT05UIGZhY2U9QXJpYWwgY29s b3I9Izk5OTk5OSBzaXplPTE+DQoNCiBESVNDTEFJTUVSOlRoZSBjb250ZW50cyBvZiB0aGlzIGVt YWlsIGFzIHdlbGwgYXMgYW55IGZpbGVzIGF0dGFjaGVkIHRvIGl0IGFyZSBjb25maWRlbnRpYWwg YW5kIGludGVuZGVkIHNvbGVseSBmb3IgaW5kaXZpZHVhbHMgb3IgZW50aXRpZXMgd2hpY2ggdGhl eSBhcmUgYWRkcmVzc2VkIHRvLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIG1lc3Nh Z2UgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBhbmQgcGVybWFuZW50bHkgcmVt b3ZlIHRoZSBtZXNzYWdlIGFuZCBhbGwgYXR0YWNoZWQgZmlsZXMgZnJvbSB0aGUgY29tcHV0ZXIu IEFueSBkaXNjbG9zdXJlLCBjb3B5aW5nIG9yIGRpc3RyaWJ1dGlvbiBvZiBhbGwgb3IgYSBwYXJ0 IG9mIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBoZXJlaW4gdG8gb3IgYnkgdGhpcmQgcGFydGllcyBp cyBwcm9oaWJpdGVkIGFuZCBtYXkgYmUgdW5sYXdmdWwuIFBsZWFzZSBub3RlIHRoYXQgYW55IHZp ZXdzIG9yIG9waW5pb25zIHByZXNlbnRlZCBpbiB0aGlzIG1lc3NhZ2UgYXJlIHNvbGVseSB0aG9z ZSBvZiB0aGUgYXV0aG9yIGFuZCBkbyBub3QgbmVjZXNzYXJpbHkgcmVwcmVzZW50IHRoZSB2aWV3 cyBhbmQgb3BpbmlvbnMgb2YgQ3JvYXRpYW4gVGVsZWNvbSBJbmMuIENyb2F0aWFuIFRlbGVjb20g SW5jLiBhY2NlcHRzIG5vIGxpYWJpbGl0eSBmb3IgYW55IHBvdGVudGlhbCBkYW1hZ2UgY2F1c2Vk IGJ5IHRoaXMgbWVzc2FnZSBhbmQgZmlsZXMgYXR0YWNoZWQgdG8gaXQuDQoNCjwvRk9OVD48L1A+ PC9IVE1MPgo= From Ted.Lemon@nominum.com Thu May 16 05:51:22 2013 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 13DB621F90EB for ; Thu, 16 May 2013 05:51:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.577 X-Spam-Level: X-Spam-Status: No, score=-106.577 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wc1ql6a1m0OI for ; Thu, 16 May 2013 05:51:15 -0700 (PDT) Received: from exprod7og126.obsmtp.com (exprod7og126.obsmtp.com [64.18.2.206]) by ietfa.amsl.com (Postfix) with ESMTP id 422F421F8EC1 for ; Thu, 16 May 2013 05:51:15 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob126.postini.com ([64.18.6.12]) with SMTP ID DSNKUZTWQtVDfgH4sKiywo94GSE0wBShfqTG@postini.com; Thu, 16 May 2013 05:51:15 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id CCA141B819F for ; Thu, 16 May 2013 05:51:13 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id BDDC319005D; Thu, 16 May 2013 05:51:13 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.02.0318.004; Thu, 16 May 2013 05:51:07 -0700 From: Ted Lemon To: Branimir Rajtar Thread-Topic: [dhcwg] Conclusion for draft-ietf-dhc-v4configuration-00 Thread-Index: AQHOUWzOksvS2kVeK0CojhlacokdApkGrpoAgABOfACAANnMAIAACTOAgABadgA= Date: Thu, 16 May 2013 12:51:05 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B63077519F6EF@mbx-01.win.nominum.com> References: <1775E640-867C-41E3-8EAC-2554D80D4DF6@cisco.com> <786F13AA11E69F4DB2CCA23F7400C2FB0142D776@S2010EXCH1.ad.local> In-Reply-To: <786F13AA11E69F4DB2CCA23F7400C2FB0142D776@S2010EXCH1.ad.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="us-ascii" Content-ID: <5A8EE52AEE1BCB4899CF481803727243@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dhcwg@ietf.org" , "volz@cisco.com" , "sunqi@csnet1.cs.tsinghua.edu.cn" Subject: Re: [dhcwg] Conclusion for draft-ietf-dhc-v4configuration-00 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 May 2013 12:51:22 -0000 On May 16, 2013, at 3:27 AM, Branimir Rajtar wrot= e: > This would also resolve Bernie's comment about the need to include a "con= " for DHCPv4-over-DHCPv6 saying that relays have to be updated as well. I think that would have to be restricted to "broken relays may need to be f= ixed," because relays _really_ shouldn't be dropping unknown message types,= even though 3315 never _required_ them not to. From ian.farrer@telekom.de Thu May 16 10:16:17 2013 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 9F74B11E812B for ; Thu, 16 May 2013 10:16:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.924 X-Spam-Level: X-Spam-Status: No, score=-2.924 tagged_above=-999 required=5 tests=[AWL=0.325, BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xCRZRzRdbMOf for ; Thu, 16 May 2013 10:16:12 -0700 (PDT) Received: from tcmail23.telekom.de (tcmail23.telekom.de [80.149.113.243]) by ietfa.amsl.com (Postfix) with ESMTP id 25F5511E8129 for ; Thu, 16 May 2013 10:16:11 -0700 (PDT) Received: from he113443.emea1.cds.t-internal.com ([10.134.93.103]) by tcmail21.telekom.de with ESMTP/TLS/AES128-SHA; 16 May 2013 19:16:09 +0200 Received: from HE111643.EMEA1.CDS.T-INTERNAL.COM ([10.134.93.12]) by HE113443.emea1.cds.t-internal.com ([::1]) with mapi; Thu, 16 May 2013 19:16:09 +0200 From: To: Date: Thu, 16 May 2013 19:16:10 +0200 Thread-Topic: Mail regarding draft-ietf-dhc-dhcpv4-over-dhcpv6 Thread-Index: Ac5SWQ5jx0WZZ3uNToWjNovpWlYo2Q== Message-ID: Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.4.130416 acceptlanguage: en-US, de-DE Content-Type: multipart/alternative; boundary="_000_CDBAE0FA70B55ianfarrertelekomde_" MIME-Version: 1.0 Cc: dhcwg@ietf.org Subject: [dhcwg] Mail regarding draft-ietf-dhc-dhcpv4-over-dhcpv6 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 May 2013 17:16:17 -0000 --_000_CDBAE0FA70B55ianfarrertelekomde_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I was just looking through this draft again and one thing that I noticed is= that the RFC4361 compliant behaviour is only mandated for clients. There i= s no mention of compliance for the server. Surely, it's needed for both? Cheers, Ian --_000_CDBAE0FA70B55ianfarrertelekomde_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi,
=
I was just looking through this draft again and one thing th= at I noticed is that the RFC4361 compliant behaviour is only mandated for c= lients. There is no mention of compliance for the server. Surely, it's need= ed for both?

Cheers,
Ian
--_000_CDBAE0FA70B55ianfarrertelekomde_-- From Ted.Lemon@nominum.com Thu May 16 10:20:58 2013 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 1EEEE11E8129 for ; Thu, 16 May 2013 10:20:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.567 X-Spam-Level: X-Spam-Status: No, score=-106.567 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SMLijJX4hoP5 for ; Thu, 16 May 2013 10:20:43 -0700 (PDT) Received: from exprod7og103.obsmtp.com (exprod7og103.obsmtp.com [64.18.2.159]) by ietfa.amsl.com (Postfix) with ESMTP id CEA8F21F898B for ; Thu, 16 May 2013 10:20:42 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob103.postini.com ([64.18.6.12]) with SMTP ID DSNKUZUVaj7aQFyWV8RowNSNhp5AFaa3G7bX@postini.com; Thu, 16 May 2013 10:20:42 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 2D6A71B8195 for ; Thu, 16 May 2013 10:20:42 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 26E2419005D; Thu, 16 May 2013 10:20:42 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.02.0318.004; Thu, 16 May 2013 10:20:42 -0700 From: Ted Lemon To: "ian.farrer@telekom.de" Thread-Topic: [dhcwg] Mail regarding draft-ietf-dhc-dhcpv4-over-dhcpv6 Thread-Index: Ac5SWQ5jx0WZZ3uNToWjNovpWlYo2QAO04MA Date: Thu, 16 May 2013 17:20:41 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B6307751A226F@mbx-01.win.nominum.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: multipart/alternative; boundary="_000_8D23D4052ABE7A4490E77B1A012B6307751A226Fmbx01winnominum_" MIME-Version: 1.0 Cc: "" , "" Subject: Re: [dhcwg] Mail regarding draft-ietf-dhc-dhcpv4-over-dhcpv6 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 May 2013 17:20:58 -0000 --_000_8D23D4052ABE7A4490E77B1A012B6307751A226Fmbx01winnominum_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On May 16, 2013, at 1:16 PM, ian.farrer@telekom.de wrote: I was just looking through this draft again and one thing that I noticed is= that the RFC4361 compliant behaviour is only mandated for clients. There i= s no mention of compliance for the server. Surely, it's needed for both? Servers don't care. It's just an opaque identifier to the server. We do= n't have a DHCPv4/DHCPv6 combined server document; if we did it might talk = about how to handle this. I think my inventory document should mention it= if it doesn't. --_000_8D23D4052ABE7A4490E77B1A012B6307751A226Fmbx01winnominum_ Content-Type: text/html; charset="us-ascii" Content-ID: <41311E347E69484787D3C7D0800AF340@nominum.com> Content-Transfer-Encoding: quoted-printable
On May 16, 2013, at 1:16 PM, = ian.farrer@telekom.de wrote:
I was just looking through this draft again and one thing that I noticed is = that the RFC4361 compliant behaviour is only mandated for clients. There is= no mention of compliance for the server. Surely, it's needed for both?

Servers don't care.   It's just an opaque identifier to the serve= r.   We don't have a DHCPv4/DHCPv6 combined server document; if we did= it might talk about how to handle this.   I think my inventory docume= nt should mention it if it doesn't.

--_000_8D23D4052ABE7A4490E77B1A012B6307751A226Fmbx01winnominum_-- From iesg-secretary@ietf.org Thu May 16 12:38:51 2013 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 6A6AF11E811B; Thu, 16 May 2013 12:38:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.51 X-Spam-Level: X-Spam-Status: No, score=-102.51 tagged_above=-999 required=5 tests=[AWL=0.090, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mBUDrQwZqTPO; Thu, 16 May 2013 12:38:50 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 829A711E80A2; Thu, 16 May 2013 12:38:50 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.45 Sender: Message-ID: <20130516193850.11997.5710.idtracker@ietfa.amsl.com> Date: Thu, 16 May 2013 12:38:50 -0700 Cc: dhcwg@ietf.org Subject: [dhcwg] Last Call: (RADIUS Option for DHCPv6 Relay Agent) to Proposed Standard X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 May 2013 19:38:51 -0000 The IESG has received a request from the Dynamic Host Configuration WG (dhc) to consider the following document: - 'RADIUS Option for DHCPv6 Relay Agent' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2013-05-30. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract The DHCPv6 RADIUS option provides a mechanism to exchange authorization and identification information between the DHCPv6 relay agent and the DHCPv6 server. This mechanism is meant for the centralized DHCPv6 server to select the right configuration for the requesting DHCPv6 client based on the authorization information received from the RADIUS server, which is not co-located with the DHCPv6 server. The Network Access Server (NAS) acts as DHCPv6 relay agent and RADIUS client simultaneously in this document. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv6-radius-opt/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv6-radius-opt/ballot/ The following IPR Declarations may be related to this I-D: http://datatracker.ietf.org/ipr/2052/ From ian.farrer@telekom.de Fri May 17 00:10:15 2013 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 D3A0321F93D1 for ; Fri, 17 May 2013 00:10:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.988 X-Spam-Level: X-Spam-Status: No, score=-2.988 tagged_above=-999 required=5 tests=[AWL=0.260, BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fH8oC6NuBSfo for ; Fri, 17 May 2013 00:10:10 -0700 (PDT) Received: from tcmail43.telekom.de (tcmail43.telekom.de [80.149.113.173]) by ietfa.amsl.com (Postfix) with ESMTP id 23DE621F93BA for ; Fri, 17 May 2013 00:10:09 -0700 (PDT) Received: from he113443.emea1.cds.t-internal.com ([10.134.93.103]) by tcmail41.telekom.de with ESMTP/TLS/AES128-SHA; 17 May 2013 09:10:07 +0200 Received: from HE111643.EMEA1.CDS.T-INTERNAL.COM ([10.134.93.12]) by HE113443.emea1.cds.t-internal.com ([::1]) with mapi; Fri, 17 May 2013 09:10:07 +0200 From: To: Date: Fri, 17 May 2013 09:10:11 +0200 Thread-Topic: [dhcwg] Mail regarding draft-ietf-dhc-dhcpv4-over-dhcpv6 Thread-Index: Ac5SzY8gF6BYqGohSTmtNW8ZvROpfA== Message-ID: In-Reply-To: <8D23D4052ABE7A4490E77B1A012B6307751A226F@mbx-01.win.nominum.com> Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.4.130416 acceptlanguage: en-US, de-DE Content-Type: multipart/alternative; boundary="_000_CDBB9A2770B67ianfarrertelekomde_" MIME-Version: 1.0 Cc: dhcwg@ietf.org, draft-ietf-dhc-dhcpv4-over-dhcpv6@tools.ietf.org Subject: Re: [dhcwg] Mail regarding draft-ietf-dhc-dhcpv4-over-dhcpv6 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 May 2013 07:10:16 -0000 --_000_CDBB9A2770B67ianfarrertelekomde_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Ted, It was section 6.3 of rfc4361 that I was mainly referring to, which says th= at the server must use the client identifier option to identify the client = if the client sends one. Surely this must be relevant for the Unified DHCPv= 4 o DHCPv6 server as well? Cheers, Ian From: Ted Lemon > Date: Thursday, 16 May 2013 19:20 To: Ian Farrer > Cc: ">" >, "<= dhcwg@ietf.org>" > Subject: Re: [dhcwg] Mail regarding draft-ietf-dhc-dhcpv4-over-dhcpv6 On May 16, 2013, at 1:16 PM, ian.farrer@telekom.de wrote: I was just looking through this draft again and one thing that I noticed is= that the RFC4361 compliant behaviour is only mandated for clients. There i= s no mention of compliance for the server. Surely, it's needed for both? Servers don't care. It's just an opaque identifier to the server. We do= n't have a DHCPv4/DHCPv6 combined server document; if we did it might talk = about how to handle this. I think my inventory document should mention it= if it doesn't. --_000_CDBB9A2770B67ianfarrertelekomde_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Ted,
<= div>

It was section 6.3 of rfc4361 tha= t I was mainly referring to, which says that the server must use the client= identifier option to identify the client if the client sends one. Surely t= his must be relevant for the Unified DHCPv4 o DHCPv6  server as well?<= /div>

Cheers,
Ian

From: Ted Lemon <Ted.Lemon@nominum.com>
Date: Thursday, 16 May 2013 19:20
To: Ian Farrer <ian.farrer@telekom.de>
Cc: "<draft-ietf-dhc-dhcpv4-over-dhcpv6@tools.ietf.org>" <<= a href=3D"mailto:draft-ietf-dhc-dhcpv4-over-dhcpv6@tools.ietf.org">draft-ie= tf-dhc-dhcpv4-over-dhcpv6@tools.ietf.org>, "<dhcwg@ietf.org>" <dhcwg@ietf.org>
Subject: Re: [dhcwg] Mail regarding draft-ietf-dhc-dhcpv4-over-dhcpv6

On May 16, 2013, at 1= :16 PM, ian.farrer@telekom.de = wrote:
I was just looking through this draft again and one thing that I noticed is = that the RFC4361 compliant behaviour is only mandated for clients. There is= no mention of compliance for the server. Surely, it's needed for both?

Servers don't care.   It's just an opaq= ue identifier to the server.   We don't have a DHCPv4/DHCPv6 combined = server document; if we did it might talk about how to handle this.   I= think my inventory document should mention it if it doesn't.
--_000_CDBB9A2770B67ianfarrertelekomde_-- From ps3910@att.com Fri May 17 08:56:24 2013 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 9330721F8633 for ; Fri, 17 May 2013 08:56:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GP+ic1nrDurf for ; Fri, 17 May 2013 08:56:17 -0700 (PDT) Received: from nbfkord-smmo06.seg.att.com (nbfkord-smmo06.seg.att.com [209.65.160.94]) by ietfa.amsl.com (Postfix) with ESMTP id 78CD921F9705 for ; Fri, 17 May 2013 08:56:17 -0700 (PDT) Received: from unknown [144.160.128.153] (EHLO flpi408.enaf.ffdc.sbc.com) by nbfkord-smmo06.seg.att.com(mxl_mta-6.15.0-1) over TLS secured channel with ESMTP id 02356915.0.183744.00-422.493828.nbfkord-smmo06.seg.att.com (envelope-from ); Fri, 17 May 2013 15:56:17 +0000 (UTC) X-MXL-Hash: 519653217d67bb2c-d36f7500c32dee2abff45be8175b0be12cf910a5 Received: from enaf.ffdc.sbc.com (localhost.localdomain [127.0.0.1]) by flpi408.enaf.ffdc.sbc.com (8.14.5/8.14.5) with ESMTP id r4HFuGFt024566 for ; Fri, 17 May 2013 08:56:16 -0700 Received: from fflint02.pst.cso.att.com (fflint02.pst.cso.att.com [150.234.39.62]) by flpi408.enaf.ffdc.sbc.com (8.14.5/8.14.5) with ESMTP id r4HFu7qJ024494 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 17 May 2013 08:56:10 -0700 Received: from CAFRFD1MSGHUB9C.ITServices.sbc.com (cafrfd1msghub9c.itservices.sbc.com [135.161.21.163]) by fflint02.pst.cso.att.com (RSA Interceptor) for ; Fri, 17 May 2013 15:55:52 GMT Received: from CAFRFD1MSGUSR9B.ITServices.sbc.com ([135.161.21.119]) by CAFRFD1MSGHUB9C.ITServices.sbc.com ([135.161.21.163]) with mapi id 14.02.0342.003; Fri, 17 May 2013 08:55:52 -0700 From: "SPHICAS, PHIL G" To: "dhcwg@ietf.org" Thread-Topic: Source address in IP header for DHCPREQUEST generated during REBINDING state? Thread-Index: Ac5TFwCZQThGRUOORB6W+9eiQ3WatA== Date: Fri, 17 May 2013 15:55:51 +0000 Message-ID: <9280E04CB62287499A422F43DB33336627A4EB@CAFRFD1MSGUSR9B.ITServices.sbc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.245.27.227] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.128.153] X-AnalysisOut: [v=2.0 cv=Hc+juF48 c=1 sm=0 a=xwOvzTHDVLE4u4nGvK72ag==:17 a] X-AnalysisOut: [=HaP5d7ZPZLwA:10 a=MPmICGlztlcA:10 a=ofMgfj31e3cA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=kj9zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=XIqpo32R] X-AnalysisOut: [AAAA:8 a=9F2vXSKZ7jsA:10 a=tiav8gdMYgC1uQg01dUA:9 a=CjuIK1] X-AnalysisOut: [q_8ugA:10 a=RwVWOfghIT0qdYND:21 a=PkPLL9voA5jwkUXr:21] X-Mailman-Approved-At: Fri, 17 May 2013 09:06:47 -0700 Subject: [dhcwg] Source address in IP header for DHCPREQUEST generated during REBINDING state? X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 May 2013 16:03:26 -0000 Hello, What is the correct source IP address for a DHCPREQUEST generated during RE= BINDING state? Should it be the unicast IP, or 0.0.0.0? I'm not quite clear on this after combing through RFC 2131 .. any pointers = would be appreciated. RFC 2131 4.3.2 DHCPREQUEST message=20 DHCPREQUEST generated during REBINDING state This message MUST be broadcast to the 0xffffffff IP broadcast address. -- This doesn't specify the source IP RFC 2131 4.1 Constructing and sending DHCP messages DHCP clients MUST use the IP address provided in the 'server identifier' op= tion for any unicast requests to the DHCP server. -- This is a broadcast request, not a unicast request DHCP messages broadcast by a client prior to that client obtaining its IP a= ddress must have the source address field in the IP header set to 0. -- This is after the client has obtained an IP address Thanks, Phil From ghalwasi@cisco.com Fri May 17 09:08:34 2013 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 5946E21F964B for ; Fri, 17 May 2013 09:08:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wc-ieYfzxhXI for ; Fri, 17 May 2013 09:08:29 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 5ECE621F90EE for ; Fri, 17 May 2013 09:08:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1392; q=dns/txt; s=iport; t=1368806909; x=1370016509; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=0K7bCbIf35/gfwbS0GWpnsucahwHW0RsbxpKZ31H3sQ=; b=CfVH6fGhwLHy/c3EwRtoHayt/L9sdKMAnAcaxRdSqcGIhOqC1fVZoVhk sip4sOWYScUw+kpjQ8Z69C8T+5mXeJ20kjwsBKB+39zZBvLU6j4w71Qp7 S825kfoRb5QSasC11hqKEokJ2a3ZkK9DKYcVrSJMNIxZXsJl9yGmA9eL7 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgwFALZUllGtJXHA/2dsb2JhbABbgwgwwVB+FnSCHwEBAQQBAQE3NBcEAgEIEQQBAQsUCQcnCxQJCAEBBAESCIgEDL06BI5wOAaCbWEDqHiBWIE3giY X-IronPort-AV: E=Sophos;i="4.87,693,1363132800"; d="scan'208";a="211853697" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-3.cisco.com with ESMTP; 17 May 2013 16:08:28 +0000 Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id r4HG8S02029879 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 17 May 2013 16:08:28 GMT Received: from xmb-aln-x06.cisco.com ([169.254.1.198]) by xhc-rcd-x04.cisco.com ([fe80::200:5efe:173.37.183.34%12]) with mapi id 14.02.0318.004; Fri, 17 May 2013 11:08:28 -0500 From: "Gaurav Halwasia (ghalwasi)" To: "SPHICAS, PHIL G" , "dhcwg@ietf.org" Thread-Topic: [dhcwg] Source address in IP header for DHCPREQUEST generated during REBINDING state? Thread-Index: Ac5TFwCZQThGRUOORB6W+9eiQ3WatAAAaxCQ Date: Fri, 17 May 2013 16:08:27 +0000 Message-ID: <90903C21C73202418A48BFBE80AEE5EB22F60728@xmb-aln-x06.cisco.com> References: <9280E04CB62287499A422F43DB33336627A4EB@CAFRFD1MSGUSR9B.ITServices.sbc.com> In-Reply-To: <9280E04CB62287499A422F43DB33336627A4EB@CAFRFD1MSGUSR9B.ITServices.sbc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.50.127] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dhcwg] Source address in IP header for DHCPREQUEST generated during REBINDING state? X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 May 2013 16:08:34 -0000 It should be unicast IP allocated by the server. -Gaurav -----Original Message----- From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of S= PHICAS, PHIL G Sent: Friday, May 17, 2013 9:26 PM To: dhcwg@ietf.org Subject: [dhcwg] Source address in IP header for DHCPREQUEST generated duri= ng REBINDING state? Hello, What is the correct source IP address for a DHCPREQUEST generated during RE= BINDING state? Should it be the unicast IP, or 0.0.0.0? I'm not quite clear on this after combing through RFC 2131 .. any pointers = would be appreciated. RFC 2131 4.3.2 DHCPREQUEST message=20 DHCPREQUEST generated during REBINDING state This message MUST be broadcast to the 0xffffffff IP broadcast address. -- This doesn't specify the source IP RFC 2131 4.1 Constructing and sending DHCP messages DHCP clients MUST use the IP address provided in the 'server identifier' op= tion for any unicast requests to the DHCP server. -- This is a broadcast request, not a unicast request DHCP messages broadcast by a client prior to that client obtaining its IP a= ddress must have the source address field in the IP header set to 0. -- This is after the client has obtained an IP address Thanks, Phil _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From akostur@incognito.com Fri May 17 09:10:36 2013 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 2AF7121F920B for ; Fri, 17 May 2013 09:10:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.977 X-Spam-Level: X-Spam-Status: No, score=-5.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zOGkhf-at7BY for ; Fri, 17 May 2013 09:10:30 -0700 (PDT) Received: from na3sys010aog106.obsmtp.com (na3sys010aog106.obsmtp.com [74.125.245.80]) by ietfa.amsl.com (Postfix) with SMTP id 8F65A21F8CEC for ; Fri, 17 May 2013 09:10:30 -0700 (PDT) Received: from mail-vb0-f46.google.com ([209.85.212.46]) (using TLSv1) by na3sys010aob106.postini.com ([74.125.244.12]) with SMTP ID DSNKUZZWdqwUhjFCYspC4bLN6aRwzhIpTzF4@postini.com; Fri, 17 May 2013 09:10:30 PDT Received: by mail-vb0-f46.google.com with SMTP id 10so2354061vbe.19 for ; Fri, 17 May 2013 09:10:29 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:x-received:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=qrmyHNHGQ6e9V5OP+7tN/Io/sNBonZfXjNqJhEyGSik=; b=nHk8xLu9lEcS+nSLQ6SmZKTAHIbX9ixgckOD2UMTLDBSexBFT9LqaOo+vaGo4sia/3 2pL0XWlzETg1dCpcOgR2dDjQ/1xqO73Ce97aASfu+byxE2NKrvQrHj0Gh2l2AcbjjchP 8lgcNoEl5TPE1tJzN4qysusn/Dm11Pg31N7d2JYF241NdBnZD0w/Pz7HsNpMWYgHlnNB HgOX1WH+ZzzPggLl+rdQsmvfLGwRu0c8VHhhbeUKPdU5wRdjW3rNTIoEKpKV9rOSyHNL S6cdA37aitJzVWr7dYluJaaoi8Ma286K3KSkEUjsGUAEs/DVZgE4M1P9eNfVunYm9byz WQVg== X-Received: by 10.59.6.101 with SMTP id ct5mr29831033ved.8.1368807029649; Fri, 17 May 2013 09:10:29 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.59.6.101 with SMTP id ct5mr29831031ved.8.1368807029573; Fri, 17 May 2013 09:10:29 -0700 (PDT) Received: by 10.220.61.198 with HTTP; Fri, 17 May 2013 09:10:29 -0700 (PDT) In-Reply-To: <9280E04CB62287499A422F43DB33336627A4EB@CAFRFD1MSGUSR9B.ITServices.sbc.com> References: <9280E04CB62287499A422F43DB33336627A4EB@CAFRFD1MSGUSR9B.ITServices.sbc.com> Date: Fri, 17 May 2013 09:10:29 -0700 Message-ID: From: Andre Kostur To: "SPHICAS, PHIL G" Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQkJuIejh0cBQP5gNit+SU+asuuE9Nvwqxvg88/VOE8C5XX20HIbmiDdHN5qHefRQPBpcGuK5QmOXEZgOu4NCT/fMcBrkGFKYFCq36B+TbaPWIX/DIL/KGkzNXUN0t+4tSh/tVEaUjgB1VuMEiBGsMYNdbyEzg== Cc: "dhcwg@ietf.org" Subject: Re: [dhcwg] Source address in IP header for DHCPREQUEST generated during REBINDING state? X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 May 2013 16:10:36 -0000 On a REBIND I would expect the source IP to be the IP of the client. At the Rebind state the client still owns the IP address, it's just that it no longer "trusts" that the server is still there, so now it is broadcasting to see if any server is willing to continue servicing this client. On Fri, May 17, 2013 at 8:55 AM, SPHICAS, PHIL G wrote: > Hello, > > What is the correct source IP address for a DHCPREQUEST generated during REBINDING state? Should it be the unicast IP, or 0.0.0.0? > > I'm not quite clear on this after combing through RFC 2131 .. any pointers would be appreciated. > > RFC 2131 > 4.3.2 DHCPREQUEST message > DHCPREQUEST generated during REBINDING state > > This message MUST be broadcast to the 0xffffffff IP broadcast address. > > -- This doesn't specify the source IP > > RFC 2131 > 4.1 Constructing and sending DHCP messages > > DHCP clients MUST use the IP address provided in the 'server identifier' option for any unicast requests to the DHCP server. > > -- This is a broadcast request, not a unicast request > > DHCP messages broadcast by a client prior to that client obtaining its IP address must have the source address field in the IP header set to 0. > > -- This is after the client has obtained an IP address > > Thanks, > Phil > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg -- Andre Kostur From sunqi.csnet.thu@gmail.com Sat May 18 20:16:01 2013 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 2126721F8AA8 for ; Sat, 18 May 2013 20:16:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_53=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w9bisx+p8zKg for ; Sat, 18 May 2013 20:15:56 -0700 (PDT) Received: from mail-pa0-f44.google.com (mail-pa0-f44.google.com [209.85.220.44]) by ietfa.amsl.com (Postfix) with ESMTP id 416C721F870F for ; Sat, 18 May 2013 20:15:56 -0700 (PDT) Received: by mail-pa0-f44.google.com with SMTP id jh10so4725153pab.3 for ; Sat, 18 May 2013 20:15:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:subject:mime-version:content-type:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer; bh=MTIReYnECl/z26IMvbSXK0MZVpqQfdP6ehSRKlA6eZY=; b=QQrOxhPjSrwXD3sTeydFMNDMU9uC3cVfszFT3LvfL8lc3r36eKU3X6KG8tvIHvknMh FspooCCkF9wBk1TzFjrxXWEyydszaDWWWr0jH37EENNkDf7izkaD5NrPAW1DumzLFD8X 7oMfLMzzxcdcuoDeEBcUFQYHXtNaKro5j2yy6xvvHxb/E+mAGfP0oy1sxNI0zUne3v9X wHb4sJsDZskpCvG+ro2rB53IL99j/ncKHuH6E8+NUokrcFaKwRot+pHwD7f2q7pD48ep QbYcXTiodh2+RI6ctF6CeVm5tvUq9iyS7op1wgdVGs1u2dJwyb7R3+D4nzz/phfAmKLL SriQ== X-Received: by 10.68.178.130 with SMTP id cy2mr30692958pbc.106.1368933355970; Sat, 18 May 2013 20:15:55 -0700 (PDT) Received: from [192.168.0.107] ([114.255.40.13]) by mx.google.com with ESMTPSA id xl10sm19283584pac.15.2013.05.18.20.15.53 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 18 May 2013 20:15:55 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=utf-8 From: Qi Sun In-Reply-To: <786F13AA11E69F4DB2CCA23F7400C2FB0142D318@S2010EXCH1.ad.local> Date: Sun, 19 May 2013 11:15:34 +0800 Content-Transfer-Encoding: quoted-printable Message-Id: <68669AD1-A5DE-4F65-8A74-FAD367C21418@gmail.com> References: <8A1B81989BCFAE44A22B2B86BF2B7631898DB0232B@HE111643.EMEA1.CDS.T-INTERNAL.COM> <51780A17.8010503@gmail.com> <489D13FBFA9B3E41812EA89F188F018E18552B99@xmb-rcd-x04.cisco.com> <518B7628.3020309@gmail.com> <786F13AA11E69F4DB2CCA23F7400C2FB0142D318@S2010EXCH1.ad.local> To: Branimir Rajtar X-Mailer: Apple Mail (2.1084) Cc: "dhcwg@ietf.org" Subject: Re: [dhcwg] Conclusion for draft-ietf-dhc-v4configuration-00 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 May 2013 03:16:01 -0000 I also think the text seems good. Best Regards, Qi Sun On 2013-5-15, at =E4=B8=8B=E5=8D=885:26, Branimir Rajtar wrote: > Hi all,=20 >=20 > Following on Tomek's e-mail and the upload of = draft-ietf-dhc-v4configuration-00, the authors would like to start the = discussion on it's conclusion. Following the talk on the mailing list, = our proposal is as follows: >=20 > "Whilst all of the approaches described here will require some = development work in order to realize, it is clear from the above = analysis that the most sustainable approach capitalizes on existing = DHCPv4 implementations and include them as new DHCPv6 message types. = The main rationale for this is that it enables all of DHCPv4's existing = options to be migrated for use over IPv6 in a single step. >=20 > Porting of all necessary DHCPv4 options to DHCPv6 would require = ongoing development work, re-implementing existing DHCPv4 functionality = in DHCPv6. This will result in having legacy DHCPv4 options in DHCPv6, = which will no longer be useful once IPv4 is completely abandoned. >=20 > Therefore, the DHCPv6 approach is not suitable for delivering IPv4 = configuration parameters in an efficient, ongoing manner. >=20 > The dynamical leasing of IPv4 addresses is fundamental to the = efficient use of remaining IPv4 resources. This will become increasingly = important in the future, so a mechanism which supports this is = necessary. DHCPv4oSW does not provide this function and so is not = recommended. >=20 > The DHCPv4o6 approach requires a DHCPv4 server (with DHCPv4o6 = functionality) for all deployment scenarios, even when DHCPv4 specific = functionality is not required by the operator. >=20 > Therefore, this memo recommends DHCPv4oDHCPv6 = as the best underlying approach for = provisioning IPv4 parameters over an IPv6 only network." >=20 > Also, we propose two changes to the document itself which we find = should better reflect the overview of all proposals: > 1. Section 3, requirement no. 6 - should be "No" for DHCPv4o6=20 > 1. Section 3, requirement no. 1 - should be "No" for DHCPv4oSW >=20 > BR, > Branimir >=20 >=20 > -----Original Message----- > From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf = Of Tomek Mrugalski > Sent: Thursday, May 09, 2013 12:11 PM > To: dhcwg@ietf.org > Subject: Re: [dhcwg] Adoption call for = draft-rajtar-dhc-v4configuration-02 - adopted! >=20 > On 13-05-08 15:51, Bernie Volz (volz) wrote: >> 2. (WG co-chair hat on): If you have not expressed support or = opposition for adopting this work, the call expires today! > Hi, >=20 > Although this adoption call looked a bit grim for the first 10 days, > large support voiced in the last couple days saved the day. We have > around a dozen support voices, which means that this I-D was adopted. >=20 > Authors, please upload it as draft-ietf-dhc-v4configuration-00. Once > that is done, I encourage authors to start a discussion about > recommendation that the WG wants to offer. >=20 > It is a pleasure to see such a strong consensus. Let's hope that the > discussion about writing Conclusion section will have equally strong > consensus. >=20 > Bernie & Tomek >=20 > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg >=20 >=20 >

>=20 > IZJAVA O ODRICANJU ODGOVORNOSTI: Sadr=C5=BEaj ove poruke i eventualno = prilo=C5=BEenih datoteka je povjerljiv i namijenjen je samo osobama ili = subjektima koji su navedeni u adresi. Ukoliko ste primili ovu poruku = gre=C5=A1kom, molimo Vas, obavijestite po=C5=A1iljatelja, a poruku i sve = njene privitke odmah, bez =C4=8Ditanja, trajno uklonite s ra=C4=8Dunala. = Bilo kakvo preno=C5=A1enje, kopiranje ili distribucija informacija = sadr=C5=BEanih u poruci tre=C4=87im osobama je zabranjeno i mo=C5=BEe = biti zakonski ka=C5=BEnjivo. Sadr=C5=BEaj, stavovi i mi=C5=A1ljenja = izneseni u poruci su autorovi i ne predstavljaju nu=C5=BEno stavove HT - = Hrvatskih telekomunikacija d.d. HT ne prihva=C4=87a nikakvu odgovornost = za eventualnu =C5=A1tetu nastalu primitkom ove poruke i priloga = sadr=C5=BEanih u poruci. >=20 >

>=20 > DISCLAIMER:The contents of this email as well as any files attached to = it are confidential and intended solely for individuals or entities = which they are addressed to. If you have received this email message in = error, please notify the sender and permanently remove the message and = all attached files from the computer. Any disclosure, copying or = distribution of all or a part of information contained herein to or by = third parties is prohibited and may be unlawful. Please note that any = views or opinions presented in this message are solely those of the = author and do not necessarily represent the views and opinions of = Croatian Telecom Inc. Croatian Telecom Inc. accepts no liability for any = potential damage caused by this message and files attached to it. >=20 >

> _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg From sunqi.csnet.thu@gmail.com Sat May 18 20:31:31 2013 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 8E58821F8B64 for ; Sat, 18 May 2013 20:31:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_53=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id swnv50xkPNPn for ; Sat, 18 May 2013 20:31:25 -0700 (PDT) Received: from mail-pa0-f43.google.com (mail-pa0-f43.google.com [209.85.220.43]) by ietfa.amsl.com (Postfix) with ESMTP id B70ED21F8B2B for ; Sat, 18 May 2013 20:31:25 -0700 (PDT) Received: by mail-pa0-f43.google.com with SMTP id hz10so4719211pad.30 for ; Sat, 18 May 2013 20:31:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:subject:mime-version:content-type:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer; bh=LcRvSdrtaPDmvGbOsbsa9nvR6/FZ7XcXxRAq9bQcKzc=; b=nvtkH4dVac7qXx0EbucTcogQR2fZvjmtjtR5TA9HbmEyLBOmB9VjPJmo08U7wxg71O btqt/iNClBP00SMSiccpJNKWWFDtamxduxGrlqPveLcgafHj1so0/KuYoFeuanKKFl84 nwKnVGFvGypoe55+cxO3kIVj8ktCxsKsO8Sd0tmBEDslaWSd8lwlxkxFTphzMdvY7uNC P7XL00RQxSXu/WZ8bGKx657W1H/mfDW5vFUiIDQ4KhVKrmNV76ST9mP7T+ZVQ4wdD8OJ k22biVvVifnLsXu/RvYthCR3KUbR0FzoeSZHaA2qGzXUegD+1Gk7mlog0+xt6whFIwEs VeJA== X-Received: by 10.68.204.35 with SMTP id kv3mr55201571pbc.87.1368934285459; Sat, 18 May 2013 20:31:25 -0700 (PDT) Received: from [192.168.0.107] ([114.255.40.13]) by mx.google.com with ESMTPSA id nt2sm17963381pbc.17.2013.05.18.20.31.22 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 18 May 2013 20:31:24 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Qi Sun In-Reply-To: Date: Sun, 19 May 2013 11:31:17 +0800 Content-Transfer-Encoding: quoted-printable Message-Id: <1975C107-2E83-46A9-91B7-95DE7CFBB537@gmail.com> References: <8A1B81989BCFAE44A22B2B86BF2B7631898DB0232B@HE111643.EMEA1.CDS.T-INTERNAL.COM> <51780A17.8010503@gmail.com> <489D13FBFA9B3E41812EA89F188F018E18552B99@xmb-rcd-x04.cisco.com> <518B7628.3020309@gmail.com> <786F13AA11E69F4DB2CCA23F7400C2FB0142D318@S2010EXCH1.ad.local>, <8D23D4052ABE7A4490E77B1A012B63077519C2C9@mbx-01.win.nominum.com> To: Branimir Rajtar X-Mailer: Apple Mail (2.1084) Cc: "dhcwg@ietf.org WG" , Ted Lemon , "Bernie Volz \(volz\)" Subject: Re: [dhcwg] Conclusion for draft-ietf-dhc-v4configuration-00 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 May 2013 03:31:31 -0000 I notice in DHCPv6 based provisioning, it doesn't mention the DHCPv6 = server is required to manage IPv4 address while a DHCPv6 client is = responsible to configure IPv4 stack. These changes would live with = DHCPv6 if one used this set of mechanisms. DHCPv4oSW also has the same = issue (IPv4 address & port set are provisioning in DHCPv6 option), while = DHCPv4oDHCPv6 doesn't for it's the DHCPv4 client that takes the job. Is it necessary to consider this? Best Regards, Qi From sunqi.csnet.thu@gmail.com Sun May 19 09:16:12 2013 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 B4D9D21F859D for ; Sun, 19 May 2013 09:16:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4qW8L3BJq4rT for ; Sun, 19 May 2013 09:16:06 -0700 (PDT) Received: from mail-pa0-f48.google.com (mail-pa0-f48.google.com [209.85.220.48]) by ietfa.amsl.com (Postfix) with ESMTP id 0F01321F87D1 for ; Sun, 19 May 2013 09:16:04 -0700 (PDT) Received: by mail-pa0-f48.google.com with SMTP id kp6so4958663pab.21 for ; Sun, 19 May 2013 09:16:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:subject:mime-version:content-type:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer; bh=NzQ4KfX/cMWm4FwBcwjGJvFZLGsEa/5kCd21KqEFZ7g=; b=cqjcsXZy4drEGM3/1cTLPMWQ3/UQSn7fJgglH15pgVcCNhD4u5AEq2MRAoVjUMITDn rknHEPPS3B639GnMmkG6qwG0TPnFzAvtRFvDCBfHD2NpO55CS5wBwTrpglV1Cw2jgiHS uN7uHaLMQOhuHkWD9/jdjZAxowR9EvVPRfPneu5VYkMxI5wzVn8beJnrujcAEhmjojhu MOyKtDD0rTcDMEgXfYWtL9rMom0jT2/st92BkXUVZYeKEr7o4+/0QZCxzoTz0BDGv2WT aVnXlDy7i1wbueTvzqmdAthTxBKmmlxsPajz/yJChy1d3Sqeqjonn3k2YYR9WTLoMCAn lZuw== X-Received: by 10.68.60.130 with SMTP id h2mr56050189pbr.208.1368980163831; Sun, 19 May 2013 09:16:03 -0700 (PDT) Received: from [192.168.0.107] ([114.255.40.13]) by mx.google.com with ESMTPSA id vv6sm21724046pab.6.2013.05.19.09.16.00 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 19 May 2013 09:16:03 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=utf-8 From: Qi Sun In-Reply-To: <8D23D4052ABE7A4490E77B1A012B63077519C539@mbx-01.win.nominum.com> Date: Mon, 20 May 2013 00:15:56 +0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <8A1B81989BCFAE44A22B2B86BF2B7631898DB0232B@HE111643.EMEA1.CDS.T-INTERNAL.COM> <51780A17.8010503@gmail.com> <489D13FBFA9B3E41812EA89F188F018E18552B99@xmb-rcd-x04.cisco.com> <518B7628.3020309@gmail.com> <786F13AA11E69F4DB2CCA23F7400C2FB0142D318@S2010EXCH1.ad.local>, <8D23D4052ABE7A4490E77B1A012B63077519C2C9@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B63077519C539@mbx-01.win.nominum.com> To: Ted Lemon X-Mailer: Apple Mail (2.1084) Cc: "dhcwg@ietf.org" , "Bernie Volz \(volz\)" Subject: Re: [dhcwg] Conclusion for draft-ietf-dhc-v4configuration-00 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 May 2013 16:16:12 -0000 Dear Ted, > This is worth documenting, if it's not clear in the draft: the DHCPv4 = client knows to do this because it's not a DHCPv4 client=E2=80=94it's a = DHCPv4-over-DHCPv6 client. So it just assumes that DHCPv4-over-DHCPv6 = is available and tries to use it; if it succeeds, it is available, and = if it fails, it's not.=20 Yes, we should make it specific on how the client knows to use = DHCPv4-over-DHCPv6. > It might additionally be worth talking about when it decides to try: = when it notices a device on the homenet trying to use IPv4 to access an = off-network service, or does it do it as soon as it comes up? IMHO, this is necessary to document. As for the two proposals, I think = the second one would be more appropriate. The clients won't conflict: = DHCPv6 client will get an IPv6 address/a prefix from the Unified server, = DHCPv4-over-DHCPv6 client will get an IPv4 address from the Unified = server, and DHCPv4 client won't work (for there is no IPv4 transmission = network uplink).=20 The first one requires the client to be aware of requests behind the = homegateway. Would that complex the client's logic/function? Best Regards, Qi Sun On 2013-5-15, at =E4=B8=8B=E5=8D=889:13, Ted Lemon wrote: > On May 15, 2013, at 9:04 AM, Bernie Volz (volz) = wrote: >> One issue which is more for the actual draft on this method is how = does dhcpv4 client determine to do this (send over v6) rather than = attempt normal dhcpv4 - or perhaps client tries both methods at same = time? But that's likely an issue for all if the techiques. >=20 > This is worth documenting, if it's not clear in the draft: the DHCPv4 = client knows to do this because it's not a DHCPv4 client=E2=80=94it's a = DHCPv4-over-DHCPv6 client. So it just assumes that DHCPv4-over-DHCPv6 = is available and tries to use it; if it succeeds, it is available, and = if it fails, it's not. It might additionally be worth talking about = when it decides to try: when it notices a device on the homenet trying = to use IPv4 to access an off-network service, or does it do it as soon = as it comes up? >=20 > I guess we really haven't talked about how this works=E2=80=94with = DHCPv4-over-IPv6, we'd intended to add a DHCPv6 option with the IP = address of the DHCPv4-over-IPv6 server, but with DHCPv4-over-DHCPv6 = that's not necessary. >=20 >=20 From sunqi.csnet.thu@gmail.com Sun May 19 09:17:31 2013 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 A0F4321F89EB for ; Sun, 19 May 2013 09:17:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.399 X-Spam-Level: X-Spam-Status: No, score=-3.399 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wUtWns2NhMO1 for ; Sun, 19 May 2013 09:17:25 -0700 (PDT) Received: from mail-pa0-f47.google.com (mail-pa0-f47.google.com [209.85.220.47]) by ietfa.amsl.com (Postfix) with ESMTP id CCEDE21F896D for ; Sun, 19 May 2013 09:17:25 -0700 (PDT) Received: by mail-pa0-f47.google.com with SMTP id kl13so4986374pab.34 for ; Sun, 19 May 2013 09:17:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:subject:mime-version:content-type:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer; bh=csHL4ReFk8ByvKn9H50QHomdt+cphv3hQBk3vizOIDQ=; b=0+Hswnq+HwoJOQqfJtbgzSG2KTmJzefwu36jCBm7yPriDquRfxHmSxdNU7UvyXg2JS UA4xrV1P9/YdAIGfXBUErDxw9HaU5emzmqoLSofQGN5DXIt1CTJycGahm8S4+DEmYe6L xJ0x24NGFvw6vSvtZsxie8WJFIb5rztfzqnLdv4elLKFlSuWvv/QzrbCs0w35qSEZwxP KBpx7tZAWOU5eTtm8Kw/o3qiTNvNgM346B4Es2avQ9iFoI+UNmMNYWMP9EFSZx0h3o5L nXC5IIwXtjAung6Npm10bcjc/flwkc/uoPgsvsCq0LzserVvPBlVx6p0cvK3Qo0xrgcU iTGw== X-Received: by 10.68.245.170 with SMTP id xp10mr2713682pbc.41.1368980245617; Sun, 19 May 2013 09:17:25 -0700 (PDT) Received: from [192.168.0.107] ([114.255.40.13]) by mx.google.com with ESMTPSA id fr1sm20200665pbb.26.2013.05.19.09.17.22 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 19 May 2013 09:17:25 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Qi Sun In-Reply-To: <8D23D4052ABE7A4490E77B1A012B63077519F6EF@mbx-01.win.nominum.com> Date: Mon, 20 May 2013 00:17:19 +0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1775E640-867C-41E3-8EAC-2554D80D4DF6@cisco.com> <786F13AA11E69F4DB2CCA23F7400C2FB0142D776@S2010EXCH1.ad.local> <8D23D4052ABE7A4490E77B1A012B63077519F6EF@mbx-01.win.nominum.com> To: Ted Lemon X-Mailer: Apple Mail (2.1084) Cc: "dhcwg@ietf.org" , "volz@cisco.com" Subject: Re: [dhcwg] Conclusion for draft-ietf-dhc-v4configuration-00 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 May 2013 16:17:31 -0000 Dear all, > I think that would have to be restricted to "broken relays may need to = be fixed," because relays _really_ shouldn't be dropping unknown message = types, even though 3315 never _required_ them not to. Yes. I think this is what the unknown message draft = (draft-ietf-dhc-dhcpv6-unknown-msg-00) documents, which intends to = update RFC3315.=20 BTW, should we include draft-ietf-dhc-dhcpv6-unknown-msg-00 as a = reference in the DHCPv4-over-DHCPv6 draft? Best Regards, Qi= From Ted.Lemon@nominum.com Sun May 19 09:31:18 2013 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 7565321F896D for ; Sun, 19 May 2013 09:31:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.556 X-Spam-Level: X-Spam-Status: No, score=-106.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id arOsnlueUx-G for ; Sun, 19 May 2013 09:31:11 -0700 (PDT) Received: from exprod7og107.obsmtp.com (exprod7og107.obsmtp.com [64.18.2.167]) by ietfa.amsl.com (Postfix) with ESMTP id B391E21F8459 for ; Sun, 19 May 2013 09:31:11 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob107.postini.com ([64.18.6.12]) with SMTP ID DSNKUZj+T8m66XNHWJOpbqSirtOqtirtDodG@postini.com; Sun, 19 May 2013 09:31:11 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 2ACE41B80A0 for ; Sun, 19 May 2013 09:31:11 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 1E9B519005D; Sun, 19 May 2013 09:31:11 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0318.004; Sun, 19 May 2013 09:31:11 -0700 From: Ted Lemon To: Qi Sun Thread-Topic: [dhcwg] Conclusion for draft-ietf-dhc-v4configuration-00 Thread-Index: AQHOUWzOksvS2kVeK0CojhlacokdApkGrpoAgAZ8LQCAAARCAA== Date: Sun, 19 May 2013 16:31:10 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B6307751A7B61@mbx-01.win.nominum.com> References: <8A1B81989BCFAE44A22B2B86BF2B7631898DB0232B@HE111643.EMEA1.CDS.T-INTERNAL.COM> <51780A17.8010503@gmail.com> <489D13FBFA9B3E41812EA89F188F018E18552B99@xmb-rcd-x04.cisco.com> <518B7628.3020309@gmail.com> <786F13AA11E69F4DB2CCA23F7400C2FB0142D318@S2010EXCH1.ad.local>, <8D23D4052ABE7A4490E77B1A012B63077519C2C9@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B63077519C539@mbx-01.win.nominum.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dhcwg@ietf.org" , "Bernie Volz \(volz\)" Subject: Re: [dhcwg] Conclusion for draft-ietf-dhc-v4configuration-00 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 May 2013 16:31:18 -0000 On May 19, 2013, at 12:15 PM, Qi Sun wrote: > IMHO, this is necessary to document. As for the two proposals, I think th= e second one would be more appropriate. The clients won't conflict: DHCPv6 = client will get an IPv6 address/a prefix from the Unified server, DHCPv4-ov= er-DHCPv6 client will get an IPv4 address from the Unified server, and DHCP= v4 client won't work (for there is no IPv4 transmission network uplink).=20 > The first one requires the client to be aware of requests behind the home= gateway. Would that complex the client's logic/function? The problem with the first way is that it means that every DHCPv4-over-DHCP= v6 gateway will always try to acquire an IPv4 configuration, even if the CP= E network has no IPv4-only devices on it, and accesses no IPv4-only service= s. So there will be no way to shut off IPv4 service for CPE networks that= don't require it. On the other hand, as you say, to make the client acquire IPv4 connectivity= only when a CPE device tries to use it is more complicated, and may even b= e impossible to do correctly. I do not have an easy answer to this question.= From Ted.Lemon@nominum.com Sun May 19 09:31:35 2013 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 A933321F87D1 for ; Sun, 19 May 2013 09:31:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.557 X-Spam-Level: X-Spam-Status: No, score=-106.557 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pxePQaLOnSPj for ; Sun, 19 May 2013 09:31:29 -0700 (PDT) Received: from exprod7og110.obsmtp.com (exprod7og110.obsmtp.com [64.18.2.173]) by ietfa.amsl.com (Postfix) with ESMTP id AA8C721F89D5 for ; Sun, 19 May 2013 09:31:27 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob110.postini.com ([64.18.6.12]) with SMTP ID DSNKUZj+X3AsNfMjsBWo0ik9EqUFU60ffclF@postini.com; Sun, 19 May 2013 09:31:27 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 53BA01B80D6 for ; Sun, 19 May 2013 09:31:27 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 4CF7D19005D; Sun, 19 May 2013 09:31:27 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.02.0318.004; Sun, 19 May 2013 09:31:27 -0700 From: Ted Lemon To: Qi Sun Thread-Topic: [dhcwg] Conclusion for draft-ietf-dhc-v4configuration-00 Thread-Index: AQHOUWzOksvS2kVeK0CojhlacokdApkGrpoAgABOfACAANnMAIAACTOAgABadgCABPCfgIAAA/IA Date: Sun, 19 May 2013 16:31:27 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B6307751A7B75@mbx-01.win.nominum.com> References: <1775E640-867C-41E3-8EAC-2554D80D4DF6@cisco.com> <786F13AA11E69F4DB2CCA23F7400C2FB0142D776@S2010EXCH1.ad.local> <8D23D4052ABE7A4490E77B1A012B63077519F6EF@mbx-01.win.nominum.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dhcwg@ietf.org" , "volz@cisco.com" Subject: Re: [dhcwg] Conclusion for draft-ietf-dhc-v4configuration-00 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 May 2013 16:31:35 -0000 On May 19, 2013, at 12:17 PM, Qi Sun wrote: > BTW, should we include draft-ietf-dhc-dhcpv6-unknown-msg-00 as a referenc= e in the DHCPv4-over-DHCPv6 draft? I think that would make sense, yes. From gnocuil@gmail.com Mon May 20 02:55:11 2013 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 10AD121F9318 for ; Mon, 20 May 2013 02:55:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.377 X-Spam-Level: X-Spam-Status: No, score=-1.377 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_53=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lLiZOu0yiNzv for ; Mon, 20 May 2013 02:55:10 -0700 (PDT) Received: from mail-we0-x22d.google.com (mail-we0-x22d.google.com [IPv6:2a00:1450:400c:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id AB81921F8681 for ; Mon, 20 May 2013 02:55:09 -0700 (PDT) Received: by mail-we0-f173.google.com with SMTP id p57so3527796wes.4 for ; Mon, 20 May 2013 02:55:08 -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:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=jE+gYz/7/tFtQCQIB/5T4R1YLm09twoC4jSYB0Ywjyw=; b=L39FP9OKToreopajMWwjqzpOvCQHAwaij86MeGEGV+hwNtvptioCxTsIYS5JhvJxLi HyALbTtsZWUt2/hV5q2TkHDhLo/WmptKyQ6o7JM3PROE31hZzsVkEQkLbfDFY9hBrVTf egsvt6V7S1WCvtZ6Riz+w2KeWggpl+eBq/x4DYXWwtwE0PRV/EeBajboJPZMMNmvZl5R JKBO4rK8fq+9fEq9VBoA5e9E+Iykl1qBh7CUeDSKdoqhZEavhNdSHfsskFarFv7SkFPO V90T7IE2XIQ+SQGPOjt6Gc8dXuD9ap7jTZ74Hl1/xiUy/+8vU+V/EcygRYsL8Vucw3c4 DT+A== X-Received: by 10.181.12.1 with SMTP id em1mr12251676wid.4.1369043708792; Mon, 20 May 2013 02:55:08 -0700 (PDT) MIME-Version: 1.0 Sender: gnocuil@gmail.com Received: by 10.194.139.135 with HTTP; Mon, 20 May 2013 02:54:48 -0700 (PDT) In-Reply-To: <786F13AA11E69F4DB2CCA23F7400C2FB0142D318@S2010EXCH1.ad.local> References: <8A1B81989BCFAE44A22B2B86BF2B7631898DB0232B@HE111643.EMEA1.CDS.T-INTERNAL.COM> <51780A17.8010503@gmail.com> <489D13FBFA9B3E41812EA89F188F018E18552B99@xmb-rcd-x04.cisco.com> <518B7628.3020309@gmail.com> <786F13AA11E69F4DB2CCA23F7400C2FB0142D318@S2010EXCH1.ad.local> From: Cong Liu Date: Mon, 20 May 2013 17:54:48 +0800 X-Google-Sender-Auth: 8eKtC2pET4gIPw6V5GFgM0jGCSA Message-ID: To: Branimir Rajtar Content-Type: multipart/alternative; boundary=f46d043c7e30f1d90c04dd235315 Cc: "dhcwg@ietf.org" Subject: Re: [dhcwg] Conclusion for draft-ietf-dhc-v4configuration-00 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 May 2013 09:55:11 -0000 --f46d043c7e30f1d90c04dd235315 Content-Type: text/plain; charset=ISO-8859-2 Content-Transfer-Encoding: quoted-printable Hi Branimir, In section 1.5 and 3.3.2, should "separation of DHCPv4 and DHCPv4 provisioning" be "separation of DHCPv4 and DHCPv6 provisioning"? I'm confused with requirement no. 4. Does it mean separated DHCPv4/DHCPv6 server devices, or separated IPv4/IPv6 address provisioning process, or separated IPv4 address/other options provisioning process? Best Regards, Cong =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Cong Liu Tsinghua University 2013/5/15 Branimir Rajtar > Hi all, > > Following on Tomek's e-mail and the upload of > draft-ietf-dhc-v4configuration-00, the authors would like to start the > discussion on it's conclusion. Following the talk on the mailing list, ou= r > proposal is as follows: > > "Whilst all of the approaches described here will require some developmen= t > work in order to realize, it is clear from the above analysis that the mo= st > sustainable approach capitalizes on existing DHCPv4 implementations and > include them as new DHCPv6 message types. The main rationale for this is > that it enables all of DHCPv4's existing options to be migrated for use > over IPv6 in a single step. > > Porting of all necessary DHCPv4 options to DHCPv6 would require ongoing > development work, re-implementing existing DHCPv4 functionality in DHCPv6= . > This will result in having legacy DHCPv4 options in DHCPv6, which will n= o > longer be useful once IPv4 is completely abandoned. > > Therefore, the DHCPv6 approach is not suitable for delivering IPv4 > configuration parameters in an efficient, ongoing manner. > > The dynamical leasing of IPv4 addresses is fundamental to the efficient > use of remaining IPv4 resources. This will become increasingly important = in > the future, so a mechanism which supports this is necessary. DHCPv4oSW do= es > not provide this function and so is not recommended. > > The DHCPv4o6 approach requires a DHCPv4 server (with DHCPv4o6 > functionality) for all deployment scenarios, even when DHCPv4 specific > functionality is not required by the operator. > > Therefore, this memo recommends DHCPv4oDHCPv6 > as the best underlying approach for > provisioning IPv4 parameters over an IPv6 only network." > > Also, we propose two changes to the document itself which we find should > better reflect the overview of all proposals: > 1. Section 3, requirement no. 6 - should be "No" for DHCPv4o6 > 1. Section 3, requirement no. 1 - should be "No" for DHCPv4oSW > > BR, > Branimir > > > -----Original Message----- > From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of > Tomek Mrugalski > Sent: Thursday, May 09, 2013 12:11 PM > To: dhcwg@ietf.org > Subject: Re: [dhcwg] Adoption call for draft-rajtar-dhc-v4configuration-0= 2 > - adopted! > > On 13-05-08 15:51, Bernie Volz (volz) wrote: > > 2. (WG co-chair hat on): If you have not expressed support or oppositio= n > for adopting this work, the call expires today! > Hi, > > Although this adoption call looked a bit grim for the first 10 days, > large support voiced in the last couple days saved the day. We have > around a dozen support voices, which means that this I-D was adopted. > > Authors, please upload it as draft-ietf-dhc-v4configuration-00. Once > that is done, I encourage authors to start a discussion about > recommendation that the WG wants to offer. > > It is a pleasure to see such a strong consensus. Let's hope that the > discussion about writing Conclusion section will have equally strong > consensus. > > Bernie & Tomek > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg > > >

> > IZJAVA O ODRICANJU ODGOVORNOSTI: Sadr=BEaj ove poruke i eventualno > prilo=BEenih datoteka je povjerljiv i namijenjen je samo osobama ili > subjektima koji su navedeni u adresi. Ukoliko ste primili ovu poruku > gre=B9kom, molimo Vas, obavijestite po=B9iljatelja, a poruku i sve njene > privitke odmah, bez =E8itanja, trajno uklonite s ra=E8unala. Bilo kakvo > preno=B9enje, kopiranje ili distribucija informacija sadr=BEanih u poruci > tre=E6im osobama je zabranjeno i mo=BEe biti zakonski ka=BEnjivo. Sadr=BE= aj, > stavovi i mi=B9ljenja izneseni u poruci su autorovi i ne predstavljaju nu= =BEno > stavove HT - Hrvatskih telekomunikacija d.d. HT ne prihva=E6a nikakvu > odgovornost za eventualnu =B9tetu nastalu primitkom ove poruke i priloga > sadr=BEanih u poruci. > >

> > DISCLAIMER:The contents of this email as well as any files attached to i= t > are confidential and intended solely for individuals or entities which th= ey > are addressed to. If you have received this email message in error, pleas= e > notify the sender and permanently remove the message and all attached fil= es > from the computer. Any disclosure, copying or distribution of all or a pa= rt > of information contained herein to or by third parties is prohibited and > may be unlawful. Please note that any views or opinions presented in this > message are solely those of the author and do not necessarily represent t= he > views and opinions of Croatian Telecom Inc. Croatian Telecom Inc. accepts > no liability for any potential damage caused by this message and files > attached to it. > >

> _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg > --f46d043c7e30f1d90c04dd235315 Content-Type: text/html; charset=ISO-8859-2 Content-Transfer-Encoding: quoted-printable
Hi=A0Branimir,

In section 1.5 and 3.3.2, should "separation of DHCPv4 and DHCPv4= provisioning" be "separation of DHCPv4 and DHCPv6 provisioning&q= uot;?

I'm confused with requirement no. 4. Doe= s it mean separated DHCPv4/DHCPv6 server devices, or separated IPv4/IPv6 ad= dress provisioning process, or separated IPv4 address/other options provisi= oning process?

Best Regards,
Cong


=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D
Cong Liu
Tsinghua Universit= y


2013/5/15 Branimir Rajtar <Branim= ir.Rajtar@t.ht.hr>
Hi all,

Following on Tomek's e-mail and the upload of draft-ietf-dhc-v4configur= ation-00, the authors would like to start the discussion on it's conclu= sion. Following the talk on the mailing list, our proposal is as follows:
"Whilst all of the approaches described here will require some develop= ment work in order to realize, it is clear from the above analysis that the= most sustainable approach capitalizes on existing DHCPv4 implementations a= nd include them as new DHCPv6 message types. =A0The main rationale for this= is that it enables all of DHCPv4's existing options to be migrated for= use over IPv6 in a single step.

Porting of all necessary DHCPv4 options to DHCPv6 would require ongoing dev= elopment work, re-implementing existing DHCPv4 functionality in DHCPv6. =A0= This will result in having legacy DHCPv4 options in DHCPv6, which will no l= onger be useful once IPv4 is completely abandoned.

Therefore, the DHCPv6 approach is not suitable for delivering IPv4 configur= ation parameters in an efficient, ongoing manner.

The dynamical leasing of IPv4 addresses is fundamental to the efficient use= of remaining IPv4 resources. This will become increasingly important in th= e future, so a mechanism which supports this is necessary. DHCPv4oSW does n= ot provide this function and so is not recommended.

The DHCPv4o6 approach requires a DHCPv4 server (with DHCPv4o6 functionality= ) for all deployment scenarios, even when DHCPv4 specific functionality is = not required by the operator.

Therefore, this memo recommends DHCPv4oDHCPv6 <I-D.ietf-dhc-dhcpv4-over-= dhcpv6> as the best underlying approach for provisioning IPv4 parameters= over an IPv6 only network."

Also, we propose two changes to the document itself which we find should be= tter reflect the overview of all proposals:
1. Section 3, requirement no. 6 - should be "No" for DHCPv4o6
1. Section 3, requirement no. 1 - should be "No" for DHCPv4oSW
BR,
Branimir


-----Original Message-----
From: dhcwg-bou= nces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of Tomek Mrugalski
Sent: Thursday, May 09, 2013 12:11 PM
To: dhcwg@ietf.org<= br> Subject: Re: [dhcwg] Adoption call for draft-rajtar-dhc-v4configuration-02 = - adopted!

On 13-05-08 15:51, Bernie Volz (volz) wrote:
> 2. (WG co-chair hat on): If you have not expressed support or oppositi= on for adopting this work, the call expires today!
Hi,

Although this adoption call looked a bit grim for the first 10 days,
large support voiced in the last couple days saved the day. We have
around a dozen support voices, which means that this I-D was adopted.

Authors, please upload it as draft-ietf-dhc-v4configuration-00. Once
that is done, I encourage authors to start a discussion about
recommendation that the WG wants to offer.

It is a pleasure to see such a strong consensus. Let's hope that the discussion about writing Conclusion section will have equally strong
consensus.

Bernie & Tomek

_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/dhcwg


<HTML><P><FONT face=3DArial color=3D#999999 size=3D1>

IZJAVA O ODRICANJU ODGOVORNOSTI: Sadr=BEaj ove poruke i eventualno prilo=BE= enih datoteka je povjerljiv i namijenjen je samo osobama ili subjektima koj= i su navedeni u adresi. Ukoliko ste primili ovu poruku gre=B9kom, molimo Va= s, obavijestite po=B9iljatelja, a poruku i sve njene privitke odmah, bez = =E8itanja, trajno uklonite s ra=E8unala. Bilo kakvo preno=B9enje, kopiranje= ili distribucija informacija sadr=BEanih u poruci tre=E6im osobama je zabr= anjeno i mo=BEe biti zakonski ka=BEnjivo. Sadr=BEaj, stavovi i mi=B9ljenja = izneseni u poruci su autorovi i ne predstavljaju nu=BEno stavove HT - Hrvat= skih telekomunikacija d.d. HT ne prihva=E6a nikakvu odgovornost za eventual= nu =B9tetu nastalu primitkom ove poruke i priloga sadr=BEanih u poruci.

</FONT></P><P><FONT face=3DArial color=3D#999999 size= =3D1>

=A0DISCLAIMER:The contents of this email as well as any files attached to i= t are confidential and intended solely for individuals or entities which th= ey are addressed to. If you have received this email message in error, plea= se notify the sender and permanently remove the message and all attached fi= les from the computer. Any disclosure, copying or distribution of all or a = part of information contained herein to or by third parties is prohibited a= nd may be unlawful. Please note that any views or opinions presented in thi= s message are solely those of the author and do not necessarily represent t= he views and opinions of Croatian Telecom Inc. Croatian Telecom Inc. accept= s no liability for any potential damage caused by this message and files at= tached to it.

</FONT></P></HTML>
_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/dhcwg

--f46d043c7e30f1d90c04dd235315-- From internet-drafts@ietf.org Mon May 20 08:02:04 2013 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 DC0F121F9371; Mon, 20 May 2013 08:02:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.471 X-Spam-Level: X-Spam-Status: No, score=-102.471 tagged_above=-999 required=5 tests=[AWL=0.129, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sk770VJMyjsY; Mon, 20 May 2013 08:02:03 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 248F321F933B; Mon, 20 May 2013 08:01:36 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.45 Message-ID: <20130520150136.31062.5142.idtracker@ietfa.amsl.com> Date: Mon, 20 May 2013 08:01:36 -0700 Cc: dhcwg@ietf.org Subject: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-radius-opt-12.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 May 2013 15:02:05 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Dynamic Host Configuration Working Group = of the IETF. Title : RADIUS Option for DHCPv6 Relay Agent Author(s) : Leaf Y. Yeh Mohamed Boucadair Filename : draft-ietf-dhc-dhcpv6-radius-opt-12.txt Pages : 11 Date : 2013-05-20 Abstract: The DHCPv6 RADIUS option provides a mechanism to exchange authorization and identification information between the DHCPv6 relay agent and the DHCPv6 server. This mechanism is meant for the centralized DHCPv6 server to select the right configuration for the requesting DHCPv6 client based on the authorization information received from the RADIUS server, which is not co-located with the DHCPv6 server. The Network Access Server (NAS) acts as DHCPv6 relay agent and RADIUS client simultaneously in this document. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv6-radius-opt There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-radius-opt-12 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dhc-dhcpv6-radius-opt-12 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From fx.lebail@yahoo.com Tue May 21 00:44:35 2013 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 1D6FA21F86CA for ; Tue, 21 May 2013 00:44:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.299 X-Spam-Level: X-Spam-Status: No, score=-4.299 tagged_above=-999 required=5 tests=[AWL=-2.000, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ALsC4vjQlLbV for ; Tue, 21 May 2013 00:44:29 -0700 (PDT) Received: from nm38-vm7.bullet.mail.ne1.yahoo.com (nm38-vm7.bullet.mail.ne1.yahoo.com [98.138.229.151]) by ietfa.amsl.com (Postfix) with ESMTP id E997521F8519 for ; Tue, 21 May 2013 00:44:28 -0700 (PDT) Received: from [98.138.226.178] by nm38.bullet.mail.ne1.yahoo.com with NNFMP; 21 May 2013 07:44:28 -0000 Received: from [98.138.86.156] by tm13.bullet.mail.ne1.yahoo.com with NNFMP; 21 May 2013 07:44:28 -0000 Received: from [127.0.0.1] by omp1014.mail.ne1.yahoo.com with NNFMP; 21 May 2013 07:44:28 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 413932.7407.bm@omp1014.mail.ne1.yahoo.com Received: (qmail 50536 invoked by uid 60001); 21 May 2013 07:44:28 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1369122268; bh=V2AZdLP/lTvdDuSR6lzmaesNF9o7pnfj9HehPzhdofE=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=g+/Y7NUAPdfY4qZw0IIqjv+3uvFX0qVL9THhKlfb8SQL6jm99bgggMO//msS2doD6u+W/shHKNG3D5rYfsalJ43Mzg11fTbS884+hGyLTka8/oSyb51U+9n8ty37Uvcu1CTd9bCZN90zneAZ+8J0zrg4QAiKyKH96ni9aPsOhrc= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=jh8Kuq7yWgXlP6KhSXC3HFndzGIz2aBsnfABwt2maAPtnK9bHFqhNuMZtxg3uUJTBmjkJC3F8N2ei2FDlWIzZWr0zSvlX380zreeXZ+Y3C9N068P43Umw9JBZsvdgPx5evhVWcLBZED+t3O6PWngeFtL0XkrWbZVsWf5NSN4xbY=; X-YMail-OSG: tuRtavYVM1l9LMhQe.uqSxBxthA2.4K9jA8CYA09rNdxTFA beOG1IrfK7whaBjbKwac5X.XFoBf1Ac7rryBtYGwewd_jZUjzzLLBVvxWbXX bb0kGpBBL9H6sL_ceQJTUTx8DrX_AA.xKAtEM1JbJCRh2.yPxl6n2Q3RpgSK EGOITD.vqwjkyYtImOrmlA2scghcENEgIWs6P9DwzYLqs2hbu0IzCZcWmb3i uXs_r4CmCPxD2_V_0mpSa2t4y7VjrJfUZ1TpExxwyFTNr5TbJISRuJKe_0NW IVjhcunvSyAu98hbNN3cR3fIBqVZ9VhnZUYismAATnW6yYAB4HEan5aGzSfC NWYAZb7BJaQtTjlTbFthgwaUt4mzD8sp_8aejAlhpeSYxRMm3VyJq3kDe54q eXajNzobi7kILFa281ZAjRxGfaBEgjV0AxylFjXAIiW1MFV2jgOQ._nVmDUp OeU3s.6AzuN20JxzGJB3BBuzLqFNffSd5YunX1b6lft1Xh1ddBePY8h_U6fT qJD0bF4WXqwSboTnU3j2lC1bg9i4AsIRi30I1VQ0Its4T7AxMZ4XHEqMsPx9 0rDTL1_vzR2T5UobivqokE1YAJQ-- Received: from [193.49.124.107] by web125506.mail.ne1.yahoo.com via HTTP; Tue, 21 May 2013 00:44:27 PDT X-Rocket-MIMEInfo: 002.001, W0FkZGluZyBkaGN3ZyBhbmQgUkZDIGF1dGhvcnNdCgoKSGVsbG8sCgpBYm91dCBSRkM1OTA4LCAiTmV0d29yayBUaW1lIFByb3RvY29sIChOVFApIFNlcnZlciBPcHRpb24gZm9yIERIQ1B2NiIuCgpTZWN0aW9uIDQgc2F5czogClRoZSBvcHRpb24gaXRzZWxmIGRvZXMgbm90IGNvbnRhaW4gYW55IHZhbHVlLsKgIEluc3RlYWQsIGl0IGNvbnRhaW5zCm9uZSBvciBzZXZlcmFsIHN1Ym9wdGlvbnMgdGhhdCBjYXJyeSBOVFAgc2VydmVyIG9yIFNOVFAgc2VydmVyCmxvY2F0aW9uLsKgIFRoaXMgb3B0aW9uIE1VU1QBMAEBAQE- X-Mailer: YahooMailWebService/0.8.142.542 Message-ID: <1369122267.50197.YahooMailNeo@web125506.mail.ne1.yahoo.com> Date: Tue, 21 May 2013 00:44:27 -0700 (PDT) From: =?iso-8859-1?Q?Fran=E7ois-Xavier_Le_Bail?= To: "ntpwg@lists.ntp.org" , "dhcwg@ietf.org" , "richard.gayraud@free.fr" , "blourdel@cisco.com" MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Subject: [dhcwg] Question about RFC5908 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: =?iso-8859-1?Q?Fran=E7ois-Xavier_Le_Bail?= List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 May 2013 07:44:35 -0000 [Adding dhcwg and RFC authors]=0A=0A=0AHello,=0A=0AAbout RFC5908, "Network = Time Protocol (NTP) Server Option for DHCPv6".=0A=0ASection 4 says: =0AThe = option itself does not contain any value.=A0 Instead, it contains=0Aone or = several suboptions that carry NTP server or SNTP server=0Alocation.=A0 This= option MUST include one, and only one, time source=0Asuboption. =0A=0A(htt= p://tools.ietf.org/html/rfc5908#section-4)=0A=0AIt seems to me contradictor= y:=0A- The option itself [...]. Instead, it contains one or several subopti= ons [...]=0A- This option MUST include one, and only one, time source subop= tion.=0A=0ADid I miss something ?=0A=0ABest regards,=0A=0AFrancois-Xavier l= e Bail=0A From Ted.Lemon@nominum.com Tue May 21 08:18:20 2013 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 F052D21F97E7 for ; Tue, 21 May 2013 08:18:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.409 X-Spam-Level: X-Spam-Status: No, score=-106.409 tagged_above=-999 required=5 tests=[AWL=-0.110, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ntAUvvta1l2t for ; Tue, 21 May 2013 08:18:13 -0700 (PDT) Received: from exprod7og110.obsmtp.com (exprod7og110.obsmtp.com [64.18.2.173]) by ietfa.amsl.com (Postfix) with ESMTP id 0735621F984F for ; Tue, 21 May 2013 08:18:13 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob110.postini.com ([64.18.6.12]) with SMTP ID DSNKUZuQNJNrFTGUZ/Go6+uMTNRc/UaQTGSD@postini.com; Tue, 21 May 2013 08:18:13 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 55F141B8198 for ; Tue, 21 May 2013 08:18:12 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 4328119005D; Tue, 21 May 2013 08:18:12 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.02.0318.004; Tue, 21 May 2013 08:18:12 -0700 From: Ted Lemon To: =?iso-8859-1?Q?Fran=E7ois-Xavier_Le_Bail?= Thread-Topic: [dhcwg] Question about RFC5908 Thread-Index: AQHOVfcNOh5dwhGRWkCEBIrpTVG/3ZkQNjqA Date: Tue, 21 May 2013 15:18:11 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B6307751AAF97@mbx-01.win.nominum.com> References: <1369122267.50197.YahooMailNeo@web125506.mail.ne1.yahoo.com> In-Reply-To: <1369122267.50197.YahooMailNeo@web125506.mail.ne1.yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <7D2F93CEF1B83546AF73029A293A5F39@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ntpwg@lists.ntp.org" , "dhcwg@ietf.org" , "blourdel@cisco.com" , "richard.gayraud@free.fr" Subject: Re: [dhcwg] Question about RFC5908 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 May 2013 15:18:20 -0000 On May 21, 2013, at 3:44 AM, Fran=E7ois-Xavier Le Bail wrote: > It seems to me contradictory: > - The option itself [...]. Instead, it contains one or several suboptions= [...] > - This option MUST include one, and only one, time source suboption. >=20 > Did I miss something ? Yes. The point is that the option can only contain one suboption in the s= et (server-addr, multicast-addr, server-fqdn). There can be more than one= of these options, and so there can be more than one source suboption in th= e DHCPv6 packet: one for each such option.= From Branimir.Rajtar@t.ht.hr Wed May 22 01:45:43 2013 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 0C14621F958D for ; Wed, 22 May 2013 01:45:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.849 X-Spam-Level: X-Spam-Status: No, score=-1.849 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, J_CHICKENPOX_53=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hrNyMJLgTcD0 for ; Wed, 22 May 2013 01:45:38 -0700 (PDT) Received: from mx01.t.ht.hr (mx01.t.ht.hr [195.29.161.88]) by ietfa.amsl.com (Postfix) with SMTP id 76E5921F9593 for ; Wed, 22 May 2013 01:45:36 -0700 (PDT) Received: from no.name.available by mx01.t.ht.hr via smtpd (for mail.ietf.org [12.22.58.30]) with ESMTP; Wed, 22 May 2013 10:13:27 +0200 Received: from (unknown [172.17.66.76]) by scmg1.t.ht.hr with smtp id 4de6_0edc_f7b89d72_c2bb_11e2_90ae_00221951415f; Wed, 22 May 2013 10:45:34 +0200 Received: (private information removed) Wed, 22 May 2013 10:45:34 +0200 Received: (private information removed) S2010EXCHCA2.ad.local ([::1]) with mapi id 14.03.0123.003; Wed, 22 May 2013 10:45:34 +0200 From: Branimir Rajtar To: Qi Sun Thread-Topic: [dhcwg] Conclusion for draft-ietf-dhc-v4configuration-00 Thread-Index: AQHOVEFYLPFjOx7CSUmM8CZD/WOJAZkQ57nA Date: Wed, 22 May 2013 08:45:33 +0000 Message-ID: <786F13AA11E69F4DB2CCA23F7400C2FB0142E72F@S2010EXCH1.ad.local> References: <8A1B81989BCFAE44A22B2B86BF2B7631898DB0232B@HE111643.EMEA1.CDS.T-INTERNAL.COM> <51780A17.8010503@gmail.com> <489D13FBFA9B3E41812EA89F188F018E18552B99@xmb-rcd-x04.cisco.com> <518B7628.3020309@gmail.com> <786F13AA11E69F4DB2CCA23F7400C2FB0142D318@S2010EXCH1.ad.local>, <8D23D4052ABE7A4490E77B1A012B63077519C2C9@mbx-01.win.nominum.com> <1975C107-2E83-46A9-91B7-95DE7CFBB537@gmail.com> In-Reply-To: <1975C107-2E83-46A9-91B7-95DE7CFBB537@gmail.com> Accept-Language: en-US, hr-HR Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.17.5.13] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginalArrivalTime: 22 May 2013 08:45:34.0585 (UTC) FILETIME=[B97E8E90:01CE56C8] X-NAIMIME-Disclaimer: 1 X-NAIMIME-Modified: 1 Cc: "dhcwg@ietf.org WG" , Ted Lemon , "Bernie Volz \(volz\)" Subject: Re: [dhcwg] Conclusion for draft-ietf-dhc-v4configuration-00 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 May 2013 08:45:43 -0000 SGksCgpJIHRoaW5rIHRoaXMgaXMgYWN0dWFsbHkgYWxyZWFkeSBjb3ZlcmVkIC0gdGhlIGRyYWZ0 IHNheXMgYWJvdXQga2VlcGluZyBJUHY0IGFuZCBJUHY2IGRvbWFpbnMgc2VwYXJhdGUgYW5kIEkg d291bGQgc2F5IHRoYXQgYSBsb3Qgb2Ygc2lnbmlmaWNhbmNlIGlzIHB1dCBvbiB0aGF0LiBIb3dl dmVyLCBsb29raW5nIGF0IHRoZSB5b3VyIGNvbW1lbnQgYW5kIG90aGVyIGNvbW1lbnRzIGZyb20g dGhlIHdvcmtpbmcgZ3JvdXAsIEkgdGhpbmsgSSBzaG91bGQgZXhwYW5kIG9uIGl0IGFuZCBwdXQg c29tZSBtb3JlIGV4cGxhbmF0aW9ucyBpbiB0aGUgbmV4dCB2ZXJzaW9uLgoKQlIsCkJyYW5pbWly CgotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQpGcm9tOiBRaSBTdW4gW21haWx0bzpzdW5xaS5j c25ldC50aHVAZ21haWwuY29tXSAKU2VudDogU3VuZGF5LCBNYXkgMTksIDIwMTMgNTozMSBBTQpU bzogQnJhbmltaXIgUmFqdGFyCkNjOiBUZWQgTGVtb247IGRoY3dnQGlldGYub3JnIFdHOyBCZXJu aWUgVm9seiAodm9seikKU3ViamVjdDogUmU6IFtkaGN3Z10gQ29uY2x1c2lvbiBmb3IgZHJhZnQt aWV0Zi1kaGMtdjRjb25maWd1cmF0aW9uLTAwCgpJIG5vdGljZSBpbiBESENQdjYgYmFzZWQgcHJv dmlzaW9uaW5nLCBpdCBkb2Vzbid0IG1lbnRpb24gdGhlIERIQ1B2NiBzZXJ2ZXIgaXMgcmVxdWly ZWQgdG8gbWFuYWdlIElQdjQgYWRkcmVzcyB3aGlsZSBhIERIQ1B2NiBjbGllbnQgaXMgcmVzcG9u c2libGUgdG8gY29uZmlndXJlIElQdjQgc3RhY2suIFRoZXNlIGNoYW5nZXMgd291bGQgbGl2ZSB3 aXRoIERIQ1B2NiBpZiBvbmUgdXNlZCB0aGlzIHNldCBvZiBtZWNoYW5pc21zLiBESENQdjRvU1cg YWxzbyBoYXMgdGhlIHNhbWUgaXNzdWUgKElQdjQgYWRkcmVzcyAmIHBvcnQgc2V0IGFyZSBwcm92 aXNpb25pbmcgaW4gREhDUHY2IG9wdGlvbiksIHdoaWxlIERIQ1B2NG9ESENQdjYgZG9lc24ndCBm b3IgaXQncyB0aGUgREhDUHY0IGNsaWVudCB0aGF0IHRha2VzIHRoZSBqb2IuCgpJcyBpdCBuZWNl c3NhcnkgdG8gY29uc2lkZXIgdGhpcz8KCkJlc3QgUmVnYXJkcywKUWkKCgoKCjxIVE1MPjxQPjxG T05UIGZhY2U9QXJpYWwgY29sb3I9Izk5OTk5OSBzaXplPTE+DQoNCklaSkFWQSBPIE9EUklDQU5K VSBPREdPVk9STk9TVEk6IFNhZHLFvmFqIG92ZSBwb3J1a2UgaSBldmVudHVhbG5vIHByaWxvxb5l bmloIGRhdG90ZWthIGplIHBvdmplcmxqaXYgaSBuYW1pamVuamVuIGplIHNhbW8gb3NvYmFtYSBp bGkgc3ViamVrdGltYSBrb2ppIHN1IG5hdmVkZW5pIHUgYWRyZXNpLiBVa29saWtvIHN0ZSBwcmlt aWxpIG92dSBwb3J1a3UgZ3JlxaFrb20sIG1vbGltbyBWYXMsIG9iYXZpamVzdGl0ZSBwb8WhaWxq YXRlbGphLCBhIHBvcnVrdSBpIHN2ZSBuamVuZSBwcml2aXRrZSBvZG1haCwgYmV6IMSNaXRhbmph LCB0cmFqbm8gdWtsb25pdGUgcyByYcSNdW5hbGEuIEJpbG8ga2Frdm8gcHJlbm/FoWVuamUsIGtv cGlyYW5qZSBpbGkgZGlzdHJpYnVjaWphIGluZm9ybWFjaWphIHNhZHLFvmFuaWggdSBwb3J1Y2kg dHJlxIdpbSBvc29iYW1hIGplIHphYnJhbmplbm8gaSBtb8W+ZSBiaXRpIHpha29uc2tpIGthxb5u aml2by4gU2FkcsW+YWosIHN0YXZvdmkgaSBtacWhbGplbmphIGl6bmVzZW5pIHUgcG9ydWNpIHN1 IGF1dG9yb3ZpIGkgbmUgcHJlZHN0YXZsamFqdSBudcW+bm8gc3Rhdm92ZSBIVCAtIEhydmF0c2tp aCB0ZWxla29tdW5pa2FjaWphIGQuZC4gSFQgbmUgcHJpaHZhxIdhIG5pa2FrdnUgb2Rnb3Zvcm5v c3QgemEgZXZlbnR1YWxudSDFoXRldHUgbmFzdGFsdSBwcmltaXRrb20gb3ZlIHBvcnVrZSBpIHBy aWxvZ2Egc2FkcsW+YW5paCB1IHBvcnVjaS4NCg0KPC9GT05UPjwvUD48UD48Rk9OVCBmYWNlPUFy aWFsIGNvbG9yPSM5OTk5OTkgc2l6ZT0xPg0KDQogRElTQ0xBSU1FUjpUaGUgY29udGVudHMgb2Yg dGhpcyBlbWFpbCBhcyB3ZWxsIGFzIGFueSBmaWxlcyBhdHRhY2hlZCB0byBpdCBhcmUgY29uZmlk ZW50aWFsIGFuZCBpbnRlbmRlZCBzb2xlbHkgZm9yIGluZGl2aWR1YWxzIG9yIGVudGl0aWVzIHdo aWNoIHRoZXkgYXJlIGFkZHJlc3NlZCB0by4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFp bCBtZXNzYWdlIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgYW5kIHBlcm1hbmVu dGx5IHJlbW92ZSB0aGUgbWVzc2FnZSBhbmQgYWxsIGF0dGFjaGVkIGZpbGVzIGZyb20gdGhlIGNv bXB1dGVyLiBBbnkgZGlzY2xvc3VyZSwgY29weWluZyBvciBkaXN0cmlidXRpb24gb2YgYWxsIG9y IGEgcGFydCBvZiBpbmZvcm1hdGlvbiBjb250YWluZWQgaGVyZWluIHRvIG9yIGJ5IHRoaXJkIHBh cnRpZXMgaXMgcHJvaGliaXRlZCBhbmQgbWF5IGJlIHVubGF3ZnVsLiBQbGVhc2Ugbm90ZSB0aGF0 IGFueSB2aWV3cyBvciBvcGluaW9ucyBwcmVzZW50ZWQgaW4gdGhpcyBtZXNzYWdlIGFyZSBzb2xl bHkgdGhvc2Ugb2YgdGhlIGF1dGhvciBhbmQgZG8gbm90IG5lY2Vzc2FyaWx5IHJlcHJlc2VudCB0 aGUgdmlld3MgYW5kIG9waW5pb25zIG9mIENyb2F0aWFuIFRlbGVjb20gSW5jLiBDcm9hdGlhbiBU ZWxlY29tIEluYy4gYWNjZXB0cyBubyBsaWFiaWxpdHkgZm9yIGFueSBwb3RlbnRpYWwgZGFtYWdl IGNhdXNlZCBieSB0aGlzIG1lc3NhZ2UgYW5kIGZpbGVzIGF0dGFjaGVkIHRvIGl0Lg0KDQo8L0ZP TlQ+PC9QPjwvSFRNTD4K From Branimir.Rajtar@t.ht.hr Wed May 22 01:51:18 2013 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 6F67521F962A for ; Wed, 22 May 2013 01:51:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[AWL=0.099, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_53=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UmviWbDqvQ-P for ; Wed, 22 May 2013 01:51:12 -0700 (PDT) Received: from mx01.t.ht.hr (mx01.t.ht.hr [195.29.161.88]) by ietfa.amsl.com (Postfix) with SMTP id 41D5F21F960E for ; Wed, 22 May 2013 01:50:57 -0700 (PDT) Received: from no.name.available by mx01.t.ht.hr via smtpd (for mail.ietf.org [12.22.58.30]) with ESMTP; Wed, 22 May 2013 10:18:48 +0200 Received: from (unknown [172.17.66.76]) by scmg1.t.ht.hr with smtp id 4de6_11ee_b74f83ee_c2bc_11e2_90ae_00221951415f; Wed, 22 May 2013 10:50:55 +0200 Received: (private information removed) Wed, 22 May 2013 10:50:55 +0200 Received: (private information removed) S2010EXCHCA1.ad.local ([::1]) with mapi id 14.03.0123.003; Wed, 22 May 2013 10:50:55 +0200 From: Branimir Rajtar To: Cong Liu Thread-Topic: [dhcwg] Conclusion for draft-ietf-dhc-v4configuration-00 Thread-Index: AQHOVUAdLPFjOx7CSUmM8CZD/WOJAZkQ5zeQ Date: Wed, 22 May 2013 08:50:54 +0000 Message-ID: <786F13AA11E69F4DB2CCA23F7400C2FB0142E741@S2010EXCH1.ad.local> References: <8A1B81989BCFAE44A22B2B86BF2B7631898DB0232B@HE111643.EMEA1.CDS.T-INTERNAL.COM> <51780A17.8010503@gmail.com> <489D13FBFA9B3E41812EA89F188F018E18552B99@xmb-rcd-x04.cisco.com> <518B7628.3020309@gmail.com> <786F13AA11E69F4DB2CCA23F7400C2FB0142D318@S2010EXCH1.ad.local> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.17.5.13] Content-Type: multipart/alternative; boundary="_000_786F13AA11E69F4DB2CCA23F7400C2FB0142E741S2010EXCH1adloc_" MIME-Version: 1.0 X-OriginalArrivalTime: 22 May 2013 08:50:55.0945 (UTC) FILETIME=[790A3390:01CE56C9] Cc: "dhcwg@ietf.org" Subject: Re: [dhcwg] Conclusion for draft-ietf-dhc-v4configuration-00 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 May 2013 08:51:18 -0000 --_000_786F13AA11E69F4DB2CCA23F7400C2FB0142E741S2010EXCH1adloc_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 X-NAIMIME-Disclaimer: 1 X-NAIMIME-Modified: 1 SGksCgpNeSBjb21tZW50cyBhcmUgaW5saW5lLi4uCgpCcmFuaW1pcgoKRnJvbTogZ25vY3VpbEBn bWFpbC5jb20gW21haWx0bzpnbm9jdWlsQGdtYWlsLmNvbV0gT24gQmVoYWxmIE9mIENvbmcgTGl1 ClNlbnQ6IE1vbmRheSwgTWF5IDIwLCAyMDEzIDExOjU1IEFNClRvOiBCcmFuaW1pciBSYWp0YXIK Q2M6IGRoY3dnQGlldGYub3JnClN1YmplY3Q6IFJlOiBbZGhjd2ddIENvbmNsdXNpb24gZm9yIGRy YWZ0LWlldGYtZGhjLXY0Y29uZmlndXJhdGlvbi0wMAoKSGkgQnJhbmltaXIsCgpJbiBzZWN0aW9u IDEuNSBhbmQgMy4zLjIsIHNob3VsZCAic2VwYXJhdGlvbiBvZiBESENQdjQgYW5kIERIQ1B2NCBw cm92aXNpb25pbmciIGJlICJzZXBhcmF0aW9uIG9mIERIQ1B2NCBhbmQgREhDUHY2IHByb3Zpc2lv bmluZyI/CgpbQlJdIFlvdSdyZSByaWdodCwgaXQncyBhIHR5cG8gLSBJJ2xsIGZpeCBpdCBmb3Ig dGhlIG5leHQgdmVyc2lvbi4KCkknbSBjb25mdXNlZCB3aXRoIHJlcXVpcmVtZW50IG5vLiA0LiBE b2VzIGl0IG1lYW4gc2VwYXJhdGVkIERIQ1B2NC9ESENQdjYgc2VydmVyIGRldmljZXMsIG9yIHNl cGFyYXRlZCBJUHY0L0lQdjYgYWRkcmVzcyBwcm92aXNpb25pbmcgcHJvY2Vzcywgb3Igc2VwYXJh dGVkIElQdjQgYWRkcmVzcy9vdGhlciBvcHRpb25zIHByb3Zpc2lvbmluZyBwcm9jZXNzPwoKW0JS XSBJdCBhY3R1YWxseSBtZWFucyBhbGwgb2YgdGhlbSA6KSBXZSB3YW50ZWQgdGhlIHNvbHV0aW9u IHRvIGJlIGFzIGZsZXhpYmxlIGFzIHBvc3NpYmxlIGZvciB0aGUgb3BlcmF0b3Igc28gaXQgY2Fu IGJlIGRlcGxveWVkIGluIHdoYXRldmVyIHNjZW5hcmlvIHRoZSBvcGVyYXRvciB3aXNoZXMuIEkg d2lsbCBleHBhbmQgdGhpcyByZXF1aXJlbWVudCBpbiB0aGUgbmV4dCB2ZXJzaW9uIG9mIHRoZSBk cmFmdC4KCkJlc3QgUmVnYXJkcywKQ29uZwoKCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT0KQ29uZyBMaXUKVHNpbmdodWEgVW5pdmVyc2l0eQoKMjAxMy81LzE1 IEJyYW5pbWlyIFJhanRhciA8QnJhbmltaXIuUmFqdGFyQHQuaHQuaHI8bWFpbHRvOkJyYW5pbWly LlJhanRhckB0Lmh0LmhyPj4KSGkgYWxsLAoKRm9sbG93aW5nIG9uIFRvbWVrJ3MgZS1tYWlsIGFu ZCB0aGUgdXBsb2FkIG9mIGRyYWZ0LWlldGYtZGhjLXY0Y29uZmlndXJhdGlvbi0wMCwgdGhlIGF1 dGhvcnMgd291bGQgbGlrZSB0byBzdGFydCB0aGUgZGlzY3Vzc2lvbiBvbiBpdCdzIGNvbmNsdXNp b24uIEZvbGxvd2luZyB0aGUgdGFsayBvbiB0aGUgbWFpbGluZyBsaXN0LCBvdXIgcHJvcG9zYWwg aXMgYXMgZm9sbG93czoKCiJXaGlsc3QgYWxsIG9mIHRoZSBhcHByb2FjaGVzIGRlc2NyaWJlZCBo ZXJlIHdpbGwgcmVxdWlyZSBzb21lIGRldmVsb3BtZW50IHdvcmsgaW4gb3JkZXIgdG8gcmVhbGl6 ZSwgaXQgaXMgY2xlYXIgZnJvbSB0aGUgYWJvdmUgYW5hbHlzaXMgdGhhdCB0aGUgbW9zdCBzdXN0 YWluYWJsZSBhcHByb2FjaCBjYXBpdGFsaXplcyBvbiBleGlzdGluZyBESENQdjQgaW1wbGVtZW50 YXRpb25zIGFuZCBpbmNsdWRlIHRoZW0gYXMgbmV3IERIQ1B2NiBtZXNzYWdlIHR5cGVzLiAgVGhl IG1haW4gcmF0aW9uYWxlIGZvciB0aGlzIGlzIHRoYXQgaXQgZW5hYmxlcyBhbGwgb2YgREhDUHY0 J3MgZXhpc3Rpbmcgb3B0aW9ucyB0byBiZSBtaWdyYXRlZCBmb3IgdXNlIG92ZXIgSVB2NiBpbiBh IHNpbmdsZSBzdGVwLgoKUG9ydGluZyBvZiBhbGwgbmVjZXNzYXJ5IERIQ1B2NCBvcHRpb25zIHRv IERIQ1B2NiB3b3VsZCByZXF1aXJlIG9uZ29pbmcgZGV2ZWxvcG1lbnQgd29yaywgcmUtaW1wbGVt ZW50aW5nIGV4aXN0aW5nIERIQ1B2NCBmdW5jdGlvbmFsaXR5IGluIERIQ1B2Ni4gIFRoaXMgd2ls bCByZXN1bHQgaW4gaGF2aW5nIGxlZ2FjeSBESENQdjQgb3B0aW9ucyBpbiBESENQdjYsIHdoaWNo IHdpbGwgbm8gbG9uZ2VyIGJlIHVzZWZ1bCBvbmNlIElQdjQgaXMgY29tcGxldGVseSBhYmFuZG9u ZWQuCgpUaGVyZWZvcmUsIHRoZSBESENQdjYgYXBwcm9hY2ggaXMgbm90IHN1aXRhYmxlIGZvciBk ZWxpdmVyaW5nIElQdjQgY29uZmlndXJhdGlvbiBwYXJhbWV0ZXJzIGluIGFuIGVmZmljaWVudCwg b25nb2luZyBtYW5uZXIuCgpUaGUgZHluYW1pY2FsIGxlYXNpbmcgb2YgSVB2NCBhZGRyZXNzZXMg aXMgZnVuZGFtZW50YWwgdG8gdGhlIGVmZmljaWVudCB1c2Ugb2YgcmVtYWluaW5nIElQdjQgcmVz b3VyY2VzLiBUaGlzIHdpbGwgYmVjb21lIGluY3JlYXNpbmdseSBpbXBvcnRhbnQgaW4gdGhlIGZ1 dHVyZSwgc28gYSBtZWNoYW5pc20gd2hpY2ggc3VwcG9ydHMgdGhpcyBpcyBuZWNlc3NhcnkuIERI Q1B2NG9TVyBkb2VzIG5vdCBwcm92aWRlIHRoaXMgZnVuY3Rpb24gYW5kIHNvIGlzIG5vdCByZWNv bW1lbmRlZC4KClRoZSBESENQdjRvNiBhcHByb2FjaCByZXF1aXJlcyBhIERIQ1B2NCBzZXJ2ZXIg KHdpdGggREhDUHY0bzYgZnVuY3Rpb25hbGl0eSkgZm9yIGFsbCBkZXBsb3ltZW50IHNjZW5hcmlv cywgZXZlbiB3aGVuIERIQ1B2NCBzcGVjaWZpYyBmdW5jdGlvbmFsaXR5IGlzIG5vdCByZXF1aXJl ZCBieSB0aGUgb3BlcmF0b3IuCgpUaGVyZWZvcmUsIHRoaXMgbWVtbyByZWNvbW1lbmRzIERIQ1B2 NG9ESENQdjYgPEktRC5pZXRmLWRoYy1kaGNwdjQtb3Zlci1kaGNwdjY+IGFzIHRoZSBiZXN0IHVu ZGVybHlpbmcgYXBwcm9hY2ggZm9yIHByb3Zpc2lvbmluZyBJUHY0IHBhcmFtZXRlcnMgb3ZlciBh biBJUHY2IG9ubHkgbmV0d29yay4iCgpBbHNvLCB3ZSBwcm9wb3NlIHR3byBjaGFuZ2VzIHRvIHRo ZSBkb2N1bWVudCBpdHNlbGYgd2hpY2ggd2UgZmluZCBzaG91bGQgYmV0dGVyIHJlZmxlY3QgdGhl IG92ZXJ2aWV3IG9mIGFsbCBwcm9wb3NhbHM6CjEuIFNlY3Rpb24gMywgcmVxdWlyZW1lbnQgbm8u IDYgLSBzaG91bGQgYmUgIk5vIiBmb3IgREhDUHY0bzYKMS4gU2VjdGlvbiAzLCByZXF1aXJlbWVu dCBuby4gMSAtIHNob3VsZCBiZSAiTm8iIGZvciBESENQdjRvU1cKCkJSLApCcmFuaW1pcgoKCi0t LS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tCkZyb206IGRoY3dnLWJvdW5jZXNAaWV0Zi5vcmc8bWFp bHRvOmRoY3dnLWJvdW5jZXNAaWV0Zi5vcmc+IFttYWlsdG86ZGhjd2ctYm91bmNlc0BpZXRmLm9y ZzxtYWlsdG86ZGhjd2ctYm91bmNlc0BpZXRmLm9yZz5dIE9uIEJlaGFsZiBPZiBUb21layBNcnVn YWxza2kKU2VudDogVGh1cnNkYXksIE1heSAwOSwgMjAxMyAxMjoxMSBQTQpUbzogZGhjd2dAaWV0 Zi5vcmc8bWFpbHRvOmRoY3dnQGlldGYub3JnPgpTdWJqZWN0OiBSZTogW2RoY3dnXSBBZG9wdGlv biBjYWxsIGZvciBkcmFmdC1yYWp0YXItZGhjLXY0Y29uZmlndXJhdGlvbi0wMiAtIGFkb3B0ZWQh CgpPbiAxMy0wNS0wOCAxNTo1MSwgQmVybmllIFZvbHogKHZvbHopIHdyb3RlOgo+IDIuIChXRyBj by1jaGFpciBoYXQgb24pOiBJZiB5b3UgaGF2ZSBub3QgZXhwcmVzc2VkIHN1cHBvcnQgb3Igb3Bw b3NpdGlvbiBmb3IgYWRvcHRpbmcgdGhpcyB3b3JrLCB0aGUgY2FsbCBleHBpcmVzIHRvZGF5IQpI aSwKCkFsdGhvdWdoIHRoaXMgYWRvcHRpb24gY2FsbCBsb29rZWQgYSBiaXQgZ3JpbSBmb3IgdGhl IGZpcnN0IDEwIGRheXMsCmxhcmdlIHN1cHBvcnQgdm9pY2VkIGluIHRoZSBsYXN0IGNvdXBsZSBk YXlzIHNhdmVkIHRoZSBkYXkuIFdlIGhhdmUKYXJvdW5kIGEgZG96ZW4gc3VwcG9ydCB2b2ljZXMs IHdoaWNoIG1lYW5zIHRoYXQgdGhpcyBJLUQgd2FzIGFkb3B0ZWQuCgpBdXRob3JzLCBwbGVhc2Ug dXBsb2FkIGl0IGFzIGRyYWZ0LWlldGYtZGhjLXY0Y29uZmlndXJhdGlvbi0wMC4gT25jZQp0aGF0 IGlzIGRvbmUsIEkgZW5jb3VyYWdlIGF1dGhvcnMgdG8gc3RhcnQgYSBkaXNjdXNzaW9uIGFib3V0 CnJlY29tbWVuZGF0aW9uIHRoYXQgdGhlIFdHIHdhbnRzIHRvIG9mZmVyLgoKSXQgaXMgYSBwbGVh c3VyZSB0byBzZWUgc3VjaCBhIHN0cm9uZyBjb25zZW5zdXMuIExldCdzIGhvcGUgdGhhdCB0aGUK ZGlzY3Vzc2lvbiBhYm91dCB3cml0aW5nIENvbmNsdXNpb24gc2VjdGlvbiB3aWxsIGhhdmUgZXF1 YWxseSBzdHJvbmcKY29uc2Vuc3VzLgoKQmVybmllICYgVG9tZWsKCl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCmRoY3dnIG1haWxpbmcgbGlzdApkaGN3Z0Bp ZXRmLm9yZzxtYWlsdG86ZGhjd2dAaWV0Zi5vcmc+Cmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vZGhjd2cKCgo8SFRNTD48UD48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPSM5OTk5 OTkgc2l6ZT0xPgoKSVpKQVZBIE8gT0RSSUNBTkpVIE9ER09WT1JOT1NUSTogU2FkcsW+YWogb3Zl IHBvcnVrZSBpIGV2ZW50dWFsbm8gcHJpbG/FvmVuaWggZGF0b3Rla2EgamUgcG92amVybGppdiBp IG5hbWlqZW5qZW4gamUgc2FtbyBvc29iYW1hIGlsaSBzdWJqZWt0aW1hIGtvamkgc3UgbmF2ZWRl bmkgdSBhZHJlc2kuIFVrb2xpa28gc3RlIHByaW1pbGkgb3Z1IHBvcnVrdSBncmXFoWtvbSwgbW9s aW1vIFZhcywgb2JhdmlqZXN0aXRlIHBvxaFpbGphdGVsamEsIGEgcG9ydWt1IGkgc3ZlIG5qZW5l IHByaXZpdGtlIG9kbWFoLCBiZXogxI1pdGFuamEsIHRyYWpubyB1a2xvbml0ZSBzIHJhxI11bmFs YS4gQmlsbyBrYWt2byBwcmVub8WhZW5qZSwga29waXJhbmplIGlsaSBkaXN0cmlidWNpamEgaW5m b3JtYWNpamEgc2FkcsW+YW5paCB1IHBvcnVjaSB0cmXEh2ltIG9zb2JhbWEgamUgemFicmFuamVu byBpIG1vxb5lIGJpdGkgemFrb25za2kga2HFvm5qaXZvLiBTYWRyxb5haiwgc3Rhdm92aSBpIG1p xaFsamVuamEgaXpuZXNlbmkgdSBwb3J1Y2kgc3UgYXV0b3JvdmkgaSBuZSBwcmVkc3RhdmxqYWp1 IG51xb5ubyBzdGF2b3ZlIEhUIC0gSHJ2YXRza2loIHRlbGVrb211bmlrYWNpamEgZC5kLiBIVCBu ZSBwcmlodmHEh2EgbmlrYWt2dSBvZGdvdm9ybm9zdCB6YSBldmVudHVhbG51IMWhdGV0dSBuYXN0 YWx1IHByaW1pdGtvbSBvdmUgcG9ydWtlIGkgcHJpbG9nYSBzYWRyxb5hbmloIHUgcG9ydWNpLgoK PC9GT05UPjwvUD48UD48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPSM5OTk5OTkgc2l6ZT0xPgoKIERJ U0NMQUlNRVI6VGhlIGNvbnRlbnRzIG9mIHRoaXMgZW1haWwgYXMgd2VsbCBhcyBhbnkgZmlsZXMg YXR0YWNoZWQgdG8gaXQgYXJlIGNvbmZpZGVudGlhbCBhbmQgaW50ZW5kZWQgc29sZWx5IGZvciBp bmRpdmlkdWFscyBvciBlbnRpdGllcyB3aGljaCB0aGV5IGFyZSBhZGRyZXNzZWQgdG8uIElmIHlv dSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgbWVzc2FnZSBpbiBlcnJvciwgcGxlYXNlIG5vdGlm eSB0aGUgc2VuZGVyIGFuZCBwZXJtYW5lbnRseSByZW1vdmUgdGhlIG1lc3NhZ2UgYW5kIGFsbCBh dHRhY2hlZCBmaWxlcyBmcm9tIHRoZSBjb21wdXRlci4gQW55IGRpc2Nsb3N1cmUsIGNvcHlpbmcg b3IgZGlzdHJpYnV0aW9uIG9mIGFsbCBvciBhIHBhcnQgb2YgaW5mb3JtYXRpb24gY29udGFpbmVk IGhlcmVpbiB0byBvciBieSB0aGlyZCBwYXJ0aWVzIGlzIHByb2hpYml0ZWQgYW5kIG1heSBiZSB1 bmxhd2Z1bC4gUGxlYXNlIG5vdGUgdGhhdCBhbnkgdmlld3Mgb3Igb3BpbmlvbnMgcHJlc2VudGVk IGluIHRoaXMgbWVzc2FnZSBhcmUgc29sZWx5IHRob3NlIG9mIHRoZSBhdXRob3IgYW5kIGRvIG5v dCBuZWNlc3NhcmlseSByZXByZXNlbnQgdGhlIHZpZXdzIGFuZCBvcGluaW9ucyBvZiBDcm9hdGlh biBUZWxlY29tIEluYy4gQ3JvYXRpYW4gVGVsZWNvbSBJbmMuIGFjY2VwdHMgbm8gbGlhYmlsaXR5 IGZvciBhbnkgcG90ZW50aWFsIGRhbWFnZSBjYXVzZWQgYnkgdGhpcyBtZXNzYWdlIGFuZCBmaWxl cyBhdHRhY2hlZCB0byBpdC4KCjwvRk9OVD48L1A+PC9IVE1MPgpfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXwpkaGN3ZyBtYWlsaW5nIGxpc3QKZGhjd2dAaWV0 Zi5vcmc8bWFpbHRvOmRoY3dnQGlldGYub3JnPgpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL2RoY3dnCgoKCjxIVE1MPjxQPjxGT05UIGZhY2U9QXJpYWwgY29sb3I9Izk5OTk5 OSBzaXplPTE+DQoNCklaSkFWQSBPIE9EUklDQU5KVSBPREdPVk9STk9TVEk6IFNhZHLFvmFqIG92 ZSBwb3J1a2UgaSBldmVudHVhbG5vIHByaWxvxb5lbmloIGRhdG90ZWthIGplIHBvdmplcmxqaXYg aSBuYW1pamVuamVuIGplIHNhbW8gb3NvYmFtYSBpbGkgc3ViamVrdGltYSBrb2ppIHN1IG5hdmVk ZW5pIHUgYWRyZXNpLiBVa29saWtvIHN0ZSBwcmltaWxpIG92dSBwb3J1a3UgZ3JlxaFrb20sIG1v bGltbyBWYXMsIG9iYXZpamVzdGl0ZSBwb8WhaWxqYXRlbGphLCBhIHBvcnVrdSBpIHN2ZSBuamVu ZSBwcml2aXRrZSBvZG1haCwgYmV6IMSNaXRhbmphLCB0cmFqbm8gdWtsb25pdGUgcyByYcSNdW5h bGEuIEJpbG8ga2Frdm8gcHJlbm/FoWVuamUsIGtvcGlyYW5qZSBpbGkgZGlzdHJpYnVjaWphIGlu Zm9ybWFjaWphIHNhZHLFvmFuaWggdSBwb3J1Y2kgdHJlxIdpbSBvc29iYW1hIGplIHphYnJhbmpl bm8gaSBtb8W+ZSBiaXRpIHpha29uc2tpIGthxb5uaml2by4gU2FkcsW+YWosIHN0YXZvdmkgaSBt acWhbGplbmphIGl6bmVzZW5pIHUgcG9ydWNpIHN1IGF1dG9yb3ZpIGkgbmUgcHJlZHN0YXZsamFq dSBudcW+bm8gc3Rhdm92ZSBIVCAtIEhydmF0c2tpaCB0ZWxla29tdW5pa2FjaWphIGQuZC4gSFQg bmUgcHJpaHZhxIdhIG5pa2FrdnUgb2Rnb3Zvcm5vc3QgemEgZXZlbnR1YWxudSDFoXRldHUgbmFz dGFsdSBwcmltaXRrb20gb3ZlIHBvcnVrZSBpIHByaWxvZ2Egc2FkcsW+YW5paCB1IHBvcnVjaS4N Cg0KPC9GT05UPjwvUD48UD48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPSM5OTk5OTkgc2l6ZT0xPg0K DQogRElTQ0xBSU1FUjpUaGUgY29udGVudHMgb2YgdGhpcyBlbWFpbCBhcyB3ZWxsIGFzIGFueSBm aWxlcyBhdHRhY2hlZCB0byBpdCBhcmUgY29uZmlkZW50aWFsIGFuZCBpbnRlbmRlZCBzb2xlbHkg Zm9yIGluZGl2aWR1YWxzIG9yIGVudGl0aWVzIHdoaWNoIHRoZXkgYXJlIGFkZHJlc3NlZCB0by4g SWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBtZXNzYWdlIGluIGVycm9yLCBwbGVhc2Ug bm90aWZ5IHRoZSBzZW5kZXIgYW5kIHBlcm1hbmVudGx5IHJlbW92ZSB0aGUgbWVzc2FnZSBhbmQg YWxsIGF0dGFjaGVkIGZpbGVzIGZyb20gdGhlIGNvbXB1dGVyLiBBbnkgZGlzY2xvc3VyZSwgY29w eWluZyBvciBkaXN0cmlidXRpb24gb2YgYWxsIG9yIGEgcGFydCBvZiBpbmZvcm1hdGlvbiBjb250 YWluZWQgaGVyZWluIHRvIG9yIGJ5IHRoaXJkIHBhcnRpZXMgaXMgcHJvaGliaXRlZCBhbmQgbWF5 IGJlIHVubGF3ZnVsLiBQbGVhc2Ugbm90ZSB0aGF0IGFueSB2aWV3cyBvciBvcGluaW9ucyBwcmVz ZW50ZWQgaW4gdGhpcyBtZXNzYWdlIGFyZSBzb2xlbHkgdGhvc2Ugb2YgdGhlIGF1dGhvciBhbmQg ZG8gbm90IG5lY2Vzc2FyaWx5IHJlcHJlc2VudCB0aGUgdmlld3MgYW5kIG9waW5pb25zIG9mIENy b2F0aWFuIFRlbGVjb20gSW5jLiBDcm9hdGlhbiBUZWxlY29tIEluYy4gYWNjZXB0cyBubyBsaWFi aWxpdHkgZm9yIGFueSBwb3RlbnRpYWwgZGFtYWdlIGNhdXNlZCBieSB0aGlzIG1lc3NhZ2UgYW5k IGZpbGVzIGF0dGFjaGVkIHRvIGl0Lg0KDQo8L0ZPTlQ+PC9QPjwvSFRNTD4K --_000_786F13AA11E69F4DB2CCA23F7400C2FB0142E741S2010EXCH1adloc_ Content-Type: text/HTML; charset="utf-8" Content-Transfer-Encoding: base64 X-NAIMIME-Disclaimer: 1 X-NAIMIME-Modified: 1 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+CjxoZWFkPgo8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNv bnRlbnQ9InRleHQvaHRtbDsgY2hhcnNldD1pc28tODg1OS0yIj4KPG1ldGEgbmFtZT0iR2VuZXJh dG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxMiAoZmlsdGVyZWQgbWVkaXVtKSI+CjxzdHls ZT48IS0tCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8KQGZvbnQtZmFjZQoJe2ZvbnQtZmFtaWx5OlNp bVN1bjsKCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQpAZm9udC1mYWNlCgl7Zm9udC1m YW1pbHk6IkNhbWJyaWEgTWF0aCI7CglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0O30KQGZv bnQtZmFjZQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7CglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAz IDIgNDt9CkBmb250LWZhY2UKCXtmb250LWZhbWlseTpUYWhvbWE7CglwYW5vc2UtMToyIDExIDYg NCAzIDUgNCA0IDIgNDt9CkBmb250LWZhY2UKCXtmb250LWZhbWlseToiXEBTaW1TdW4iOwoJcGFu b3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9Ci8qIFN0eWxlIERlZmluaXRpb25zICovCnAuTXNv Tm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwKCXttYXJnaW46MGNtOwoJbWFyZ2lu LWJvdHRvbTouMDAwMXB0OwoJZm9udC1zaXplOjEyLjBwdDsKCWZvbnQtZmFtaWx5OiJUaW1lcyBO ZXcgUm9tYW4iLCJzZXJpZiI7fQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rCgl7bXNvLXN0eWxl LXByaW9yaXR5Ojk5OwoJY29sb3I6Ymx1ZTsKCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQKCXttc28tc3R5bGUtcHJpb3JpdHk6 OTk7Cgljb2xvcjpwdXJwbGU7Cgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30Kc3Bhbi5FbWFp bFN0eWxlMTcKCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsKCWZvbnQtZmFtaWx5OiJD YWxpYnJpIiwic2Fucy1zZXJpZiI7Cgljb2xvcjojMUY0OTdEO30KLk1zb0NocERlZmF1bHQKCXtt c28tc3R5bGUtdHlwZTpleHBvcnQtb25seTt9CkBwYWdlIFdvcmRTZWN0aW9uMQoJe3NpemU6NjEy LjBwdCA3OTIuMHB0OwoJbWFyZ2luOjcwLjg1cHQgNzAuODVwdCA3MC44NXB0IDcwLjg1cHQ7fQpk aXYuV29yZFNlY3Rpb24xCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQotLT48L3N0eWxlPjwhLS1baWYg Z3RlIG1zbyA5XT48eG1sPgo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIx MDI2IiAvPgo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4KPG86c2hh cGVsYXlvdXQgdjpleHQ9ImVkaXQiPgo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4K PC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPgo8L2hlYWQ+Cjxib2R5IGxhbmc9IkhS IiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPkhpLAo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj5NeSBjb21tZW50cyBhcmUgaW5saW5lJiM4MjMwOzxvOnA+PC9v OnA+PC9zcGFuPjwvcD4KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PkJyYW5pbWlyPG86cD48L286cD48L3NwYW4+PC9wPgo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPgo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0 REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+CjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+ PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IGdub2N1aWxAZ21h aWwuY29tIFttYWlsdG86Z25vY3VpbEBnbWFpbC5jb21dCjxiPk9uIEJlaGFsZiBPZiA8L2I+Q29u ZyBMaXU8YnI+CjxiPlNlbnQ6PC9iPiBNb25kYXksIE1heSAyMCwgMjAxMyAxMTo1NSBBTTxicj4K PGI+VG86PC9iPiBCcmFuaW1pciBSYWp0YXI8YnI+CjxiPkNjOjwvYj4gZGhjd2dAaWV0Zi5vcmc8 YnI+CjxiPlN1YmplY3Q6PC9iPiBSZTogW2RoY3dnXSBDb25jbHVzaW9uIGZvciBkcmFmdC1pZXRm LWRoYy12NGNvbmZpZ3VyYXRpb24tMDA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+CjwvZGl2Pgo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4KPGRpdj4KPGRpdj4KPHAgY2xh c3M9Ik1zb05vcm1hbCI+SGkmbmJzcDs8c3BhbiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkJyYW5pbWly LDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4KPC9kaXY+CjxkaXY+CjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPgo8L2Rpdj4KPGRpdj4KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ SW4gc2VjdGlvbiAxLjUgYW5kIDMuMy4yLCBzaG91bGQgJnF1b3Q7c2VwYXJhdGlvbiBvZiBESENQ djQgYW5kIERIQ1B2NCBwcm92aXNpb25pbmcmcXVvdDsgYmUgJnF1b3Q7c2VwYXJhdGlvbiBvZiBE SENQdjQgYW5kIERIQ1B2NiBwcm92aXNpb25pbmcmcXVvdDs/PG86cD48L286cD48L3A+CjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5bQlJdIFlvdSdyZSByaWdodCwg aXQncyBhIHR5cG8gJiM4MjExOyBJJ2xsIGZpeCBpdCBmb3IgdGhlIG5leHQgdmVyc2lvbi48bzpw PjwvbzpwPjwvc3Bhbj48L3A+CjwvZGl2Pgo8ZGl2Pgo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4KPC9kaXY+CjxkaXY+CjxwIGNsYXNzPSJNc29Ob3JtYWwiPkknbSBj b25mdXNlZCB3aXRoIHJlcXVpcmVtZW50IG5vLiA0LiBEb2VzIGl0IG1lYW4gc2VwYXJhdGVkIERI Q1B2NC9ESENQdjYgc2VydmVyIGRldmljZXMsIG9yIHNlcGFyYXRlZCBJUHY0L0lQdjYgYWRkcmVz cyBwcm92aXNpb25pbmcgcHJvY2Vzcywgb3Igc2VwYXJhdGVkIElQdjQgYWRkcmVzcy9vdGhlciBv cHRpb25zIHByb3Zpc2lvbmluZyBwcm9jZXNzPzxvOnA+PC9vOnA+PC9wPgo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPgo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+W0JSXSBJdCBhY3R1YWxseSBtZWFucyBhbGwg b2YgdGhlbSA6KSBXZSB3YW50ZWQgdGhlIHNvbHV0aW9uIHRvIGJlIGFzIGZsZXhpYmxlIGFzIHBv c3NpYmxlIGZvciB0aGUgb3BlcmF0b3Igc28gaXQgY2FuIGJlIGRlcGxveWVkIGluIHdoYXRldmVy IHNjZW5hcmlvIHRoZSBvcGVyYXRvcgogd2lzaGVzLiBJIHdpbGwgZXhwYW5kIHRoaXMgcmVxdWly ZW1lbnQgaW4gdGhlIG5leHQgdmVyc2lvbiBvZiB0aGUgZHJhZnQuIDxvOnA+PC9vOnA+PC9zcGFu PjwvcD4KPC9kaXY+CjxkaXY+CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPgo8L2Rpdj4KPGRpdj4KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QmVzdCBSZWdhcmRzLDxvOnA+ PC9vOnA+PC9wPgo8L2Rpdj4KPGRpdj4KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Q29uZzxvOnA+PC9v OnA+PC9wPgo8L2Rpdj4KPGRpdj4KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+CjwvZGl2Pgo8ZGl2Pgo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnIgY2xlYXI9ImFsbCI+ CjxvOnA+PC9vOnA+PC9wPgo8ZGl2Pgo8ZGl2Pgo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEzLjVwdDtmb250LWZhbWlseTpTaW1TdW4iPj09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT08L3NwYW4+PG86cD48L286cD48L3A+Cjxk aXY+CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTMuNXB0O2Zv bnQtZmFtaWx5OlNpbVN1biI+Q29uZyBMaXU8L3NwYW4+PG86cD48L286cD48L3A+CjwvZGl2Pgo8 ZGl2Pgo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEzLjVwdDtm b250LWZhbWlseTpTaW1TdW4iPlRzaW5naHVhIFVuaXZlcnNpdHk8L3NwYW4+PG86cD48L286cD48 L3A+CjwvZGl2Pgo8L2Rpdj4KPC9kaXY+CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW4tYm90dG9tOjEyLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3A+CjxkaXY+CjxwIGNsYXNzPSJN c29Ob3JtYWwiPjIwMTMvNS8xNSBCcmFuaW1pciBSYWp0YXIgJmx0OzxhIGhyZWY9Im1haWx0bzpC cmFuaW1pci5SYWp0YXJAdC5odC5ociIgdGFyZ2V0PSJfYmxhbmsiPkJyYW5pbWlyLlJhanRhckB0 Lmh0LmhyPC9hPiZndDs8bzpwPjwvbzpwPjwvcD4KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SGkgYWxs LDxicj4KPGJyPgpGb2xsb3dpbmcgb24gVG9tZWsncyBlLW1haWwgYW5kIHRoZSB1cGxvYWQgb2Yg ZHJhZnQtaWV0Zi1kaGMtdjRjb25maWd1cmF0aW9uLTAwLCB0aGUgYXV0aG9ycyB3b3VsZCBsaWtl IHRvIHN0YXJ0IHRoZSBkaXNjdXNzaW9uIG9uIGl0J3MgY29uY2x1c2lvbi4gRm9sbG93aW5nIHRo ZSB0YWxrIG9uIHRoZSBtYWlsaW5nIGxpc3QsIG91ciBwcm9wb3NhbCBpcyBhcyBmb2xsb3dzOjxi cj4KPGJyPgomcXVvdDtXaGlsc3QgYWxsIG9mIHRoZSBhcHByb2FjaGVzIGRlc2NyaWJlZCBoZXJl IHdpbGwgcmVxdWlyZSBzb21lIGRldmVsb3BtZW50IHdvcmsgaW4gb3JkZXIgdG8gcmVhbGl6ZSwg aXQgaXMgY2xlYXIgZnJvbSB0aGUgYWJvdmUgYW5hbHlzaXMgdGhhdCB0aGUgbW9zdCBzdXN0YWlu YWJsZSBhcHByb2FjaCBjYXBpdGFsaXplcyBvbiBleGlzdGluZyBESENQdjQgaW1wbGVtZW50YXRp b25zIGFuZCBpbmNsdWRlIHRoZW0gYXMgbmV3IERIQ1B2NiBtZXNzYWdlCiB0eXBlcy4gJm5ic3A7 VGhlIG1haW4gcmF0aW9uYWxlIGZvciB0aGlzIGlzIHRoYXQgaXQgZW5hYmxlcyBhbGwgb2YgREhD UHY0J3MgZXhpc3Rpbmcgb3B0aW9ucyB0byBiZSBtaWdyYXRlZCBmb3IgdXNlIG92ZXIgSVB2NiBp biBhIHNpbmdsZSBzdGVwLjxicj4KPGJyPgpQb3J0aW5nIG9mIGFsbCBuZWNlc3NhcnkgREhDUHY0 IG9wdGlvbnMgdG8gREhDUHY2IHdvdWxkIHJlcXVpcmUgb25nb2luZyBkZXZlbG9wbWVudCB3b3Jr LCByZS1pbXBsZW1lbnRpbmcgZXhpc3RpbmcgREhDUHY0IGZ1bmN0aW9uYWxpdHkgaW4gREhDUHY2 LiAmbmJzcDtUaGlzIHdpbGwgcmVzdWx0IGluIGhhdmluZyBsZWdhY3kgREhDUHY0IG9wdGlvbnMg aW4gREhDUHY2LCB3aGljaCB3aWxsIG5vIGxvbmdlciBiZSB1c2VmdWwgb25jZSBJUHY0IGlzIGNv bXBsZXRlbHkKIGFiYW5kb25lZC48YnI+Cjxicj4KVGhlcmVmb3JlLCB0aGUgREhDUHY2IGFwcHJv YWNoIGlzIG5vdCBzdWl0YWJsZSBmb3IgZGVsaXZlcmluZyBJUHY0IGNvbmZpZ3VyYXRpb24gcGFy YW1ldGVycyBpbiBhbiBlZmZpY2llbnQsIG9uZ29pbmcgbWFubmVyLjxicj4KPGJyPgpUaGUgZHlu YW1pY2FsIGxlYXNpbmcgb2YgSVB2NCBhZGRyZXNzZXMgaXMgZnVuZGFtZW50YWwgdG8gdGhlIGVm ZmljaWVudCB1c2Ugb2YgcmVtYWluaW5nIElQdjQgcmVzb3VyY2VzLiBUaGlzIHdpbGwgYmVjb21l IGluY3JlYXNpbmdseSBpbXBvcnRhbnQgaW4gdGhlIGZ1dHVyZSwgc28gYSBtZWNoYW5pc20gd2hp Y2ggc3VwcG9ydHMgdGhpcyBpcyBuZWNlc3NhcnkuIERIQ1B2NG9TVyBkb2VzIG5vdCBwcm92aWRl IHRoaXMgZnVuY3Rpb24gYW5kIHNvCiBpcyBub3QgcmVjb21tZW5kZWQuPGJyPgo8YnI+ClRoZSBE SENQdjRvNiBhcHByb2FjaCByZXF1aXJlcyBhIERIQ1B2NCBzZXJ2ZXIgKHdpdGggREhDUHY0bzYg ZnVuY3Rpb25hbGl0eSkgZm9yIGFsbCBkZXBsb3ltZW50IHNjZW5hcmlvcywgZXZlbiB3aGVuIERI Q1B2NCBzcGVjaWZpYyBmdW5jdGlvbmFsaXR5IGlzIG5vdCByZXF1aXJlZCBieSB0aGUgb3BlcmF0 b3IuPGJyPgo8YnI+ClRoZXJlZm9yZSwgdGhpcyBtZW1vIHJlY29tbWVuZHMgREhDUHY0b0RIQ1B2 NiAmbHQ7SS1ELmlldGYtZGhjLWRoY3B2NC1vdmVyLWRoY3B2NiZndDsgYXMgdGhlIGJlc3QgdW5k ZXJseWluZyBhcHByb2FjaCBmb3IgcHJvdmlzaW9uaW5nIElQdjQgcGFyYW1ldGVycyBvdmVyIGFu IElQdjYgb25seSBuZXR3b3JrLiZxdW90Ozxicj4KPGJyPgpBbHNvLCB3ZSBwcm9wb3NlIHR3byBj aGFuZ2VzIHRvIHRoZSBkb2N1bWVudCBpdHNlbGYgd2hpY2ggd2UgZmluZCBzaG91bGQgYmV0dGVy IHJlZmxlY3QgdGhlIG92ZXJ2aWV3IG9mIGFsbCBwcm9wb3NhbHM6PGJyPgoxLiBTZWN0aW9uIDMs IHJlcXVpcmVtZW50IG5vLiA2IC0gc2hvdWxkIGJlICZxdW90O05vJnF1b3Q7IGZvciBESENQdjRv Njxicj4KMS4gU2VjdGlvbiAzLCByZXF1aXJlbWVudCBuby4gMSAtIHNob3VsZCBiZSAmcXVvdDtO byZxdW90OyBmb3IgREhDUHY0b1NXPGJyPgo8YnI+CkJSLDxicj4KQnJhbmltaXI8YnI+Cjxicj4K PGJyPgotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxicj4KRnJvbTogPGEgaHJlZj0ibWFpbHRv OmRoY3dnLWJvdW5jZXNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5kaGN3Zy1ib3VuY2VzQGll dGYub3JnPC9hPiBbbWFpbHRvOjxhIGhyZWY9Im1haWx0bzpkaGN3Zy1ib3VuY2VzQGlldGYub3Jn IiB0YXJnZXQ9Il9ibGFuayI+ZGhjd2ctYm91bmNlc0BpZXRmLm9yZzwvYT5dIE9uIEJlaGFsZiBP ZiBUb21layBNcnVnYWxza2k8YnI+ClNlbnQ6IFRodXJzZGF5LCBNYXkgMDksIDIwMTMgMTI6MTEg UE08YnI+ClRvOiA8YSBocmVmPSJtYWlsdG86ZGhjd2dAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5r Ij5kaGN3Z0BpZXRmLm9yZzwvYT48YnI+ClN1YmplY3Q6IFJlOiBbZGhjd2ddIEFkb3B0aW9uIGNh bGwgZm9yIGRyYWZ0LXJhanRhci1kaGMtdjRjb25maWd1cmF0aW9uLTAyIC0gYWRvcHRlZCE8YnI+ Cjxicj4KT24gMTMtMDUtMDggMTU6NTEsIEJlcm5pZSBWb2x6ICh2b2x6KSB3cm90ZTo8YnI+CiZn dDsgMi4gKFdHIGNvLWNoYWlyIGhhdCBvbik6IElmIHlvdSBoYXZlIG5vdCBleHByZXNzZWQgc3Vw cG9ydCBvciBvcHBvc2l0aW9uIGZvciBhZG9wdGluZyB0aGlzIHdvcmssIHRoZSBjYWxsIGV4cGly ZXMgdG9kYXkhPGJyPgpIaSw8YnI+Cjxicj4KQWx0aG91Z2ggdGhpcyBhZG9wdGlvbiBjYWxsIGxv b2tlZCBhIGJpdCBncmltIGZvciB0aGUgZmlyc3QgMTAgZGF5cyw8YnI+CmxhcmdlIHN1cHBvcnQg dm9pY2VkIGluIHRoZSBsYXN0IGNvdXBsZSBkYXlzIHNhdmVkIHRoZSBkYXkuIFdlIGhhdmU8YnI+ CmFyb3VuZCBhIGRvemVuIHN1cHBvcnQgdm9pY2VzLCB3aGljaCBtZWFucyB0aGF0IHRoaXMgSS1E IHdhcyBhZG9wdGVkLjxicj4KPGJyPgpBdXRob3JzLCBwbGVhc2UgdXBsb2FkIGl0IGFzIGRyYWZ0 LWlldGYtZGhjLXY0Y29uZmlndXJhdGlvbi0wMC4gT25jZTxicj4KdGhhdCBpcyBkb25lLCBJIGVu Y291cmFnZSBhdXRob3JzIHRvIHN0YXJ0IGEgZGlzY3Vzc2lvbiBhYm91dDxicj4KcmVjb21tZW5k YXRpb24gdGhhdCB0aGUgV0cgd2FudHMgdG8gb2ZmZXIuPGJyPgo8YnI+Ckl0IGlzIGEgcGxlYXN1 cmUgdG8gc2VlIHN1Y2ggYSBzdHJvbmcgY29uc2Vuc3VzLiBMZXQncyBob3BlIHRoYXQgdGhlPGJy PgpkaXNjdXNzaW9uIGFib3V0IHdyaXRpbmcgQ29uY2x1c2lvbiBzZWN0aW9uIHdpbGwgaGF2ZSBl cXVhbGx5IHN0cm9uZzxicj4KY29uc2Vuc3VzLjxicj4KPGJyPgpCZXJuaWUgJmFtcDsgVG9tZWs8 YnI+Cjxicj4KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188 YnI+CmRoY3dnIG1haWxpbmcgbGlzdDxicj4KPGEgaHJlZj0ibWFpbHRvOmRoY3dnQGlldGYub3Jn IiB0YXJnZXQ9Il9ibGFuayI+ZGhjd2dAaWV0Zi5vcmc8L2E+PGJyPgo8YSBocmVmPSJodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RoY3dnIiB0YXJnZXQ9Il9ibGFuayI+aHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kaGN3ZzwvYT48YnI+Cjxicj4KPGJy PgombHQ7SFRNTCZndDsmbHQ7UCZndDsmbHQ7Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPSM5OTk5OTkg c2l6ZT0xJmd0Ozxicj4KPGJyPgpJWkpBVkEgTyBPRFJJQ0FOSlUgT0RHT1ZPUk5PU1RJOiBTYWRy xb5haiBvdmUgcG9ydWtlIGkgZXZlbnR1YWxubyBwcmlsb8W+ZW5paCBkYXRvdGVrYSBqZSBwb3Zq ZXJsaml2IGkgbmFtaWplbmplbiBqZSBzYW1vIG9zb2JhbWEgaWxpIHN1Ympla3RpbWEga29qaSBz dSBuYXZlZGVuaSB1IGFkcmVzaS4gVWtvbGlrbyBzdGUgcHJpbWlsaSBvdnUgcG9ydWt1IGdyZcWh a29tLCBtb2xpbW8gVmFzLCBvYmF2aWplc3RpdGUgcG/FoWlsamF0ZWxqYSwgYSBwb3J1a3UKIGkg c3ZlIG5qZW5lIHByaXZpdGtlIG9kbWFoLCBiZXogxI1pdGFuamEsIHRyYWpubyB1a2xvbml0ZSBz IHJhxI11bmFsYS4gQmlsbyBrYWt2byBwcmVub8WhZW5qZSwga29waXJhbmplIGlsaSBkaXN0cmli dWNpamEgaW5mb3JtYWNpamEgc2FkcsW+YW5paCB1IHBvcnVjaSB0cmXEh2ltIG9zb2JhbWEgamUg emFicmFuamVubyBpIG1vxb5lIGJpdGkgemFrb25za2kga2HFvm5qaXZvLiBTYWRyxb5haiwgc3Rh dm92aSBpIG1pxaFsamVuamEgaXpuZXNlbmkgdSBwb3J1Y2kKIHN1IGF1dG9yb3ZpIGkgbmUgcHJl ZHN0YXZsamFqdSBudcW+bm8gc3Rhdm92ZSBIVCAtIEhydmF0c2tpaCB0ZWxla29tdW5pa2FjaWph IGQuZC4gSFQgbmUgcHJpaHZhxIdhIG5pa2FrdnUgb2Rnb3Zvcm5vc3QgemEgZXZlbnR1YWxudSDF oXRldHUgbmFzdGFsdSBwcmltaXRrb20gb3ZlIHBvcnVrZSBpIHByaWxvZ2Egc2FkcsW+YW5paCB1 IHBvcnVjaS48YnI+Cjxicj4KJmx0Oy9GT05UJmd0OyZsdDsvUCZndDsmbHQ7UCZndDsmbHQ7Rk9O VCBmYWNlPUFyaWFsIGNvbG9yPSM5OTk5OTkgc2l6ZT0xJmd0Ozxicj4KPGJyPgombmJzcDtESVND TEFJTUVSOlRoZSBjb250ZW50cyBvZiB0aGlzIGVtYWlsIGFzIHdlbGwgYXMgYW55IGZpbGVzIGF0 dGFjaGVkIHRvIGl0IGFyZSBjb25maWRlbnRpYWwgYW5kIGludGVuZGVkIHNvbGVseSBmb3IgaW5k aXZpZHVhbHMgb3IgZW50aXRpZXMgd2hpY2ggdGhleSBhcmUgYWRkcmVzc2VkIHRvLiBJZiB5b3Ug aGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIG1lc3NhZ2UgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkg dGhlIHNlbmRlciBhbmQgcGVybWFuZW50bHkKIHJlbW92ZSB0aGUgbWVzc2FnZSBhbmQgYWxsIGF0 dGFjaGVkIGZpbGVzIGZyb20gdGhlIGNvbXB1dGVyLiBBbnkgZGlzY2xvc3VyZSwgY29weWluZyBv ciBkaXN0cmlidXRpb24gb2YgYWxsIG9yIGEgcGFydCBvZiBpbmZvcm1hdGlvbiBjb250YWluZWQg aGVyZWluIHRvIG9yIGJ5IHRoaXJkIHBhcnRpZXMgaXMgcHJvaGliaXRlZCBhbmQgbWF5IGJlIHVu bGF3ZnVsLiBQbGVhc2Ugbm90ZSB0aGF0IGFueSB2aWV3cyBvciBvcGluaW9ucyBwcmVzZW50ZWQK IGluIHRoaXMgbWVzc2FnZSBhcmUgc29sZWx5IHRob3NlIG9mIHRoZSBhdXRob3IgYW5kIGRvIG5v dCBuZWNlc3NhcmlseSByZXByZXNlbnQgdGhlIHZpZXdzIGFuZCBvcGluaW9ucyBvZiBDcm9hdGlh biBUZWxlY29tIEluYy4gQ3JvYXRpYW4gVGVsZWNvbSBJbmMuIGFjY2VwdHMgbm8gbGlhYmlsaXR5 IGZvciBhbnkgcG90ZW50aWFsIGRhbWFnZSBjYXVzZWQgYnkgdGhpcyBtZXNzYWdlIGFuZCBmaWxl cyBhdHRhY2hlZCB0byBpdC48YnI+Cjxicj4KJmx0Oy9GT05UJmd0OyZsdDsvUCZndDsmbHQ7L0hU TUwmZ3Q7PGJyPgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xzxicj4KZGhjd2cgbWFpbGluZyBsaXN0PGJyPgo8YSBocmVmPSJtYWlsdG86ZGhjd2dAaWV0Zi5v cmciIHRhcmdldD0iX2JsYW5rIj5kaGN3Z0BpZXRmLm9yZzwvYT48YnI+CjxhIGhyZWY9Imh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZGhjd2ciIHRhcmdldD0iX2JsYW5rIj5o dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RoY3dnPC9hPjxvOnA+PC9vOnA+ PC9wPgo8L2Rpdj4KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+Cjwv ZGl2Pgo8L2Rpdj4KPC9kaXY+Cgo8RElWPjxQPjxIUj4KPFA+PEZPTlQgY29sb3I9Izk5OTk5OSBz aXplPTEgZmFjZT1BcmlhbD5JWkpBVkEgTyBPRFJJQ0FOSlUgT0RHT1ZPUk5PU1RJOiBTYWRyJiMz ODI7YWogb3ZlIHBvcnVrZSBpIGV2ZW50dWFsbm8gcHJpbG8mIzM4MjtlbmloIGRhdG90ZWthIGpl IHBvdmplcmxqaXYgaSBuYW1pamVuamVuIGplIHNhbW8gb3NvYmFtYSBpbGkgc3ViamVrdGltYSBr b2ppIHN1IG5hdmVkZW5pIHUgYWRyZXNpLiBVa29saWtvIHN0ZSBwcmltaWxpIG92dSBwb3J1a3Ug Z3JlJiMzNTM7a29tLCBtb2xpbW8gVmFzLCBvYmF2aWplc3RpdGUgcG8mIzM1MztpbGphdGVsamEs IGEgcG9ydWt1IGkgc3ZlIG5qZW5lIHByaXZpdGtlIG9kbWFoLCBiZXogJiMyNjk7aXRhbmphLCB0 cmFqbm8gdWtsb25pdGUgcyByYSYjMjY5O3VuYWxhLiBCaWxvIGtha3ZvIHByZW5vJiMzNTM7ZW5q ZSwga29waXJhbmplIGlsaSBkaXN0cmlidWNpamEgaW5mb3JtYWNpamEgc2FkciYjMzgyO2FuaWgg dSBwb3J1Y2kgdHJlJiMyNjM7aW0gb3NvYmFtYSBqZSB6YWJyYW5qZW5vIGkgbW8mIzM4MjtlIGJp dGkgemFrb25za2kga2EmIzM4Mjtuaml2by4gU2FkciYjMzgyO2FqLCBzdGF2b3ZpIGkgbWkmIzM1 MztsamVuamEgaXpuZXNlbmkgdSBwb3J1Y2kgc3UgYXV0b3JvdmkgaSBuZSBwcmVkc3RhdmxqYWp1 IG51JiMzODI7bm8gc3Rhdm92ZSBIVCAtIEhydmF0c2tvZyBUZWxla29tYSBkLmQuIEhUIG5lIHBy aWh2YSYjMjYzO2EgbmlrYWt2dSBvZGdvdm9ybm9zdCB6YSBldmVudHVhbG51ICYjMzUzO3RldHUg bmFzdGFsdSBwcmltaXRrb20gb3ZlIHBvcnVrZSBpIHByaWxvZ2Egc2FkciYjMzgyO2FuaWggdSBw b3J1Y2kuIDwvRk9OVD48L1A+DQo8UD48Rk9OVCBjb2xvcj0jOTk5OTk5IHNpemU9MSBmYWNlPUFy aWFsPkRJU0NMQUlNRVI6VGhlIGNvbnRlbnRzIG9mIHRoaXMgZW1haWwgYXMgd2VsbCBhcyBhbnkg ZmlsZXMgYXR0YWNoZWQgdG8gaXQgYXJlIGNvbmZpZGVudGlhbCBhbmQgaW50ZW5kZWQgc29sZWx5 IGZvciBpbmRpdmlkdWFscyBvciBlbnRpdGllcyB3aGljaCB0aGV5IGFyZSBhZGRyZXNzZWQgdG8u IElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgbWVzc2FnZSBpbiBlcnJvciwgcGxlYXNl IG5vdGlmeSB0aGUgc2VuZGVyIGFuZCBwZXJtYW5lbnRseSByZW1vdmUgdGhlIG1lc3NhZ2UgYW5k IGFsbCBhdHRhY2hlZCBmaWxlcyBmcm9tIHRoZSBjb21wdXRlci4gQW55IGRpc2Nsb3N1cmUsIGNv cHlpbmcgb3IgZGlzdHJpYnV0aW9uIG9mIGFsbCBvciBhIHBhcnQgb2YgaW5mb3JtYXRpb24gY29u dGFpbmVkIGhlcmVpbiB0byBvciBieSB0aGlyZCBwYXJ0aWVzIGlzIHByb2hpYml0ZWQgYW5kIG1h eSBiZSB1bmxhd2Z1bC4gUGxlYXNlIG5vdGUgdGhhdCBhbnkgdmlld3Mgb3Igb3BpbmlvbnMgcHJl c2VudGVkIGluIHRoaXMgbWVzc2FnZSBhcmUgc29sZWx5IHRob3NlIG9mIHRoZSBhdXRob3IgYW5k IGRvIG5vdCBuZWNlc3NhcmlseSByZXByZXNlbnQgdGhlIHZpZXdzIGFuZCBvcGluaW9ucyBvZiBD cm9hdGlhbiBUZWxlY29tIEluYy4gQ3JvYXRpYW4gVGVsZWNvbSBJbmMuIGFjY2VwdHMgbm8gbGlh YmlsaXR5IGZvciBhbnkgcG90ZW50aWFsIGRhbWFnZSBjYXVzZWQgYnkgdGhpcyBtZXNzYWdlIGFu ZCBmaWxlcyBhdHRhY2hlZCB0byBpdC4gPC9GT05UPjwvUD4KPC9QPjwvRElWPgo8L2JvZHk+Cjwv aHRtbD4K --_000_786F13AA11E69F4DB2CCA23F7400C2FB0142E741S2010EXCH1adloc_-- From fx.lebail@yahoo.com Wed May 22 06:58:32 2013 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 5953621F925B for ; Wed, 22 May 2013 06:58:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.632 X-Spam-Level: X-Spam-Status: No, score=-3.632 tagged_above=-999 required=5 tests=[AWL=-1.333, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UhrRuwQnomBE for ; Wed, 22 May 2013 06:58:26 -0700 (PDT) Received: from nm31-vm5.bullet.mail.ne1.yahoo.com (nm31-vm5.bullet.mail.ne1.yahoo.com [98.138.229.45]) by ietfa.amsl.com (Postfix) with ESMTP id CF3F421F923D for ; Wed, 22 May 2013 06:58:25 -0700 (PDT) Received: from [98.138.226.176] by nm31.bullet.mail.ne1.yahoo.com with NNFMP; 22 May 2013 13:58:25 -0000 Received: from [98.138.89.199] by tm11.bullet.mail.ne1.yahoo.com with NNFMP; 22 May 2013 13:58:25 -0000 Received: from [127.0.0.1] by omp1057.mail.ne1.yahoo.com with NNFMP; 22 May 2013 13:58:25 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 107570.23317.bm@omp1057.mail.ne1.yahoo.com Received: (qmail 92942 invoked by uid 60001); 22 May 2013 13:58:25 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1369231104; bh=pouWjFhIutEvVaOY3hivsJUnF0n/dkfHNMFlCDab9mI=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=lSfEDVKu46aSZR9D08dd2vOqNTotGURe8LmIqUyP8SlOktNH3fL4/vHB6071IND0u5cRzOHgMqnFcXuF5Im1sK4ZVvyQtgpTlK4c1BJ2Zf2CbCrStrxnnFNvDcxrMyP8DzCXEBBw/wznrtSvMnScUKmV3E7nDR1MxONQx0YWzFM= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=aB8Cc0hqtdRlCY8z5kssAHwyrbb7apJ30jwEAe/AdOLaSARAaug84GQOB57ola93FIuQpWnmdBf+sRd6NNBKAlZLVZwOK2hgr7A6Q2kijtAZ3Lm3M16yKTUQItLrLvNXqf+Ri52WEO1loB4TojwrQNS7aMPRVRw7Hb3lNerbIeY=; X-YMail-OSG: 1lYbpCIVM1kWS95.U.ngcgyVNRyXc.9cyoKJY_k4pskvhNM _MvtPmgtZzX6txmfDkMSdWcPrp2B2ikM_wr0RMfLktonzz3xE2pPs0uemN3r ar6yOiqvuJ3nnG6TBi_XDhO3kKc.i_cO64SdwMFj.E19ohbQIIlpRIM9.XWV A5dA27htl60oE0RGnsQxRQpGa8Q0G8KyzJ0k3jwuYwt_CSHS1sk348OqocEa 2g5J10.0Jku3Be7nugQifuYEJCpAse4BRCzjLq7pmD7iC8Ab05taqwUGRdbF esW.1q.Qd.1XV8dXIsTMx_tn5ZQfIDP.rtSVxRgbnvZ0l2SoKxu2l_V6nHlt gllEEGG3YF1oVNRafjy3TU6pk5dMaNFWpIcnyDBx6ScjHFXqWLTJ9tKrLySE zHCaY5TaGT_WfkrRzLgTK7YHlyzInDqzsqlf7f_4MicWl1BQnaq6ebgTakD7 zlij5ZvdrzaQXGcWuADD.pJ6jZ.gij3UdRaf1nsZfP0rCJ6b_KbiCayTC8Au AiKMpqdl8jksRiAOZgOQJY9NwRE4JVmJ02vlGeK4- Received: from [193.49.124.107] by web125503.mail.ne1.yahoo.com via HTTP; Wed, 22 May 2013 06:58:24 PDT X-Rocket-MIMEInfo: 002.001, LS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLQoKPiBGcm9tOiBUZWQgTGVtb24gPFRlZC5MZW1vbkBub21pbnVtLmNvbT4KPiBUbzogRnJhbsOnb2lzLVhhdmllciBMZSBCYWlsIDxmeC5sZWJhaWxAeWFob28uY29tPgo.IENjOiAibnRwd2dAbGlzdHMubnRwLm9yZyIgPG50cHdnQGxpc3RzLm50cC5vcmc.OyAiZGhjd2dAaWV0Zi5vcmciIDxkaGN3Z0BpZXRmLm9yZz47ICJyaWNoYXJkLmdheXJhdWRAZnJlZS5mciIgPHJpY2hhcmQuZ2F5cmF1ZEBmcmVlLmZyPjsgImJsb3VyZGVsQGNpc2NvLmNvbSIgPGJsb3UBMAEBAQE- X-Mailer: YahooMailWebService/0.8.142.542 References: <1369122267.50197.YahooMailNeo@web125506.mail.ne1.yahoo.com> <8D23D4052ABE7A4490E77B1A012B6307751AAF97@mbx-01.win.nominum.com> Message-ID: <1369231104.81780.YahooMailNeo@web125503.mail.ne1.yahoo.com> Date: Wed, 22 May 2013 06:58:24 -0700 (PDT) From: =?iso-8859-1?Q?Fran=E7ois-Xavier_Le_Bail?= To: Ted Lemon In-Reply-To: <8D23D4052ABE7A4490E77B1A012B6307751AAF97@mbx-01.win.nominum.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "ntpwg@lists.ntp.org" , "dhcwg@ietf.org" , "blourdel@cisco.com" , "richard.gayraud@free.fr" Subject: Re: [dhcwg] Question about RFC5908 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: =?iso-8859-1?Q?Fran=E7ois-Xavier_Le_Bail?= List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 May 2013 13:58:32 -0000 ----- Original Message -----=0A=0A> From: Ted Lemon = =0A> To: Fran=E7ois-Xavier Le Bail =0A> Cc: "ntpwg@lis= ts.ntp.org" ; "dhcwg@ietf.org" ; "rich= ard.gayraud@free.fr" ; "blourdel@cisco.com" =0A> Sent: Tuesday, May 21, 2013 5:18 PM=0A> Subject: Re: [dh= cwg] Question about RFC5908=0A> =0A> On May 21, 2013, at 3:44 AM, Fran=E7oi= s-Xavier Le Bail =0A> wrote:=0A>> It seems to me con= tradictory:=0A>> - The option itself [...]. Instead, it contains one or se= veral suboptions =0A> [...]=0A>> - This option MUST include one, and only = one, time source suboption.=0A>> =0A>> Did I miss something ?=0A> =0A> Yes= .=A0 The point is that the option can only contain one suboption in the se= t =0A> (server-addr, multicast-addr, server-fqdn).=A0 There can be more th= an one of =0A> these options, and so there can be more than one source subo= ption in the DHCPv6 =0A> packet: one for each such option=0A=0AI think the = text is not clear:=0AWhy not :=0AThis option MUST include one, and only one= , time source suboption type ?=0A From volz@cisco.com Wed May 22 08:31:15 2013 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 3D04021F8E93 for ; Wed, 22 May 2013 08:31:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.374 X-Spam-Level: X-Spam-Status: No, score=-10.374 tagged_above=-999 required=5 tests=[AWL=-0.075, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZyftUtBYttdN for ; Wed, 22 May 2013 08:31:10 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id CBEDE21F8263 for ; Wed, 22 May 2013 08:31:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1476; q=dns/txt; s=iport; t=1369236663; x=1370446263; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=HX0x31+AuaqH26YRUqOGk818FqdNiKtbVEXqtaarU+w=; b=CgB4Cfbhvxt5ltUX4yxa6axnF+HhQchCFBI9JhEBB+J2CszUuJP0kiMu 3VSujU/Odik0lw1M+rLvNei6C4HC8Z5KsWkCRgWyMENifPGYcl4QylDNl iezSf6U49TSBnivGtY5C34zya7be4Alzb99bujk67gKSoXe2gv/dVhOqH U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArAFAJDjnFGtJV2c/2dsb2JhbABagwgwr0uPEIMTgQUWdIIjAQEBBAEBAWsLDAQCAQgRBAEBAS4nAQoTCggCBA4Fh3sDBgkMslMMiGkEjEaCJAgrBwaCbWEDiGeMDWKBYowdhSODDw X-IronPort-AV: E=Sophos;i="4.87,722,1363132800"; d="scan'208";a="213467622" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-1.cisco.com with ESMTP; 22 May 2013 15:31:02 +0000 Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id r4MFV1GW013079 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 22 May 2013 15:31:01 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.77]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.02.0318.004; Wed, 22 May 2013 10:31:00 -0500 From: "Bernie Volz (volz)" To: =?iso-8859-1?Q?Fran=E7ois-Xavier_Le_Bail?= Thread-Topic: [dhcwg] Question about RFC5908 Thread-Index: AQHOVvR3Q5+93RlQMUODKTU5opwrJ5kRVNAh Date: Wed, 22 May 2013 15:30:59 +0000 Message-ID: <4C556A17-243B-4748-AE87-3272F1C62281@cisco.com> References: <1369122267.50197.YahooMailNeo@web125506.mail.ne1.yahoo.com> <8D23D4052ABE7A4490E77B1A012B6307751AAF97@mbx-01.win.nominum.com>, <1369231104.81780.YahooMailNeo@web125503.mail.ne1.yahoo.com> In-Reply-To: <1369231104.81780.YahooMailNeo@web125503.mail.ne1.yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ntpwg@lists.ntp.org" , "dhcwg@ietf.org" , "richard.gayraud@free.fr" , Ted Lemon , "blourdel@cisco.com" Subject: Re: [dhcwg] Question about RFC5908 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 May 2013 15:31:15 -0000 You can always file an errata. - Bernie On May 22, 2013, at 9:58 AM, "Fran=E7ois-Xavier Le Bail" wrote: > ----- Original Message ----- >=20 >> From: Ted Lemon >> To: Fran=E7ois-Xavier Le Bail >> Cc: "ntpwg@lists.ntp.org" ; "dhcwg@ietf.org" ; "richard.gayraud@free.fr" ; "blourdel@= cisco.com" >> Sent: Tuesday, May 21, 2013 5:18 PM >> Subject: Re: [dhcwg] Question about RFC5908 >>=20 >> On May 21, 2013, at 3:44 AM, Fran=E7ois-Xavier Le Bail =20 >> wrote: >>> It seems to me contradictory: >>> - The option itself [...]. Instead, it contains one or several suboptio= ns >> [...] >>> - This option MUST include one, and only one, time source suboption. >>>=20 >>> Did I miss something ? >>=20 >> Yes. The point is that the option can only contain one suboption in th= e set=20 >> (server-addr, multicast-addr, server-fqdn). There can be more than one= of=20 >> these options, and so there can be more than one source suboption in the= DHCPv6=20 >> packet: one for each such option >=20 > I think the text is not clear: > Why not : > This option MUST include one, and only one, time source suboption type ? >=20 > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg From Ted.Lemon@nominum.com Wed May 22 09:41:23 2013 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 B12C521F93FC for ; Wed, 22 May 2013 09:41:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.402 X-Spam-Level: X-Spam-Status: No, score=-106.402 tagged_above=-999 required=5 tests=[AWL=-0.103, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hc0+0WgfLszg for ; Wed, 22 May 2013 09:41:17 -0700 (PDT) Received: from exprod7og112.obsmtp.com (exprod7og112.obsmtp.com [64.18.2.177]) by ietfa.amsl.com (Postfix) with ESMTP id 09B4121F9195 for ; Wed, 22 May 2013 09:41:16 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob112.postini.com ([64.18.6.12]) with SMTP ID DSNKUZz1LFYpfwfCS7XqDVArxnRr2tPogs3W@postini.com; Wed, 22 May 2013 09:41:17 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 580721B8199 for ; Wed, 22 May 2013 09:41:16 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 4DFA719005D; Wed, 22 May 2013 09:41:16 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0318.004; Wed, 22 May 2013 09:41:16 -0700 From: Ted Lemon To: =?iso-8859-1?Q?Fran=E7ois-Xavier_Le_Bail?= Thread-Topic: [dhcwg] Question about RFC5908 Thread-Index: AQHOVfcNOh5dwhGRWkCEBIrpTVG/3ZkQNjqAgAF8CgCAAC2AgA== Date: Wed, 22 May 2013 16:41:16 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B6307751AD00C@mbx-01.win.nominum.com> References: <1369122267.50197.YahooMailNeo@web125506.mail.ne1.yahoo.com> <8D23D4052ABE7A4490E77B1A012B6307751AAF97@mbx-01.win.nominum.com> <1369231104.81780.YahooMailNeo@web125503.mail.ne1.yahoo.com> In-Reply-To: <1369231104.81780.YahooMailNeo@web125503.mail.ne1.yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <0E8117774C19704390A79CF275311115@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ntpwg@lists.ntp.org" , "dhcwg@ietf.org" , "blourdel@cisco.com" , "richard.gayraud@free.fr" Subject: Re: [dhcwg] Question about RFC5908 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 May 2013 16:41:23 -0000 On May 22, 2013, at 9:58 AM, Fran=E7ois-Xavier Le Bail wrote: > This option MUST include one, and only one, time source suboption type ? No, this would be less correct, because you are now allowing for two time s= ource options of the same type, which the current document (I believe corre= ctly) forbids. From Ted.Lemon@nominum.com Wed May 22 10:25:33 2013 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 5DC7921F8900 for ; Wed, 22 May 2013 10:25:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.549 X-Spam-Level: X-Spam-Status: No, score=-106.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AUYdXHerkDUx for ; Wed, 22 May 2013 10:25:26 -0700 (PDT) Received: from exprod7og102.obsmtp.com (exprod7og102.obsmtp.com [64.18.2.157]) by ietfa.amsl.com (Postfix) with ESMTP id 9483811E80EF for ; Wed, 22 May 2013 10:25:26 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob102.postini.com ([64.18.6.12]) with SMTP ID DSNKUZz/ht8ELDlSqH2mU4wBKrpWA96OBHEA@postini.com; Wed, 22 May 2013 10:25:26 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id D719F1B8199 for ; Wed, 22 May 2013 10:25:21 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id C60C619005D; Wed, 22 May 2013 10:25:21 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0318.004; Wed, 22 May 2013 10:25:21 -0700 From: Ted Lemon To: "Bernie Volz (volz)" Thread-Topic: [dhcwg] Question about RFC5908 Thread-Index: AQHOVfcNOh5dwhGRWkCEBIrpTVG/3ZkQNjqAgAF8CgCAABnegIAAH/MA Date: Wed, 22 May 2013 17:25:21 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B6307751AD1E1@mbx-01.win.nominum.com> References: <1369122267.50197.YahooMailNeo@web125506.mail.ne1.yahoo.com> <8D23D4052ABE7A4490E77B1A012B6307751AAF97@mbx-01.win.nominum.com>, <1369231104.81780.YahooMailNeo@web125503.mail.ne1.yahoo.com> <4C556A17-243B-4748-AE87-3272F1C62281@cisco.com> In-Reply-To: <4C556A17-243B-4748-AE87-3272F1C62281@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <56FCC61396B7B240A0878B70D9F8DBF3@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ntpwg@lists.ntp.org" , "dhcwg@ietf.org" , "blourdel@cisco.com" , "richard.gayraud@free.fr" Subject: Re: [dhcwg] Question about RFC5908 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 May 2013 17:25:33 -0000 On May 22, 2013, at 11:30 AM, Bernie Volz (volz) wrote: > You can always file an errata. An erratum, some errata. But please don't, because you are mistaken about= this (or at least, you have failed to explain why you are not mistaken). From volz@cisco.com Wed May 22 10:37:00 2013 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 C9A9B21F9685 for ; Wed, 22 May 2013 10:37:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.509 X-Spam-Level: X-Spam-Status: No, score=-10.509 tagged_above=-999 required=5 tests=[AWL=0.090, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B7z0WMeLv8R6 for ; Wed, 22 May 2013 10:36:55 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 4938021F9676 for ; Wed, 22 May 2013 10:36:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=500; q=dns/txt; s=iport; t=1369244215; x=1370453815; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=U0bwICEG0ABt88uQixLPaGWeYu6dkxXtS2ZUeXFE+Hs=; b=m6Ryq/lMan0egUX2/bj+eXjSenHJzyobBHeRmilk8yr4zkasbI0/Jn99 R2xiozeAROOZxGgTqEMOZrNA5zUiS65Enm6xROdv9iuBqJoN4Ri582UKS ighXZ0cEjI2cRqx6C031WAi6JMXo0O6xbxvDUUx1k+GmvziUqzY6P6+Vj w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnEFAM8AnVGtJV2b/2dsb2JhbABagwiDJL56gQcWdIIjAQEBAwF5BQsCAQgYLjIlAgQOBYgHBrsFjmozB4JzYQOIZ45RkUCDDw X-IronPort-AV: E=Sophos;i="4.87,722,1363132800"; d="scan'208";a="213705945" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-2.cisco.com with ESMTP; 22 May 2013 17:36:54 +0000 Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r4MHas1W008745 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 22 May 2013 17:36:54 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.77]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.02.0318.004; Wed, 22 May 2013 12:36:54 -0500 From: "Bernie Volz (volz)" To: Ted Lemon Thread-Topic: [dhcwg] Question about RFC5908 Thread-Index: AQHOVvR3Q5+93RlQMUODKTU5opwrJ5kRVNAhgABzxID//69oAw== Date: Wed, 22 May 2013 17:36:53 +0000 Message-ID: <1DD0BE84-5C32-4193-9052-F6515C3B3B56@cisco.com> References: <1369122267.50197.YahooMailNeo@web125506.mail.ne1.yahoo.com> <8D23D4052ABE7A4490E77B1A012B6307751AAF97@mbx-01.win.nominum.com>, <1369231104.81780.YahooMailNeo@web125503.mail.ne1.yahoo.com> <4C556A17-243B-4748-AE87-3272F1C62281@cisco.com>, <8D23D4052ABE7A4490E77B1A012B6307751AD1E1@mbx-01.win.nominum.com> In-Reply-To: <8D23D4052ABE7A4490E77B1A012B6307751AD1E1@mbx-01.win.nominum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ntpwg@lists.ntp.org" , "dhcwg@ietf.org" , "blourdel@cisco.com" , "richard.gayraud@free.fr" Subject: Re: [dhcwg] Question about RFC5908 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 May 2013 17:37:00 -0000 I am not in favor of it being filed. The text could certainly have been bet= ter but I think it has not been an issue. - Bernie (from iPad) On May 22, 2013, at 1:25 PM, "Ted Lemon" wrote: > On May 22, 2013, at 11:30 AM, Bernie Volz (volz) wrote: >> You can always file an errata. >=20 > An erratum, some errata. But please don't, because you are mistaken abo= ut this (or at least, you have failed to explain why you are not mistaken). >=20 From akostur@incognito.com Wed May 22 10:38:52 2013 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 B17E511E80FD for ; Wed, 22 May 2013 10:38:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.977 X-Spam-Level: X-Spam-Status: No, score=-5.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wyNpGH88FG6B for ; Wed, 22 May 2013 10:38:41 -0700 (PDT) Received: from na3sys010aog110.obsmtp.com (na3sys010aog110.obsmtp.com [74.125.245.88]) by ietfa.amsl.com (Postfix) with SMTP id 6E05721F9700 for ; Wed, 22 May 2013 10:38:41 -0700 (PDT) Received: from mail-vb0-f47.google.com ([209.85.212.47]) (using TLSv1) by na3sys010aob110.postini.com ([74.125.244.12]) with SMTP ID DSNKUZ0CoJhFVzH/DylZ1IFAbR00fC6KfG2g@postini.com; Wed, 22 May 2013 10:38:41 PDT Received: by mail-vb0-f47.google.com with SMTP id x13so1445437vbb.6 for ; Wed, 22 May 2013 10:38:39 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=6ei3yADgOhSdKL1qHbIG1EfGk6thG3y3L7hi+KlzPcQ=; b=cUJVkP8dGOdwViZAbzeJ1BKg59I4YgZsDkZUs/ylTNUj+cChGKzXmeAR4eKj+bU9zd 1seUsq+eaOayX5Inqc2enASV7BcZav/xB4KS0SeJueV3gxFXwW9CGDwZqzJF5BiXRw6l sYwpEIQpPqxoUxHYBRVu4aMe8FHKmS5jyVVFGhih3MLUiryEAp3fWJa8nGHpQeCbQtue zDVx3+YUEjp4AXVQewanfG0D8WvC9DQAaLCZFfDjD7LNAHgA5H6O33teFmlzUY+3ayFc 1QUxdYnCivHjX+qjOAoCjfJz0qlOA4aJgQky9Y6LKw3oATr+i5F+c6m175VpwYNLhuDr Jf5A== X-Received: by 10.58.208.228 with SMTP id mh4mr3159064vec.23.1369244319607; Wed, 22 May 2013 10:38:39 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.58.208.228 with SMTP id mh4mr3159059vec.23.1369244319536; Wed, 22 May 2013 10:38:39 -0700 (PDT) Received: by 10.220.231.136 with HTTP; Wed, 22 May 2013 10:38:39 -0700 (PDT) In-Reply-To: <8D23D4052ABE7A4490E77B1A012B6307751AD1E1@mbx-01.win.nominum.com> References: <1369122267.50197.YahooMailNeo@web125506.mail.ne1.yahoo.com> <8D23D4052ABE7A4490E77B1A012B6307751AAF97@mbx-01.win.nominum.com> <1369231104.81780.YahooMailNeo@web125503.mail.ne1.yahoo.com> <4C556A17-243B-4748-AE87-3272F1C62281@cisco.com> <8D23D4052ABE7A4490E77B1A012B6307751AD1E1@mbx-01.win.nominum.com> Date: Wed, 22 May 2013 10:38:39 -0700 Message-ID: From: Andre Kostur To: Ted Lemon Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQk3F3wvdBi+itj1M9jb9kVYI1h4vSjmTEt9QIfo51Ay2CPuXFrZijHnhUv39LGJwVhgnfCq0fvhWXxytJnqz7dn+HPPN3b8tlAXosWkoieBc0Vk1+neaJ5Zj2IjjCDx5bRJvV5uEzYlYS5dd+QreKwKm6yRYA== Cc: "ntpwg@lists.ntp.org" , "dhcwg@ietf.org" , "richard.gayraud@free.fr" , "Bernie Volz \(volz\)" , "blourdel@cisco.com" Subject: Re: [dhcwg] Question about RFC5908 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 May 2013 17:38:53 -0000 On Wed, May 22, 2013 at 10:25 AM, Ted Lemon wrote: > An erratum, some errata. But please don't, because you are mistaken about this (or at least, you have failed to explain why you are not mistaken). I'm not clear where the RFC forbids a response with two instances of 56, each with one instance of sub-option 1, or where one instance of 56 may only contain one sub-option instance. I do see where there may be multiple instances of 56 (both sections 4 & 5 acknowledge this), and an instance of 56 may contain multiple sub-options (section 4, and the diagram of option 56 acknowledge this). I do think that the phrasing of "This option MUST include one, and only one, time source suboption." is ambiguous and does appear to directly contradict the previous statement "Instead, it contains one or several suboptions that carry...". -- Andre Kostur From Ted.Lemon@nominum.com Wed May 22 10:45:20 2013 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 A143521F90BB for ; Wed, 22 May 2013 10:45:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.55 X-Spam-Level: X-Spam-Status: No, score=-106.55 tagged_above=-999 required=5 tests=[AWL=0.049, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xjM8JwEY+Zwt for ; Wed, 22 May 2013 10:45:10 -0700 (PDT) Received: from exprod7og128.obsmtp.com (exprod7og128.obsmtp.com [64.18.2.121]) by ietfa.amsl.com (Postfix) with ESMTP id B698621F9048 for ; Wed, 22 May 2013 10:45:10 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob128.postini.com ([64.18.6.12]) with SMTP ID DSNKUZ0EJu3WtzWCzcXDEVa29hYkRG3jBhOA@postini.com; Wed, 22 May 2013 10:45:10 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 3D2F01B819B for ; Wed, 22 May 2013 10:45:10 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 3589719005D; Wed, 22 May 2013 10:45:10 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.02.0318.004; Wed, 22 May 2013 10:45:10 -0700 From: Ted Lemon To: Andre Kostur Thread-Topic: [dhcwg] Question about RFC5908 Thread-Index: AQHOVfcNOh5dwhGRWkCEBIrpTVG/3ZkQNjqAgAF8CgCAABnegIAAH/MAgAADuYCAAAHPAA== Date: Wed, 22 May 2013 17:45:09 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B6307751AD3DF@mbx-01.win.nominum.com> References: <1369122267.50197.YahooMailNeo@web125506.mail.ne1.yahoo.com> <8D23D4052ABE7A4490E77B1A012B6307751AAF97@mbx-01.win.nominum.com> <1369231104.81780.YahooMailNeo@web125503.mail.ne1.yahoo.com> <4C556A17-243B-4748-AE87-3272F1C62281@cisco.com> <8D23D4052ABE7A4490E77B1A012B6307751AD1E1@mbx-01.win.nominum.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <068F5F04AB105049A05AB053C426558B@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ntpwg@lists.ntp.org" , "dhcwg@ietf.org" , "richard.gayraud@free.fr" , "Bernie Volz \(volz\)" , "blourdel@cisco.com" Subject: Re: [dhcwg] Question about RFC5908 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 May 2013 17:45:20 -0000 On May 22, 2013, at 1:38 PM, Andre Kostur wrote: > I do see where there may be multiple instances of 56 (both sections 4 > & 5 acknowledge this), and an instance of 56 may contain multiple > sub-options (section 4, and the diagram of option 56 acknowledge > this). I do think that the phrasing of "This option MUST include one, > and only one, time source suboption." is ambiguous and does appear to > directly contradict the previous statement "Instead, it contains one > or several suboptions that carry...". No, it doesn't, because not all suboptions are time source suboptions. From akostur@incognito.com Wed May 22 10:52:29 2013 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 9886421F9622 for ; Wed, 22 May 2013 10:52:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.977 X-Spam-Level: X-Spam-Status: No, score=-5.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UnTPBlejo55o for ; Wed, 22 May 2013 10:52:14 -0700 (PDT) Received: from na3sys010aog105.obsmtp.com (na3sys010aog105.obsmtp.com [74.125.245.78]) by ietfa.amsl.com (Postfix) with SMTP id A75B621F960C for ; Wed, 22 May 2013 10:52:13 -0700 (PDT) Received: from mail-ve0-f180.google.com ([209.85.128.180]) (using TLSv1) by na3sys010aob105.postini.com ([74.125.244.12]) with SMTP ID DSNKUZ0FzSIJx4mBLAUsqmHvwO3XwHtNViq4@postini.com; Wed, 22 May 2013 10:52:13 PDT Received: by mail-ve0-f180.google.com with SMTP id c13so1653518vea.11 for ; Wed, 22 May 2013 10:52:12 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=Y8vbN1ZzrsfwRmc9m+ed/pqp8PVGH5LXMFaGMjOKRww=; b=EIBk9OGBHQAUF/EsyHEqKCnJdt0qNi2pVUcvBN53StQJVOXbBAhO+zHh91ojgI7SQY PFdEC+nKSxR3tTHSjgCrTWpW0AHHdp3orol/SrckyM2bxhIkdbopygoxZ4AS03CBK8T+ zbdhBdNWuFx1fIl5tDbqCc8ReFnISgh3VaExKVIfCfmzxryAEfulTESYY46DhqQd7Pp3 WQrb8TOOhcz+idFpj4Q+KW3iifnRvtBLX/k+0VdXChZHXd3rFdZZIg13G2tVsDaHQB59 QikB4GifDsapUK+BMSI3ZUrGIPI59Pw7YNgso+4dSojA50zvRDNxUqFdBVLMq83+CfiM /YnQ== X-Received: by 10.220.176.71 with SMTP id bd7mr3150376vcb.12.1369245132863; Wed, 22 May 2013 10:52:12 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.220.176.71 with SMTP id bd7mr3150372vcb.12.1369245132773; Wed, 22 May 2013 10:52:12 -0700 (PDT) Received: by 10.220.231.136 with HTTP; Wed, 22 May 2013 10:52:12 -0700 (PDT) In-Reply-To: <8D23D4052ABE7A4490E77B1A012B6307751AD3DF@mbx-01.win.nominum.com> References: <1369122267.50197.YahooMailNeo@web125506.mail.ne1.yahoo.com> <8D23D4052ABE7A4490E77B1A012B6307751AAF97@mbx-01.win.nominum.com> <1369231104.81780.YahooMailNeo@web125503.mail.ne1.yahoo.com> <4C556A17-243B-4748-AE87-3272F1C62281@cisco.com> <8D23D4052ABE7A4490E77B1A012B6307751AD1E1@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751AD3DF@mbx-01.win.nominum.com> Date: Wed, 22 May 2013 10:52:12 -0700 Message-ID: From: Andre Kostur To: Ted Lemon Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQkBly5Ai++T1wk3tCo5qliaWL1gtl5TvgLhBVzRJXj/DoG60/bD9eEEoSmsfVd2eR0HOFh4q3/O9ZaOTx5NaSCjT9h6iiMhrC5x7dZzJaAIauqL7R3e5Y1+SdKIn6BkET1uRWKfqaeqUZEjzC21IsZXObXBeg== Cc: "ntpwg@lists.ntp.org" , "dhcwg@ietf.org" , "richard.gayraud@free.fr" , "Bernie Volz \(volz\)" , "blourdel@cisco.com" Subject: Re: [dhcwg] Question about RFC5908 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 May 2013 17:52:29 -0000 On Wed, May 22, 2013 at 10:45 AM, Ted Lemon wrote: > On May 22, 2013, at 1:38 PM, Andre Kostur wrote: >> I do see where there may be multiple instances of 56 (both sections 4 >> & 5 acknowledge this), and an instance of 56 may contain multiple >> sub-options (section 4, and the diagram of option 56 acknowledge >> this). I do think that the phrasing of "This option MUST include one, >> and only one, time source suboption." is ambiguous and does appear to >> directly contradict the previous statement "Instead, it contains one >> or several suboptions that carry...". > > No, it doesn't, because not all suboptions are time source suboptions. > So it's trying to acknowledge that there may be a bunch of other, unrelated suboptions stuck into this option? Wait... are we possibly arguing over a typo? If we re-read the problematic statement as "Instead, it contains one _of_ several suboptions that carry..." that seems to make more sense. -- Andre Kostur From Ted.Lemon@nominum.com Wed May 22 11:19:44 2013 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 A619021F8EEA for ; Wed, 22 May 2013 11:19:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.551 X-Spam-Level: X-Spam-Status: No, score=-106.551 tagged_above=-999 required=5 tests=[AWL=0.048, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gaU96MoaGMkL for ; Wed, 22 May 2013 11:19:38 -0700 (PDT) Received: from exprod7og126.obsmtp.com (exprod7og126.obsmtp.com [64.18.2.206]) by ietfa.amsl.com (Postfix) with ESMTP id CCDEA11E8129 for ; Wed, 22 May 2013 11:19:37 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob126.postini.com ([64.18.6.12]) with SMTP ID DSNKUZ0MOHbMh+M3YYsRk3T9jVyfjKVoksQP@postini.com; Wed, 22 May 2013 11:19:37 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id BB6BB1B81B3 for ; Wed, 22 May 2013 11:19:35 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id ACD7C19005D; Wed, 22 May 2013 11:19:35 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.02.0318.004; Wed, 22 May 2013 11:19:35 -0700 From: Ted Lemon To: Andre Kostur Thread-Topic: [dhcwg] Question about RFC5908 Thread-Index: AQHOVfcNOh5dwhGRWkCEBIrpTVG/3ZkQNjqAgAF8CgCAABnegIAAH/MAgAADuYCAAAHPAIAAAfoAgAAHpQA= Date: Wed, 22 May 2013 18:19:35 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B6307751AD4F5@mbx-01.win.nominum.com> References: <1369122267.50197.YahooMailNeo@web125506.mail.ne1.yahoo.com> <8D23D4052ABE7A4490E77B1A012B6307751AAF97@mbx-01.win.nominum.com> <1369231104.81780.YahooMailNeo@web125503.mail.ne1.yahoo.com> <4C556A17-243B-4748-AE87-3272F1C62281@cisco.com> <8D23D4052ABE7A4490E77B1A012B6307751AD1E1@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751AD3DF@mbx-01.win.nominum.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <4F16AD4C2B9F934DBD45ED074C369E39@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ntpwg@lists.ntp.org" , "dhcwg@ietf.org" , "richard.gayraud@free.fr" , "Bernie Volz \(volz\)" , "blourdel@cisco.com" Subject: Re: [dhcwg] Question about RFC5908 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 May 2013 18:19:44 -0000 On May 22, 2013, at 1:52 PM, Andre Kostur wrote: > So it's trying to acknowledge that there may be a bunch of other, > unrelated suboptions stuck into this option? Wait... are we possibly > arguing over a typo? If we re-read the problematic statement as > "Instead, it contains one _of_ several suboptions that carry..." that > seems to make more sense. It might have been better to say "one or more," but the meaning of the sent= ence is correct, and your proposed change would make it incorrect. The op= tion can contain any number of suboptions greater than zero. Exactly one = of those suboptions can be a time source suboption. That's what the text = says, and that's what the text was intended to say. There is no error or = ambiguity here. From akostur@incognito.com Wed May 22 12:37:21 2013 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 370C611E8152 for ; Wed, 22 May 2013 12:37:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.977 X-Spam-Level: X-Spam-Status: No, score=-5.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oLeHfX1uqf0T for ; Wed, 22 May 2013 12:37:15 -0700 (PDT) Received: from na3sys010aog110.obsmtp.com (na3sys010aog110.obsmtp.com [74.125.245.88]) by ietfa.amsl.com (Postfix) with SMTP id 3393011E815A for ; Wed, 22 May 2013 12:37:14 -0700 (PDT) Received: from mail-vb0-f41.google.com ([209.85.212.41]) (using TLSv1) by na3sys010aob110.postini.com ([74.125.244.12]) with SMTP ID DSNKUZ0eat2XIzmoTbIEvNsbsMAjKRBqIWUL@postini.com; Wed, 22 May 2013 12:37:15 PDT Received: by mail-vb0-f41.google.com with SMTP id p14so1596047vbm.0 for ; Wed, 22 May 2013 12:37:13 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=wI9RKcdvzu94slB9EPZltNmMtFOsBP5Au59L24959hY=; b=GCQ4nSvg7zdGHtYlrFldLhwdyawJJUdUcaZ4G4Vcyk4tDhB48RgA7FUq+UsLj26jRA BQQOQfC/P1zd43guahWMMSO0+3BJHCIFrcXVOWjzTQqoS99ITFleKH7m9i0rj2sazSPg 2EoYfAn+hPgEqQHp2RckRbKwtn5XX+AN9/JSY5f13/t1Y1k/qlZOnf1IvHHcCNqkUMwc DfU9iP9IhS8foAYJdy109dn4qt8oE9YyWJvVQEPbsz9idcgk80iItuX4UPFrZnI6J8Q7 LpUT45oB2XuoEG1mfI+S2WHcnugeSJY4n3jXl7Bpw58/8WV5b5vkqUvoc/k2rN6EbwbE u0eQ== X-Received: by 10.52.17.203 with SMTP id q11mr1250780vdd.120.1369251433583; Wed, 22 May 2013 12:37:13 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.52.17.203 with SMTP id q11mr1250778vdd.120.1369251433487; Wed, 22 May 2013 12:37:13 -0700 (PDT) Received: by 10.220.231.136 with HTTP; Wed, 22 May 2013 12:37:13 -0700 (PDT) In-Reply-To: <8D23D4052ABE7A4490E77B1A012B6307751AD4F5@mbx-01.win.nominum.com> References: <1369122267.50197.YahooMailNeo@web125506.mail.ne1.yahoo.com> <8D23D4052ABE7A4490E77B1A012B6307751AAF97@mbx-01.win.nominum.com> <1369231104.81780.YahooMailNeo@web125503.mail.ne1.yahoo.com> <4C556A17-243B-4748-AE87-3272F1C62281@cisco.com> <8D23D4052ABE7A4490E77B1A012B6307751AD1E1@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751AD3DF@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751AD4F5@mbx-01.win.nominum.com> Date: Wed, 22 May 2013 12:37:13 -0700 Message-ID: From: Andre Kostur To: Ted Lemon Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQlraAdAqiNnnqyygDuAR3YMmGgvZL8TY5/g5AqyUoj+uM1L7BttoJdwaXxn/geIQuocLD3VgCWlsnAENUzhMYWQp5bvHE+z/t9cvRUHwPLvCMoEmOC225aT1tcwKubYRpibvkUqkFSHizShlrTaQ3jdPdh7eg== Cc: "ntpwg@lists.ntp.org" , "dhcwg@ietf.org" , "richard.gayraud@free.fr" , "Bernie Volz \(volz\)" , "blourdel@cisco.com" Subject: Re: [dhcwg] Question about RFC5908 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 May 2013 19:37:21 -0000 On Wed, May 22, 2013 at 11:19 AM, Ted Lemon wrote: > On May 22, 2013, at 1:52 PM, Andre Kostur wrote: >> So it's trying to acknowledge that there may be a bunch of other, >> unrelated suboptions stuck into this option? Wait... are we possibly >> arguing over a typo? If we re-read the problematic statement as >> "Instead, it contains one _of_ several suboptions that carry..." that >> seems to make more sense. > > It might have been better to say "one or more," but the meaning of the se= ntence is correct, and your proposed change would make it incorrect. The = option can contain any number of suboptions greater than zero. Exactly on= e of those suboptions can be a time source suboption. That's what the tex= t says, and that's what the text was intended to say. There is no error o= r ambiguity here. > What other suboptions can it be? -- Andre Kostur From volz@cisco.com Wed May 22 13:04:20 2013 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 AE63621F971D for ; Wed, 22 May 2013 13:04:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.099 X-Spam-Level: X-Spam-Status: No, score=-10.099 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I3Zg+Pehik6I for ; Wed, 22 May 2013 13:04:15 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 4BBB821F971E for ; Wed, 22 May 2013 13:04:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3710; q=dns/txt; s=iport; t=1369253055; x=1370462655; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=Zc0Uu7oppzxK6kLnmVBw3bczc3N9dysSuDTVCJ6/hhc=; b=Ds/ggkHBJCDvtGVNEenF1i4UmkNdwiw+6J8LH1zKfR6JN4EjXWRQPYvz rs2/O07dlO0fhtUqDSLSLc4gFW4m+XOy9xqgV+OLuL0w5X6FoVAgzFet1 NmuiAH5debVHNf/Q++e+JgvQOxHn5pMH02iu/IN14tM7V355vEZ2kK9Ql c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao0FAFIknVGtJXHA/2dsb2JhbABagwgwvl2DE4EHFnSCIwEBAQQBAjc/DAQCAQgOAwQBAQEKFAkHKAoUCQgCBAENBQgBh3IDBgkMsX8MiHOObAYrBwIEgm1hA5R0lASDD4Im X-IronPort-AV: E=Sophos;i="4.87,723,1363132800"; d="scan'208";a="210829404" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-9.cisco.com with ESMTP; 22 May 2013 20:04:06 +0000 Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id r4MK46gp016537 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 22 May 2013 20:04:06 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.77]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.02.0318.004; Wed, 22 May 2013 15:04:05 -0500 From: "Bernie Volz (volz)" To: Andre Kostur , Ted Lemon Thread-Topic: [dhcwg] Question about RFC5908 Thread-Index: AQHOVvR3Q5+93RlQMUODKTU5opwrJ5kRVNAhgABzxICAAAO4gIAAAdGAgAAB+ACAAAemgIAAFbGA//+xjMA= Date: Wed, 22 May 2013 20:04:04 +0000 Message-ID: <489D13FBFA9B3E41812EA89F188F018E18569437@xmb-rcd-x04.cisco.com> References: <1369122267.50197.YahooMailNeo@web125506.mail.ne1.yahoo.com> <8D23D4052ABE7A4490E77B1A012B6307751AAF97@mbx-01.win.nominum.com> <1369231104.81780.YahooMailNeo@web125503.mail.ne1.yahoo.com> <4C556A17-243B-4748-AE87-3272F1C62281@cisco.com> <8D23D4052ABE7A4490E77B1A012B6307751AD1E1@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751AD3DF@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751AD4F5@mbx-01.win.nominum.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [161.44.65.116] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ntpwg@lists.ntp.org" , "dhcwg@ietf.org" , "blourdel@cisco.com" , "richard.gayraud@free.fr" Subject: Re: [dhcwg] Question about RFC5908 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 May 2013 20:04:20 -0000 This option serves as a container for server location information related to one NTP server or Simple Network Time Protocol (SNTP) [RFC4330] server. This option can appear multiple times in a DHCPv6 message. Each instance of this option is to be considered by the NTP client or SNTP client as a server to include in its configuration. The option itself does not contain any value. Instead, it contains one or several suboptions that carry NTP server or SNTP server location. This option MUST include one, and only one, time source suboption. The currently defined time source suboptions are NTP_OPTION_SRV_ADDR, NTP_OPTION_SRV_MC_ADDR, and NTP_OPTION_SRV_FQDN. Those 3 suboptions are the only ones currently defined. Bottom line is: - There may be multiple instances of the OPTION_NTP_SERVER option. - A OPTION_NTP_SERVER ONLY contains suboption(s). (This is what is meant by= "The option itself does not contain any value. ") - Each OPTION_NTP_SERVER MUST only contain ONE time-source suboption: thus = one of the 3 currently defined suboptions: NTP_OPTION_SRV_ADDR, NTP_OPTION_= SRV_MC_ADDR, and NTP_OPTION_SRV_FQDN. - If there are future suboptions defined (I don't believe there are), they = may or may not be time-source suboptions and if they are not, they might ap= pear in addition to a time-source suboption. The IANA considerations are also broken: 8. IANA Considerations IANA has assigned 56 as an option code from the "DHCPv6 Options Codes" registry for OPTION_NTP_SERVER. IANA is required to maintain a new number space of NTP time source suboptions, located in the BOOTP-DHCP Parameters Registry. The initial suboptions are described in Section 4 of this document. IANA assigns future NTP time source suboptions with an "IETF Consensus" policy as described in [RFC5226]. Future proposed suboptions are to be referenced symbolically in the documents that describe them, and shall be assigned numeric codes by IANA when approved for publication as an RFC. I am not sure why this new number space was in the "BOOTP-DHCP Parameters R= egistry" as that is the DHCPv4 registry, not the DHCPv6 registry. IANA did = do what the RFC requested (http://www.iana.org/assignments/bootp-dhcp-param= eters/bootp-dhcp-parameters.xml#ntp-time-source). This document is really bad and it is too bad it slipped through the cracks= . - Bernie -----Original Message----- From: Andre Kostur [mailto:akostur@incognito.com]=20 Sent: Wednesday, May 22, 2013 3:37 PM To: Ted Lemon Cc: Bernie Volz (volz); ntpwg@lists.ntp.org; dhcwg@ietf.org; blourdel@cisco= .com; richard.gayraud@free.fr Subject: Re: [dhcwg] Question about RFC5908 On Wed, May 22, 2013 at 11:19 AM, Ted Lemon wrote: > On May 22, 2013, at 1:52 PM, Andre Kostur wrote: >> So it's trying to acknowledge that there may be a bunch of other, >> unrelated suboptions stuck into this option? Wait... are we possibly >> arguing over a typo? If we re-read the problematic statement as=20 >> "Instead, it contains one _of_ several suboptions that carry..." that=20 >> seems to make more sense. > > It might have been better to say "one or more," but the meaning of the se= ntence is correct, and your proposed change would make it incorrect. The = option can contain any number of suboptions greater than zero. Exactly on= e of those suboptions can be a time source suboption. That's what the tex= t says, and that's what the text was intended to say. There is no error o= r ambiguity here. > What other suboptions can it be? -- Andre Kostur From Ted.Lemon@nominum.com Wed May 22 13:24:18 2013 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 38E2721F9408 for ; Wed, 22 May 2013 13:24:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.552 X-Spam-Level: X-Spam-Status: No, score=-106.552 tagged_above=-999 required=5 tests=[AWL=0.047, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EWwTIZiNWel5 for ; Wed, 22 May 2013 13:24:10 -0700 (PDT) Received: from exprod7og129.obsmtp.com (exprod7og129.obsmtp.com [64.18.2.122]) by ietfa.amsl.com (Postfix) with ESMTP id 9239D21F8F61 for ; Wed, 22 May 2013 13:24:10 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob129.postini.com ([64.18.6.12]) with SMTP ID DSNKUZ0patlJ7TfvePwJDpBG6kI0gYv1Wu8w@postini.com; Wed, 22 May 2013 13:24:10 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 16C251B8199 for ; Wed, 22 May 2013 13:24:10 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 0874D19005D; Wed, 22 May 2013 13:24:10 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.02.0318.004; Wed, 22 May 2013 13:24:03 -0700 From: Ted Lemon To: Andre Kostur Thread-Topic: [dhcwg] Question about RFC5908 Thread-Index: AQHOVfcNOh5dwhGRWkCEBIrpTVG/3ZkQNjqAgAF8CgCAABnegIAAH/MAgAADuYCAAAHPAIAAAfoAgAAHpQCAABWygIAADRUA Date: Wed, 22 May 2013 20:24:03 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B6307751AD858@mbx-01.win.nominum.com> References: <1369122267.50197.YahooMailNeo@web125506.mail.ne1.yahoo.com> <8D23D4052ABE7A4490E77B1A012B6307751AAF97@mbx-01.win.nominum.com> <1369231104.81780.YahooMailNeo@web125503.mail.ne1.yahoo.com> <4C556A17-243B-4748-AE87-3272F1C62281@cisco.com> <8D23D4052ABE7A4490E77B1A012B6307751AD1E1@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751AD3DF@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751AD4F5@mbx-01.win.nominum.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ntpwg@lists.ntp.org" , "dhcwg@ietf.org" , "Bernie Volz \(volz\)" , "richard.gayraud@free.fr" Subject: Re: [dhcwg] Question about RFC5908 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 May 2013 20:24:18 -0000 On May 22, 2013, at 3:37 PM, Andre Kostur wrote: > What other suboptions can it be? Right now no non-time source suboptions are defined. I don't know what th= e authors had in mind for this, TBH, but I'm pretty sure that the intent of= the text that you see there was to allow for multiple suboptions, as long = as only one was a time source option. If you want to open a can of worms here, the fact is that this option speci= fication is badly broken, not only because it is the only option definition= for IPv6 that uses suboptions, but as written, there is no value to the su= boptions. The reason it's broken in this way is that the NTP working grou= p disregarded substantial comment from the DHC working group. Personally, I think (ad hat off) that the DHC working group should just def= ine a new NTP option and deprecate this one. There is no excuse for somet= hing as basic as configuring an NTP server to be so complicated. From iesg-secretary@ietf.org Thu May 23 12:18:40 2013 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 5FAEE21F9682; Thu, 23 May 2013 12:18:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.33 X-Spam-Level: X-Spam-Status: No, score=-102.33 tagged_above=-999 required=5 tests=[AWL=0.270, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hwu91iV-JJk4; Thu, 23 May 2013 12:18:30 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A3E2421F9683; Thu, 23 May 2013 11:51:48 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.50 Message-ID: <20130523185148.3663.46559.idtracker@ietfa.amsl.com> Date: Thu, 23 May 2013 11:51:48 -0700 Cc: dhc mailing list , dhc chair , RFC Editor Subject: [dhcwg] Protocol Action: 'Reconfigure Triggered by DHCPv6 Relay Agents' to Proposed Standard (draft-ietf-dhc-triggered-reconfigure-07.txt) X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 May 2013 19:18:40 -0000 The IESG has approved the following document: - 'Reconfigure Triggered by DHCPv6 Relay Agents' (draft-ietf-dhc-triggered-reconfigure-07.txt) as Proposed Standard This document is the product of the Dynamic Host Configuration Working Group. The IESG contact persons are Ted Lemon and Brian Haberman. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-dhc-triggered-reconfigure/ Technical Summary: This document defines new DHCPv6 messages: Reconfigure-Request and Reconfigure-Reply. Reconfigure-Request message is sent by a DHCPv6 relay agent to notify a DHCPv6 server about a configuration information change, so that the DHCPv6 server can send a Reconfigure message accordingly. Reconfigure-Reply message is used by the server to acknowledge the receipt of Reconfigure-Request. Working Group Summary: This document was proposed in the working group in August 2012 as an extension to trigger client reconfiguration, via the DHCPv6 server, when configuration changes are made on the relay agent. The work was adopted as a WG item in September 2012 as there was good support and interest for the work. Document Quality: I'm not aware of any existing implementations. This is something that a number of folks and relay agent vendors have requested, and we expect to see implementation in relay agents and servers.. I think everyone who provided substantive review of the document is mentioned in the acknowledgements section. Personnel: Bernie Volz is the document shepherd. Ted Lemon is the responsible AD. From volz@cisco.com Thu May 23 14:11:06 2013 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 6D5BD21F97A1 for ; Thu, 23 May 2013 14:11:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tqwGyh0uKWcN for ; Thu, 23 May 2013 14:10:51 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 8B61021F97FC for ; Thu, 23 May 2013 13:25:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10913; q=dns/txt; s=iport; t=1369340737; x=1370550337; h=from:to:cc:subject:date:message-id:mime-version; bh=Y4s5mTvhq1NfKisD/3B2/T3gXmU7VfSeOOnpW6B7Q7A=; b=DrRT+KBise+EmvetjGRI+n6nre4psGdaRdawQezNHLsT/+hJmKktKh5j LdyARy6lRCe8I0e4VM+Hj43Hkucog0oHWtOlxlOmiuWjM3HL8z3DMqlxz 7t/L+rb+ZiF/TE1bePXgiYUUHdWQIQXtN9witwGUuci2dRi34Nbtsq3xi U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkEHACB6nlGtJXG8/2dsb2JhbABZgkREMLl1iDqBDBZtB4IlAQQdEEELEgEqViYBBA4NAYgEDLltjVuBETGCemEDiGePfZAXgw+BcTU X-IronPort-AV: E=Sophos;i="4.87,730,1363132800"; d="scan'208,217";a="214304245" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-7.cisco.com with ESMTP; 23 May 2013 20:25:37 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id r4NKPatj006304 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 23 May 2013 20:25:36 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.77]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.02.0318.004; Thu, 23 May 2013 15:25:36 -0500 From: "Bernie Volz (volz)" To: "dhcwg@ietf.org" Thread-Topic: IETF-87 (Berlin) Call for Agenda Items Thread-Index: Ac5X8enB4MREKIgyR3avcn9uMSaTsA== Date: Thu, 23 May 2013 20:25:36 +0000 Message-ID: <489D13FBFA9B3E41812EA89F188F018E1856AE22@xmb-rcd-x04.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.252.24] Content-Type: multipart/alternative; boundary="_000_489D13FBFA9B3E41812EA89F188F018E1856AE22xmbrcdx04ciscoc_" MIME-Version: 1.0 Cc: "Dhc Chairs \(dhc-chairs@tools.ietf.org\)" Subject: [dhcwg] IETF-87 (Berlin) Call for Agenda Items X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 May 2013 21:11:06 -0000 --_000_489D13FBFA9B3E41812EA89F188F018E1856AE22xmbrcdx04ciscoc_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi: While perhaps a bit early, we are starting the call for agenda items for th= e dhc wg meeting. And, as late June and July tend to be a prime vacation pe= riods, perhaps best to get people to start thinking about this now. We have asked for two slots: - One 2 =BD hour slot for the usual dhc wg meeting - One 1 hour slot as a joint meeting with the sunset4 wg to discus= s http://tools.ietf.org/html/draft-perreault-sunset4-noipv4 If you have a draft you would like to discuss, please send your request for= agenda time to the dhc chairs. Please include: - the title and file name of the draft - a brief summary of why it needs to be discussed - the speakers name (and email) - and how much time you need will need for presentation and antici= pated discussion. We will give priority, if needed, to requests for documents that are curren= tly working group items or were actively discussed on the mailing list. We do expect to spend some time discussing a re-charter and also a DHCP dir= ectorate (more on this before the meeting). Please have agenda items to us by 2013-07-01 (Monday) and also note the fol= lowing deadlines for IETF87: 2013-07-08 (Monday): Internet Draft Cut-off for initial document (-00) subm= ission by UTC 24:00 2013-07-15 (Monday): Internet Draft final submission cut-off by UTC 24:00 For full details about the meeting, see http://www.ietf.org/meetings/87/. - Tomek & Bernie --_000_489D13FBFA9B3E41812EA89F188F018E1856AE22xmbrcdx04ciscoc_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi:

 

While perhaps a bit early, we are starting the ca= ll for agenda items for the dhc wg meeting. And, as late June and July tend= to be a prime vacation periods, perhaps best to get people to start thinki= ng about this now.

 

We have asked for two slots:

-       = ;   One 2 =BD hour slot for the usual dhc wg meeting

-       = ;   One 1 hour slot as a joint meeting with the sunset4= wg to discuss http:= //tools.ietf.org/html/draft-perreault-sunset4-noipv4

 

If you have a draft you would like to discuss, pl= ease send your request for agenda time to the dhc chairs. Please include:

-       = ;   the title and file name of the draft

-       = ;   a brief summary of why it needs to be discussed

-       = ;   the speakers name (and email)

-       = ;   and how much time you need will need for presentati= on and anticipated discussion.

 

We will give priority, if needed, to requests for= documents that are currently working group items or were actively discusse= d on the mailing list.

 

We do expect to spend some time discussing a re-c= harter and also a DHCP directorate (more on this before the meeting).<= /o:p>

 

Please have agenda items to us by 2013-07-01 (Mon= day) and also note the following deadlines for IETF87:

 

2013-07-08 (Monday): Internet Draft Cut-off for i= nitial document (-00) submission by UTC 24:00

2013-07-15 (Monday): Internet Draft final submiss= ion cut-off by UTC 24:00

 

For full details about the meeting, see http://www.ietf.org/meetings/87/.

 

-     &= nbsp;    Tomek & Bernie

--_000_489D13FBFA9B3E41812EA89F188F018E1856AE22xmbrcdx04ciscoc_-- From fx.lebail@yahoo.com Sat May 25 09:27:16 2013 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 6151721F8717 for ; Sat, 25 May 2013 09:27:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.098 X-Spam-Level: * X-Spam-Status: No, score=1.098 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, MIME_8BIT_HEADER=0.3, RCVD_ILLEGAL_IP=1.908] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kcvm3gbNkPqk for ; Sat, 25 May 2013 09:27:10 -0700 (PDT) Received: from nm36-vm3.bullet.mail.ne1.yahoo.com (nm36-vm3.bullet.mail.ne1.yahoo.com [98.138.229.115]) by ietfa.amsl.com (Postfix) with ESMTP id B95A321F8BBC for ; Sat, 25 May 2013 09:27:09 -0700 (PDT) Received: from [98.138.90.57] by nm36.bullet.mail.ne1.yahoo.com with NNFMP; 25 May 2013 16:27:07 -0000 Received: from [98.138.89.252] by tm10.bullet.mail.ne1.yahoo.com with NNFMP; 25 May 2013 16:27:07 -0000 Received: from [127.0.0.1] by omp1044.mail.ne1.yahoo.com with NNFMP; 25 May 2013 16:27:07 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 521063.31301.bm@omp1044.mail.ne1.yahoo.com Received: (qmail 51498 invoked by uid 60001); 25 May 2013 16:27:07 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1369499227; bh=OoSURLxRxwu3YVe0RLmhlxc3hA18tTcuRIdqUvNsGuI=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=tIh+ZXfNhn7j6T07b0nBgkts/AktJNeXKhS3byA95nfoi9G+gcL4G92Y1PzpDhjPcDm05JE9vV5/j8FYLRilbCNPKx8YMcSmG8HuGmHqBqFNzn++jnoJ+t0OBgL1mo/kfpkzhcbM249i1vN0XugAgou1RGDl+5wIIO8W9xRf9UQ= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=TSbxykvMxjoV8KRVGUjn478ZUgI0wk7K4PKWT675IdQNku5nTR0qBUYt+7efPN+iDUWARNoedkgaZcSuJxTQ/xKPrcc3rN+VXEyH3QKz2LHK7f0W9YPOS8IHJDrZujcdc3t3eL5nqAFSPQO0mG4bJOyB6JcsKf4ctFmJ0oNY9vg=; X-YMail-OSG: bCSXMSEVM1lOdgXEIDT06q5RWqG9cQ8nRCHSFE4pDOOzsoE zP9R4gyo5dazEeoXeDO6ppZtaKQr7FVkCEY0kC4oQdXvsi3XZxtCTmeFTdSr t3bV_Fy8Opl5LJLcAGSc3FGTDKkaj5UB6xH1dymHbkSEYt6d7m4RaPhNmlco TlBRP3AQzawNLnARtEUsFLESxmBDw_w6Y4orShtQDkUx0oovLMl.ilY.QOxA nir5vU8dTeD1AUWYKLjXWsxGA8NK4RUh73YRx4axJrSJ_eO8ebT0X2YYABT_ HgDDZHY6JZoMQodZijJUW82_3mO8tY8sNNOPGBC1N6SWYmONI4XnbHQsplJs fkgXpRYqrP82Pam13q2VaWTwweicgI2YFgo6iix0fe.K6ibGupmab0UUulXX AiEnsuqmSxQyMJRo4l3d6Ti5AZm2Ykd_tMaymuS0xX5ZoEY2K325EvZThFuf gmPfST03mX5L7sivPsAhD4a75_Gx1SWlrTuGj0qfj_8lSR477MM0Frkl2oA2 5qD7HD7U6RjU0u4bGAYGTMv700nQSfxECH6H1YQ-- Received: from [2.11.110.162] by web125505.mail.ne1.yahoo.com via HTTP; Sat, 25 May 2013 09:27:07 PDT X-Rocket-MIMEInfo: 002.001, PiBUaGlzIGRvY3VtZW50IGlzIHJlYWxseSBiYWQgYW5kIGl0IGlzIHRvbyBiYWQgaXQgc2xpcHBlZCB0aHJvdWdoIHRoZSBjcmFja3MuCgoKKzEBMAEBAQE- X-Mailer: YahooMailWebService/0.8.144.546 References: <1369122267.50197.YahooMailNeo@web125506.mail.ne1.yahoo.com> <8D23D4052ABE7A4490E77B1A012B6307751AAF97@mbx-01.win.nominum.com> <1369231104.81780.YahooMailNeo@web125503.mail.ne1.yahoo.com> <4C556A17-243B-4748-AE87-3272F1C62281@cisco.com> <8D23D4052ABE7A4490E77B1A012B6307751AD1E1@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751AD3DF@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751AD4F5@mbx-01.win.nominum.com> <489D13FBFA9B3E41812EA89F188F018E18569437@xmb-rcd-x04.cisco.com> Message-ID: <1369499227.51115.YahooMailNeo@web125505.mail.ne1.yahoo.com> Date: Sat, 25 May 2013 09:27:07 -0700 (PDT) From: =?iso-8859-1?Q?Fran=E7ois-Xavier_Le_Bail?= To: "Bernie Volz \(volz\)" , Andre Kostur , Ted Lemon In-Reply-To: <489D13FBFA9B3E41812EA89F188F018E18569437@xmb-rcd-x04.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "ntpwg@lists.ntp.org" , "dhcwg@ietf.org" , "blourdel@cisco.com" , "richard.gayraud@free.fr" Subject: Re: [dhcwg] Question about RFC5908 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: =?iso-8859-1?Q?Fran=E7ois-Xavier_Le_Bail?= List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 May 2013 16:27:16 -0000 > This document is really bad and it is too bad it slipped through the crac= ks.=0A=0A=0A+1 From internet-drafts@ietf.org Tue May 28 06:34:35 2013 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 F03A421F9734; Tue, 28 May 2013 06:34:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.466 X-Spam-Level: X-Spam-Status: No, score=-102.466 tagged_above=-999 required=5 tests=[AWL=0.134, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 12zHr34Z2ymb; Tue, 28 May 2013 06:34:35 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D8AD521F972F; Tue, 28 May 2013 06:34:33 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.50 Message-ID: <20130528133433.12576.32840.idtracker@ietfa.amsl.com> Date: Tue, 28 May 2013 06:34:33 -0700 Cc: dhcwg@ietf.org Subject: [dhcwg] I-D Action: draft-ietf-dhc-v4configuration-01.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 May 2013 13:34:36 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Dynamic Host Configuration Working Group = of the IETF. Title : Provisioning IPv4 Configuration Over IPv6 Only Networks Author(s) : Branimir Rajtar Ian Farrer Filename : draft-ietf-dhc-v4configuration-01.txt Pages : 14 Date : 2013-05-28 Abstract: As IPv6 becomes more widely adopted, some service providers are taking the approach of deploying IPv6 only networks, without dual- stack functionality for IPv4. However, access to IPv4 based services is still an ongoing requirement and approaches such as IPv4-in-IPv6 softwire tunnels are being developed to meet this need. In order to provision end-user's hosts with the necessary IPv4 configuration, a number of different mechanisms have been proposed. This memo discusses the benefits and drawbacks of each, with the aim of recommending a single approach as the basis for future work. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dhc-v4configuration There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-dhc-v4configuration-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dhc-v4configuration-01 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From Branimir.Rajtar@t.ht.hr Tue May 28 07:06:26 2013 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 C50D021F8555 for ; Tue, 28 May 2013 07:06:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fSWVP6VH2gYu for ; Tue, 28 May 2013 07:06:22 -0700 (PDT) Received: from mx02.t.ht.hr (mx02.t.ht.hr [195.29.161.89]) by ietfa.amsl.com (Postfix) with SMTP id A699E21F853A for ; Tue, 28 May 2013 07:06:21 -0700 (PDT) Received: from no.name.available by mx02.t.ht.hr via smtpd (for mail.ietf.org [12.22.58.30]) with ESMTP; Tue, 28 May 2013 15:34:12 +0200 Received: from (unknown [172.17.66.76]) by scmg2.t.ht.hr with smtp id 4d5f_17a1_c5223a4c_c79f_11e2_9679_00219b931f47; Tue, 28 May 2013 16:06:19 +0200 Received: (private information removed) Tue, 28 May 2013 16:06:19 +0200 Received: (private information removed) S2010EXCHCA1.ad.local ([::1]) with mapi id 14.03.0123.003; Tue, 28 May 2013 16:06:19 +0200 From: Branimir Rajtar To: "dhcwg@ietf.org" Thread-Topic: new version of draft-ietf-dhc-v4configuration Thread-Index: Ac5brIYF9EKPT8o0Qq+6vHSUZzpWIg== Date: Tue, 28 May 2013 14:06:19 +0000 Message-ID: <786F13AA11E69F4DB2CCA23F7400C2FB01431062@S2010EXCH1.ad.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.17.5.14] Content-Type: multipart/alternative; boundary="_000_786F13AA11E69F4DB2CCA23F7400C2FB01431062S2010EXCH1adloc_" MIME-Version: 1.0 X-OriginalArrivalTime: 28 May 2013 14:06:19.0574 (UTC) FILETIME=[86E15560:01CE5BAC] Subject: [dhcwg] new version of draft-ietf-dhc-v4configuration X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 May 2013 14:06:26 -0000 --_000_786F13AA11E69F4DB2CCA23F7400C2FB01431062S2010EXCH1adloc_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 X-NAIMIME-Disclaimer: 1 X-NAIMIME-Modified: 1 SGkgYWxsLAoKSWYgeW91IGhhdmVuJ3Qgbm90aWNlZCwgYSBuZXcgdmVyc2lvbiBvZiBkcmFmdC1p ZXRmLWRoYy12NGNvbmZpZ3VyYXRpb24gaGFzIGJlZW4gcG9zdGVkICh2ZXJzaW9uIC0wMSkuIEl0 IGluY29ycG9yYXRlcyB0aGUgY29uY2x1c2lvbiBhcyBhZ3JlZWQgaW4gdGhlIHdvcmtpbmcgZ3Jv dXAsIGFzIHdlbGwgYXMgb3RoZXIgY29tbWVudHMgZnJvbSB0aGUgbWFpbGluZyBsaXN0LgoKaHR0 cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLWRoYy12NGNvbmZpZ3VyYXRp b24vCgpCUiwKQnJhbmltaXIKCgoKPEhUTUw+PFA+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj0jOTk5 OTk5IHNpemU9MT4NCg0KSVpKQVZBIE8gT0RSSUNBTkpVIE9ER09WT1JOT1NUSTogU2FkcsW+YWog b3ZlIHBvcnVrZSBpIGV2ZW50dWFsbm8gcHJpbG/FvmVuaWggZGF0b3Rla2EgamUgcG92amVybGpp diBpIG5hbWlqZW5qZW4gamUgc2FtbyBvc29iYW1hIGlsaSBzdWJqZWt0aW1hIGtvamkgc3UgbmF2 ZWRlbmkgdSBhZHJlc2kuIFVrb2xpa28gc3RlIHByaW1pbGkgb3Z1IHBvcnVrdSBncmXFoWtvbSwg bW9saW1vIFZhcywgb2JhdmlqZXN0aXRlIHBvxaFpbGphdGVsamEsIGEgcG9ydWt1IGkgc3ZlIG5q ZW5lIHByaXZpdGtlIG9kbWFoLCBiZXogxI1pdGFuamEsIHRyYWpubyB1a2xvbml0ZSBzIHJhxI11 bmFsYS4gQmlsbyBrYWt2byBwcmVub8WhZW5qZSwga29waXJhbmplIGlsaSBkaXN0cmlidWNpamEg aW5mb3JtYWNpamEgc2FkcsW+YW5paCB1IHBvcnVjaSB0cmXEh2ltIG9zb2JhbWEgamUgemFicmFu amVubyBpIG1vxb5lIGJpdGkgemFrb25za2kga2HFvm5qaXZvLiBTYWRyxb5haiwgc3Rhdm92aSBp IG1pxaFsamVuamEgaXpuZXNlbmkgdSBwb3J1Y2kgc3UgYXV0b3JvdmkgaSBuZSBwcmVkc3Rhdmxq YWp1IG51xb5ubyBzdGF2b3ZlIEhUIC0gSHJ2YXRza2loIHRlbGVrb211bmlrYWNpamEgZC5kLiBI VCBuZSBwcmlodmHEh2EgbmlrYWt2dSBvZGdvdm9ybm9zdCB6YSBldmVudHVhbG51IMWhdGV0dSBu YXN0YWx1IHByaW1pdGtvbSBvdmUgcG9ydWtlIGkgcHJpbG9nYSBzYWRyxb5hbmloIHUgcG9ydWNp Lg0KDQo8L0ZPTlQ+PC9QPjxQPjxGT05UIGZhY2U9QXJpYWwgY29sb3I9Izk5OTk5OSBzaXplPTE+ DQoNCiBESVNDTEFJTUVSOlRoZSBjb250ZW50cyBvZiB0aGlzIGVtYWlsIGFzIHdlbGwgYXMgYW55 IGZpbGVzIGF0dGFjaGVkIHRvIGl0IGFyZSBjb25maWRlbnRpYWwgYW5kIGludGVuZGVkIHNvbGVs eSBmb3IgaW5kaXZpZHVhbHMgb3IgZW50aXRpZXMgd2hpY2ggdGhleSBhcmUgYWRkcmVzc2VkIHRv LiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIG1lc3NhZ2UgaW4gZXJyb3IsIHBsZWFz ZSBub3RpZnkgdGhlIHNlbmRlciBhbmQgcGVybWFuZW50bHkgcmVtb3ZlIHRoZSBtZXNzYWdlIGFu ZCBhbGwgYXR0YWNoZWQgZmlsZXMgZnJvbSB0aGUgY29tcHV0ZXIuIEFueSBkaXNjbG9zdXJlLCBj b3B5aW5nIG9yIGRpc3RyaWJ1dGlvbiBvZiBhbGwgb3IgYSBwYXJ0IG9mIGluZm9ybWF0aW9uIGNv bnRhaW5lZCBoZXJlaW4gdG8gb3IgYnkgdGhpcmQgcGFydGllcyBpcyBwcm9oaWJpdGVkIGFuZCBt YXkgYmUgdW5sYXdmdWwuIFBsZWFzZSBub3RlIHRoYXQgYW55IHZpZXdzIG9yIG9waW5pb25zIHBy ZXNlbnRlZCBpbiB0aGlzIG1lc3NhZ2UgYXJlIHNvbGVseSB0aG9zZSBvZiB0aGUgYXV0aG9yIGFu ZCBkbyBub3QgbmVjZXNzYXJpbHkgcmVwcmVzZW50IHRoZSB2aWV3cyBhbmQgb3BpbmlvbnMgb2Yg Q3JvYXRpYW4gVGVsZWNvbSBJbmMuIENyb2F0aWFuIFRlbGVjb20gSW5jLiBhY2NlcHRzIG5vIGxp YWJpbGl0eSBmb3IgYW55IHBvdGVudGlhbCBkYW1hZ2UgY2F1c2VkIGJ5IHRoaXMgbWVzc2FnZSBh bmQgZmlsZXMgYXR0YWNoZWQgdG8gaXQuDQoNCjwvRk9OVD48L1A+PC9IVE1MPgo= --_000_786F13AA11E69F4DB2CCA23F7400C2FB01431062S2010EXCH1adloc_ Content-Type: text/HTML; charset="utf-8" Content-Transfer-Encoding: base64 X-NAIMIME-Disclaimer: 1 X-NAIMIME-Modified: 1 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6eD0idXJuOnNjaGVtYXMtbWljcm9z b2Z0LWNvbTpvZmZpY2U6ZXhjZWwiIHhtbG5zOnA9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206 b2ZmaWNlOnBvd2VycG9pbnQiIHhtbG5zOmE9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2Zm aWNlOmFjY2VzcyIgeG1sbnM6ZHQ9InV1aWQ6QzJGNDEwMTAtNjVCMy0xMWQxLUEyOUYtMDBBQTAw QzE0ODgyIiB4bWxuczpzPSJ1dWlkOkJEQzZFM0YwLTZEQTMtMTFkMS1BMkEzLTAwQUEwMEMxNDg4 MiIgeG1sbnM6cnM9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206cm93c2V0IiB4bWxuczp6PSIj Um93c2V0U2NoZW1hIiB4bWxuczpiPSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpw dWJsaXNoZXIiIHhtbG5zOnNzPSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpzcHJl YWRzaGVldCIgeG1sbnM6Yz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6Y29tcG9u ZW50OnNwcmVhZHNoZWV0IiB4bWxuczpvZGM9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2Zm aWNlOm9kYyIgeG1sbnM6b2E9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOmFjdGl2 YXRpb24iIHhtbG5zOmh0bWw9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1odG1sNDAiIHhtbG5z OnE9Imh0dHA6Ly9zY2hlbWFzLnhtbHNvYXAub3JnL3NvYXAvZW52ZWxvcGUvIiB4bWxuczpydGM9 Imh0dHA6Ly9taWNyb3NvZnQuY29tL29mZmljZW5ldC9jb25mZXJlbmNpbmciIHhtbG5zOkQ9IkRB VjoiIHhtbG5zOlJlcGw9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vcmVwbC8iIHhtbG5z Om10PSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL3NoYXJlcG9pbnQvc29hcC9tZWV0aW5n cy8iIHhtbG5zOngyPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS9leGNlbC8y MDAzL3htbCIgeG1sbnM6cHBkYT0iaHR0cDovL3d3dy5wYXNzcG9ydC5jb20vTmFtZVNwYWNlLnhz ZCIgeG1sbnM6b2lzPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL3NoYXJlcG9pbnQvc29h cC9vaXMvIiB4bWxuczpkaXI9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2lu dC9zb2FwL2RpcmVjdG9yeS8iIHhtbG5zOmRzPSJodHRwOi8vd3d3LnczLm9yZy8yMDAwLzA5L3ht bGRzaWcjIiB4bWxuczpkc3A9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2lu dC9kc3AiIHhtbG5zOnVkYz0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9kYXRhL3VkYyIg eG1sbnM6eHNkPSJodHRwOi8vd3d3LnczLm9yZy8yMDAxL1hNTFNjaGVtYSIgeG1sbnM6c3ViPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL3NoYXJlcG9pbnQvc29hcC8yMDAyLzEvYWxlcnRz LyIgeG1sbnM6ZWM9Imh0dHA6Ly93d3cudzMub3JnLzIwMDEvMDQveG1sZW5jIyIgeG1sbnM6c3A9 Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2ludC8iIHhtbG5zOnNwcz0iaHR0 cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9zaGFyZXBvaW50L3NvYXAvIiB4bWxuczp4c2k9Imh0 dHA6Ly93d3cudzMub3JnLzIwMDEvWE1MU2NoZW1hLWluc3RhbmNlIiB4bWxuczp1ZGNzPSJodHRw Oi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL2RhdGEvdWRjL3NvYXAiIHhtbG5zOnVkY3hmPSJodHRw Oi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL2RhdGEvdWRjL3htbGZpbGUiIHhtbG5zOnVkY3AycD0i aHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9kYXRhL3VkYy9wYXJ0dG9wYXJ0IiB4bWxuczp3 Zj0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9zaGFyZXBvaW50L3NvYXAvd29ya2Zsb3cv IiB4bWxuczpkc3NzPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA2L2Rp Z3NpZy1zZXR1cCIgeG1sbnM6ZHNzaT0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9vZmZp Y2UvMjAwNi9kaWdzaWciIHhtbG5zOm1kc3NpPSJodHRwOi8vc2NoZW1hcy5vcGVueG1sZm9ybWF0 cy5vcmcvcGFja2FnZS8yMDA2L2RpZ2l0YWwtc2lnbmF0dXJlIiB4bWxuczptdmVyPSJodHRwOi8v c2NoZW1hcy5vcGVueG1sZm9ybWF0cy5vcmcvbWFya3VwLWNvbXBhdGliaWxpdHkvMjAwNiIgeG1s bnM6bT0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4 bWxuczptcmVscz0iaHR0cDovL3NjaGVtYXMub3BlbnhtbGZvcm1hdHMub3JnL3BhY2thZ2UvMjAw Ni9yZWxhdGlvbnNoaXBzIiB4bWxuczpzcHdwPSJodHRwOi8vbWljcm9zb2Z0LmNvbS9zaGFyZXBv aW50L3dlYnBhcnRwYWdlcyIgeG1sbnM6ZXgxMnQ9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5j b20vZXhjaGFuZ2Uvc2VydmljZXMvMjAwNi90eXBlcyIgeG1sbnM6ZXgxMm09Imh0dHA6Ly9zY2hl bWFzLm1pY3Jvc29mdC5jb20vZXhjaGFuZ2Uvc2VydmljZXMvMjAwNi9tZXNzYWdlcyIgeG1sbnM6 cHB0c2w9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2ludC9zb2FwL1NsaWRl TGlicmFyeS8iIHhtbG5zOnNwc2w9Imh0dHA6Ly9taWNyb3NvZnQuY29tL3dlYnNlcnZpY2VzL1No YXJlUG9pbnRQb3J0YWxTZXJ2ZXIvUHVibGlzaGVkTGlua3NTZXJ2aWNlIiB4bWxuczpaPSJ1cm46 c2NoZW1hcy1taWNyb3NvZnQtY29tOiIgeG1sbnM6c3Q9IiYjMTsiIHhtbG5zPSJodHRwOi8vd3d3 LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4KPGhlYWQ+CjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQt VHlwZSIgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXVzLWFzY2lpIj4KPG1ldGEgbmFtZT0i R2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxMiAoZmlsdGVyZWQgbWVkaXVtKSI+ CjxzdHlsZT48IS0tCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8KQGZvbnQtZmFjZQoJe2ZvbnQtZmFt aWx5OiJDYW1icmlhIE1hdGgiOwoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9CkBmb250 LWZhY2UKCXtmb250LWZhbWlseTpDYWxpYnJpOwoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLwpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBk aXYuTXNvTm9ybWFsCgl7bWFyZ2luOjBjbTsKCW1hcmdpbi1ib3R0b206LjAwMDFwdDsKCWZvbnQt c2l6ZToxMS4wcHQ7Cglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO30KYTpsaW5r LCBzcGFuLk1zb0h5cGVybGluawoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsKCWNvbG9yOmJsdWU7 Cgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlu a0ZvbGxvd2VkCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5OwoJY29sb3I6cHVycGxlOwoJdGV4dC1k ZWNvcmF0aW9uOnVuZGVybGluZTt9CnNwYW4uRW1haWxTdHlsZTE3Cgl7bXNvLXN0eWxlLXR5cGU6 cGVyc29uYWwtY29tcG9zZTsKCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Cglj b2xvcjp3aW5kb3d0ZXh0O30KLk1zb0NocERlZmF1bHQKCXttc28tc3R5bGUtdHlwZTpleHBvcnQt b25seTt9CkBwYWdlIFdvcmRTZWN0aW9uMQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0OwoJbWFyZ2lu OjcwLjg1cHQgNzAuODVwdCA3MC44NXB0IDcwLjg1cHQ7fQpkaXYuV29yZFNlY3Rpb24xCgl7cGFn ZTpXb3JkU2VjdGlvbjE7fQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPgo8bzpz aGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPgo8L3htbD48IVtlbmRp Zl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQi Pgo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4KPC9vOnNoYXBlbGF5b3V0PjwveG1s PjwhW2VuZGlmXS0tPgo8L2hlYWQ+Cjxib2R5IGxhbmc9IkhSIiBsaW5rPSJibHVlIiB2bGluaz0i cHVycGxlIj4KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiPkhpIGFsbCw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+CjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5JZiB5b3UgaGF2ZW4m IzgyMTc7dCBub3RpY2VkLCBhIG5ldyB2ZXJzaW9uIG9mIGRyYWZ0LWlldGYtZGhjLXY0Y29uZmln dXJhdGlvbiBoYXMgYmVlbiBwb3N0ZWQgKHZlcnNpb24gLTAxKS4gSXQgaW5jb3Jwb3JhdGVzIHRo ZSBjb25jbHVzaW9uIGFzIGFncmVlZCBpbiB0aGUgd29ya2luZyBncm91cCwgYXMgd2VsbCBhcyBv dGhlciBjb21tZW50cyBmcm9tIHRoZSBtYWlsaW5nIGxpc3QuPG86cD48L286cD48L3NwYW4+PC9w Pgo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPgo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PGEg aHJlZj0iaHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLWRoYy12NGNv bmZpZ3VyYXRpb24vIj5odHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYt ZGhjLXY0Y29uZmlndXJhdGlvbi88L2E+PG86cD48L286cD48L3NwYW4+PC9wPgo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pgo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+QlIsPG86cD48L286cD48 L3NwYW4+PC9wPgo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+QnJhbmlt aXI8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+Cjwv c3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1l cyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iREUiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4KPC9kaXY+Cgo8RElWPjxQPjxIUj4KPFA+PEZPTlQgY29sb3I9Izk5OTk5OSBz aXplPTEgZmFjZT1BcmlhbD5JWkpBVkEgTyBPRFJJQ0FOSlUgT0RHT1ZPUk5PU1RJOiBTYWRyJiMz ODI7YWogb3ZlIHBvcnVrZSBpIGV2ZW50dWFsbm8gcHJpbG8mIzM4MjtlbmloIGRhdG90ZWthIGpl IHBvdmplcmxqaXYgaSBuYW1pamVuamVuIGplIHNhbW8gb3NvYmFtYSBpbGkgc3ViamVrdGltYSBr b2ppIHN1IG5hdmVkZW5pIHUgYWRyZXNpLiBVa29saWtvIHN0ZSBwcmltaWxpIG92dSBwb3J1a3Ug Z3JlJiMzNTM7a29tLCBtb2xpbW8gVmFzLCBvYmF2aWplc3RpdGUgcG8mIzM1MztpbGphdGVsamEs IGEgcG9ydWt1IGkgc3ZlIG5qZW5lIHByaXZpdGtlIG9kbWFoLCBiZXogJiMyNjk7aXRhbmphLCB0 cmFqbm8gdWtsb25pdGUgcyByYSYjMjY5O3VuYWxhLiBCaWxvIGtha3ZvIHByZW5vJiMzNTM7ZW5q ZSwga29waXJhbmplIGlsaSBkaXN0cmlidWNpamEgaW5mb3JtYWNpamEgc2FkciYjMzgyO2FuaWgg dSBwb3J1Y2kgdHJlJiMyNjM7aW0gb3NvYmFtYSBqZSB6YWJyYW5qZW5vIGkgbW8mIzM4MjtlIGJp dGkgemFrb25za2kga2EmIzM4Mjtuaml2by4gU2FkciYjMzgyO2FqLCBzdGF2b3ZpIGkgbWkmIzM1 MztsamVuamEgaXpuZXNlbmkgdSBwb3J1Y2kgc3UgYXV0b3JvdmkgaSBuZSBwcmVkc3RhdmxqYWp1 IG51JiMzODI7bm8gc3Rhdm92ZSBIVCAtIEhydmF0c2tvZyBUZWxla29tYSBkLmQuIEhUIG5lIHBy aWh2YSYjMjYzO2EgbmlrYWt2dSBvZGdvdm9ybm9zdCB6YSBldmVudHVhbG51ICYjMzUzO3RldHUg bmFzdGFsdSBwcmltaXRrb20gb3ZlIHBvcnVrZSBpIHByaWxvZ2Egc2FkciYjMzgyO2FuaWggdSBw b3J1Y2kuIDwvRk9OVD48L1A+DQo8UD48Rk9OVCBjb2xvcj0jOTk5OTk5IHNpemU9MSBmYWNlPUFy aWFsPkRJU0NMQUlNRVI6VGhlIGNvbnRlbnRzIG9mIHRoaXMgZW1haWwgYXMgd2VsbCBhcyBhbnkg ZmlsZXMgYXR0YWNoZWQgdG8gaXQgYXJlIGNvbmZpZGVudGlhbCBhbmQgaW50ZW5kZWQgc29sZWx5 IGZvciBpbmRpdmlkdWFscyBvciBlbnRpdGllcyB3aGljaCB0aGV5IGFyZSBhZGRyZXNzZWQgdG8u IElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgbWVzc2FnZSBpbiBlcnJvciwgcGxlYXNl IG5vdGlmeSB0aGUgc2VuZGVyIGFuZCBwZXJtYW5lbnRseSByZW1vdmUgdGhlIG1lc3NhZ2UgYW5k IGFsbCBhdHRhY2hlZCBmaWxlcyBmcm9tIHRoZSBjb21wdXRlci4gQW55IGRpc2Nsb3N1cmUsIGNv cHlpbmcgb3IgZGlzdHJpYnV0aW9uIG9mIGFsbCBvciBhIHBhcnQgb2YgaW5mb3JtYXRpb24gY29u dGFpbmVkIGhlcmVpbiB0byBvciBieSB0aGlyZCBwYXJ0aWVzIGlzIHByb2hpYml0ZWQgYW5kIG1h eSBiZSB1bmxhd2Z1bC4gUGxlYXNlIG5vdGUgdGhhdCBhbnkgdmlld3Mgb3Igb3BpbmlvbnMgcHJl c2VudGVkIGluIHRoaXMgbWVzc2FnZSBhcmUgc29sZWx5IHRob3NlIG9mIHRoZSBhdXRob3IgYW5k IGRvIG5vdCBuZWNlc3NhcmlseSByZXByZXNlbnQgdGhlIHZpZXdzIGFuZCBvcGluaW9ucyBvZiBD cm9hdGlhbiBUZWxlY29tIEluYy4gQ3JvYXRpYW4gVGVsZWNvbSBJbmMuIGFjY2VwdHMgbm8gbGlh YmlsaXR5IGZvciBhbnkgcG90ZW50aWFsIGRhbWFnZSBjYXVzZWQgYnkgdGhpcyBtZXNzYWdlIGFu ZCBmaWxlcyBhdHRhY2hlZCB0byBpdC4gPC9GT05UPjwvUD4KPC9QPjwvRElWPgo8L2JvZHk+Cjwv aHRtbD4K --_000_786F13AA11E69F4DB2CCA23F7400C2FB01431062S2010EXCH1adloc_--