From internet-drafts@ietf.org Mon Jun 3 06:28:19 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 CC19221F96C6; Mon, 3 Jun 2013 06:28:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.342 X-Spam-Level: X-Spam-Status: No, score=-102.342 tagged_above=-999 required=5 tests=[AWL=0.258, 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 qKOXaUaRsvph; Mon, 3 Jun 2013 06:28:19 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0608821F9649; Mon, 3 Jun 2013 06:28:19 -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: <20130603132806.14025.41176.idtracker@ietfa.amsl.com> Date: Mon, 03 Jun 2013 06:28:06 -0700 Cc: dhcwg@ietf.org Subject: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-solmaxrt-update-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: Mon, 03 Jun 2013 13:28:20 -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 : Modification to Default Value of SOL_MAX_RT Author(s) : Ralph Droms Filename : draft-ietf-dhc-dhcpv6-solmaxrt-update-01.txt Pages : 7 Date : 2013-06-03 Abstract: This document updates RFC 3315 by redefining the default values for SOL_MAX_RT and INF_MAX_RT, and defining options through which a DHCPv6 server can override the client's default value for SOL_MAX_RT and INF_MAX_RT with a new value. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv6-solmaxrt-update There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-solmaxrt-update-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dhc-dhcpv6-solmaxrt-update-01 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From rdroms.ietf@gmail.com Mon Jun 3 06:55: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 0BEDC21F934B for ; Mon, 3 Jun 2013 06:55:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[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 dWkG-kJkF7Cl for ; Mon, 3 Jun 2013 06:55:20 -0700 (PDT) Received: from mail-qc0-x234.google.com (mail-qc0-x234.google.com [IPv6:2607:f8b0:400d:c01::234]) by ietfa.amsl.com (Postfix) with ESMTP id 77C9D21F8E8F for ; Mon, 3 Jun 2013 06:55:20 -0700 (PDT) Received: by mail-qc0-f180.google.com with SMTP id a10so2144036qcx.39 for ; Mon, 03 Jun 2013 06:55:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to:x-mailer; bh=pLl9qceIi7Qbetp0ToR0lbvNHY6yT6pq6Oxj4xdwyXk=; b=EGpOjxef75yLmS+NqqqYtOUulNOikx/dBV16Q0Pk9rZelZT5Ey5EQfcBzTwkTSNW5h UGlI67nqpBjnkHAnrQkUcK1zyk1KE/z4j9/v6CUY/hz2ht8Pu1mnhzqgseQDlo6XUhcU rjj2rIwObEsbgYeEzSzckZLHpBsTMVwPw3I4DDIev5EXwdsFlfG78b8AX1Oq2oj70OEz Ys+4VQEAktSua+cdc4KvDTyWc2QVErzLyvZAXflCB7sMAQTVwoO89X5YhhkmSIckqxAY WBq+oJoTmqWlyO7r00MxuOWfHyMgAqSpCuGHbeK75058FUIuNtPe86YdSXLNT4KsqITS Yx/w== X-Received: by 10.49.128.7 with SMTP id nk7mr21499492qeb.35.1370267719900; Mon, 03 Jun 2013 06:55:19 -0700 (PDT) Received: from ?IPv6:2001:420:2481:20:4122:d767:8b81:2c27? ([2001:420:2481:20:4122:d767:8b81:2c27]) by mx.google.com with ESMTPSA id c7sm45094qaj.5.2013.06.03.06.55.18 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 03 Jun 2013 06:55:19 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Ralph Droms In-Reply-To: <20130603132806.14025.41176.idtracker@ietfa.amsl.com> Date: Mon, 3 Jun 2013 09:55:15 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <2DED259A-9BCB-4D25-B043-84B26F4B1988@gmail.com> References: <20130603132806.14025.41176.idtracker@ietfa.amsl.com> To: dhcwg@ietf.org X-Mailer: Apple Mail (2.1503) Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-solmaxrt-update-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: Mon, 03 Jun 2013 13:55:22 -0000 This revision addresses some of the issues raised during discussion on = the WG mailing list: * added INF_MAX_RT * added text updating RFC 3315: "A client is not expected to listen for = a response during the entire period between transmission of Solicit or = Information-Request messages." The revision does not address these issues: * clarification of semantics of "Elapsed Time" option * send "small integer number" of Solicit and Information-request = messages at max retry time instead of just one I've requested a short slot in the Berlin dhc WG meeting agenda to = discuss the revisions and the remaining issues. - Ralph On Jun 3, 2013, at 9:28 AM 6/3/13, internet-drafts@ietf.org wrote: >=20 > 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. >=20 > Title : Modification to Default Value of SOL_MAX_RT > Author(s) : Ralph Droms > Filename : draft-ietf-dhc-dhcpv6-solmaxrt-update-01.txt > Pages : 7 > Date : 2013-06-03 >=20 > Abstract: > This document updates RFC 3315 by redefining the default values for > SOL_MAX_RT and INF_MAX_RT, and defining options through which a > DHCPv6 server can override the client's default value for SOL_MAX_RT > and INF_MAX_RT with a new value. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv6-solmaxrt-update >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-solmaxrt-update-01 >=20 > A diff from the previous version is available at: > = http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dhc-dhcpv6-solmaxrt-update-0= 1 >=20 >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg From john_brzozowski@cable.comcast.com Mon Jun 3 18:20: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 E7EF721F8FBE for ; Mon, 3 Jun 2013 18:20:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.047 X-Spam-Level: X-Spam-Status: No, score=-101.047 tagged_above=-999 required=5 tests=[AWL=-2.450, BAYES_00=-2.599, HOST_EQ_MODEMCABLE=1.368, IP_NOT_FRIENDLY=0.334, MANGLED_TOOL=2.3, 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 zt+WvLCmWWsL for ; Mon, 3 Jun 2013 18:19:40 -0700 (PDT) Received: from cable.comcast.com (pacdcavout01.cable.comcast.com [69.241.43.119]) by ietfa.amsl.com (Postfix) with ESMTP id 9B01311E8101 for ; Mon, 3 Jun 2013 17:38:15 -0700 (PDT) Received: from ([24.40.56.116]) by pacdcavout01.cable.comcast.com with ESMTP id 97wm3m1.54380068; Mon, 03 Jun 2013 20:35:01 -0400 Received: from PACDCEXHUB04.cable.comcast.com (24.40.56.121) by pacdcexhub03.cable.comcast.com (24.40.56.116) with Microsoft SMTP Server (TLS) id 14.2.318.1; Mon, 3 Jun 2013 20:37:19 -0400 Received: from PACDCEXMB01.cable.comcast.com ([169.254.1.173]) by pacdcexhub04.cable.comcast.com ([fe80::1532:d330:f9a5:c8a1%18]) with mapi id 14.02.0318.001; Mon, 3 Jun 2013 20:37:19 -0400 From: "Brzozowski, John" To: Ralph Droms , "dhcwg@ietf.org" Thread-Topic: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-solmaxrt-update-01.txt Thread-Index: AQHOYLurxydl9nQaH0aioXEX1+BIhg== Date: Tue, 4 Jun 2013 00:37:18 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.4.130416 x-originating-ip: [24.40.55.71] Content-Type: text/plain; charset="us-ascii" Content-ID: <93ED93D52D804740B94AD815A6929E67@cable.comcast.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-solmaxrt-update-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, 04 Jun 2013 01:20:08 -0000 Ralph, Thanks for keeping this document going, one item I noticed in -01: * section 3=20 OLD:=09 INF_MAX_RT 120 secs Max Information-request timeout value=09 =09 NEW:=09 SOL_MAX_RT 3600 secs Max Information-request timeout value [jjmb] shouldn't new refer to INF_MAX_RT? Is the slot in Berlin to simply review the changes from -00 to -01? John =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 John Jason Brzozowski Comcast Cable m) 484-962-0060 o) 609-377-6594 w) www.comcast6.net e) john_brzozowski@cable.comcast.com =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 -----Original Message----- From: Ralph Droms Date: Monday, June 3, 2013 9:55 AM To: dhc WG Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-solmaxrt-update-01.txt >This revision addresses some of the issues raised during discussion on >the WG mailing list: > >* added INF_MAX_RT >* added text updating RFC 3315: "A client is not expected to listen for a >response during the entire period between transmission of Solicit or >Information-Request messages." > >The revision does not address these issues: > >* clarification of semantics of "Elapsed Time" option >* send "small integer number" of Solicit and Information-request messages >at max retry time instead of just one > >I've requested a short slot in the Berlin dhc WG meeting agenda to >discuss the revisions and the remaining issues. > >- Ralph > >On Jun 3, 2013, at 9:28 AM 6/3/13, internet-drafts@ietf.org wrote: > >>=20 >> 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. >>=20 >> Title : Modification to Default Value of SOL_MAX_RT >> Author(s) : Ralph Droms >> Filename : draft-ietf-dhc-dhcpv6-solmaxrt-update-01.txt >> Pages : 7 >> Date : 2013-06-03 >>=20 >> Abstract: >> This document updates RFC 3315 by redefining the default values for >> SOL_MAX_RT and INF_MAX_RT, and defining options through which a >> DHCPv6 server can override the client's default value for SOL_MAX_RT >> and INF_MAX_RT with a new value. >>=20 >>=20 >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv6-solmaxrt-update >>=20 >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-solmaxrt-update-01 >>=20 >> A diff from the previous version is available at: >>=20 >>http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dhc-dhcpv6-solmaxrt-update-= 01 >>=20 >>=20 >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >>=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 wwwrun@rfc-editor.org Wed Jun 5 05:02: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 05B2C21F9476 for ; Wed, 5 Jun 2013 05:02:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.053 X-Spam-Level: X-Spam-Status: No, score=-102.053 tagged_above=-999 required=5 tests=[AWL=0.547, 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 8DGZapfuowbB for ; Wed, 5 Jun 2013 05:02:19 -0700 (PDT) Received: from rfc-editor.org (unknown [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 219DC21F99C5 for ; Wed, 5 Jun 2013 05:02:06 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id C52426210F; Wed, 5 Jun 2013 05:00:34 -0700 (PDT) To: droms@bucknell.edu, brian@innovationslab.net, ted.lemon@nominum.com, volz@cisco.com, tomasz.mrugalski@gmail.com From: RFC Errata System Message-Id: <20130605120038.C52426210F@rfc-editor.org> Date: Wed, 5 Jun 2013 05:00:34 -0700 (PDT) Cc: dhcwg@ietf.org, carpres@gmail.com, rfc-editor@rfc-editor.org Subject: [dhcwg] [Editorial Errata Reported] RFC2131 (3638) 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, 05 Jun 2013 12:02:20 -0000 The following errata report has been submitted for RFC2131, "Dynamic Host Configuration Protocol". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=2131&eid=3638 -------------------------------------- Type: Editorial Reported by: Carlos Prendes Section: Errata 490 Original Text ------------- Section 4.1 says: Normally, DHCP servers and BOOTP relay agents attempt to deliver DHCPOFFER, DHCPACK and DHCPNAK messages directly to the client using uicast delivery. It should say: Normally, DHCP servers and BOOTP relay agents attempt to deliver DHCPOFFER, DHCPACK and DHCPNAK messages directly to the client using uicast delivery. Notes: typo (uicast -> unicast) Corrected Text -------------- Section 4.1 says: Normally, DHCP servers and BOOTP relay agents attempt to deliver DHCPOFFER, DHCPACK and DHCPNAK messages directly to the client using uicast delivery. It should say: Normally, DHCP servers and BOOTP relay agents attempt to deliver DHCPOFFER, DHCPACK and DHCPNAK messages directly to the client using unicast delivery. Notes: typo (uicast -> unicast) Notes ----- The errata is not corrected in the errata correction. 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. -------------------------------------- RFC2131 (no draft string recorded) -------------------------------------- Title : Dynamic Host Configuration Protocol Publication Date : March 1997 Author(s) : R. Droms Category : DRAFT STANDARD Source : Dynamic Host Configuration Area : Internet Stream : IETF Verifying Party : IESG From volz@cisco.com Wed Jun 5 05:20:46 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 1A30921F999A for ; Wed, 5 Jun 2013 05:20:46 -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 eq5gdTbJdpTV for ; Wed, 5 Jun 2013 05:20:41 -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 27E0021F9997 for ; Wed, 5 Jun 2013 05:20:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3137; q=dns/txt; s=iport; t=1370434841; x=1371644441; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=HCbZI45HwguIV2YRcCyqfJxrADWtGDOekE5uFwCfglE=; b=dPq+7vvYbP1xa8/tVtiho37wJ9+nGHftmKL/a3kikqrNBLhDt6z+ASrN oqM/r9dV0hoDkQWvcqRbgnXieMSnxKsXl0Ea8AJ0Fir7UaCD7EgYZw2u/ 2y8JMGNwanYJ7t5qS5iUVGiTQ11nCSHvaYq4464h9Z8dOP2++uEPkmyxx w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgIFALgrr1GtJV2b/2dsb2JhbAA/GoMJML8qfBZ0giMBAQEDAScTPwULAgEINhAhESUCBA4Fh3sDCQYMMrNdDYhOjEmCKDMHgnphA5VYgWeMHYUjgw96 X-IronPort-AV: E=Sophos;i="4.87,806,1363132800"; d="scan'208";a="219025209" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-8.cisco.com with ESMTP; 05 Jun 2013 12:20:40 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r55CKeds009522 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 5 Jun 2013 12:20:40 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, 5 Jun 2013 07:20:39 -0500 From: "Bernie Volz (volz)" To: RFC Errata System Thread-Topic: [Editorial Errata Reported] RFC2131 (3638) Thread-Index: AQHOYeSADm5M3xqWoEGAT72wvXvaPZknCmQT Date: Wed, 5 Jun 2013 12:20:38 +0000 Message-ID: <0A230E5A-A1E8-4BD7-A801-BE88260AC4C2@cisco.com> References: <20130605120038.C52426210F@rfc-editor.org> In-Reply-To: <20130605120038.C52426210F@rfc-editor.org> 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: "brian@innovationslab.net" , "carpres@gmail.com" , "droms@bucknell.edu" , "dhcwg@ietf.org" , "rfc-editor@rfc-editor.org" , "ted.lemon@nominum.com" Subject: Re: [dhcwg] [Editorial Errata Reported] RFC2131 (3638) 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, 05 Jun 2013 12:20:46 -0000 Yes, the one place were uicast is used it should be unicast. The errata loo= ks like it is badly formed as first attempt at old/new does not fix issue a= nd is thus not needed. it should just be: Section 4.1: Original Text ------------- Normally, DHCP servers and BOOTP relay agents attempt to deliver DHCPOFFER, DHCPACK and DHCPNAK messages directly to the client using uicast delivery. Corrected Text -------------- Normally, DHCP servers and BOOTP relay agents attempt to deliver DHCPOFFER, DHCPACK and DHCPNAK messages directly to the client using unicast delivery. This one is kind of obvious and there are no plans to work on a 2131biz. - Bernie (from iPad) On Jun 5, 2013, at 8:02 AM, "RFC Errata System" = wrote: > The following errata report has been submitted for RFC2131, > "Dynamic Host Configuration Protocol". >=20 > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=3D2131&eid=3D3638 >=20 > -------------------------------------- > Type: Editorial > Reported by: Carlos Prendes >=20 > Section: Errata 490 >=20 > Original Text > ------------- > Section 4.1 says: >=20 >=20 >=20 > Normally, DHCP servers and BOOTP relay agents attempt to deliver DHCPOFFE= R, >=20 > DHCPACK and DHCPNAK messages directly to the client using uicast delivery= . >=20 >=20 >=20 > It should say: >=20 >=20 >=20 > Normally, DHCP servers and BOOTP relay agents attempt to deliver DHCPOFFE= R, >=20 > DHCPACK and DHCPNAK messages directly to the client using uicast delivery= . >=20 >=20 >=20 > Notes: >=20 >=20 >=20 > typo (uicast -> unicast)=20 >=20 > Corrected Text > -------------- > Section 4.1 says: >=20 >=20 >=20 > Normally, DHCP servers and BOOTP relay agents attempt to deliver DHCPOFFE= R, >=20 > DHCPACK and DHCPNAK messages directly to the client using uicast delivery= . >=20 >=20 >=20 > It should say: >=20 >=20 >=20 > Normally, DHCP servers and BOOTP relay agents attempt to deliver DHCPOFFE= R, >=20 > DHCPACK and DHCPNAK messages directly to the client using unicast deliver= y. >=20 >=20 >=20 > Notes: >=20 >=20 >=20 > typo (uicast -> unicast)=20 >=20 > Notes > ----- > The errata is not corrected in the errata correction. >=20 > 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.=20 >=20 > -------------------------------------- > RFC2131 (no draft string recorded) > -------------------------------------- > Title : Dynamic Host Configuration Protocol > Publication Date : March 1997 > Author(s) : R. Droms > Category : DRAFT STANDARD > Source : Dynamic Host Configuration > Area : Internet > Stream : IETF > Verifying Party : IESG From praspati@cisco.com Fri Jun 7 05:45:03 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 9E55A21F936E for ; Fri, 7 Jun 2013 05:45:02 -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 1pctwKH6zbw1 for ; Fri, 7 Jun 2013 05:44: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 A177421F92E7 for ; Fri, 7 Jun 2013 05:44:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1756; q=dns/txt; s=iport; t=1370609095; x=1371818695; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=R3TzArVCdVGcPwkuzhRBriOz9mpWpqwJCTyd4Sc3nTQ=; b=Ja5HJHHTKQ+13NVYUqHKOYpIToR5qLc3tlQGVpixHnSfsGRCBPdJOyOp NcKfZuVN4nyTX0j2abuwbP8KGkIOnxs4swFvf9YCMtLmz+y5CzAtBGp+4 79xMBE+w71ry4BZC4cVx7IR10zWPzHgpPBtAJgYAW05tWfWFTValB/0Me U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiIGADTVsVGtJV2Y/2dsb2JhbABZgwkwQ74tfRZtB4IjAQEBBDo9AhIBCCIUQhsBBgMCBA4FCAGIBAcFvEmPBzEHgnthA5hpkBmDD4In X-IronPort-AV: E=Sophos;i="4.87,822,1363132800"; d="scan'208";a="219977188" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-2.cisco.com with ESMTP; 07 Jun 2013 12:44:55 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r57CisgJ011034 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 7 Jun 2013 12:44:55 GMT Received: from xmb-rcd-x07.cisco.com ([169.254.7.39]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.02.0318.004; Fri, 7 Jun 2013 07:44:53 -0500 From: "Prashanth Patil (praspati)" To: "dhcwg@ietf.org" Thread-Topic: New Version Notification for draft-wing-dhc-dns-reconfigure-01.txt Thread-Index: AQHOY3uM9UALGIVfFEmPJoU9Kl4stpkq4qaA Date: Fri, 7 Jun 2013 12:44:53 +0000 Message-ID: In-Reply-To: <20130607123546.18442.28001.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.4.130416 x-originating-ip: [173.39.67.75] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Tirumaleswar Reddy \(tireddy\)" Subject: [dhcwg] FW: New Version Notification for draft-wing-dhc-dns-reconfigure-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: Fri, 07 Jun 2013 12:45:03 -0000 Hi all, This draft proposes a mechanism to extend DHCPv6 such that a DHCPv6 Relay Agent can dynamically influence priority of DNS servers provided to a host, so that a host can use an optimal DNS server for resolution. Regards, Prashanth On 07/06/13 6:05 PM, "internet-drafts@ietf.org" wrote: > >A new version of I-D, draft-wing-dhc-dns-reconfigure-01.txt >has been successfully submitted by Dan Wing and posted to the >IETF repository. > >Filename: draft-wing-dhc-dns-reconfigure >Revision: 01 >Title: DHCPv6 Dynamic DNS Reconfiguration >Creation date: 2013-06-07 >Group: Individual Submission >Number of pages: 8 >URL: =20 >http://www.ietf.org/internet-drafts/draft-wing-dhc-dns-reconfigure-01.txt >Status: =20 >http://datatracker.ietf.org/doc/draft-wing-dhc-dns-reconfigure >Htmlized: =20 >http://tools.ietf.org/html/draft-wing-dhc-dns-reconfigure-01 >Diff: =20 >http://www.ietf.org/rfcdiff?url2=3Ddraft-wing-dhc-dns-reconfigure-01 > >Abstract: > Some networks are expected to support IPv4-only, dual-stack, and > IPV6-only hosts at the same time. This makes prioritizing the DNS > servers for hosts tricky due to a heterogeneous mix of protocol > stacks causing optimal behavior to occur only when the host stack re- > initializes. The networks infrastructure is usually well equipped to > be aware of single/dual-stack nature of hosts. This specification > extends DHCPv6 so that a DHCPv6 Relay Agent can dynamically influence > the priority of DNS servers provided to the host, so that the host > can use an optimal DNS server for resolution. > > =20 > =20 > > >The IETF Secretariat > From mohamed.boucadair@orange.com Fri Jun 7 05:57: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 3FF2421F8CF4 for ; Fri, 7 Jun 2013 05:57:17 -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=[BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 DHyQCW6oT6P8 for ; Fri, 7 Jun 2013 05:57:11 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 4C6A321F84B1 for ; Fri, 7 Jun 2013 05:57:04 -0700 (PDT) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm12.si.francetelecom.fr (ESMTP service) with ESMTP id 02AB118CD4C; Fri, 7 Jun 2013 14:57:00 +0200 (CEST) Received: from puexch31.nanterre.francetelecom.fr (unknown [10.101.44.29]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id D665227C046; Fri, 7 Jun 2013 14:56:59 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.13]) by puexch31.nanterre.francetelecom.fr ([10.101.44.29]) with mapi; Fri, 7 Jun 2013 14:56:59 +0200 From: To: "Prashanth Patil (praspati)" , "dhcwg@ietf.org" Date: Fri, 7 Jun 2013 14:56:57 +0200 Thread-Topic: New Version Notification for draft-wing-dhc-dns-reconfigure-01.txt Thread-Index: AQHOY3uM9UALGIVfFEmPJoU9Kl4stpkq4qaA//9RvbA= Message-ID: <94C682931C08B048B7A8645303FDC9F36ED58ED045@PUEXCB1B.nanterre.francetelecom.fr> References: <20130607123546.18442.28001.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.5.21.113319 Cc: "Tirumaleswar Reddy \(tireddy\)" Subject: Re: [dhcwg] New Version Notification for draft-wing-dhc-dns-reconfigure-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: Fri, 07 Jun 2013 12:57:17 -0000 Hi all, FWIW, more discussion on the problem space can be found here: http://www.ie= tf.org/mail-archive/web/v6ops/current/msg16276.html or http://tools.ietf.or= g/html/draft-kaliwoda-sunset4-dual-ipv6-coexist-01#section-2. draft-wing-* solves this issue for dhcp-enabled networks. Cheers, Med >-----Message d'origine----- >De=A0: Prashanth Patil (praspati) [mailto:praspati@cisco.com] >Envoy=E9=A0: vendredi 7 juin 2013 14:45 >=C0=A0: dhcwg@ietf.org >Cc=A0: Dan Wing (dwing); Tirumaleswar Reddy (tireddy); BOUCADAIR Mohamed >OLNC/OLN >Objet=A0: FW: New Version Notification for draft-wing-dhc-dns-reconfigure- >01.txt > >Hi all, >This draft proposes a mechanism to extend DHCPv6 such that a DHCPv6 Relay >Agent can dynamically influence priority of DNS servers provided to a >host, so that a host can use an optimal DNS server for resolution. > > >Regards, >Prashanth > >On 07/06/13 6:05 PM, "internet-drafts@ietf.org" >wrote: > >> >>A new version of I-D, draft-wing-dhc-dns-reconfigure-01.txt >>has been successfully submitted by Dan Wing and posted to the >>IETF repository. >> >>Filename: draft-wing-dhc-dns-reconfigure >>Revision: 01 >>Title: DHCPv6 Dynamic DNS Reconfiguration >>Creation date: 2013-06-07 >>Group: Individual Submission >>Number of pages: 8 >>URL: >>http://www.ietf.org/internet-drafts/draft-wing-dhc-dns-reconfigure-01.txt >>Status: >>http://datatracker.ietf.org/doc/draft-wing-dhc-dns-reconfigure >>Htmlized: >>http://tools.ietf.org/html/draft-wing-dhc-dns-reconfigure-01 >>Diff: >>http://www.ietf.org/rfcdiff?url2=3Ddraft-wing-dhc-dns-reconfigure-01 >> >>Abstract: >> Some networks are expected to support IPv4-only, dual-stack, and >> IPV6-only hosts at the same time. This makes prioritizing the DNS >> servers for hosts tricky due to a heterogeneous mix of protocol >> stacks causing optimal behavior to occur only when the host stack re- >> initializes. The networks infrastructure is usually well equipped to >> be aware of single/dual-stack nature of hosts. This specification >> extends DHCPv6 so that a DHCPv6 Relay Agent can dynamically influence >> the priority of DNS servers provided to the host, so that the host >> can use an optimal DNS server for resolution. >> >> >> >> >> >>The IETF Secretariat >> From gvithal@gmail.com Sun Jun 9 06:07: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 689CB21F8976 for ; Sun, 9 Jun 2013 06:07: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, 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 ciOyyr7OYLsZ for ; Sun, 9 Jun 2013 06:07:39 -0700 (PDT) Received: from mail-vb0-x22f.google.com (mail-vb0-x22f.google.com [IPv6:2607:f8b0:400c:c02::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 1309921F8546 for ; Sun, 9 Jun 2013 06:07:37 -0700 (PDT) Received: by mail-vb0-f47.google.com with SMTP id x14so3733879vbb.34 for ; Sun, 09 Jun 2013 06:07:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=3zerwuZkxoDenTX7UviGOWPwiIdfZlIr24nJLpxbgVc=; b=a0HFY6Icaqw0tGBMGaqWeU9aGdpSIdBBtFjzfVJGqL0Q7K6WmSEyqSBLBg2jl8vZhC K3BrYsG9PtjrUgvkyLUGF01dKN2zQph6Is+mskwkWZjYgEG2RijaCrNGWigImrTplEdH S6fhmDLWyKtY3uWsQ9VMhoINqjOVBCgDWIBmE3S4k+niOS0tXMfftPL/X3oJgQtOHCps 3AU+4EIS2YADBMfHmeX+z7z5Nd30P/EagL2qinciGH/24/MZcyyEyQOyVNJRZahn7628 q6RX4ZEtlCKKzTBKfZNEFi4fNlHGMbI3laxJ/yhGmhLPhdYdaK1UhwfWRWOkjDYtU62i qf1A== MIME-Version: 1.0 X-Received: by 10.220.161.2 with SMTP id p2mr3336153vcx.72.1370783257381; Sun, 09 Jun 2013 06:07:37 -0700 (PDT) Received: by 10.58.88.8 with HTTP; Sun, 9 Jun 2013 06:07:37 -0700 (PDT) Date: Sun, 9 Jun 2013 18:37:37 +0530 Message-ID: From: "gvithal ." To: "" Content-Type: multipart/alternative; boundary=001a11c1e2401ed31204deb8594a Subject: [dhcwg] Change in server identifier between OFFER and ACK 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, 09 Jun 2013 13:07:39 -0000 --001a11c1e2401ed31204deb8594a Content-Type: text/plain; charset=ISO-8859-1 As per the standard, is it valid scenario for server identifier to change between OFFER and ACK for the same transaction id (i.e. for the same DORA transaction). If the server identifier changes between OFFER and ACK, what is the expected client behaviour. There does not seem to be any text in RFC 2131 related to this scenario. Thanks, Prasad --001a11c1e2401ed31204deb8594a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
As per the standard, is it valid scenario for server ident= ifier to change between OFFER and ACK for the same transaction id (i.e. for= the same DORA transaction).
If the server identifier changes bet= ween OFFER and ACK, what is the expected client behaviour.=A0
There does not seem to be any text in RFC 2131 related to this s= cenario.

Thanks,
Prasa= d
--001a11c1e2401ed31204deb8594a-- From internet-drafts@ietf.org Mon Jun 10 04:46: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 64CD721F8D2B; Mon, 10 Jun 2013 04:46:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.519 X-Spam-Level: X-Spam-Status: No, score=-102.519 tagged_above=-999 required=5 tests=[AWL=0.081, 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 1l53PS9WCFFu; Mon, 10 Jun 2013 04:46:47 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B143421F8CB4; Mon, 10 Jun 2013 04:46:45 -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: <20130610114642.3698.66510.idtracker@ietfa.amsl.com> Date: Mon, 10 Jun 2013 04:46:42 -0700 Cc: dhcwg@ietf.org Subject: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-failover-requirements-05.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, 10 Jun 2013 11:46:53 -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-05.txt Pages : 20 Date : 2013-06-10 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-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dhc-dhcpv6-failover-requireme= nts-05 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From simon.perreault@viagenie.ca Mon Jun 10 05:54: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 D761321F8895 for ; Mon, 10 Jun 2013 05:54:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-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 5nW9nSMay2vF for ; Mon, 10 Jun 2013 05:54:48 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 9828521F843F for ; Mon, 10 Jun 2013 05:54:44 -0700 (PDT) Received: from [IPv6:::1] (unknown [IPv6:2001:660:3001:4012:975:db0c:5b8b:bf26]) by jazz.viagenie.ca (Postfix) with ESMTPSA id E13BD4044B for ; Mon, 10 Jun 2013 08:54:43 -0400 (EDT) Message-ID: <51B5CC92.1030903@viagenie.ca> Date: Mon, 10 Jun 2013 14:54:42 +0200 From: Simon Perreault User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: dhcwg@ietf.org References: <20130607123546.18442.28001.idtracker@ietfa.amsl.com> <94C682931C08B048B7A8645303FDC9F36ED58ED045@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <94C682931C08B048B7A8645303FDC9F36ED58ED045@PUEXCB1B.nanterre.francetelecom.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [dhcwg] New Version Notification for draft-wing-dhc-dns-reconfigure-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: Mon, 10 Jun 2013 12:54:50 -0000 Hmmm... My first reaction was "this is crazy"... The useful nugget in this draft is the host mode detection that is done by the relay and its communication to the server. It applies to much more than just DNS server list prioritization. Why not generalize this a little bit? That is, have the relay send generic messages such as "host A changed from mode X to mode Y" to the server. The server would then decide whatever actions need to be done, such as reconfiguring DNS server lists. Simon Le 2013-06-07 14:56, mohamed.boucadair@orange.com a écrit : > FWIW, more discussion on the problem space can be found here: http://www.ietf.org/mail-archive/web/v6ops/current/msg16276.html or http://tools.ietf.org/html/draft-kaliwoda-sunset4-dual-ipv6-coexist-01#section-2. > > draft-wing-* solves this issue for dhcp-enabled networks. > > Cheers, > Med > >> -----Message d'origine----- >> De : Prashanth Patil (praspati) [mailto:praspati@cisco.com] >> Envoyé : vendredi 7 juin 2013 14:45 >> À : dhcwg@ietf.org >> Cc : Dan Wing (dwing); Tirumaleswar Reddy (tireddy); BOUCADAIR Mohamed >> OLNC/OLN >> Objet : FW: New Version Notification for draft-wing-dhc-dns-reconfigure- >> 01.txt >> >> Hi all, >> This draft proposes a mechanism to extend DHCPv6 such that a DHCPv6 Relay >> Agent can dynamically influence priority of DNS servers provided to a >> host, so that a host can use an optimal DNS server for resolution. >> >> >> Regards, >> Prashanth >> >> On 07/06/13 6:05 PM, "internet-drafts@ietf.org" >> wrote: >> >>> >>> A new version of I-D, draft-wing-dhc-dns-reconfigure-01.txt >>> has been successfully submitted by Dan Wing and posted to the >>> IETF repository. >>> >>> Filename: draft-wing-dhc-dns-reconfigure >>> Revision: 01 >>> Title: DHCPv6 Dynamic DNS Reconfiguration >>> Creation date: 2013-06-07 >>> Group: Individual Submission >>> Number of pages: 8 >>> URL: >>> http://www.ietf.org/internet-drafts/draft-wing-dhc-dns-reconfigure-01.txt >>> Status: >>> http://datatracker.ietf.org/doc/draft-wing-dhc-dns-reconfigure >>> Htmlized: >>> http://tools.ietf.org/html/draft-wing-dhc-dns-reconfigure-01 >>> Diff: >>> http://www.ietf.org/rfcdiff?url2=draft-wing-dhc-dns-reconfigure-01 >>> >>> Abstract: >>> Some networks are expected to support IPv4-only, dual-stack, and >>> IPV6-only hosts at the same time. This makes prioritizing the DNS >>> servers for hosts tricky due to a heterogeneous mix of protocol >>> stacks causing optimal behavior to occur only when the host stack re- >>> initializes. The networks infrastructure is usually well equipped to >>> be aware of single/dual-stack nature of hosts. This specification >>> extends DHCPv6 so that a DHCPv6 Relay Agent can dynamically influence >>> the priority of DNS servers provided to the host, so that the host >>> can use an optimal DNS server for resolution. >>> >>> >>> >>> >>> >>> The IETF Secretariat >>> > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg > From mohamed.boucadair@orange.com Mon Jun 10 06:03: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 4013021F854D for ; Mon, 10 Jun 2013 06:03:42 -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.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 mIlRZng6QCFD for ; Mon, 10 Jun 2013 06:03:38 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id B9E2D21F854E for ; Mon, 10 Jun 2013 06:03:37 -0700 (PDT) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm12.si.francetelecom.fr (ESMTP service) with ESMTP id 6231418C6DD; Mon, 10 Jun 2013 15:03:36 +0200 (CEST) Received: from PUEXCH61.nanterre.francetelecom.fr (unknown [10.101.44.32]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 4176D4C017; Mon, 10 Jun 2013 15:03:36 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.13]) by PUEXCH61.nanterre.francetelecom.fr ([10.101.44.32]) with mapi; Mon, 10 Jun 2013 15:03:36 +0200 From: To: Simon Perreault , "dhcwg@ietf.org" Date: Mon, 10 Jun 2013 15:03:32 +0200 Thread-Topic: [dhcwg] New Version Notification for draft-wing-dhc-dns-reconfigure-01.txt Thread-Index: Ac5l2bVfBuWLwIolTYWkgAKkJ8Py8AAAGHEQ Message-ID: <94C682931C08B048B7A8645303FDC9F36ED58ED4EF@PUEXCB1B.nanterre.francetelecom.fr> References: <20130607123546.18442.28001.idtracker@ietfa.amsl.com> <94C682931C08B048B7A8645303FDC9F36ED58ED045@PUEXCB1B.nanterre.francetelecom.fr> <51B5CC92.1030903@viagenie.ca> In-Reply-To: <51B5CC92.1030903@viagenie.ca> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.5.21.113319 Subject: Re: [dhcwg] New Version Notification for draft-wing-dhc-dns-reconfigure-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: Mon, 10 Jun 2013 13:03:42 -0000 Hi Simon, Do you still think it is a crazy solution? The draft focuses on the DNS since this is the concrete issue to be encount= ered. But, yes I do agree with you sending a generic message characterizing= the connectivity gained by the connected device would be even better than = giving the impression the message is dns-specific. The triggered-reconfigur= e procedure will be similar to what is already described in the draft.=20 Cheers, Med=20 >-----Message d'origine----- >De=A0: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] De la part d= e >Simon Perreault >Envoy=E9=A0: lundi 10 juin 2013 14:55 >=C0=A0: dhcwg@ietf.org >Objet=A0: Re: [dhcwg] New Version Notification for draft-wing-dhc-dns- >reconfigure-01.txt > >Hmmm... My first reaction was "this is crazy"... > >The useful nugget in this draft is the host mode detection that is done >by the relay and its communication to the server. It applies to much >more than just DNS server list prioritization. > >Why not generalize this a little bit? That is, have the relay send >generic messages such as "host A changed from mode X to mode Y" to the >server. The server would then decide whatever actions need to be done, >such as reconfiguring DNS server lists. > >Simon > >Le 2013-06-07 14:56, mohamed.boucadair@orange.com a =E9crit : >> FWIW, more discussion on the problem space can be found here: >http://www.ietf.org/mail-archive/web/v6ops/current/msg16276.html or >http://tools.ietf.org/html/draft-kaliwoda-sunset4-dual-ipv6-coexist- >01#section-2. >> >> draft-wing-* solves this issue for dhcp-enabled networks. >> >> Cheers, >> Med >> >>> -----Message d'origine----- >>> De : Prashanth Patil (praspati) [mailto:praspati@cisco.com] >>> Envoy=E9 : vendredi 7 juin 2013 14:45 >>> =C0 : dhcwg@ietf.org >>> Cc : Dan Wing (dwing); Tirumaleswar Reddy (tireddy); BOUCADAIR Mohamed >>> OLNC/OLN >>> Objet : FW: New Version Notification for draft-wing-dhc-dns-reconfigure= - >>> 01.txt >>> >>> Hi all, >>> This draft proposes a mechanism to extend DHCPv6 such that a DHCPv6 >Relay >>> Agent can dynamically influence priority of DNS servers provided to a >>> host, so that a host can use an optimal DNS server for resolution. >>> >>> >>> Regards, >>> Prashanth >>> >>> On 07/06/13 6:05 PM, "internet-drafts@ietf.org" drafts@ietf.org> >>> wrote: >>> >>>> >>>> A new version of I-D, draft-wing-dhc-dns-reconfigure-01.txt >>>> has been successfully submitted by Dan Wing and posted to the >>>> IETF repository. >>>> >>>> Filename: draft-wing-dhc-dns-reconfigure >>>> Revision: 01 >>>> Title: DHCPv6 Dynamic DNS Reconfiguration >>>> Creation date: 2013-06-07 >>>> Group: Individual Submission >>>> Number of pages: 8 >>>> URL: >>>> http://www.ietf.org/internet-drafts/draft-wing-dhc-dns-reconfigure- >01.txt >>>> Status: >>>> http://datatracker.ietf.org/doc/draft-wing-dhc-dns-reconfigure >>>> Htmlized: >>>> http://tools.ietf.org/html/draft-wing-dhc-dns-reconfigure-01 >>>> Diff: >>>> http://www.ietf.org/rfcdiff?url2=3Ddraft-wing-dhc-dns-reconfigure-01 >>>> >>>> Abstract: >>>> Some networks are expected to support IPv4-only, dual-stack, and >>>> IPV6-only hosts at the same time. This makes prioritizing the DNS >>>> servers for hosts tricky due to a heterogeneous mix of protocol >>>> stacks causing optimal behavior to occur only when the host stack >re- >>>> initializes. The networks infrastructure is usually well equipped >to >>>> be aware of single/dual-stack nature of hosts. This specification >>>> extends DHCPv6 so that a DHCPv6 Relay Agent can dynamically >influence >>>> the priority of DNS servers provided to the host, so that the host >>>> can use an optimal DNS server for resolution. >>>> >>>> >>>> >>>> >>>> >>>> The IETF Secretariat >>>> >> >> _______________________________________________ >> 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 simon.perreault@viagenie.ca Mon Jun 10 06:27: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 A9BCA21F9104 for ; Mon, 10 Jun 2013 06:27:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-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 B-mPwNppYo8j for ; Mon, 10 Jun 2013 06:27:08 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 2293021F86D3 for ; Mon, 10 Jun 2013 06:27:08 -0700 (PDT) Received: from [IPv6:::1] (unknown [IPv6:2001:660:3001:4012:975:db0c:5b8b:bf26]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 6B9C04044B; Mon, 10 Jun 2013 09:27:07 -0400 (EDT) Message-ID: <51B5D429.8020701@viagenie.ca> Date: Mon, 10 Jun 2013 15:27:05 +0200 From: Simon Perreault User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: mohamed.boucadair@orange.com References: <20130607123546.18442.28001.idtracker@ietfa.amsl.com> <94C682931C08B048B7A8645303FDC9F36ED58ED045@PUEXCB1B.nanterre.francetelecom.fr> <51B5CC92.1030903@viagenie.ca> <94C682931C08B048B7A8645303FDC9F36ED58ED4EF@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <94C682931C08B048B7A8645303FDC9F36ED58ED4EF@PUEXCB1B.nanterre.francetelecom.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "dhcwg@ietf.org" Subject: Re: [dhcwg] New Version Notification for draft-wing-dhc-dns-reconfigure-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: Mon, 10 Jun 2013 13:27:09 -0000 Le 2013-06-10 15:03, mohamed.boucadair@orange.com a écrit : > Do you still think it is a crazy solution? I'm at the "it could work" stage. Still far from the "it's a good idea" stage. ;) > The draft focuses on the DNS since this is the concrete issue to be > encountered. But, yes I do agree with you sending a generic message > characterizing the connectivity gained by the connected device would > be even better than giving the impression the message is > dns-specific. The triggered-reconfigure procedure will be similar to > what is already described in the draft. Awesome. Simon From akostur@incognito.com Mon Jun 10 07:00: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 ABD2021F871D for ; Mon, 10 Jun 2013 07:00:04 -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 fCjQyp68EUqY for ; Mon, 10 Jun 2013 07:00:00 -0700 (PDT) Received: from na3sys010aog114.obsmtp.com (na3sys010aog114.obsmtp.com [74.125.245.96]) by ietfa.amsl.com (Postfix) with SMTP id C8DF321F86C0 for ; Mon, 10 Jun 2013 06:59:59 -0700 (PDT) Received: from mail-vc0-f177.google.com ([209.85.220.177]) (using TLSv1) by na3sys010aob114.postini.com ([74.125.244.12]) with SMTP ID DSNKUbXb3rn6XsfdMn+HF35kjr5MnhITWFm5@postini.com; Mon, 10 Jun 2013 06:59:59 PDT Received: by mail-vc0-f177.google.com with SMTP id hv10so4453152vcb.36 for ; Mon, 10 Jun 2013 06:59:58 -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=jHJJ8lefzl1j/Noq3Qy2Lo2y3Ywl8gMIGfz+UWInINc=; b=HKDC2UmEqoYTtxv30WyEn4fLfJWnuuwezAzBsAJe9dLeaGheJRRKJZSJT0w5fdVXig NONAllhZDrHxfvZMzM+8qC/EbJLiqytnNWAt/dKXO0gO0UzTkUvEAuIKhNzmT+NGK/pq tFEfbLMwuc2gnEF8B/wr/B+yVl2TkSz3dF8SZ75uszfT6G1FQfeCBOdksykGtPxlL5v2 hCcWPvpe3b9XVHotiv7Fb59usTFztXGEsQqGSh80JDBVxqBG8JuTptuibW6QwxoiT11G cDYzrlhkCgkdhoqc0Du4FtSOrU22EJ2YUxWEo2P/fXab5zPBlz9PHTJ9tifP9ZFwWv1Y zx1Q== X-Received: by 10.58.214.105 with SMTP id nz9mr5523261vec.58.1370872798241; Mon, 10 Jun 2013 06:59:58 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.58.214.105 with SMTP id nz9mr5523258vec.58.1370872798108; Mon, 10 Jun 2013 06:59:58 -0700 (PDT) Received: by 10.220.182.8 with HTTP; Mon, 10 Jun 2013 06:59:57 -0700 (PDT) In-Reply-To: References: Date: Mon, 10 Jun 2013 06:59:57 -0700 Message-ID: From: Andre Kostur To: "gvithal ." Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQn0LWrSEJO7+0f6YiBhIttEYq1pWf2LWJ1COIBse5EA85PELdBS9VP/53cWbrVMCTfZrNlxJChqLqtzjy/uZZ3iWkLC8eOAP90J8d+2fxk5Ixaipd3fu6LgXD3QSzZWXRvN8mAxeGG8dNPrucT/X7ikwUDphQ== Cc: "" Subject: Re: [dhcwg] Change in server identifier between OFFER and ACK 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, 10 Jun 2013 14:00:05 -0000 I suppose if you looked between the lines hard enough, you can see it in 2131, Section 4.4.1: "Once the DHCPACK message from the server arrives....". From the client perspective, it's not the same server if the Server ID is different. >From a more intuitive standpoint, I would expect the client to ignore it. A server that isn't the one that the client has selected is attempting to answer. Ignore the response. Wait for the normal timeout and rebroadcast your REQUEST in the hopes that the server that you did select answers you. If that server really wanted to give me an address, why didn't I see the OFFER that came from that server? On Sun, Jun 9, 2013 at 6:07 AM, gvithal . wrote: > As per the standard, is it valid scenario for server identifier to change > between OFFER and ACK for the same transaction id (i.e. for the same DORA > transaction). > If the server identifier changes between OFFER and ACK, what is the expected > client behaviour. > There does not seem to be any text in RFC 2131 related to this scenario. > > Thanks, > Prasad > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg > -- Andre Kostur Distinguished Software Architect & Engineer P: 604-678-2864 E: akostur@incognito.com Toll-Free: 1-800-877-1856 F: 604-678-2864 VoIP: sip:864@sip.incognito.com From volz@cisco.com Mon Jun 10 12:55:19 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 BDC8B21F9A22 for ; Mon, 10 Jun 2013 12:55:19 -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 y+3WhX0ynbGX for ; Mon, 10 Jun 2013 12:55:14 -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 A592621F9A23 for ; Mon, 10 Jun 2013 12:55:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=33916; q=dns/txt; s=iport; t=1370894113; x=1372103713; h=from:to:cc:subject:date:message-id:mime-version; bh=eWPLYO1YQ/fYfDEGVY3kFOzTqKcZowmbDw+N2HiAmCU=; b=NMRAPw++mriiw3GsYJ/SnDO0A/qsw8xTkBt16oIzUcpvmNWdq0WwUw/c ZttB0kTfx9k4NJjOCIIoPsShx4KzcGkc5jseVjZkaL3Un8ArmjeIjg61j AwpHp0Gx3LPj1Gb03+OlAHnuOuZ82fwRyd0uPAJAt6FLwbaWiVRhjIWFU 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArEGAHwutlGtJV2b/2dsb2JhbABZgkVEMEm+RIEFFm0HgiMBAQEELUwSARkEAQELFgEGORQJCQEEDgUIiAW5aY8HMQYHgnlhA6kCgw+CJw X-IronPort-AV: E=Sophos;i="4.87,840,1363132800"; d="scan'208,217";a="221049087" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-8.cisco.com with ESMTP; 10 Jun 2013 19:55:12 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r5AJtCYJ032232 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 10 Jun 2013 19:55:12 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.77]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.02.0318.004; Mon, 10 Jun 2013 14:55:12 -0500 From: "Bernie Volz (volz)" To: "dhcwg@ietf.org" Thread-Topic: 2nd Try - draft-ietf-dhc-dhcpv6-stateful-issues-04.txt Thread-Index: Ac5mDwOCm/6nW/ykRcKtRPT2sF6nQQ== Date: Mon, 10 Jun 2013 19:55:11 +0000 Message-ID: <489D13FBFA9B3E41812EA89F188F018E1859B0CF@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.241.52] Content-Type: multipart/alternative; boundary="_000_489D13FBFA9B3E41812EA89F188F018E1859B0CFxmbrcdx04ciscoc_" MIME-Version: 1.0 Cc: "Kim Kinnear \(kkinnear\)" , "Ole Troan \(otroan\)" , "Ralph Droms \(rdroms\)" Subject: [dhcwg] 2nd Try - 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, 10 Jun 2013 19:55:19 -0000 --_000_489D13FBFA9B3E41812EA89F188F018E1859B0CFxmbrcdx04ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable As this is a WG document, I would like some feedback from people about whet= her the proposed change is "valid". I received no feedback or discussion ab= out this Rebind issue. While this technically doesn't change 3315 as 3315 p= ermits a Rebind to return the NoBinding status in the Reply and 18.2.4 neve= r mentions adding 'new' addresses, I think this may well be a valid interpr= etation of what is not said in 18.2.4. To perhaps make the intended change more clear, here's some potential wordi= ng for replacement text of 18.2.4 of RFC 3315. Some text was moved and new = text has + in column 1. This may not be the final text (suggestions to impr= ove greatly welcome). 18.2.4. Receipt of Rebind Messages When the server receives a Rebind message that contains an IA option from a client, it locates the client's binding and verifies that the information in the IA from the client matches the information stored for that client. + If the server finds the addresses in the IA for the client and the server determines that the addresses in the IA are appropriate for the link to which the client's interface is attached according to the server's explicit configuration information, the server SHOULD send back the IA to the client with new lifetimes and T1/T2 times. If the server cannot find a client entry for the IA and the server determines that the addresses in the IA are not appropriate for the link to which the client's interface is attached according to the server's explicit configuration information, the server MAY send a Reply message to the client containing the client's IA, with the lifetimes for the addresses in the IA set to zero. This Reply constitutes an explicit notification to the client that the addresses in the IA are no longer valid. In this situation, if the server does not send a Reply message it silently discards the Rebind message. + If the server cannot find a client entry for the IA and the server determines that the addresses in the IA are appropriate for the link to which the client's interface is attached according to the server's explicit configuration information, and the addresses are not in use, the server MAY assign the addresses to the client and send a Reply message to the client with new lifetimes and 1T1/T2 time for the bindings. If the server cannot assign the addresses to the client, the server returns the IA containing no addresses with a Status Code option set to NoBinding in the Reply message. + Note: A server SHOULD NOT provide additional bindings to the client as the client could accept a Reply from a different server (this is the same issue as in the Discussion under the Rapid Commit option, see section 22.14). The server constructs a Reply message by setting the "msg-type" field to REPLY, and copying the transaction ID from the Rebind message into the transaction-id field. The server MUST include a Server Identifier option containing the server's DUID and the Client Identifier option from the Rebind message in the Reply message. The server includes other options containing configuration information to be returned to the client as described in section 18.2. There are four possible response to a Rebind (note that I'm restricting my = wording here to addresses as that is all RFC 3315 speaks to, but you can re= place "address" with "delegated prefix" for 3633): 1. No response. This is used when the server does not have a record o= f the bindings and cannot determine whether the bindings are on-link. As th= e addresses may be valid, but this server has insufficient information to d= etermine this, it is best it remain silent. If other servers respond, the c= lient will have its information. Otherwise, the client will deal with the i= ssues when the lifetimes expire. 2. Reply with Bindings with 0 lifetimes. This is used when the server= determines that the bindings are not on-link. 3. Reply with NoBinding status code(s) response. This is used when th= e server is unable to assign the addresses requested or the client needs "n= ew" information. As this will cause the client to return to sending Request= , it provides the server another and better chance to provide the client co= mplete information. 4. Reply with updated lifetimes and T1/T2 times. This is when the ser= ver has a record of bindings and they are still valid or is able to assign = what the client already has. Based on other changes to stateful-issues, I'd also indicate that the serve= r MUST pick one of these for ALL of the IA_* options. And, I think the serv= er should pick the lowest numbered respond based on processing each binding= . Note again the server should NOT allocate any "new" addresses to the client= even if its current configuration would dictate as it would not know if th= e client uses this information, UNLESS the server is configured honor Rapid= Commit. If there is new information that should go to the client, the serv= er should either respond as in case 3 above or initiate a Reconfigure of th= e client. - Bernie From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of B= ernie Volz (volz) Sent: Monday, May 13, 2013 2:04 PM To: dhcwg@ietf.org Subject: [dhcwg] draft-ietf-dhc-dhcpv6-stateful-issues-04.txt 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_489D13FBFA9B3E41812EA89F188F018E1859B0CFxmbrcdx04ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

As this is a WG docume= nt, I would like some feedback from people about whether the proposed chang= e is “valid”. I received no feedback or discussion about this R= ebind issue. While this technically doesn’t change 3315 as 3315 permits a Rebind to return the NoBinding status in the Reply = and 18.2.4 never mentions adding ‘new’ addresses, I think this = may well be a valid interpretation of what is not said in 18.2.4.

 

To perhaps make the in= tended change more clear, here’s some potential wording for replaceme= nt text of 18.2.4 of RFC 3315. Some text was moved and new text has + i= n column 1. This may not be the final text (suggestions to improve greatly welcome).

 

18.2.4. Receipt of Rebind Messages=

 

   When the server receives a Rebin= d message that contains an IA option

   from a client, it locates the cl= ient's binding and verifies that the

   information in the IA from the c= lient matches the information stored

   for that client.

 

= +  If the server finds the addresses in the IA for the client and = the

=    server determines that the addresses in the IA are appropriate= for

=    the link to which the client’s interface is attached acc= ording to the

=    server’s explicit configuration information, the server = SHOULD send

=    back the IA to the client with new lifetimes and T1/T2 times.<= o:p>

 

   If the server cannot find a clie= nt entry for the IA and the server

   determines that the addresses in= the IA are not appropriate for the

   link to which the client's inter= face is attached according to the

   server's explicit configuration = information, the server MAY send a

   Reply message to the client cont= aining the client's IA, with the

   lifetimes for the addresses in t= he IA set to zero.  This Reply

   constitutes an explicit notifica= tion to the client that the addresses

   in the IA are no longer valid.&n= bsp; In this situation, if the server does

=    not send a Reply message it silently discards the Rebind messa= ge.

=  

= +  If the server cannot find a client entry for the IA and the ser= ver

=    determines that the addresses in the IA are appropriate for th= e link

=    to which the client’s interface is attached according to= the server’s

=    explicit configuration information, and the addresses are not = in use,

=    the server MAY assign the addresses to the client and send a R= eply

=    message to the client with new lifetimes and 1T1/T2 time for t= he

=    bindings. If the server cannot assign the addresses to the cli= ent,

   the server returns the IA contai= ning no addresses with a Status Code

   option set to NoBinding in the R= eply message.

=  

+  Note: A server SHOULD NOT provide= additional bindings to the client

   as the client could accept a Rep= ly from a different server (this is

   the same issue as in the Discuss= ion under the Rapid Commit option,

   see section 22.14).

 

   The server constructs a Reply me= ssage by setting the "msg-type" field

   to REPLY, and copying the transa= ction ID from the Rebind message into

   the transaction-id field.

 

   The server MUST include a Server= Identifier option containing the

   server's DUID and the Client Ide= ntifier option from the Rebind

   message in the Reply message.

 

   The server includes other option= s containing configuration

   information to be returned to th= e client as described in section

=    18.2.

 

 

There are four possibl= e response to a Rebind (note that I’m restricting my wording here to = addresses as that is all RFC 3315 speaks to, but you can replace “add= ress” with “delegated prefix” for 3633):

1.&n= bsp;      No response. T= his is used when the server does not have a record of the bindings and cann= ot determine whether the bindings are on-link. As the addresses may be vali= d, but this server has insufficient information to determine this, it is best it remain silent. If other serve= rs respond, the client will have its information. Otherwise, the client wil= l deal with the issues when the lifetimes expire.

2.&n= bsp;      Reply with Bin= dings with 0 lifetimes. This is used when the server determines that the bi= ndings are not on-link.

3.&n= bsp;      Reply with NoB= inding status code(s) response. This is used when the server is unable to a= ssign the addresses requested or the client needs “new” informa= tion. As this will cause the client to return to sending Request, it provides the server another and better chance to pr= ovide the client complete information.

4.&n= bsp;      Reply with upd= ated lifetimes and T1/T2 times. This is when the server has a record of bin= dings and they are still valid or is able to assign what the client already= has.

Based on other changes= to stateful-issues, I’d also indicate that the server MUST pick one = of these for ALL of the IA_* options. And, I think the server should pick t= he lowest numbered respond based on processing each binding.

 

Note again the server = should NOT allocate any “new” addresses to the client even if i= ts current configuration would dictate as it would not know if the client u= ses this information, UNLESS the server is configured honor Rapid Commit. If there is new information that should go to the clie= nt, the server should either respond as in case 3 above or initiate a Recon= figure of the client.

 

-&nb= sp;         Bernie

 

From: dhcwg-bo= unces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of Bernie Volz (volz)
Sent: Monday, May 13, 2013 2:04 PM
To: dhcwg@ietf.org
Subject: [dhcwg] draft-ietf-dhc-dhcpv6-stateful-issues-04.txt

 

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_489D13FBFA9B3E41812EA89F188F018E1859B0CFxmbrcdx04ciscoc_-- From tomasz.mrugalski@gmail.com Tue Jun 11 12:28: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 25B9B21F99ED for ; Tue, 11 Jun 2013 12:28:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.401 X-Spam-Level: ** X-Spam-Status: No, score=2.401 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_SUMOF=5] 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 Xk-PHwFKunkg for ; Tue, 11 Jun 2013 12:28:46 -0700 (PDT) Received: from mail-bk0-x233.google.com (mail-bk0-x233.google.com [IPv6:2a00:1450:4008:c01::233]) by ietfa.amsl.com (Postfix) with ESMTP id DD26821F99EC for ; Tue, 11 Jun 2013 12:28:45 -0700 (PDT) Received: by mail-bk0-f51.google.com with SMTP id ji1so3398879bkc.24 for ; Tue, 11 Jun 2013 12:28:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :x-enigmail-version:content-type:content-transfer-encoding; bh=M9mHE5lOmGYat0mW5OmlrZVpQRyk3xhVul/93qeDx8k=; b=0o0yJJeVHD8sVVvDB4sIa5bKAe5A0K+bMuQBMBWe1NQaHenn6DK2SQKLaHqqNJw5OL SpNGK2ATghjlX580vTep4axDvdv7u2LOKMj6dhsSvnjuXkgpi2YZwIE+bW86qqtKthcX /fxylNvRZDfZ7zJyD0OlgE9x83BPs+0/nq+FPWke9Q8gomg9A7bgkq+LSbY65ZgpQFJ7 F9m0vDlbOS5mZ7x4GC+eVAIDKVL2dL9NeIjL3WlQmz/VJE99Exupb+MXIGAK0a9/7Hsc AT82CX7M7vXJmIsyXiwxb3hLJj15IMAUjanRzG+0zzhZSMbxy5KAvyN3xtnluRU2u9pe 8DMg== X-Received: by 10.204.231.197 with SMTP id jr5mr2451989bkb.18.1370978924847; Tue, 11 Jun 2013 12:28:44 -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 jy7sm6364489bkb.6.2013.06.11.12.28.42 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 11 Jun 2013 12:28:43 -0700 (PDT) Message-ID: <51B77A69.7010602@gmail.com> Date: Tue, 11 Jun 2013 21:28:41 +0200 From: Tomek Mrugalski User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: DHC WG X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [dhcwg] Comments on draft-ietf-dhc-dhcpv6-load-balancing-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: Tue, 11 Jun 2013 19:28:47 -0000 As part of my shepherd duties for this document, I did review it. Here are my comments: Abstract: Please remove duplicate "(DHCPv6") in 6th line. Abstract should mention that it extends already defined and well proven mechanism for DHCPv4 to cover DHCPv6. "The same method is proposed to select the target server of a DHCPv6 relay." Not true! The text does not mention relays at all (just in the abstract). See my comments below on relays. Section 1: The load balancing is not really a protocol, as it doesn't send or receive anything on its own, does not define packets or options. It defines certain behaviors. I would recommend to replacing "this protocol" with "this extension". I would like to see a brief text in the Introduction that explains the differences or relation between load balancing and failover. You may put informative reference to draft-ietf-dhc-failover-requirements (currently in IESG) or RFC6853 if you find that useful. It would be good to debunk some common misconceptions (e.g. I have 2 servers => I have high availability, no need for failover!). It would be helpful to add a paragraph in section 1 that gives an very short overview of the mechanims specified in RFC3074. Something along the lines: "As a convenience for the user, we mention here that the servers supporting load balancing calculate hash values for service transaction id (or STID), which are client-specific values (client-id for DHCPv6 and client-id or chaddr field for DHCPv4) for each incoming packet. Calculated value is then segregated to specific bucket. Two or more servers are configured to serve certain buckets." Section 2 is not precise enough. Please explicitly say which packets are load balanced and say that others are not. There are more packet types in DHCPv6 than there are in DHCPv4. Couple tricky examples to consider: LEASEQUERY (RFC5007), BOOTREQUESTV6 (draft-ietf-dhc-dhcpv4-over-dhcpv6-00), RELAY-FORW, RECONFIGURE-REQUEST etc. The text should be clear that the packets received over TCP (see RFC5007) are not load-balanced (or at that only the packets coming from the client are load balanced). This is tricky, because some consider requestor (see RFC5007) as special type of a client, so please word your text carefully. Section 3.1.1 says that the server should respond. I don't like the "respond" word. RFC3315 has many cases when invalid packets should be discarded. That would introduce a conflicting requirements. It is much better to say "process" here. Section 3.1.2: A question about "A DHCPv6 server receiving a REQUEST or RENEW with the server's Server ID specified MAY answer the request even if the request would normally be ignored by load balancing.". Does it mean that the opposite is true - server MAY chose to not answer if the load balancing says so, even when server-id matches? That's what rest of the first paragraph suggests. If that is what you meant, then I strongly oppose. Here's why: The text mentions a case of 2 servers, with the first one going offline and the second server taking over all clients. The text says that once the first server recovers and the second server ignores RENEWs, eventually the first server will be able to respond clients that start REBINDing. This will cause the clients to constantly go through REQUEST->failed RENEW attempts->REBIND cycles, even when both servers are fine. Nothing really gained, but you just introduced REBINDs to perfectly healthy network (with the extra processing needed for REBINDs and possible warnings all around, as REBIND is usually a sign of troubles). Section 3.2 mentions STID, but that acronym is not explained. Please at least refer to RFC3074. There are packets where client-id is optional: INFORMATION-REQUEST. Although my understanding is that it is rare (I'm aware of only one implementation - Dibbler - that does that and only if explicitly configured to do so), such a case of "anonymous" INFORMATION-REQUEST is perfectly valid. The text does not explain what to do in such a case. If you don't have any other preference, I would recommend to assign such packets to the first bucket. Security considerations section is nice, but not sufficient. You also mention that by misconfiguring HBA, administrators can fail to service certain group of users and finding a pattern in such a group would be difficult. As a practical aspect, debugging off-by-1 issues would be tricky e.g. first server handles 1-127 and the second handles 128-255 (who is serving bucket 0?). Some warning about it - that the sum of all Hash Bucket Assignments of all servers must cover the whole range - would be useful. Another concern that security considerations is missing is misconfiguration between relays and servers. If you do load balancing on relays, then you should not do another one on servers. And if you do, you just increase you chances to make configuration error, because load balancing configuration on relays must match load balancing configuration on servers. It would be good to have some trade-offs discussed for LB done on servers vs on relays. And speaking of relays, RFC3074 mentions a mechanism for DHCPv4 relays to do load balancing and sending the packets to specific servers only. This draft mentions relay in the abstract only, but not in the text. As a potential implementor, I'm confused - how should DHCPv6 relays do LB? They work radically different than in DHCPv4. A separate chapter explaining that would be very useful. Finally, I'm not sure if updates 3074 is needed here. Nothing in 3074 is changed - the DHCPv4 load balancing works exactly the same as before. I would argue that your draft updates 3315, as it changes some of the behaviors defined there. 3315 says that server responds in certain cases, but your drafts says that the server does not. Changing existing behavior constitutes an update in my opinion. There are some idnits issues. Please run your draft through idnits tool (http://tools.ietf.org/tools/idnits/) and make sure it is clean. IESG frowns upon drafts that have idnits issues. Please update the draft and upload -01. Depending on the scope of changes, we'll see what the next steps will be. (write-up and send out to IESG or quick WGLC to confirm changes if they are large). Hope that helps, Tomek From otroan@employees.org Wed Jun 12 04:31: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 837A121F9A57 for ; Wed, 12 Jun 2013 04:31:25 -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=[AWL=0.000, 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 Hx+6K2pFDjqj for ; Wed, 12 Jun 2013 04:31:24 -0700 (PDT) Received: from banjo.employees.org (banjo.employees.org [IPv6:2001:1868:205::19]) by ietfa.amsl.com (Postfix) with ESMTP id 870C221F9BFD for ; Wed, 12 Jun 2013 04:31:24 -0700 (PDT) Received: from dhcp-10-61-111-155.cisco.com (64-103-25-233.cisco.com [64.103.25.233]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: otroan) by banjo.employees.org (Postfix) with ESMTPSA id 469DE5E97 for ; Wed, 12 Jun 2013 04:31:23 -0700 (PDT) From: Ole Troan Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 12 Jun 2013 13:31:21 +0200 References: <20130612112504.2403.22751.idtracker@ietfa.amsl.com> To: "dhcwg@ietf.org WG" Message-Id: <32536718-0436-4463-A54F-92D484E09B1D@employees.org> Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) X-Mailer: Apple Mail (2.1508) Subject: [dhcwg] Fwd: New Version Notification for draft-troan-dhc-dhcpv4osw-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, 12 Jun 2013 11:31:25 -0000 I've just posted a one pager on how I think DHCPv4 over IPv4 over IPv6 = tunnels can work. this is the solution "DHCPv4oSW" in = http://tools.ietf.org/html/draft-ietf-dhc-v4configuration-01 I wrote this largely for myself to try to understand why we couldn't run = DHCPv4 over the tunnel just like any other link-layer. please let me know what I've missed. cheers, Ole Begin forwarded message: > From: > Subject: New Version Notification for draft-troan-dhc-dhcpv4osw-00.txt > Date: June 12, 2013 13:25:04 GMT+02:00 > To: Ole Troan > Message-Id: <20130612112504.2403.22751.idtracker@ietfa.amsl.com> >=20 >=20 > A new version of I-D, draft-troan-dhc-dhcpv4osw-00.txt > has been successfully submitted by Ole Troan and posted to the > IETF repository. >=20 > Filename: draft-troan-dhc-dhcpv4osw > Revision: 00 > Title: DHCPv4 over A+P softwires > Creation date: 2013-06-12 > Group: Individual Submission > Number of pages: 4 > URL: = http://www.ietf.org/internet-drafts/draft-troan-dhc-dhcpv4osw-00.txt > Status: = http://datatracker.ietf.org/doc/draft-troan-dhc-dhcpv4osw > Htmlized: = http://tools.ietf.org/html/draft-troan-dhc-dhcpv4osw-00 >=20 >=20 > Abstract: > A node getting IPv4 access via an A+P mechanism might need other = IPv4 > configuration information. This memo describes how DHCPv4 is > supported, on IPv4 over IPv6 tunnels with shared IPv4 addresses. >=20 >=20 >=20 >=20 > The IETF Secretariat >=20 From Ted.Lemon@nominum.com Wed Jun 12 05:39: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 C1FDB21F99E2 for ; Wed, 12 Jun 2013 05:39:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.62 X-Spam-Level: X-Spam-Status: No, score=-106.62 tagged_above=-999 required=5 tests=[AWL=-0.021, 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 Qqtyl6C+XfsO for ; Wed, 12 Jun 2013 05:39:00 -0700 (PDT) Received: from exprod7og106.obsmtp.com (exprod7og106.obsmtp.com [64.18.2.165]) by ietfa.amsl.com (Postfix) with ESMTP id ACB4521F9B8F for ; Wed, 12 Jun 2013 05:38:59 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob106.postini.com ([64.18.6.12]) with SMTP ID DSNKUbhr4jmQHF/7Rlc1cjJNLHVCJnVKy5oy@postini.com; Wed, 12 Jun 2013 05:38:59 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 495D31B81FC for ; Wed, 12 Jun 2013 05:38:58 -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 42AF819005D; Wed, 12 Jun 2013 05:38:58 -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, 12 Jun 2013 05:38:58 -0700 From: Ted Lemon To: Ole Troan Thread-Topic: [dhcwg] New Version Notification for draft-troan-dhc-dhcpv4osw-00.txt Thread-Index: AQHOZ2nOn4iVMOtK/kmX7s4CaSrQGw== Date: Wed, 12 Jun 2013 12:38:58 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B6307751D2B11@mbx-01.win.nominum.com> References: <20130612112504.2403.22751.idtracker@ietfa.amsl.com> <32536718-0436-4463-A54F-92D484E09B1D@employees.org> In-Reply-To: <32536718-0436-4463-A54F-92D484E09B1D@employees.org> 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 WG" Subject: Re: [dhcwg] New Version Notification for draft-troan-dhc-dhcpv4osw-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, 12 Jun 2013 12:39:06 -0000 A few obvious things: - You should note that DHCP servers need to be modified to return packets t= o the source port rather than the port defined in RFC2131, bearing in mind = the complication that DHCP servers return packets to a different port depen= ding on whether they think they are talking to a relay or a client. An ex= isting DHCP server will always return the DHCP packet to port 68 if it's a = direct communication to the client, regardless of the source port the clien= t used, and may indeed drop DHCP packets with bogus source ports. - Is it in fact the case that IPv4-in-IPv6 tunnels will work before the CE = IPv4 address is known? - Does the BR have a way to tell over which tunnel a packet arrived, in the= case that the unspecified address is used? What does it use to identify = the tunnel in option 82=97a new option containing the IPv6 address of the C= E tunnel endpoint? - DHCP often uses option 82 to determine information about the client; does= the BR need to act as an L2 relay in the case that the client unicasts its= request to the DHCP server? I guess the main reaction I have to this document is disquiet. RFC2131 wa= s issued before the IETF got really serious about normative language and co= nsistency, and it has some inconsistencies that have never been resolved, _= particularly_ with regard to the handling of DHCPINFORM and unicast exchang= es with the DHCP server. There is a lot of existing practice that is not = documented anywhere. The best I can say about what you are proposing here= is that the behavior of the agents on the network is likely to be unpredic= table, because you are building this on a foundation of sand. Weirdly, I think that both DHCPv4overIPv6 and DHCPv4overDHCPv6 have the vir= tue of being so _different_ in their underlying transport that these issues= don't arise: the complete path from the client to the server has to be re-= specified and re-implemented, and there's no possibility of code reuse, so = no possibility that the reused code will have unexpected behaviors. I think writing this up is a useful effort, but getting this to the point w= here it is really solid and accounts for all the edge cases is going to be = a lot of work=97it's vastly underspecified at the moment, as I'm sure you'r= e aware. Is it really worth the working group's time to go through the ef= fort of making this into a solid document? From ian.farrer@telekom.de Wed Jun 12 05:43: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 6719321F9C06 for ; Wed, 12 Jun 2013 05:43:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[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 EpNJrMOvoqkw for ; Wed, 12 Jun 2013 05:43:31 -0700 (PDT) Received: from tcmail43.telekom.de (tcmail43.telekom.de [80.149.113.173]) by ietfa.amsl.com (Postfix) with ESMTP id 6303421F9A5E for ; Wed, 12 Jun 2013 05:43:31 -0700 (PDT) Received: from he113445.emea1.cds.t-internal.com ([10.134.93.105]) by tcmail41.telekom.de with ESMTP/TLS/AES128-SHA; 12 Jun 2013 14:43:29 +0200 Received: from HE111643.EMEA1.CDS.T-INTERNAL.COM ([10.134.93.12]) by HE113445.emea1.cds.t-internal.com ([::1]) with mapi; Wed, 12 Jun 2013 14:43:28 +0200 From: To: , Date: Wed, 12 Jun 2013 14:43:49 +0200 Thread-Topic: [dhcwg] Fwd: New Version Notification for draft-troan-dhc-dhcpv4osw-00.txt Thread-Index: Ac5nam/rXROCYxg3RQe22m3H+Wmd+g== Message-ID: In-Reply-To: <32536718-0436-4463-A54F-92D484E09B1D@employees.org> 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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dhcwg] Fwd: New Version Notification for draft-troan-dhc-dhcpv4osw-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, 12 Jun 2013 12:43:36 -0000 Hi Ole, Thanks for writing that one up. A few observations: 1, From a BR implementation perspective, this changes the forwarding logic a little: I.e. If there is a valid MAP rule for the packet then forward, if there is no valid MAP rule and the encapsulated SRC is 0.0.0.0/port 67 then relay else drop. Does this cause any implementation problems? 2, The DHCP client will need to reconfigure the port that it is working on dynamically throughout its lifecycle. I.e: the initial allocation process is sourced from port 67, but then it needs to reconfigure itself to be sourced from a valid port allocated to the client. This may change 3, One thing that I think needs to be considered - If the client successfully gets configured, then the BR forwarding is broken - I.e there is no corresponding MAP rule in the BR based on the dynamic address allocation that the BR has relayed. This needs to be considered as part of this as even unicast based renew messages necessary for maintaining the lease don't work. The obvious way that this would be resolved is that the BR would dynamically build its mapping rules based on snooping the contents of the DHCP responses from the server. There is an additional consideration about spoofing DHCP replies and DOSing the BR in this case. 4, One technical clarification on page 2 - A DHCPv4 client communicates directly with the DHCPv4 server after it has acquired addresses. That requires that the DHCPv4 server supports clients using a different UDP port than 68. Surely, this should be port 67? 5, I'm not sure if you're advocating that this is the best way to tackle the config problem or if it's just fleshing out the solution so that it can be properly considered within draft-ietf-dhc-v4configuration (without changing the published conclusion). Cheers, Ian On 12/06/2013 13:31, "Ole Troan" wrote: >I've just posted a one pager on how I think DHCPv4 over IPv4 over IPv6 >tunnels can work. >this is the solution "DHCPv4oSW" in >http://tools.ietf.org/html/draft-ietf-dhc-v4configuration-01 > >I wrote this largely for myself to try to understand why we couldn't run >DHCPv4 over the tunnel >just like any other link-layer. > >please let me know what I've missed. > >cheers, >Ole > > >Begin forwarded message: > >> From: >> Subject: New Version Notification for draft-troan-dhc-dhcpv4osw-00.txt >> Date: June 12, 2013 13:25:04 GMT+02:00 >> To: Ole Troan >> Message-Id: <20130612112504.2403.22751.idtracker@ietfa.amsl.com> >>=20 >>=20 >> A new version of I-D, draft-troan-dhc-dhcpv4osw-00.txt >> has been successfully submitted by Ole Troan and posted to the >> IETF repository. >>=20 >> Filename: draft-troan-dhc-dhcpv4osw >> Revision: 00 >> Title: DHCPv4 over A+P softwires >> Creation date: 2013-06-12 >> Group: Individual Submission >> Number of pages: 4 >> URL: =20 >>http://www.ietf.org/internet-drafts/draft-troan-dhc-dhcpv4osw-00.txt >> Status: =20 >>http://datatracker.ietf.org/doc/draft-troan-dhc-dhcpv4osw >> Htmlized: http://tools.ietf.org/html/draft-troan-dhc-dhcpv4osw-00 >>=20 >>=20 >> Abstract: >> A node getting IPv4 access via an A+P mechanism might need other IPv4 >> configuration information. This memo describes how DHCPv4 is >> supported, on IPv4 over IPv6 tunnels with shared IPv4 addresses. >>=20 >>=20 >>=20 >>=20 >> The IETF Secretariat >>=20 > >_______________________________________________ >dhcwg mailing list >dhcwg@ietf.org >https://www.ietf.org/mailman/listinfo/dhcwg From otroan@employees.org Wed Jun 12 06:25: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 ADDEA21F853A for ; Wed, 12 Jun 2013 06:25:49 -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 xgvVoLDRvocT for ; Wed, 12 Jun 2013 06:25:43 -0700 (PDT) Received: from ams-iport-4.cisco.com (ams-iport-4.cisco.com [144.254.224.147]) by ietfa.amsl.com (Postfix) with ESMTP id 894C221F995C for ; Wed, 12 Jun 2013 06:25:43 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjUFAEZ2uFGQ/khM/2dsb2JhbABPCoMJv1GBABZ0giMBAQEDAXcCBQsLRlcGiBsGuXGOB4EJMweCf2EDqQKDETo X-IronPort-AV: E=Sophos;i="4.87,852,1363132800"; d="scan'208";a="14647152" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-4.cisco.com with ESMTP; 12 Jun 2013 13:25:42 +0000 Received: from dhcp-10-61-96-45.cisco.com (dhcp-10-61-96-45.cisco.com [10.61.96.45]) by ams-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r5CDPddK019752 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 12 Jun 2013 13:25:40 GMT Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Ole Troan In-Reply-To: <8D23D4052ABE7A4490E77B1A012B6307751D2B11@mbx-01.win.nominum.com> Date: Wed, 12 Jun 2013 15:25:39 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <6D7079F4-2D1F-468E-B052-695E94F1D26B@employees.org> References: <20130612112504.2403.22751.idtracker@ietfa.amsl.com> <32536718-0436-4463-A54F-92D484E09B1D@employees.org> <8D23D4052ABE7A4490E77B1A012B6307751D2B11@mbx-01.win.nominum.com> To: Ted Lemon X-Mailer: Apple Mail (2.1508) Cc: "dhcwg@ietf.org WG" Subject: Re: [dhcwg] New Version Notification for draft-troan-dhc-dhcpv4osw-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, 12 Jun 2013 13:25:49 -0000 Ted, thanks for the expedient review!=20 > A few obvious things: >=20 > - You should note that DHCP servers need to be modified to return = packets to the source port rather than the port defined in RFC2131, = bearing in mind the complication that DHCP servers return packets to a = different port depending on whether they think they are talking to a = relay or a client. An existing DHCP server will always return the DHCP = packet to port 68 if it's a direct communication to the client, = regardless of the source port the client used, and may indeed drop DHCP = packets with bogus source ports. yes, the draft says: "A DHCPv4 client communicates directly with the DHCPv4 server after = it has acquired addresses. That requires that the DHCPv4 server supports clients using a different UDP port than 68." > - Is it in fact the case that IPv4-in-IPv6 tunnels will work before = the CE IPv4 address is known? I can't think of a reason why they wouldn't work. > - Does the BR have a way to tell over which tunnel a packet arrived, = in the case that the unspecified address is used? What does it use to = identify the tunnel in option 82=97a new option containing the IPv6 = address of the CE tunnel endpoint? yes. and probably also the source UDP port. > - DHCP often uses option 82 to determine information about the client; = does the BR need to act as an L2 relay in the case that the client = unicasts its request to the DHCP server? I wouldn't think so. given a port aware DHCPv4 server, then DHCP can run = directly between client and server, as soon as the initial bootstrap is = done. > I guess the main reaction I have to this document is disquiet. = RFC2131 was issued before the IETF got really serious about normative = language and consistency, and it has some inconsistencies that have = never been resolved, _particularly_ with regard to the handling of = DHCPINFORM and unicast exchanges with the DHCP server. There is a lot = of existing practice that is not documented anywhere. The best I can = say about what you are proposing here is that the behavior of the agents = on the network is likely to be unpredictable, because you are building = this on a foundation of sand. good to know! ;-) > Weirdly, I think that both DHCPv4overIPv6 and DHCPv4overDHCPv6 have = the virtue of being so _different_ in their underlying transport that = these issues don't arise: the complete path from the client to the = server has to be re-specified and re-implemented, and there's no = possibility of code reuse, so no possibility that the reused code will = have unexpected behaviors. that's also the argument against these mechanisms, that they are = essentially new protocols. do we really have to spend so much time and resources to support = sunsetting of IPv4? should we? > I think writing this up is a useful effort, but getting this to the = point where it is really solid and accounts for all the edge cases is = going to be a lot of work=97it's vastly underspecified at the moment, as = I'm sure you're aware. Is it really worth the working group's time to = go through the effort of making this into a solid document? the benefits of this is that it is well understood, and with regards to = your concerns about building on sand. it is a reasonably closed and controlled environment. the DHCPv4 client = runs on a CPE (that will have to be updated for this), the relay and = server runs under the control of the ISP. and all of those needs to be = touched and tested for this. it isn't like you can connect an unsuspecting DHCP client here (well, = I'm sure you can... ;-)) cheers, Ole= From otroan@employees.org Wed Jun 12 06:35: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 0F4B221F9A33 for ; Wed, 12 Jun 2013 06:35:29 -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 VE0jNfDhY4jM for ; Wed, 12 Jun 2013 06:35:23 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id DD51021F9A3F for ; Wed, 12 Jun 2013 06:35:18 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjYFACt4uFGQ/khN/2dsb2JhbABZgwm/UYEAFnSCIwEBAQMBOj0CBQsLRlcGLodtBrl5jxAzBxaCaWEDkE2YNYMROg X-IronPort-AV: E=Sophos;i="4.87,852,1363132800"; d="scan'208";a="155252982" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-1.cisco.com with ESMTP; 12 Jun 2013 13:35:17 +0000 Received: from dhcp-10-61-96-45.cisco.com (dhcp-10-61-96-45.cisco.com [10.61.96.45]) by ams-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r5CDZD7h030279 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 12 Jun 2013 13:35:15 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Ole Troan In-Reply-To: Date: Wed, 12 Jun 2013 15:35:13 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <81240250-048D-44FF-80DF-CC804C65C3C1@employees.org> References: To: X-Mailer: Apple Mail (2.1508) Cc: dhcwg@ietf.org Subject: Re: [dhcwg] Fwd: New Version Notification for draft-troan-dhc-dhcpv4osw-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, 12 Jun 2013 13:35:29 -0000 Ian, > 1, =46rom a BR implementation perspective, this changes the forwarding = logic > a little: I.e. If there is a valid MAP rule for the packet then = forward, > if there is no valid MAP rule and the encapsulated SRC is 0.0.0.0/port = 67 > then relay else drop. Does this cause any implementation problems? I haven't looked at the code, but it is in theory no different than the = normal UDP helper. > 2, The DHCP client will need to reconfigure the port that it is = working on > dynamically throughout its lifecycle. I.e: the initial allocation = process > is sourced from port 67, but then it needs to reconfigure itself to be > sourced from a valid port allocated to the client. This may change yes, the port will change. the source port must be in the DHCP binding. > 3, One thing that I think needs to be considered - If the client > successfully gets configured, then the BR forwarding is broken - I.e = there > is no corresponding MAP rule in the BR based on the dynamic address > allocation that the BR has relayed. This needs to be considered as = part of > this as even unicast based renew messages necessary for maintaining = the > lease don't work. yes, but this is no different than the DHCP server giving out an address = to a client, which there is no routing for in the network. configuration error. don't do it. ;-) > The obvious way that this would be resolved is that the BR would > dynamically build its mapping rules based on snooping the contents of = the > DHCP responses from the server. There is an additional consideration = about > spoofing DHCP replies and DOSing the BR in this case. yes, in this case snooping could definitely work. > 4, One technical clarification on page 2 - >=20 > A DHCPv4 client communicates directly with the DHCPv4 server after it > has acquired addresses. That requires that the DHCPv4 server > supports clients using a different UDP port than 68. >=20 > Surely, this should be port 67? doesn't the client use source port 68? so that source port has to be allocated from the port range. while the = well-known server port can stay unchanged and fixed at 67. > 5, I'm not sure if you're advocating that this is the best way to = tackle > the config problem or if it's just fleshing out the solution so that = it > can be properly considered within draft-ietf-dhc-v4configuration = (without > changing the published conclusion). I'm not either. I'm probably mostly advocating that only DHCPv6 should = be used, and all services that otherwise would need IPv4 configuration information should run on IPv6. but then I'm = known to be disconnected from reality too. ;-) cheers, Ole= From otroan@employees.org Wed Jun 12 06:37: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 7007421F9C25 for ; Wed, 12 Jun 2013 06:37:15 -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 30thFHLmSa-L for ; Wed, 12 Jun 2013 06:37:09 -0700 (PDT) Received: from ams-iport-4.cisco.com (ams-iport-4.cisco.com [144.254.224.147]) by ietfa.amsl.com (Postfix) with ESMTP id 5BD0A21F9A3D for ; Wed, 12 Jun 2013 06:37:09 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjUFAKx4uFGQ/khN/2dsb2JhbABZgwm/UYEAFnSCIwEBAQMBOj0CBQsLRlcGiBsGuXyPEDMHgn9hA6kCgxE6 X-IronPort-AV: E=Sophos;i="4.87,852,1363132800"; d="scan'208";a="14647468" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-4.cisco.com with ESMTP; 12 Jun 2013 13:37:08 +0000 Received: from dhcp-10-61-96-45.cisco.com (dhcp-10-61-96-45.cisco.com [10.61.96.45]) by ams-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r5CDb53U030755 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 12 Jun 2013 13:37:06 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Ole Troan In-Reply-To: <786F13AA11E69F4DB2CCA23F7400C2FB01466694@S2010EXCH1.ad.local> Date: Wed, 12 Jun 2013 15:37:05 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <534E5AD0-8C85-4116-9C3F-E555DDAAAEF5@employees.org> References: <20130612112504.2403.22751.idtracker@ietfa.amsl.com> <32536718-0436-4463-A54F-92D484E09B1D@employees.org> <786F13AA11E69F4DB2CCA23F7400C2FB01466694@S2010EXCH1.ad.local> To: Branimir Rajtar X-Mailer: Apple Mail (2.1508) Cc: "dhcwg@ietf.org WG" Subject: Re: [dhcwg] Fwd: New Version Notification for draft-troan-dhc-dhcpv4osw-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, 12 Jun 2013 13:37:15 -0000 Branimir, > I sam Ted and Ian already posted some comments, but I have an = additional one: >=20 > If the BR works in DHCP relay mode, at the initial communication it = will have to check if the source UDP port is 68 (given the source = address is 0.0.0.0) and perform the relaying function. This is basically = DPI and would have to be implemented in hardware for it to work = efficiently... If you work in an virtualized environment, I expect it = would slow down the BR. >=20 > This is an observation which I think would be worthwhile to include in = the draft - comparing to other approaches, the BR will either be more = expensive or lacking in performance. absolutely correct. I didn't include it, since that's how all DHCP = relays work today on other link-layers too. you may argue the finer point that listening to broadcast for a packet = to yourself isn't DPI. ;-) cheers, Ole= From Ted.Lemon@nominum.com Wed Jun 12 06:57: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 74C6821F9BEE for ; Wed, 12 Jun 2013 06:57:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.319 X-Spam-Level: X-Spam-Status: No, score=-106.319 tagged_above=-999 required=5 tests=[AWL=-0.320, BAYES_00=-2.599, J_CHICKENPOX_53=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 6v-gAyuJ4kGZ for ; Wed, 12 Jun 2013 06:57:18 -0700 (PDT) Received: from exprod7og115.obsmtp.com (exprod7og115.obsmtp.com [64.18.2.217]) by ietfa.amsl.com (Postfix) with ESMTP id DB2F721F9B27 for ; Wed, 12 Jun 2013 06:57:17 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob115.postini.com ([64.18.6.12]) with SMTP ID DSNKUbh+PajMWV4Bey1yUdTZlw84S2S1NPw/@postini.com; Wed, 12 Jun 2013 06:57: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 77FC81B81D2 for ; Wed, 12 Jun 2013 06:57:17 -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 695FB19005D; Wed, 12 Jun 2013 06:57:17 -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, 12 Jun 2013 06:57:11 -0700 From: Ted Lemon To: Ole Troan Thread-Topic: [dhcwg] New Version Notification for draft-troan-dhc-dhcpv4osw-00.txt Thread-Index: AQHOZ3BYRHWLt3q4GkSeFfzv/hNWD5kyj/CA Date: Wed, 12 Jun 2013 13:57:12 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B6307751D2ECF@mbx-01.win.nominum.com> References: <20130612112504.2403.22751.idtracker@ietfa.amsl.com> <32536718-0436-4463-A54F-92D484E09B1D@employees.org> <8D23D4052ABE7A4490E77B1A012B6307751D2B11@mbx-01.win.nominum.com> <6D7079F4-2D1F-468E-B052-695E94F1D26B@employees.org> In-Reply-To: <6D7079F4-2D1F-468E-B052-695E94F1D26B@employees.org> 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: <08D5D90E6C111F4980AC0DB932D55796@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dhcwg@ietf.org WG" Subject: Re: [dhcwg] New Version Notification for draft-troan-dhc-dhcpv4osw-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, 12 Jun 2013 13:57:34 -0000 On Jun 12, 2013, at 9:25 AM, Ole Troan wrote: >> - Is it in fact the case that IPv4-in-IPv6 tunnels will work before the = CE IPv4 address is known? > I can't think of a reason why they wouldn't work. Essentially now you have a half-built tunnel that works one way when you do= n't have an IP address, and possibly a different way when you do. Where is= the RFC that describes how this tunnel works? Suppose I send an IP addre= ss down the tunnel with a destination of 255.255.255.255: how does the rout= ing for that packet work? It's certainly true that we can intuit how it o= ught to work, but the question is, is there a specification that says how i= t works, or are you relying on the implementor's intuition? > that's also the argument against these mechanisms, that they are essentia= lly new protocols. > do we really have to spend so much time and resources to support sunsetti= ng of IPv4? should we? This is an argument in favor of dropping all the work softwire is currently= doing, and has done. Stateless 4over6 and DSlite both require substantial= implementation work for what is essentially a temporary technology. Furthermore, either you are reusing existing technology with dhcpv4osw, or = you are writing a new protocol. If you are reusing existing technology, t= hen the argument that you are building this on a foundation of sand applies= . If you are writing a new protocol, then the argument you raise above do= es not apply, because dhcpv4osw is notionally exactly the same as the other= two alternatives, only much more complicated to specify because it isn't u= sing IPv6 as a transport=97it's using an IPv4 tunnel in a half-configured s= tate. So again, why are you wasting the working group's time on this? If this i= s really just for your information, can we please drop it now? If you are= seriously proposing reopening the debate about how to do DHCPv4 over a nat= ive IPv6 network, a debate which I _thought_ we'd settled in Orlando, can y= ou explain why you think it's worth the working group's time to revisit thi= s issue? From otroan@employees.org Wed Jun 12 07:09: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 7564F21F9942 for ; Wed, 12 Jun 2013 07:09:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, 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 RxdFTgS-l6Or for ; Wed, 12 Jun 2013 07:09:14 -0700 (PDT) Received: from banjo.employees.org (banjo.employees.org [198.137.202.19]) by ietfa.amsl.com (Postfix) with ESMTP id B6CB621F9946 for ; Wed, 12 Jun 2013 07:09:14 -0700 (PDT) Received: from dhcp-10-61-96-45.cisco.com (64-103-25-233.cisco.com [64.103.25.233]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: otroan) by banjo.employees.org (Postfix) with ESMTPSA id F1E4F5E9C; Wed, 12 Jun 2013 07:09:13 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Ole Troan In-Reply-To: <8D23D4052ABE7A4490E77B1A012B6307751D2ECF@mbx-01.win.nominum.com> Date: Wed, 12 Jun 2013 16:09:12 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <4CDE1297-53FB-418D-B441-16EEB7574BB9@employees.org> References: <20130612112504.2403.22751.idtracker@ietfa.amsl.com> <32536718-0436-4463-A54F-92D484E09B1D@employees.org> <8D23D4052ABE7A4490E77B1A012B6307751D2B11@mbx-01.win.nominum.com> <6D7079F4-2D1F-468E-B052-695E94F1D26B@employees.org> <8D23D4052ABE7A4490E77B1A012B6307751D2ECF@mbx-01.win.nominum.com> To: Ted Lemon X-Mailer: Apple Mail (2.1508) Cc: "dhcwg@ietf.org WG" Subject: Re: [dhcwg] New Version Notification for draft-troan-dhc-dhcpv4osw-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, 12 Jun 2013 14:09:20 -0000 Ted, >>> - Is it in fact the case that IPv4-in-IPv6 tunnels will work before = the CE IPv4 address is known? >> I can't think of a reason why they wouldn't work. >=20 > Essentially now you have a half-built tunnel that works one way when = you don't have an IP address, and possibly a different way when you do. = Where is the RFC that describes how this tunnel works? Suppose I send = an IP address down the tunnel with a destination of 255.255.255.255: how = does the routing for that packet work? It's certainly true that we can = intuit how it ought to work, but the question is, is there a = specification that says how it works, or are you relying on the = implementor's intuition? hmm, not sure I get the point. if you connect an IPv4 host to an = Ethernet link, then that client sends a packet with an unspecified = source and 255.255.255.255 as destination. how 'routing' is done for = that client, isn't that the same problem? and no, routing (as in forwarding) isn't done, that's why there is a = relay there. >> that's also the argument against these mechanisms, that they are = essentially new protocols. >> do we really have to spend so much time and resources to support = sunsetting of IPv4? should we? >=20 > This is an argument in favor of dropping all the work softwire is = currently doing, and has done. Stateless 4over6 and DSlite both require = substantial implementation work for what is essentially a temporary = technology. yep. > Furthermore, either you are reusing existing technology with = dhcpv4osw, or you are writing a new protocol. If you are reusing = existing technology, then the argument that you are building this on a = foundation of sand applies. If you are writing a new protocol, then = the argument you raise above does not apply, because dhcpv4osw is = notionally exactly the same as the other two alternatives, only much = more complicated to specify because it isn't using IPv6 as a = transport=97it's using an IPv4 tunnel in a half-configured state. no, the tunnel isn't in a half configured state, just as an Ethernet = isn't in a half configured state before IPv4 address is assigned. the L2 is up. > So again, why are you wasting the working group's time on this? If = this is really just for your information, can we please drop it now? = If you are seriously proposing reopening the debate about how to do = DHCPv4 over a native IPv6 network, a debate which I _thought_ we'd = settled in Orlando, can you explain why you think it's worth the working = group's time to revisit this issue? I object to your use of language. if you feel this is a waste of time, = then stop engaging in the debate. I'm reopening the debate, because I don't think we have explored what = appears to me to be the obvious and simple solution, and I'm somewhat puzzled that we are exploring building new protocols = for a problem that is already solved, and should hopefully have a short lifetime. cheers, Ole= From Ted.Lemon@nominum.com Wed Jun 12 07:25:38 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 C012121F9B5E for ; Wed, 12 Jun 2013 07:25:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.611 X-Spam-Level: X-Spam-Status: No, score=-106.611 tagged_above=-999 required=5 tests=[AWL=-0.012, 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 l+bTa0PxERqZ for ; Wed, 12 Jun 2013 07:25:26 -0700 (PDT) Received: from exprod7og118.obsmtp.com (exprod7og118.obsmtp.com [64.18.2.8]) by ietfa.amsl.com (Postfix) with ESMTP id D846F21F9B1A for ; Wed, 12 Jun 2013 07:25:16 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob118.postini.com ([64.18.6.12]) with SMTP ID DSNKUbiErkUeVZdIKbNbFmR4epAj+65YbZ4a@postini.com; Wed, 12 Jun 2013 07:25:16 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 C3C5C1B81DA for ; Wed, 12 Jun 2013 07:24:46 -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 BD62819005D; Wed, 12 Jun 2013 07:24:46 -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, 12 Jun 2013 07:24:46 -0700 From: Ted Lemon To: Ole Troan Thread-Topic: [dhcwg] New Version Notification for draft-troan-dhc-dhcpv4osw-00.txt Thread-Index: AQHOZ3BYRHWLt3q4GkSeFfzv/hNWD5kyj/CAgAADWwCAAARYgA== Date: Wed, 12 Jun 2013 14:24:46 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B6307751D306D@mbx-01.win.nominum.com> References: <20130612112504.2403.22751.idtracker@ietfa.amsl.com> <32536718-0436-4463-A54F-92D484E09B1D@employees.org> <8D23D4052ABE7A4490E77B1A012B6307751D2B11@mbx-01.win.nominum.com> <6D7079F4-2D1F-468E-B052-695E94F1D26B@employees.org> <8D23D4052ABE7A4490E77B1A012B6307751D2ECF@mbx-01.win.nominum.com> <4CDE1297-53FB-418D-B441-16EEB7574BB9@employees.org> In-Reply-To: <4CDE1297-53FB-418D-B441-16EEB7574BB9@employees.org> 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: <77D9BEFDE6BDD54F8785726B25655489@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dhcwg@ietf.org WG" Subject: Re: [dhcwg] New Version Notification for draft-troan-dhc-dhcpv4osw-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, 12 Jun 2013 14:25:38 -0000 On Jun 12, 2013, at 10:09 AM, Ole Troan wrote: > hmm, not sure I get the point. if you connect an IPv4 host to an Ethernet= link, then that client sends a packet with an unspecified source and 255.2= 55.255.255 as destination. how 'routing' is done for that client, isn't tha= t the same problem? > and no, routing (as in forwarding) isn't done, that's why there is a rela= y there. I would expect that a naive tunnel implementation that wasn't specifically = addressed to this use case would drop the packet, because it's not to a val= id destination. > no, the tunnel isn't in a half configured state, just as an Ethernet isn'= t in a half configured state before IPv4 address is assigned. > the L2 is up. I think you are splitting hairs. If you wanted to configure a tunnel of t= his type on your OpenWRT router, today, what would you type at the shell pr= ompt? >> So again, why are you wasting the working group's time on this? If thi= s is really just for your information, can we please drop it now? If you = are seriously proposing reopening the debate about how to do DHCPv4 over a = native IPv6 network, a debate which I _thought_ we'd settled in Orlando, ca= n you explain why you think it's worth the working group's time to revisit = this issue? >=20 > I object to your use of language. if you feel this is a waste of time, th= en stop engaging in the debate. I can't, because you've re-raised it, even though it was settled in Orlando= after a huge amount of wasted time prior to Orlando. Object to my langua= ge all you want, but this is a trivial issue that does not need further deb= ate. > I'm reopening the debate, because I don't think we have explored what app= ears to me to be the obvious and simple solution, > and I'm somewhat puzzled that we are exploring building new protocols for= a problem that is already solved, and should > hopefully have a short lifetime. The problem is not already solved: the solution you are proposing requires = changes on DHCP servers, DHCP clients, DHCP relay agents and probably stack= changes as well to support the tunnel functionality your solution requires= . It requires new infrastructure that doesn't already exist. It require= s tunnel functionality that is not documented in any RFC (I assume your fai= lure to list an RFC confirms this). It requires detailed specification, r= ather than simple specification, in order to (we would hope) catch all the = edge cases that are underspecified in existing documents. You and I went over this in painful detail in a long private email exchange= at the end of the IETF meeting in Atlanta. So I'm sorry if it seems to y= ou that I am being unkind in my use of language, but your claim that this r= eally needs to be explored and that you are not wasting the working group's= time by raising it yet again does not match with the history of this discu= ssion. From otroan@employees.org Wed Jun 12 14:05: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 7E0C511E80D9 for ; Wed, 12 Jun 2013 14:05:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.539 X-Spam-Level: X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[AWL=0.060, 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 bLTn7kiuQkLS for ; Wed, 12 Jun 2013 14:05:06 -0700 (PDT) Received: from banjo.employees.org (banjo.employees.org [IPv6:2001:1868:205::19]) by ietfa.amsl.com (Postfix) with ESMTP id C40F611E80CC for ; Wed, 12 Jun 2013 14:05:06 -0700 (PDT) Received: from dhcp-10-61-111-244.cisco.com (64-103-25-233.cisco.com [64.103.25.233]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: otroan) by banjo.employees.org (Postfix) with ESMTPSA id 8D6BA5ECA; Wed, 12 Jun 2013 14:05:05 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Ole Troan In-Reply-To: <8D23D4052ABE7A4490E77B1A012B6307751D306D@mbx-01.win.nominum.com> Date: Wed, 12 Jun 2013 23:05:02 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130612112504.2403.22751.idtracker@ietfa.amsl.com> <32536718-0436-4463-A54F-92D484E09B1D@employees.org> <8D23D4052ABE7A4490E77B1A012B6307751D2B11@mbx-01.win.nominum.com> <6D7079F4-2D1F-468E-B052-695E94F1D26B@employees.org> <8D23D4052ABE7A4490E77B1A012B6307751D2ECF@mbx-01.win.nominum.com> <4CDE1297-53FB-418D-B441-16EEB7574BB9@employees.org> <8D23D4052ABE7A4490E77B1A012B6307751D306D@mbx-01.win.nominum.com> To: Ted Lemon X-Mailer: Apple Mail (2.1508) Cc: "dhcwg@ietf.org WG" Subject: Re: [dhcwg] New Version Notification for draft-troan-dhc-dhcpv4osw-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, 12 Jun 2013 21:05:07 -0000 Ted, >> hmm, not sure I get the point. if you connect an IPv4 host to an = Ethernet link, then that client sends a packet with an unspecified = source and 255.255.255.255 as destination. how 'routing' is done for = that client, isn't that the same problem? >> and no, routing (as in forwarding) isn't done, that's why there is a = relay there. >=20 > I would expect that a naive tunnel implementation that wasn't = specifically addressed to this use case would drop the packet, because = it's not to a valid destination. >=20 >> no, the tunnel isn't in a half configured state, just as an Ethernet = isn't in a half configured state before IPv4 address is assigned. >> the L2 is up. >=20 > I think you are splitting hairs. If you wanted to configure a tunnel = of this type on your OpenWRT router, today, what would you type at the = shell prompt? I think you are digressing. if you want evidence of how existing implementations work, I did set up = the equivalent of draft-ietf-softwire-public-4over6-09 in IOS. (which is the same as MAP 1:1 with separate provisioning. which is the = same as an RFC2473 tunnel with DHCPV4 over it, or the same as LW46 in = full address sharing mode.) CE =3D=3D=3D BR ---- DHCPv4 server manually configured RFC2473 tunnel with DHCPv4 over it. CE: interface Ethernet0/0 ipv6 address 1::2/64 interface Tunnel0 ip address dhcp tunnel source Ethernet0/0 tunnel mode ipv6 tunnel destination 1::1 BR: interface Ethernet0/0 ipv6 address 1::1/64 interface Ethernet0/1 ip address 1.1.1.2 255.255.255.0 interface Tunnel0 ip address 2.2.2.2 255.255.255.0 ip helper-address 1.1.1.1 tunnel source Ethernet0/0 tunnel mode ipv6 tunnel destination 1::2 Server: interface Ethernet0/0 ip address 1.1.1.1 255.255.255.0 ip dhcp pool MAP network 2.2.2.0 255.255.255.0 server#show ip dhcp binding=20 Bindings from all pools not associated with VRF: IP address Client-ID/ Lease expiration Type Hardware address/ User name 2.2.2.1 0063.6973.636f.2d61. Jun 13 2013 08:49 PM = Automatic ce#show dhcp lease Temp IP addr: 2.2.2.1 for peer on Interface: Tunnel0 Temp sub net mask: 255.255.255.0 DHCP Lease server: 1.1.1.1, state: 5 Bound DHCP transaction id: 45 Lease: 86400 secs, Renewal: 43200 secs, Rebind: 75600 secs Next timer fires after: 11:54:32 Retry count: 0 Client-ID: cisco-aabb.cc00.6500-Tu0 Client-ID hex dump: 636973636F2D616162622E636330302E 363530302D547530 Hostname: ce ce# this is an unchanged 15.1 release. just works. there is MAP support on OpenWRT, but I haven't built the VM images to = test that with yet. [...] > The problem is not already solved: the solution you are proposing = requires changes on DHCP servers, DHCP clients, DHCP relay agents and = probably stack changes as well to support the tunnel functionality your = solution requires. It requires new infrastructure that doesn't already = exist. It requires tunnel functionality that is not documented in any = RFC (I assume your failure to list an RFC confirms this). It requires = detailed specification, rather than simple specification, in order to = (we would hope) catch all the edge cases that are underspecified in = existing documents. it works with existing implementations for full IPv4 address over = tunnels. my draft and I can't see you have refuted that, suggests that it is = quite simple to make the adjustments to also support the=20 address sharing case. it is easy to think that a completely new solution that only exists on = the whiteboard will solve all problems better, old as well as new. the pragmatic approach of small incremental change to existing stuff = appears to me to be the safer choice. > You and I went over this in painful detail in a long private email = exchange at the end of the IETF meeting in Atlanta. So I'm sorry if it = seems to you that I am being unkind in my use of language, but your = claim that this really needs to be explored and that you are not wasting = the working group's time by raising it yet again does not match with the = history of this discussion. I don't appreciate you trying to stifle the debate without letting = others air their views. this is the time for the DHC working group to thoroughly consider what = the best approach to IPv4 over IPv6 softwires provisioning should be. it = is a lot less time-wasting to do due diligence now. given that the DHC = working group has decided to go down this path in the first place. cheers, Ole From Ted.Lemon@nominum.com Wed Jun 12 14:21: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 E394411E80BA for ; Wed, 12 Jun 2013 14:21:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.609 X-Spam-Level: X-Spam-Status: No, score=-106.609 tagged_above=-999 required=5 tests=[AWL=-0.010, 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 A2zqa6xSfQdp for ; Wed, 12 Jun 2013 14:21:41 -0700 (PDT) Received: from exprod7og123.obsmtp.com (exprod7og123.obsmtp.com [64.18.2.24]) by ietfa.amsl.com (Postfix) with ESMTP id 3646E11E80D9 for ; Wed, 12 Jun 2013 14:21:39 -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 DSNKUbjmYke6P1FY0ADIGzqUXWwBSYWABfiL@postini.com; Wed, 12 Jun 2013 14:21:39 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 99B5D1B81CF for ; Wed, 12 Jun 2013 14:21:38 -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 8F53C19005D; Wed, 12 Jun 2013 14:21:38 -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, 12 Jun 2013 14:21:38 -0700 From: Ted Lemon To: Ole Troan Thread-Topic: [dhcwg] New Version Notification for draft-troan-dhc-dhcpv4osw-00.txt Thread-Index: AQHOZ7CHIEa8Lhs9PUSqzcID8vyhkZkzC5yA Date: Wed, 12 Jun 2013 21:21:37 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B6307751D41D3@mbx-01.win.nominum.com> References: <20130612112504.2403.22751.idtracker@ietfa.amsl.com> <32536718-0436-4463-A54F-92D484E09B1D@employees.org> <8D23D4052ABE7A4490E77B1A012B6307751D2B11@mbx-01.win.nominum.com> <6D7079F4-2D1F-468E-B052-695E94F1D26B@employees.org> <8D23D4052ABE7A4490E77B1A012B6307751D2ECF@mbx-01.win.nominum.com> <4CDE1297-53FB-418D-B441-16EEB7574BB9@employees.org> <8D23D4052ABE7A4490E77B1A012B6307751D306D@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: <6DF33F24754FEC4DAD3464067486C9A0@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dhcwg@ietf.org WG" Subject: Re: [dhcwg] New Version Notification for draft-troan-dhc-dhcpv4osw-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, 12 Jun 2013 21:21:51 -0000 On Jun 12, 2013, at 5:05 PM, Ole Troan wrote: > this is an unchanged 15.1 release. just works. > there is MAP support on OpenWRT, but I haven't built the VM images to tes= t that with yet. OK, so Public 4over6 with DHCP over the tunnel works on IOS. >> The problem is not already solved: the solution you are proposing requir= es changes on DHCP servers, DHCP clients, DHCP relay agents and probably st= ack changes as well to support the tunnel functionality your solution requi= res. It requires new infrastructure that doesn't already exist. It requ= ires tunnel functionality that is not documented in any RFC (I assume your = failure to list an RFC confirms this). It requires detailed specification= , rather than simple specification, in order to (we would hope) catch all t= he edge cases that are underspecified in existing documents. >=20 > it works with existing implementations for full IPv4 address over tunnels= . > my draft and I can't see you have refuted that, suggests that it is quite= simple to make the adjustments to also support the=20 > address sharing case. Yes, it is quite simple to make the changes. All of the solutions we've t= alked about are quite simple. > it is easy to think that a completely new solution that only exists on th= e whiteboard will solve all problems better, old as well as new. There are several working implementations of DHCPv4 over IPv6. I don't kn= ow if anybody's done DHCPv4 over DHCPv6 yet. There is no existing impleme= ntation of what you are proposing. So "only exists on the whiteboard" app= lies to what you are proposing. > the pragmatic approach of small incremental change to existing stuff appe= ars to me to be the safer choice. It's always a great rhetorical idea to call the idea you favor "pragmatic" = and requiring only "small incremental change," but that doesn't make it so.= In fact, the amount of change in your proposal is marginally more than r= equired for DHCPv4-over-DHCPv6. But this simply isn't a valid differentia= ting argument. What you are proposing is neither pragmatic nor incrementa= l in any sense that doesn't equally apply to all the other solutions. > I don't appreciate you trying to stifle the debate without letting others= air their views. I can't stop you from airing your view, and I'm not proposing that anyone e= lse not air theirs. What I am saying is that the working group already co= nsidered your proposal, and three other competing proposals, and we'd alrea= dy decided to go with DHCPv4-over-DHCPv6. That is to say, the debate had = already happened. And now you want to reopen it. > this is the time for the DHC working group to thoroughly consider what th= e best approach to IPv4 over IPv6 softwires provisioning should be. it is a= lot less time-wasting to do due diligence now. given that the DHC working = group has decided to go down this path in the first place. As an IETF participant, you are free to try to spend the working group's ti= me continuing this debate. The working group is free to continue debating= this point until IPv6 deployment reaches 100%. As a working group partic= ipant (that is, not an AD), I am advocating that the working group not do t= his. What the working group actually decides to do is not up to me or to = you. From otroan@employees.org Wed Jun 12 14:33: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 8989411E8104 for ; Wed, 12 Jun 2013 14:33:45 -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 jntyDBSDqJf2 for ; Wed, 12 Jun 2013 14:33:39 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 7196411E80FF for ; Wed, 12 Jun 2013 14:33:39 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAD3nuFGQ/khR/2dsb2JhbABagwm/Q4EBFnSCIwEBAQMBOj0CEAtGVwaIGwa7Lo8QMweCf2EDqQKDETo X-IronPort-AV: E=Sophos;i="4.87,854,1363132800"; d="scan'208";a="155269977" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-1.cisco.com with ESMTP; 12 Jun 2013 21:33:38 +0000 Received: from dhcp-10-61-111-244.cisco.com (dhcp-10-61-111-244.cisco.com [10.61.111.244]) by ams-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r5CLXZBp007290 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 12 Jun 2013 21:33:36 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Ole Troan In-Reply-To: <8D23D4052ABE7A4490E77B1A012B6307751D41D3@mbx-01.win.nominum.com> Date: Wed, 12 Jun 2013 23:33:35 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130612112504.2403.22751.idtracker@ietfa.amsl.com> <32536718-0436-4463-A54F-92D484E09B1D@employees.org> <8D23D4052ABE7A4490E77B1A012B6307751D2B11@mbx-01.win.nominum.com> <6D7079F4-2D1F-468E-B052-695E94F1D26B@employees.org> <8D23D4052ABE7A4490E77B1A012B6307751D2ECF@mbx-01.win.nominum.com> <4CDE1297-53FB-418D-B441-16EEB7574BB9@employees.org> <8D23D4052ABE7A4490E77B1A012B6307751D306D@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751D41D3@mbx-01.win.nominum.com> To: Ted Lemon X-Mailer: Apple Mail (2.1508) Cc: "dhcwg@ietf.org WG" Subject: Re: [dhcwg] New Version Notification for draft-troan-dhc-dhcpv4osw-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, 12 Jun 2013 21:33:45 -0000 Ted, >> I don't appreciate you trying to stifle the debate without letting = others air their views. >=20 > I can't stop you from airing your view, and I'm not proposing that = anyone else not air theirs. What I am saying is that the working group = already considered your proposal, and three other competing proposals, = and we'd already decided to go with DHCPv4-over-DHCPv6. That is to = say, the debate had already happened. And now you want to reopen it. sorry, then I must have missed that debate. from the Orlando minutes I see I'm just following up on what I said = then, which was: Ole: I think is a grand idea for now, but I reserve my right = to change my mind tomorrow. Would it be easier to deploy if you colocate = DHCPv4 and DHCPv6 servers? anyway, I don't think continuing this tangential discussion between the = two of us is good use of WG time. if anyone else has comments or interest I would welcome that. cheers, Ole= From Ted.Lemon@nominum.com Wed Jun 12 14:45:03 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 243AE21E8105 for ; Wed, 12 Jun 2013 14:45:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.609 X-Spam-Level: X-Spam-Status: No, score=-106.609 tagged_above=-999 required=5 tests=[AWL=-0.010, 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 4djl6TxlmHlx for ; Wed, 12 Jun 2013 14:44:55 -0700 (PDT) Received: from exprod7og103.obsmtp.com (exprod7og103.obsmtp.com [64.18.2.159]) by ietfa.amsl.com (Postfix) with ESMTP id 3B5D221E80FB for ; Wed, 12 Jun 2013 14:44:55 -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 DSNKUbjr1x0TaX28zkL7xU8cchbTMT3s4CBF@postini.com; Wed, 12 Jun 2013 14:44:55 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 D34801B81D2 for ; Wed, 12 Jun 2013 14:44:54 -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 CCA8719005D; Wed, 12 Jun 2013 14:44:54 -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, 12 Jun 2013 14:44:55 -0700 From: Ted Lemon To: Ole Troan Thread-Topic: [dhcwg] New Version Notification for draft-troan-dhc-dhcpv4osw-00.txt Thread-Index: AQHOZ7SB1/CDIKGDjUmT3qs+P6cpaZkzEhUA Date: Wed, 12 Jun 2013 21:44:54 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B6307751D4321@mbx-01.win.nominum.com> References: <20130612112504.2403.22751.idtracker@ietfa.amsl.com> <32536718-0436-4463-A54F-92D484E09B1D@employees.org> <8D23D4052ABE7A4490E77B1A012B6307751D2B11@mbx-01.win.nominum.com> <6D7079F4-2D1F-468E-B052-695E94F1D26B@employees.org> <8D23D4052ABE7A4490E77B1A012B6307751D2ECF@mbx-01.win.nominum.com> <4CDE1297-53FB-418D-B441-16EEB7574BB9@employees.org> <8D23D4052ABE7A4490E77B1A012B6307751D306D@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751D41D3@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 WG" Subject: Re: [dhcwg] New Version Notification for draft-troan-dhc-dhcpv4osw-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, 12 Jun 2013 21:45:03 -0000 On Jun 12, 2013, at 5:33 PM, Ole Troan wrote: > from the Orlando minutes I see I'm just following up on what I said then,= which was: > Ole: I think is a grand idea for now, but I reserve my right to = change my > mind tomorrow. Would it be easier to deploy if you colocate DHCP= v4 and > DHCPv6 servers? :) > anyway, I don't think continuing this tangential discussion between the t= wo of us is good use of WG time. > if anyone else has comments or interest I would welcome that. Ditto. From ian.farrer@telekom.de Thu Jun 13 01:23: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 886A521F9A65 for ; Thu, 13 Jun 2013 01:23:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[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 xm9YjCgIOYjC for ; Thu, 13 Jun 2013 01:23:03 -0700 (PDT) Received: from tcmail23.telekom.de (tcmail23.telekom.de [80.149.113.243]) by ietfa.amsl.com (Postfix) with ESMTP id 53BA721F9A77 for ; Thu, 13 Jun 2013 01:22:58 -0700 (PDT) Received: from he111630.emea1.cds.t-internal.com ([10.134.93.22]) by tcmail21.telekom.de with ESMTP/TLS/AES128-SHA; 13 Jun 2013 10:22:50 +0200 Received: from HE111643.EMEA1.CDS.T-INTERNAL.COM ([10.134.93.12]) by HE111630.emea1.cds.t-internal.com ([::1]) with mapi; Thu, 13 Jun 2013 10:22:50 +0200 From: To: Date: Thu, 13 Jun 2013 10:22:48 +0200 Thread-Topic: [dhcwg] Fwd: New Version Notification for draft-troan-dhc-dhcpv4osw-00.txt Thread-Index: Ac5oDzEuyJUZ9TYBSRmYSkYvLxAkOA== Message-ID: In-Reply-To: <81240250-048D-44FF-80DF-CC804C65C3C1@employees.org> Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.5.130515 acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: dhcwg@ietf.org Subject: Re: [dhcwg] Fwd: New Version Notification for draft-troan-dhc-dhcpv4osw-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: Thu, 13 Jun 2013 08:23:11 -0000 Hi Ole, Thinking a little further on this, there's a bigger problem here. The DHCP relay in the BR can catch the broadcast DHCP messages for address allocations and create MAPping rules accordingly. However, the DHCP release mechanism is unicast based, so how does remove the MAPping rules once the DHCPv4 lease is no longer valid? Also, what about addresses that don't get cleanly released and expire in the DHCPv4 server? To fix this, either the DHCPv4 server has to be co-located in the BR, or there's going to need to be a lot of DPI on DHCP unicast messages passing through the BR, with corresponding lifetimes attached to the MAP rules. Cheers, Ian On 12/06/2013 15:35, "Ole Troan" wrote: >Ian, > >> 1, From a BR implementation perspective, this changes the forwarding >>logic >> a little: I.e. If there is a valid MAP rule for the packet then forward, >> if there is no valid MAP rule and the encapsulated SRC is 0.0.0.0/port >>67 >> then relay else drop. Does this cause any implementation problems? > >I haven't looked at the code, but it is in theory no different than the >normal UDP helper. > >> 2, The DHCP client will need to reconfigure the port that it is working >>on >> dynamically throughout its lifecycle. I.e: the initial allocation >>process >> is sourced from port 67, but then it needs to reconfigure itself to be >> sourced from a valid port allocated to the client. This may change > >yes, the port will change. >the source port must be in the DHCP binding. > >> 3, One thing that I think needs to be considered - If the client >> successfully gets configured, then the BR forwarding is broken - I.e >>there >> is no corresponding MAP rule in the BR based on the dynamic address >> allocation that the BR has relayed. This needs to be considered as part >>of >> this as even unicast based renew messages necessary for maintaining the >> lease don't work. > >yes, but this is no different than the DHCP server giving out an address >to a client, which there >is no routing for in the network. configuration error. don't do it. ;-) [ian] This one's a bit different to normal DHCPv4 relaying though. If the routing is not correct in the network, the client will never get an address and so DHCP will fail. In this case, if DHCP config is successful then further DHCP communications will fail (without a mechanism for creating dynamic MAPing rules). > >> The obvious way that this would be resolved is that the BR would >> dynamically build its mapping rules based on snooping the contents of >>the >> DHCP responses from the server. There is an additional consideration >>about >> spoofing DHCP replies and DOSing the BR in this case. > >yes, in this case snooping could definitely work. > >> 4, One technical clarification on page 2 - >>=20 >> A DHCPv4 client communicates directly with the DHCPv4 server after it >> has acquired addresses. That requires that the DHCPv4 server >> supports clients using a different UDP port than 68. >>=20 >> Surely, this should be port 67? > >doesn't the client use source port 68? >so that source port has to be allocated from the port range. while the >well-known server port can stay unchanged >and fixed at 67. [ian] My mistake. > >> 5, I'm not sure if you're advocating that this is the best way to tackle >> the config problem or if it's just fleshing out the solution so that it >> can be properly considered within draft-ietf-dhc-v4configuration >>(without >> changing the published conclusion). > >I'm not either. I'm probably mostly advocating that only DHCPv6 should be >used, and all services that otherwise would >need IPv4 configuration information should run on IPv6. but then I'm >known to be disconnected from reality too. ;-) > >cheers, >Ole From otroan@employees.org Thu Jun 13 02:29: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 73A1121F8B04 for ; Thu, 13 Jun 2013 02:29:52 -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 6fm5BjmuULnf for ; Thu, 13 Jun 2013 02:29:46 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 6D9D521F9944 for ; Thu, 13 Jun 2013 02:29:44 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAHSQuVGQ/khN/2dsb2JhbABbgwm/YX8WdIIjAQEBAwE6PQIFCwsSNEkOBogbBrsljxAzBxaCaWEDqQKDETo X-IronPort-AV: E=Sophos;i="4.87,857,1363132800"; d="scan'208";a="83321322" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-2.cisco.com with ESMTP; 13 Jun 2013 09:29:43 +0000 Received: from dhcp-10-61-110-245.cisco.com (dhcp-10-61-110-245.cisco.com [10.61.110.245]) by ams-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r5D9TeOn031132 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 13 Jun 2013 09:29:41 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Ole Troan In-Reply-To: Date: Thu, 13 Jun 2013 11:29:40 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: X-Mailer: Apple Mail (2.1508) Cc: dhcwg@ietf.org Subject: Re: [dhcwg] Fwd: New Version Notification for draft-troan-dhc-dhcpv4osw-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: Thu, 13 Jun 2013 09:29:52 -0000 Ian, > Thinking a little further on this, there's a bigger problem here. The = DHCP > relay in the BR can catch the broadcast DHCP messages for address > allocations and create MAPping rules accordingly. However, the DHCP > release mechanism is unicast based, so how does remove the MAPping = rules > once the DHCPv4 lease is no longer valid? Also, what about addresses = that > don't get cleanly released and expire in the DHCPv4 server? >=20 > To fix this, either the DHCPv4 server has to be co-located in the BR, = or > there's going to need to be a lot of DPI on DHCP unicast messages = passing > through the BR, with corresponding lifetimes attached to the MAP = rules. the DHCPv4 relay _could_ force all DHCP traffic to go through itself, by = rewriting the server id. that's apparently quite common, see RFC5107. you do bring up a good point though; a stateful relay is really at odds = with the MAP architecture of stateless BRs where CEs use anycast to get to them. any time you want redundancy you'd have a problem. (to others following the discussion, we're now discussing the case of = LW46 with complete indepdence between IPv6 and IPv4 address, and where there is also no dependency = between IPv6 provisioning and IPv4 provisioning. none of this matter of course, if you just use = DHCPv4 to get other configuration information) an out of band mechanism to populate per subscriber LW46/MAP state, = would allow for stateless DHCP relays. btw: force renew, that's not something generally used is it? cause = supporting that I think would require the server to include the client's UDP port in the binding, while otherwise it would = not be required. cheers, Ole From Branimir.Rajtar@t.ht.hr Thu Jun 13 07:18:57 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 2A80321F9A47 for ; Thu, 13 Jun 2013 07:18:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.999 X-Spam-Level: X-Spam-Status: No, score=-0.999 tagged_above=-999 required=5 tests=[AWL=1.601, 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 y+8jwsrGeqeG for ; Thu, 13 Jun 2013 07:18:53 -0700 (PDT) Received: from mx01.t.ht.hr (mx01.t.ht.hr [195.29.161.88]) by ietfa.amsl.com (Postfix) with SMTP id 621E621F99D5 for ; Thu, 13 Jun 2013 07:18:51 -0700 (PDT) Received: from (unknown [172.17.66.76]) by scmg1.t.ht.hr with smtp id 35e8_10db_b3304a2e_d364_11e2_a67f_00221951415f; Wed, 12 Jun 2013 15:33:42 +0200 Received: from S2010EXCHCA1.ad.local ([10.240.132.138]) by mailgw.ad.local with Microsoft SMTPSVC(6.0.3790.4675); Wed, 12 Jun 2013 15:33:43 +0200 Received: from S2010EXCH1.ad.local ([fe80::2d7b:39dd:876e:f277]) by S2010EXCHCA1.ad.local ([::1]) with mapi id 14.03.0123.003; Wed, 12 Jun 2013 15:33:42 +0200 From: Branimir Rajtar To: Ole Troan , "dhcwg@ietf.org WG" Thread-Topic: [dhcwg] Fwd: New Version Notification for draft-troan-dhc-dhcpv4osw-00.txt Thread-Index: AQHOZ2Bl/MLxqRJlTUiTeqbZnDAdXZkyCNeg Date: Wed, 12 Jun 2013 13:33:42 +0000 Message-ID: <786F13AA11E69F4DB2CCA23F7400C2FB01466694@S2010EXCH1.ad.local> References: <20130612112504.2403.22751.idtracker@ietfa.amsl.com> <32536718-0436-4463-A54F-92D484E09B1D@employees.org> In-Reply-To: <32536718-0436-4463-A54F-92D484E09B1D@employees.org> 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: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginalArrivalTime: 12 Jun 2013 13:33:43.0176 (UTC) FILETIME=[74F8F080:01CE6771] X-NAIMIME-Disclaimer: 1 X-NAIMIME-Modified: 1 Subject: Re: [dhcwg] Fwd: New Version Notification for draft-troan-dhc-dhcpv4osw-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: Thu, 13 Jun 2013 14:18:57 -0000 SGksCgpJIHNhbSBUZWQgYW5kIElhbiBhbHJlYWR5IHBvc3RlZCBzb21lIGNvbW1lbnRzLCBidXQg SSBoYXZlIGFuIGFkZGl0aW9uYWwgb25lOgoKSWYgdGhlIEJSIHdvcmtzIGluIERIQ1AgcmVsYXkg bW9kZSwgYXQgdGhlIGluaXRpYWwgY29tbXVuaWNhdGlvbiBpdCB3aWxsIGhhdmUgdG8gY2hlY2sg aWYgdGhlIHNvdXJjZSBVRFAgcG9ydCBpcyA2OCAoZ2l2ZW4gdGhlIHNvdXJjZSBhZGRyZXNzIGlz IDAuMC4wLjApIGFuZCBwZXJmb3JtIHRoZSByZWxheWluZyBmdW5jdGlvbi4gVGhpcyBpcyBiYXNp Y2FsbHkgRFBJIGFuZCB3b3VsZCBoYXZlIHRvIGJlIGltcGxlbWVudGVkIGluIGhhcmR3YXJlIGZv ciBpdCB0byB3b3JrIGVmZmljaWVudGx5Li4uIElmIHlvdSB3b3JrIGluIGFuIHZpcnR1YWxpemVk IGVudmlyb25tZW50LCBJIGV4cGVjdCBpdCB3b3VsZCBzbG93IGRvd24gdGhlIEJSLgoKVGhpcyBp cyBhbiBvYnNlcnZhdGlvbiB3aGljaCBJIHRoaW5rIHdvdWxkIGJlIHdvcnRod2hpbGUgdG8gaW5j bHVkZSBpbiB0aGUgZHJhZnQgLSBjb21wYXJpbmcgdG8gb3RoZXIgYXBwcm9hY2hlcywgdGhlIEJS IHdpbGwgZWl0aGVyIGJlIG1vcmUgZXhwZW5zaXZlIG9yIGxhY2tpbmcgaW4gcGVyZm9ybWFuY2Uu CgpCUiwKQnJhbmltaXIKCgotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQpGcm9tOiBkaGN3Zy1i b3VuY2VzQGlldGYub3JnIFttYWlsdG86ZGhjd2ctYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxm IE9mIE9sZSBUcm9hbgpTZW50OiBXZWRuZXNkYXksIEp1bmUgMTIsIDIwMTMgMTozMSBQTQpUbzog ZGhjd2dAaWV0Zi5vcmcgV0cKU3ViamVjdDogW2RoY3dnXSBGd2Q6IE5ldyBWZXJzaW9uIE5vdGlm aWNhdGlvbiBmb3IgZHJhZnQtdHJvYW4tZGhjLWRoY3B2NG9zdy0wMC50eHQKCkkndmUganVzdCBw b3N0ZWQgYSBvbmUgcGFnZXIgb24gaG93IEkgdGhpbmsgREhDUHY0IG92ZXIgSVB2NCBvdmVyIElQ djYgdHVubmVscyBjYW4gd29yay4KdGhpcyBpcyB0aGUgc29sdXRpb24gIkRIQ1B2NG9TVyIgaW4g aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1kaGMtdjRjb25maWd1cmF0aW9u LTAxCgpJIHdyb3RlIHRoaXMgbGFyZ2VseSBmb3IgbXlzZWxmIHRvIHRyeSB0byB1bmRlcnN0YW5k IHdoeSB3ZSBjb3VsZG4ndCBydW4gREhDUHY0IG92ZXIgdGhlIHR1bm5lbApqdXN0IGxpa2UgYW55 IG90aGVyIGxpbmstbGF5ZXIuCgpwbGVhc2UgbGV0IG1lIGtub3cgd2hhdCBJJ3ZlIG1pc3NlZC4K CmNoZWVycywKT2xlCgoKQmVnaW4gZm9yd2FyZGVkIG1lc3NhZ2U6Cgo+IEZyb206IDxpbnRlcm5l dC1kcmFmdHNAaWV0Zi5vcmc+Cj4gU3ViamVjdDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZv ciBkcmFmdC10cm9hbi1kaGMtZGhjcHY0b3N3LTAwLnR4dAo+IERhdGU6IEp1bmUgMTIsIDIwMTMg MTM6MjU6MDQgR01UKzAyOjAwCj4gVG86IE9sZSBUcm9hbiA8b3RAY2lzY28uY29tPgo+IE1lc3Nh Z2UtSWQ6IDwyMDEzMDYxMjExMjUwNC4yNDAzLjIyNzUxLmlkdHJhY2tlckBpZXRmYS5hbXNsLmNv bT4KPiAKPiAKPiBBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtdHJvYW4tZGhjLWRoY3B2NG9z dy0wMC50eHQKPiBoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IE9sZSBUcm9hbiBh bmQgcG9zdGVkIHRvIHRoZQo+IElFVEYgcmVwb3NpdG9yeS4KPiAKPiBGaWxlbmFtZToJIGRyYWZ0 LXRyb2FuLWRoYy1kaGNwdjRvc3cKPiBSZXZpc2lvbjoJIDAwCj4gVGl0bGU6CQkgREhDUHY0IG92 ZXIgQStQIHNvZnR3aXJlcwo+IENyZWF0aW9uIGRhdGU6CSAyMDEzLTA2LTEyCj4gR3JvdXA6CQkg SW5kaXZpZHVhbCBTdWJtaXNzaW9uCj4gTnVtYmVyIG9mIHBhZ2VzOiA0Cj4gVVJMOiAgICAgICAg ICAgICBodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC10cm9hbi1kaGMt ZGhjcHY0b3N3LTAwLnR4dAo+IFN0YXR1czogICAgICAgICAgaHR0cDovL2RhdGF0cmFja2VyLmll dGYub3JnL2RvYy9kcmFmdC10cm9hbi1kaGMtZGhjcHY0b3N3Cj4gSHRtbGl6ZWQ6ICAgICAgICBo dHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC10cm9hbi1kaGMtZGhjcHY0b3N3LTAwCj4g Cj4gCj4gQWJzdHJhY3Q6Cj4gICBBIG5vZGUgZ2V0dGluZyBJUHY0IGFjY2VzcyB2aWEgYW4gQStQ IG1lY2hhbmlzbSBtaWdodCBuZWVkIG90aGVyIElQdjQKPiAgIGNvbmZpZ3VyYXRpb24gaW5mb3Jt YXRpb24uICBUaGlzIG1lbW8gZGVzY3JpYmVzIGhvdyBESENQdjQgaXMKPiAgIHN1cHBvcnRlZCwg b24gSVB2NCBvdmVyIElQdjYgdHVubmVscyB3aXRoIHNoYXJlZCBJUHY0IGFkZHJlc3Nlcy4KPiAK PiAKPiAKPiAKPiBUaGUgSUVURiBTZWNyZXRhcmlhdAo+IAoKX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18KZGhjd2cgbWFpbGluZyBsaXN0CmRoY3dnQGlldGYu b3JnCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZGhjd2cKCgo8SFRNTD48 UD48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPSM5OTk5OTkgc2l6ZT0xPg0KDQpJWkpBVkEgTyBPRFJJ Q0FOSlUgT0RHT1ZPUk5PU1RJOiBTYWRyxb5haiBvdmUgcG9ydWtlIGkgZXZlbnR1YWxubyBwcmls b8W+ZW5paCBkYXRvdGVrYSBqZSBwb3ZqZXJsaml2IGkgbmFtaWplbmplbiBqZSBzYW1vIG9zb2Jh bWEgaWxpIHN1Ympla3RpbWEga29qaSBzdSBuYXZlZGVuaSB1IGFkcmVzaS4gVWtvbGlrbyBzdGUg cHJpbWlsaSBvdnUgcG9ydWt1IGdyZcWha29tLCBtb2xpbW8gVmFzLCBvYmF2aWplc3RpdGUgcG/F oWlsamF0ZWxqYSwgYSBwb3J1a3UgaSBzdmUgbmplbmUgcHJpdml0a2Ugb2RtYWgsIGJleiDEjWl0 YW5qYSwgdHJham5vIHVrbG9uaXRlIHMgcmHEjXVuYWxhLiBCaWxvIGtha3ZvIHByZW5vxaFlbmpl LCBrb3BpcmFuamUgaWxpIGRpc3RyaWJ1Y2lqYSBpbmZvcm1hY2lqYSBzYWRyxb5hbmloIHUgcG9y dWNpIHRyZcSHaW0gb3NvYmFtYSBqZSB6YWJyYW5qZW5vIGkgbW/FvmUgYml0aSB6YWtvbnNraSBr YcW+bmppdm8uIFNhZHLFvmFqLCBzdGF2b3ZpIGkgbWnFoWxqZW5qYSBpem5lc2VuaSB1IHBvcnVj aSBzdSBhdXRvcm92aSBpIG5lIHByZWRzdGF2bGphanUgbnXFvm5vIHN0YXZvdmUgSFQgLSBIcnZh dHNraWggdGVsZWtvbXVuaWthY2lqYSBkLmQuIEhUIG5lIHByaWh2YcSHYSBuaWtha3Z1IG9kZ292 b3Jub3N0IHphIGV2ZW50dWFsbnUgxaF0ZXR1IG5hc3RhbHUgcHJpbWl0a29tIG92ZSBwb3J1a2Ug aSBwcmlsb2dhIHNhZHLFvmFuaWggdSBwb3J1Y2kuDQoNCjwvRk9OVD48L1A+PFA+PEZPTlQgZmFj ZT1BcmlhbCBjb2xvcj0jOTk5OTk5IHNpemU9MT4NCg0KIERJU0NMQUlNRVI6VGhlIGNvbnRlbnRz IG9mIHRoaXMgZW1haWwgYXMgd2VsbCBhcyBhbnkgZmlsZXMgYXR0YWNoZWQgdG8gaXQgYXJlIGNv bmZpZGVudGlhbCBhbmQgaW50ZW5kZWQgc29sZWx5IGZvciBpbmRpdmlkdWFscyBvciBlbnRpdGll cyB3aGljaCB0aGV5IGFyZSBhZGRyZXNzZWQgdG8uIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMg ZW1haWwgbWVzc2FnZSBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGFuZCBwZXJt YW5lbnRseSByZW1vdmUgdGhlIG1lc3NhZ2UgYW5kIGFsbCBhdHRhY2hlZCBmaWxlcyBmcm9tIHRo ZSBjb21wdXRlci4gQW55IGRpc2Nsb3N1cmUsIGNvcHlpbmcgb3IgZGlzdHJpYnV0aW9uIG9mIGFs bCBvciBhIHBhcnQgb2YgaW5mb3JtYXRpb24gY29udGFpbmVkIGhlcmVpbiB0byBvciBieSB0aGly ZCBwYXJ0aWVzIGlzIHByb2hpYml0ZWQgYW5kIG1heSBiZSB1bmxhd2Z1bC4gUGxlYXNlIG5vdGUg dGhhdCBhbnkgdmlld3Mgb3Igb3BpbmlvbnMgcHJlc2VudGVkIGluIHRoaXMgbWVzc2FnZSBhcmUg c29sZWx5IHRob3NlIG9mIHRoZSBhdXRob3IgYW5kIGRvIG5vdCBuZWNlc3NhcmlseSByZXByZXNl bnQgdGhlIHZpZXdzIGFuZCBvcGluaW9ucyBvZiBDcm9hdGlhbiBUZWxlY29tIEluYy4gQ3JvYXRp YW4gVGVsZWNvbSBJbmMuIGFjY2VwdHMgbm8gbGlhYmlsaXR5IGZvciBhbnkgcG90ZW50aWFsIGRh bWFnZSBjYXVzZWQgYnkgdGhpcyBtZXNzYWdlIGFuZCBmaWxlcyBhdHRhY2hlZCB0byBpdC4NCg0K PC9GT05UPjwvUD48L0hUTUw+Cg== From Ted.Lemon@nominum.com Thu Jun 13 07:52: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 D948E21F9644 for ; Thu, 13 Jun 2013 07:52:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.609 X-Spam-Level: X-Spam-Status: No, score=-106.609 tagged_above=-999 required=5 tests=[AWL=-0.010, 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 mzsQ3LX3V2JK for ; Thu, 13 Jun 2013 07:52:18 -0700 (PDT) Received: from exprod7og111.obsmtp.com (exprod7og111.obsmtp.com [64.18.2.175]) by ietfa.amsl.com (Postfix) with ESMTP id 64FBF21F8F6E for ; Thu, 13 Jun 2013 07:52:17 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob111.postini.com ([64.18.6.12]) with SMTP ID DSNKUbncoLGUSlIPW0gEASsa7wDUJA5ul7Z3@postini.com; Thu, 13 Jun 2013 07:52: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 CBDA31B81D7 for ; Thu, 13 Jun 2013 07:52:16 -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 BFBFC19005D; Thu, 13 Jun 2013 07:52:16 -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, 13 Jun 2013 07:52:17 -0700 From: Ted Lemon To: Branimir Rajtar Thread-Topic: [dhcwg] New Version Notification for draft-troan-dhc-dhcpv4osw-00.txt Thread-Index: AQHOaEWYZm3X/slqf0y2LxVLiCUGEQ== Date: Thu, 13 Jun 2013 14:52:15 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B6307751D5774@mbx-01.win.nominum.com> References: <20130612112504.2403.22751.idtracker@ietfa.amsl.com> <32536718-0436-4463-A54F-92D484E09B1D@employees.org> <786F13AA11E69F4DB2CCA23F7400C2FB01466694@S2010EXCH1.ad.local> In-Reply-To: <786F13AA11E69F4DB2CCA23F7400C2FB01466694@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="Windows-1252" Content-ID: <1D3F99E537142B4DBBEC1A45D1312524@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dhcwg@ietf.org WG" Subject: Re: [dhcwg] New Version Notification for draft-troan-dhc-dhcpv4osw-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: Thu, 13 Jun 2013 14:52:35 -0000 On Jun 12, 2013, at 9:33 AM, Branimir Rajtar wrot= e: > If the BR works in DHCP relay mode, at the initial communication it will = have to check if the source UDP port is 68 (given the source address is 0.0= .0.0) and perform the relaying function. This is basically DPI and would ha= ve to be implemented in hardware for it to work efficiently... If you work = in an virtualized environment, I expect it would slow down the BR. I don't think this is an issue=97as long as the BR is willing to received p= ackets sent to 255.255.255.255 over the tunnel, they will be delivered to t= he relay agent process on the BR by the IP stack without requiring any DPI.= That's something that would need to be documented and implemented, but a= s Ole has said, it already works on IOS, presumably without DPI. From ian.farrer@telekom.de Thu Jun 13 08:50: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 5C0D821F997F for ; Thu, 13 Jun 2013 08:50:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.949 X-Spam-Level: X-Spam-Status: No, score=-2.949 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 9B5u4qp0Vrhy for ; Thu, 13 Jun 2013 08:50:02 -0700 (PDT) Received: from tcmail23.telekom.de (tcmail23.telekom.de [80.149.113.243]) by ietfa.amsl.com (Postfix) with ESMTP id C1D1D21F88A9 for ; Thu, 13 Jun 2013 08:50:01 -0700 (PDT) Received: from he111631.emea1.cds.t-internal.com ([10.134.93.23]) by tcmail21.telekom.de with ESMTP/TLS/AES128-SHA; 13 Jun 2013 17:49:55 +0200 Received: from HE111643.EMEA1.CDS.T-INTERNAL.COM ([10.134.93.12]) by HE111631.emea1.cds.t-internal.com ([::1]) with mapi; Thu, 13 Jun 2013 17:49:55 +0200 From: To: Date: Thu, 13 Jun 2013 17:49:50 +0200 Thread-Topic: [dhcwg] Fwd: New Version Notification for draft-troan-dhc-dhcpv4osw-00.txt Thread-Index: Ac5oTaX+UL/wpQNwTaiWh2+1Wp8zuA== 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.5.130515 acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: dhcwg@ietf.org Subject: Re: [dhcwg] Fwd: New Version Notification for draft-troan-dhc-dhcpv4osw-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: Thu, 13 Jun 2013 15:50:08 -0000 Hi Ole, I'm just doing an update to draft-ietf-dhc-v4configuration. Could you have a look through the DHCPv4oSW relevant sections and see if you think that any changes need to be made based on your draft / this discussion? Cheers, Ian On 13/06/2013 11:29, "Ole Troan" wrote: >Ian, > >> Thinking a little further on this, there's a bigger problem here. The >>DHCP >> relay in the BR can catch the broadcast DHCP messages for address >> allocations and create MAPping rules accordingly. However, the DHCP >> release mechanism is unicast based, so how does remove the MAPping rules >> once the DHCPv4 lease is no longer valid? Also, what about addresses >>that >> don't get cleanly released and expire in the DHCPv4 server? >>=20 >> To fix this, either the DHCPv4 server has to be co-located in the BR, or >> there's going to need to be a lot of DPI on DHCP unicast messages >>passing >> through the BR, with corresponding lifetimes attached to the MAP rules. > >the DHCPv4 relay _could_ force all DHCP traffic to go through itself, by >rewriting the server id. >that's apparently quite common, see RFC5107. > >you do bring up a good point though; a stateful relay is really at odds >with the MAP architecture of stateless BRs >where CEs use anycast to get to them. >any time you want redundancy you'd have a problem. > >(to others following the discussion, we're now discussing the case of >LW46 with complete indepdence >between IPv6 and IPv4 address, and where there is also no dependency >between IPv6 provisioning >and IPv4 provisioning. none of this matter of course, if you just use >DHCPv4 to get other configuration >information) > >an out of band mechanism to populate per subscriber LW46/MAP state, would >allow for stateless DHCP relays. [ian] I think that the problem here is because successful softwire provisioning in the BR is fundamental to how this works, then it's not enough to say that an out of band mechanism will take care of this. It needs to be covered It does also mean that DHCPv4 over softwire is linked to having a softwire. If another (non-softwire) reason for needing to provision IPv4 over and IPv6 native network appears in the future, then it's going to need a softwire deployment. > >btw: force renew, that's not something generally used is it? cause >supporting that I think would require the server to >include the client's UDP port in the binding, while otherwise it would >not be required. [ian] I don=B9t have any plans for using force renew. You can generally get enough control with lease lengths. > >cheers, >Ole > From akostur@incognito.com Thu Jun 13 11:36:48 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 B919C21F925A for ; Thu, 13 Jun 2013 11:36:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.177 X-Spam-Level: X-Spam-Status: No, score=-3.177 tagged_above=-999 required=5 tests=[AWL=-2.800, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, GB_SUMOF=5, HTML_MESSAGE=0.001, J_CHICKENPOX_28=0.6, 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 OBPM95R5786o for ; Thu, 13 Jun 2013 11:36:36 -0700 (PDT) Received: from na3sys010aog110.obsmtp.com (na3sys010aog110.obsmtp.com [74.125.245.88]) by ietfa.amsl.com (Postfix) with SMTP id 3577721F8C40 for ; Thu, 13 Jun 2013 11:36:35 -0700 (PDT) Received: from mail-ve0-f170.google.com ([209.85.128.170]) (using TLSv1) by na3sys010aob110.postini.com ([74.125.244.12]) with SMTP ID DSNKUboRM0vFdQJaHIls82Tx7ERL2dmi2cdh@postini.com; Thu, 13 Jun 2013 11:36:36 PDT Received: by mail-ve0-f170.google.com with SMTP id 14so8080739vea.1 for ; Thu, 13 Jun 2013 11:36:34 -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=BguXh6miFut5PZZ0zmxvNzcwuP/gDYs2jZeFUXBQCR8=; b=TI4eFtXrInk0ixnKsZW+o6DqZ0j7J7Ha6TAEScRA1JbeKr8WwN/6Oz5QD74jGxL47v /NOtXKPT2tIXN/mHqFL2qltFZ/OjaEp4weM8AxUoAOvj6fJBk52qPOdDluu9Bi+p8rCQ NnRrj1LDZthWcyGSap98jaYBS9W0o7jYrMIGeaYwNMMMf3GpuWiV/F8FoLsQiKvv5B86 imNo0PCInAbQAy8J4B1t3R3mc5BskMPYiqKTEGRnEd3csVZSZ/2ZumvZdktK/GxvIM5S ZsIa3V4ii3uwKuq7ifad6VP633a8PnrQ53qFvFom0wpT+UtuodRI7IbG44vqbUc0YjIt ZCkw== X-Received: by 10.220.170.72 with SMTP id c8mr926232vcz.14.1371148594569; Thu, 13 Jun 2013 11:36:34 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.220.170.72 with SMTP id c8mr926223vcz.14.1371148594378; Thu, 13 Jun 2013 11:36:34 -0700 (PDT) Received: by 10.221.49.73 with HTTP; Thu, 13 Jun 2013 11:36:34 -0700 (PDT) In-Reply-To: <51B77A69.7010602@gmail.com> References: <51B77A69.7010602@gmail.com> Date: Thu, 13 Jun 2013 11:36:34 -0700 Message-ID: From: Andre Kostur To: Tomek Mrugalski Content-Type: multipart/alternative; boundary=001a11c2d024e7159a04df0d684b X-Gm-Message-State: ALoCoQkPOzHJyu5DDRj3jpS6s0tivm2suK9yVIZ8Xb78vEo2/JEv8LW3wPT9uS8cQWVEqQf294rJC5/CpA2Ia77JCpt7sHwcqZaZ3VP61X2GfX+xzalcqmUPkQ5Nj9WZJGnDez0Vl2MsyfyWHV6OhvlZwSuZ/NLrXA== Cc: DHC WG Subject: Re: [dhcwg] Comments on draft-ietf-dhc-dhcpv6-load-balancing-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, 13 Jun 2013 18:36:48 -0000 --001a11c2d024e7159a04df0d684b Content-Type: text/plain; charset=ISO-8859-1 Some general clarification questions (inline): On Tue, Jun 11, 2013 at 12:28 PM, Tomek Mrugalski < tomasz.mrugalski@gmail.com> wrote: Section 3.1.2: A question about "A DHCPv6 server receiving a REQUEST or > RENEW with the server's Server ID specified MAY answer the request even > if the request would normally be ignored by load balancing.". Does it > mean that the opposite is true - server MAY chose to not answer if the > load balancing says so, even when server-id matches? That's what rest of > the first paragraph suggests. If that is what you meant, then I strongly > oppose. Here's why: > I don't think it says that. The servers are still doing the logic of "If the client is supplying a server ID, and it's not me, don't process this packet." (Not including potential logic of discarding an advertised IA as it has seen that a different DHCP server is being chosen, or other such logic). Also barring server policy causing it to ignore that packet for other reasons. The text mentions a case of 2 servers, with the first one going offline > and the second server taking over all clients. The text says that once > the first server recovers and the second server ignores RENEWs, > eventually the first server will be able to respond clients that start > REBINDing. This will cause the clients to constantly go through > REQUEST->failed RENEW attempts->REBIND cycles, even when both servers > are fine. Nothing really gained, but you just introduced REBINDs to > perfectly healthy network (with the extra processing needed for REBINDs > and possible warnings all around, as REBIND is usually a sign of troubles). > This shouldn't result in a constant cycle, only one cycle (where "primary client" == a client which should be answered by the primary server in a LB+Failover pair, and "secondary client" == a client which should be answered by the secondary server in a LB+Failover pair): 1) All servers are healthy 2) Primary server fails 3) A set of clients come online. (mix of primary and secondary clients). The Secondary clients are perfectly happy as the secondary server is still online. The primary clients get serviced by the secondary server as well, as the secondary server knows that the primary is offline. 4) Primary server is restored 5) Secondary clients can Renew as the secondary server never went away 6) Primary clients Renewing against the secondary server get ignored 7) Primary clients transition to Rebind, where the primary server then answers them. The clients then remember that the primary server answered and will do future Renews to the primary. This is only one cycle of failed RENEW -> REBIND. Security considerations section is nice, but not sufficient. You also > mention that by misconfiguring HBA, administrators can fail to service > certain group of users and finding a pattern in such a group would be > difficult. As a practical aspect, debugging off-by-1 issues would be > tricky e.g. first server handles 1-127 and the second handles 128-255 > (who is serving bucket 0?). Some warning about it - that the sum of all > Hash Bucket Assignments of all servers must cover the whole range - > would be useful. > Are these security considerations, or just potential configuration errors? > Another concern that security considerations is missing is > misconfiguration between relays and servers. If you do load balancing on > relays, then you should not do another one on servers. And if you do, > you just increase you chances to make configuration error, because load > balancing configuration on relays must match load balancing > configuration on servers. It would be good to have some trade-offs > discussed for LB done on servers vs on relays. > Again, are these security considerations, or just potential configuration errors? -- *Andre Kostur* Distinguished Software Architect & Engineer *P:* 604-678-2864 *E:* akostur@incognito.com *Toll-Free:* 1-800-877-1856 *F:* 604-678-2864 *VoIP:* sip:864@sip.incognito.com [image: Incognito Software Inc.] --001a11c2d024e7159a04df0d684b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Some general clarification questions (inline):


On Tue, Jun 11, 2013 at= 12:28 PM, Tomek Mrugalski <tomasz.mrugalski@gmail.com> wrote:

Section 3.1.2: A question about &q= uot;A DHCPv6 server receiving a REQUEST or
RENEW with the server's Server ID specified MAY answer the request even=
if the request would normally be ignored by load balancing.". Does it<= br> mean that the opposite is true - server MAY chose to not answer if the
load balancing says so, even when server-id matches? That's what rest o= f
the first paragraph suggests. If that is what you meant, then I strongly oppose. Here's why:

I don'= ;t think it says that. =A0The servers are still doing the logic of "If= the client is supplying a server ID, and it's not me, don't proces= s this packet." =A0(Not including potential logic of discarding an adv= ertised IA as it has seen that a different DHCP server is being chosen, or = other such logic). =A0Also barring server policy causing it to ignore that = packet for other reasons.

The text mentions a case of 2 servers, with the first one going offline
and the second server taking over all clients. The text says that once
the first server recovers and the second server ignores RENEWs,
eventually the first server will be able to respond clients that start
REBINDing. This will cause the clients to constantly go through
REQUEST->failed RENEW attempts->REBIND cycles, even when both servers=
are fine. Nothing really gained, but you just introduced REBINDs to
perfectly healthy network (with the extra processing needed for REBINDs
and possible warnings all around, as REBIND is usually a sign of troubles).=

This shouldn't result in a c= onstant cycle, only one cycle (where "primary client" =3D=3D a cl= ient which should be answered by the primary server in a LB+Failover pair, = and "secondary client" =3D=3D a client which should be answered b= y the secondary server in a LB+Failover pair):
1) All servers are healthy
2) Primary server fai= ls
3) A set of clients come online. =A0(mix of primary and = secondary clients). =A0The Secondary clients are perfectly happy as the sec= ondary server is still online. =A0The primary clients get serviced by the s= econdary server as well, as the secondary server knows that the primary is = offline.
4) Primary server is restored
5) Secondary clien= ts can Renew as the secondary server never went away
6) Pri= mary clients Renewing against the secondary server get ignored
7) Primary clients transition to Rebind, where the primary server then answ= ers them. =A0The clients then remember that the primary server answered and= will do future Renews to the primary.

This is only one cycle of failed RENEW -> REBIND.

Security considerations section is nice,= but not sufficient. You also
mention that by misconfiguring HBA, administrators can fail to service
certain group of users and finding a pattern in such a group would be
difficult. As a practical aspect, debugging off-by-1 issues would be
tricky e.g. first server handles 1-127 and the second handles 128-255
(who is serving bucket 0?). Some warning about it - that the sum of all
Hash Bucket Assignments of all servers must cover the whole range -
would be useful.

Are these securi= ty considerations, or just potential configuration errors?
= =A0
Another concern that security considerations is missing is
misconfiguration between relays and servers. If you do load balancing on relays, then you should not do another one on servers. And if you do,
you just increase you chances to make configuration error, because load
balancing configuration on relays must match load balancing
configuration on servers. It would be good to have some trade-offs
discussed for LB done on servers vs on relays.

Again, are these security considerations, or just potential c= onfiguration errors?

--
Andre Kostu= r
Distinguished Software Architect & Engineer
P: 604-678-2864
E: akostur@incognito.com
Toll-Free: 1-800-877= -1856

F: 604-678-2864
VoIP: sip:864@sip= .incognito.com

3D"Incognito

--001a11c2d024e7159a04df0d684b-- From Branimir.Rajtar@t.ht.hr Fri Jun 14 00:43:46 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 DF64521F9C45 for ; Fri, 14 Jun 2013 00:43:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.799 X-Spam-Level: X-Spam-Status: No, score=-1.799 tagged_above=-999 required=5 tests=[AWL=0.800, 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 zmb+bRvkTMS7 for ; Fri, 14 Jun 2013 00:43:41 -0700 (PDT) Received: from mx01.t.ht.hr (mx01.t.ht.hr [195.29.161.88]) by ietfa.amsl.com (Postfix) with SMTP id 4377621F9C0C for ; Fri, 14 Jun 2013 00:43:40 -0700 (PDT) Received: from (unknown [172.17.66.76]) by mx01.t.ht.hr with smtp id 237e_02a1_204d9190_d4c6_11e2_9564_00221951415f; Fri, 14 Jun 2013 09:43:38 +0200 Received: from S2010EXCHCA1.ad.local ([10.240.132.138]) by mailgw.ad.local with Microsoft SMTPSVC(6.0.3790.4675); Fri, 14 Jun 2013 09:43:38 +0200 Received: from S2010EXCH1.ad.local ([fe80::2d7b:39dd:876e:f277]) by S2010EXCHCA1.ad.local ([::1]) with mapi id 14.03.0123.003; Fri, 14 Jun 2013 09:43:38 +0200 From: Branimir Rajtar To: Ted Lemon Thread-Topic: [dhcwg] New Version Notification for draft-troan-dhc-dhcpv4osw-00.txt Thread-Index: AQHOaEWYZm3X/slqf0y2LxVLiCUGEZk00cMQ Date: Fri, 14 Jun 2013 07:43:37 +0000 Message-ID: <786F13AA11E69F4DB2CCA23F7400C2FB01467296@S2010EXCH1.ad.local> References: <20130612112504.2403.22751.idtracker@ietfa.amsl.com> <32536718-0436-4463-A54F-92D484E09B1D@employees.org> <786F13AA11E69F4DB2CCA23F7400C2FB01466694@S2010EXCH1.ad.local> <8D23D4052ABE7A4490E77B1A012B6307751D5774@mbx-01.win.nominum.com> In-Reply-To: <8D23D4052ABE7A4490E77B1A012B6307751D5774@mbx-01.win.nominum.com> 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: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginalArrivalTime: 14 Jun 2013 07:43:38.0543 (UTC) FILETIME=[E20FCBF0:01CE68D2] X-NAIMIME-Disclaimer: 1 X-NAIMIME-Modified: 1 Cc: "dhcwg@ietf.org WG" Subject: Re: [dhcwg] New Version Notification for draft-troan-dhc-dhcpv4osw-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: Fri, 14 Jun 2013 07:43:47 -0000 SGksCgpJJ20gbm90IHN1cmUgd2hldGhlciBvciBub3QgSSBhZ3JlZSBvbiB0aGlzIG9uZS4gVGhl IEJSIHNob3VsZCBvbmx5IHBlcmZvcm0gImR1bWIiIGVuY2Fwc3VsYXRpb24gYW5kIGRlY2Fwc3Vs YXRpb24gb2YgSVAgaGVhZGVycywgYW5kIG1hdGNoIHRoZW0gdG8gdGhlIG1hcHBpbmcgdGFibGUu IElmIG5vIG1hdGNoIGlzIGZvdW5kLCB0aGUgQlIgd291bGQgdGhlbiBoYXZlIHRvIHN0cmlwIHRo ZSBJUHY2IGhlYWRlciBhbmQgY2hlY2sgd2hldGhlciBvciBub3QgdGhlIGRlc3RpbmF0aW9uIElQ IGFkZHJlc3MgaXMgMjU1LjI1NS4yNTUuMjU1LiBhbmQgYWZ0ZXJ3YXJkcyBjaGVjayB0aGUgc291 cmNlIFVEUCBwb3J0LiAgSU1ITywgdGhpcyB3b3VsZCBtZXNzIHVwIHRoZSBoYXJkd2FyZSBvcHRp bWl6YXRpb24gaWYgeW91J3JlIGRvaW5nIGVuY2FwLWRlY2FwIG9ubHkuCgpIb3dldmVyLCBJIHBy b3Bvc2Ugbm90IHRvIHdhc3RlIG1vcmUgdGltZSBvbiB0aGlzIHRvcGljIHNpbmNlIGl0J3Mgbm90 IHJlYWxseSBzaWduaWZpY2FudCB0byB0aGUgb3ZlcmFsbCBkaXNjdXNzaW9uLiBPdGhlcndpc2Us IEkgdGhpbmsgd2UgY291bGQgd2FzdGUgZGF5cyBvbiB0aGlzIDopCgpCcmFuaW1pcgoKCi0tLS0t T3JpZ2luYWwgTWVzc2FnZS0tLS0tCkZyb206IFRlZCBMZW1vbiBbbWFpbHRvOlRlZC5MZW1vbkBu b21pbnVtLmNvbV0gClNlbnQ6IFRodXJzZGF5LCBKdW5lIDEzLCAyMDEzIDQ6NTIgUE0KVG86IEJy YW5pbWlyIFJhanRhcgpDYzogT2xlIFRyb2FuOyBkaGN3Z0BpZXRmLm9yZyBXRwpTdWJqZWN0OiBS ZTogW2RoY3dnXSBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LXRyb2FuLWRoYy1k aGNwdjRvc3ctMDAudHh0CgpPbiBKdW4gMTIsIDIwMTMsIGF0IDk6MzMgQU0sIEJyYW5pbWlyIFJh anRhciA8QnJhbmltaXIuUmFqdGFyQHQuaHQuaHI+IHdyb3RlOgo+IElmIHRoZSBCUiB3b3JrcyBp biBESENQIHJlbGF5IG1vZGUsIGF0IHRoZSBpbml0aWFsIGNvbW11bmljYXRpb24gaXQgd2lsbCBo YXZlIHRvIGNoZWNrIGlmIHRoZSBzb3VyY2UgVURQIHBvcnQgaXMgNjggKGdpdmVuIHRoZSBzb3Vy Y2UgYWRkcmVzcyBpcyAwLjAuMC4wKSBhbmQgcGVyZm9ybSB0aGUgcmVsYXlpbmcgZnVuY3Rpb24u IFRoaXMgaXMgYmFzaWNhbGx5IERQSSBhbmQgd291bGQgaGF2ZSB0byBiZSBpbXBsZW1lbnRlZCBp biBoYXJkd2FyZSBmb3IgaXQgdG8gd29yayBlZmZpY2llbnRseS4uLiBJZiB5b3Ugd29yayBpbiBh biB2aXJ0dWFsaXplZCBlbnZpcm9ubWVudCwgSSBleHBlY3QgaXQgd291bGQgc2xvdyBkb3duIHRo ZSBCUi4KCkkgZG9uJ3QgdGhpbmsgdGhpcyBpcyBhbiBpc3N1ZS1hcyBsb25nIGFzIHRoZSBCUiBp cyB3aWxsaW5nIHRvIHJlY2VpdmVkIHBhY2tldHMgc2VudCB0byAyNTUuMjU1LjI1NS4yNTUgb3Zl ciB0aGUgdHVubmVsLCB0aGV5IHdpbGwgYmUgZGVsaXZlcmVkIHRvIHRoZSByZWxheSBhZ2VudCBw cm9jZXNzIG9uIHRoZSBCUiBieSB0aGUgSVAgc3RhY2sgd2l0aG91dCByZXF1aXJpbmcgYW55IERQ SS4gICBUaGF0J3Mgc29tZXRoaW5nIHRoYXQgd291bGQgbmVlZCB0byBiZSBkb2N1bWVudGVkIGFu ZCBpbXBsZW1lbnRlZCwgYnV0IGFzIE9sZSBoYXMgc2FpZCwgaXQgYWxyZWFkeSB3b3JrcyBvbiBJ T1MsIHByZXN1bWFibHkgd2l0aG91dCBEUEkuCgoKCjxIVE1MPjxQPjxGT05UIGZhY2U9QXJpYWwg Y29sb3I9Izk5OTk5OSBzaXplPTE+DQoNCklaSkFWQSBPIE9EUklDQU5KVSBPREdPVk9STk9TVEk6 IFNhZHLFvmFqIG92ZSBwb3J1a2UgaSBldmVudHVhbG5vIHByaWxvxb5lbmloIGRhdG90ZWthIGpl IHBvdmplcmxqaXYgaSBuYW1pamVuamVuIGplIHNhbW8gb3NvYmFtYSBpbGkgc3ViamVrdGltYSBr b2ppIHN1IG5hdmVkZW5pIHUgYWRyZXNpLiBVa29saWtvIHN0ZSBwcmltaWxpIG92dSBwb3J1a3Ug Z3JlxaFrb20sIG1vbGltbyBWYXMsIG9iYXZpamVzdGl0ZSBwb8WhaWxqYXRlbGphLCBhIHBvcnVr dSBpIHN2ZSBuamVuZSBwcml2aXRrZSBvZG1haCwgYmV6IMSNaXRhbmphLCB0cmFqbm8gdWtsb25p dGUgcyByYcSNdW5hbGEuIEJpbG8ga2Frdm8gcHJlbm/FoWVuamUsIGtvcGlyYW5qZSBpbGkgZGlz dHJpYnVjaWphIGluZm9ybWFjaWphIHNhZHLFvmFuaWggdSBwb3J1Y2kgdHJlxIdpbSBvc29iYW1h IGplIHphYnJhbmplbm8gaSBtb8W+ZSBiaXRpIHpha29uc2tpIGthxb5uaml2by4gU2FkcsW+YWos IHN0YXZvdmkgaSBtacWhbGplbmphIGl6bmVzZW5pIHUgcG9ydWNpIHN1IGF1dG9yb3ZpIGkgbmUg cHJlZHN0YXZsamFqdSBudcW+bm8gc3Rhdm92ZSBIVCAtIEhydmF0c2tpaCB0ZWxla29tdW5pa2Fj aWphIGQuZC4gSFQgbmUgcHJpaHZhxIdhIG5pa2FrdnUgb2Rnb3Zvcm5vc3QgemEgZXZlbnR1YWxu dSDFoXRldHUgbmFzdGFsdSBwcmltaXRrb20gb3ZlIHBvcnVrZSBpIHByaWxvZ2Egc2FkcsW+YW5p aCB1IHBvcnVjaS4NCg0KPC9GT05UPjwvUD48UD48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPSM5OTk5 OTkgc2l6ZT0xPg0KDQogRElTQ0xBSU1FUjpUaGUgY29udGVudHMgb2YgdGhpcyBlbWFpbCBhcyB3 ZWxsIGFzIGFueSBmaWxlcyBhdHRhY2hlZCB0byBpdCBhcmUgY29uZmlkZW50aWFsIGFuZCBpbnRl bmRlZCBzb2xlbHkgZm9yIGluZGl2aWR1YWxzIG9yIGVudGl0aWVzIHdoaWNoIHRoZXkgYXJlIGFk ZHJlc3NlZCB0by4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBtZXNzYWdlIGluIGVy cm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgYW5kIHBlcm1hbmVudGx5IHJlbW92ZSB0aGUg bWVzc2FnZSBhbmQgYWxsIGF0dGFjaGVkIGZpbGVzIGZyb20gdGhlIGNvbXB1dGVyLiBBbnkgZGlz Y2xvc3VyZSwgY29weWluZyBvciBkaXN0cmlidXRpb24gb2YgYWxsIG9yIGEgcGFydCBvZiBpbmZv cm1hdGlvbiBjb250YWluZWQgaGVyZWluIHRvIG9yIGJ5IHRoaXJkIHBhcnRpZXMgaXMgcHJvaGli aXRlZCBhbmQgbWF5IGJlIHVubGF3ZnVsLiBQbGVhc2Ugbm90ZSB0aGF0IGFueSB2aWV3cyBvciBv cGluaW9ucyBwcmVzZW50ZWQgaW4gdGhpcyBtZXNzYWdlIGFyZSBzb2xlbHkgdGhvc2Ugb2YgdGhl IGF1dGhvciBhbmQgZG8gbm90IG5lY2Vzc2FyaWx5IHJlcHJlc2VudCB0aGUgdmlld3MgYW5kIG9w aW5pb25zIG9mIENyb2F0aWFuIFRlbGVjb20gSW5jLiBDcm9hdGlhbiBUZWxlY29tIEluYy4gYWNj ZXB0cyBubyBsaWFiaWxpdHkgZm9yIGFueSBwb3RlbnRpYWwgZGFtYWdlIGNhdXNlZCBieSB0aGlz IG1lc3NhZ2UgYW5kIGZpbGVzIGF0dGFjaGVkIHRvIGl0Lg0KDQo8L0ZPTlQ+PC9QPjwvSFRNTD4K From Ted.Lemon@nominum.com Fri Jun 14 03:30:38 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 C246821F9AF7 for ; Fri, 14 Jun 2013 03:30:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.607 X-Spam-Level: X-Spam-Status: No, score=-106.607 tagged_above=-999 required=5 tests=[AWL=-0.008, 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 GN6-nYi0LqGe for ; Fri, 14 Jun 2013 03:30:32 -0700 (PDT) Received: from exprod7og117.obsmtp.com (exprod7og117.obsmtp.com [64.18.2.6]) by ietfa.amsl.com (Postfix) with ESMTP id EA74821F9AEC for ; Fri, 14 Jun 2013 03:30:31 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob117.postini.com ([64.18.6.12]) with SMTP ID DSNKUbrwx1eBgLWqpIlc5/ydI7bwiE9q8/3n@postini.com; Fri, 14 Jun 2013 03:30:31 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 A73571B81E0 for ; Fri, 14 Jun 2013 03:30:31 -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 9FBD7190060; Fri, 14 Jun 2013 03:30:31 -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; Fri, 14 Jun 2013 03:30:31 -0700 From: Ted Lemon To: Branimir Rajtar Thread-Topic: [dhcwg] New Version Notification for draft-troan-dhc-dhcpv4osw-00.txt Thread-Index: AQHOaEWYZm3X/slqf0y2LxVLiCUGEZk00cMQgACnboA= Date: Fri, 14 Jun 2013 10:30:31 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B6307751D73F1@mbx-01.win.nominum.com> References: <20130612112504.2403.22751.idtracker@ietfa.amsl.com> <32536718-0436-4463-A54F-92D484E09B1D@employees.org> <786F13AA11E69F4DB2CCA23F7400C2FB01466694@S2010EXCH1.ad.local> <8D23D4052ABE7A4490E77B1A012B6307751D5774@mbx-01.win.nominum.com> <786F13AA11E69F4DB2CCA23F7400C2FB01467296@S2010EXCH1.ad.local> In-Reply-To: <786F13AA11E69F4DB2CCA23F7400C2FB01467296@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="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dhcwg@ietf.org WG" Subject: Re: [dhcwg] New Version Notification for draft-troan-dhc-dhcpv4osw-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: Fri, 14 Jun 2013 10:30:38 -0000 On Jun 14, 2013, at 3:43 AM, Branimir Rajtar wrot= e: > I'm not sure whether or not I agree on this one. The BR should only perfo= rm "dumb" encapsulation and decapsulation of IP headers, and match them to = the mapping table. If no match is found, the BR would then have to strip th= e IPv6 header and check whether or not the destination IP address is 255.25= 5.255.255. and afterwards check the source UDP port. IMHO, this would mess= up the hardware optimization if you're doing encap-decap only. Oh, interesting. I see your point. Maybe the BR doesn't have an IPv4 ad= dress. Thanks for being persistent in getting that point across=97I wasn'= t even thinking in that direction. From otroan@employees.org Fri Jun 14 03:39:19 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 B220321F9C3D for ; Fri, 14 Jun 2013 03:39:19 -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 WaC8sU7w9SmR for ; Fri, 14 Jun 2013 03:39:06 -0700 (PDT) Received: from ams-iport-4.cisco.com (ams-iport-4.cisco.com [144.254.224.147]) by ietfa.amsl.com (Postfix) with ESMTP id 274BB21F9C17 for ; Fri, 14 Jun 2013 03:39:06 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAPvxulGQ/khM/2dsb2JhbABagwm8UYMCgQYWdIIjAQEBAwF3AhALRlcGiBsGukuPFTMHgn9hA6kDgxE6 X-IronPort-AV: E=Sophos;i="4.87,865,1363132800"; d="scan'208";a="14701340" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-4.cisco.com with ESMTP; 14 Jun 2013 10:39:02 +0000 Received: from dhcp-10-61-99-159.cisco.com (dhcp-10-61-99-159.cisco.com [10.61.99.159]) by ams-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r5EAcxtw013700 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 14 Jun 2013 10:38:59 GMT Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Ole Troan In-Reply-To: <8D23D4052ABE7A4490E77B1A012B6307751D73F1@mbx-01.win.nominum.com> Date: Fri, 14 Jun 2013 12:38:58 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <24FC6E06-280D-456B-8434-98D71A38DCA3@employees.org> References: <20130612112504.2403.22751.idtracker@ietfa.amsl.com> <32536718-0436-4463-A54F-92D484E09B1D@employees.org> <786F13AA11E69F4DB2CCA23F7400C2FB01466694@S2010EXCH1.ad.local> <8D23D4052ABE7A4490E77B1A012B6307751D5774@mbx-01.win.nominum.com> <786F13AA11E69F4DB2CCA23F7400C2FB01467296@S2010EXCH1.ad.local> <8D23D4052ABE7A4490E77B1A012B6307751D73F1@mbx-01.win.nominum.com> To: Ted Lemon X-Mailer: Apple Mail (2.1508) Cc: "dhcwg@ietf.org WG" Subject: Re: [dhcwg] New Version Notification for draft-troan-dhc-dhcpv4osw-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: Fri, 14 Jun 2013 10:39:19 -0000 Ted, >> I'm not sure whether or not I agree on this one. The BR should only = perform "dumb" encapsulation and decapsulation of IP headers, and match = them to the mapping table. If no match is found, the BR would then have = to strip the IPv6 header and check whether or not the destination IP = address is 255.255.255.255. and afterwards check the source UDP port. = IMHO, this would mess up the hardware optimization if you're doing = encap-decap only. >=20 > Oh, interesting. I see your point. Maybe the BR doesn't have an = IPv4 address. Thanks for being persistent in getting that point = across=97I wasn't even thinking in that direction. the BR is the device connecting the MAP domain to the IPv4 Internet. it = has an IPv4 address. cheers, Ole= From Ted.Lemon@nominum.com Fri Jun 14 04:36:37 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 6FFF021F9C1E for ; Fri, 14 Jun 2013 04:36:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.607 X-Spam-Level: X-Spam-Status: No, score=-106.607 tagged_above=-999 required=5 tests=[AWL=-0.008, 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 rHvSZMmBLioq for ; Fri, 14 Jun 2013 04:36:30 -0700 (PDT) Received: from exprod7og104.obsmtp.com (exprod7og104.obsmtp.com [64.18.2.161]) by ietfa.amsl.com (Postfix) with ESMTP id A9AB421F9BEB for ; Fri, 14 Jun 2013 04:36:30 -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 DSNKUbsAPi2cU9ic8jKDKOHfj0ejFxdmKaCv@postini.com; Fri, 14 Jun 2013 04:36:30 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 372941B81EA for ; Fri, 14 Jun 2013 04:36:30 -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 2BFEC19005D; Fri, 14 Jun 2013 04:36:30 -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; Fri, 14 Jun 2013 04:36:30 -0700 From: Ted Lemon To: Ole Troan Thread-Topic: [dhcwg] New Version Notification for draft-troan-dhc-dhcpv4osw-00.txt Thread-Index: AQHOaOtkCBN6Wmd3ZkukPWXFfMZXUZk1ilSA Date: Fri, 14 Jun 2013 11:36:29 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B6307751D75E2@mbx-01.win.nominum.com> References: <20130612112504.2403.22751.idtracker@ietfa.amsl.com> <32536718-0436-4463-A54F-92D484E09B1D@employees.org> <786F13AA11E69F4DB2CCA23F7400C2FB01466694@S2010EXCH1.ad.local> <8D23D4052ABE7A4490E77B1A012B6307751D5774@mbx-01.win.nominum.com> <786F13AA11E69F4DB2CCA23F7400C2FB01467296@S2010EXCH1.ad.local> <8D23D4052ABE7A4490E77B1A012B6307751D73F1@mbx-01.win.nominum.com> <24FC6E06-280D-456B-8434-98D71A38DCA3@employees.org> In-Reply-To: <24FC6E06-280D-456B-8434-98D71A38DCA3@employees.org> 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: <85AFF715FCBD7C43A4DFA0BCC50AA1E7@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dhcwg@ietf.org WG" Subject: Re: [dhcwg] New Version Notification for draft-troan-dhc-dhcpv4osw-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: Fri, 14 Jun 2013 11:36:37 -0000 On Jun 14, 2013, at 6:38 AM, Ole Troan wrote: > the BR is the device connecting the MAP domain to the IPv4 Internet. it h= as an IPv4 address. Is this a given? Of course it will relay packets addressed to client IPv4= addresses to those clients, but does it have to have its _own_ IPv4 addres= s? Does it have to have an IPv4 stack? Serious questions=97I am by no m= eans an expert on this, but I don't see why this would necessarily be the c= ase. I guess if you mean that the BR is a router through which all AFTR traffic = is routed, and is not itself necessarily an AFTR, then you'd be right, but = in that case the BR doesn't have access to the IPv6 address of the client, = and doesn't even know which client a particular packet came from. From otroan@employees.org Fri Jun 14 05:37: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 1C4CC21F9C8C for ; Fri, 14 Jun 2013 05:37:32 -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 SKr+ZPcRwAN7 for ; Fri, 14 Jun 2013 05:37:27 -0700 (PDT) Received: from ams-iport-3.cisco.com (ams-iport-3.cisco.com [144.254.224.146]) by ietfa.amsl.com (Postfix) with ESMTP id F2D5B21F9C8A for ; Fri, 14 Jun 2013 05:37:20 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AowIAAoOu1GQ/khM/2dsb2JhbABagwkwqxuUCIEGFnSCIwEBAQMBawwCBQsLRlcGiBsGDLpDjxUzB4J/YQOYapAZgxE6 X-IronPort-AV: E=Sophos;i="4.87,866,1363132800"; d="scan'208";a="14234686" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-3.cisco.com with ESMTP; 14 Jun 2013 12:37:17 +0000 Received: from dhcp-10-61-97-28.cisco.com (dhcp-10-61-97-28.cisco.com [10.61.97.28]) by ams-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r5ECbETc021339 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 14 Jun 2013 12:37:14 GMT Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Ole Troan In-Reply-To: <8D23D4052ABE7A4490E77B1A012B6307751D75E2@mbx-01.win.nominum.com> Date: Fri, 14 Jun 2013 14:37:14 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <38964714-AD44-4320-BB92-D3823889F044@employees.org> References: <20130612112504.2403.22751.idtracker@ietfa.amsl.com> <32536718-0436-4463-A54F-92D484E09B1D@employees.org> <786F13AA11E69F4DB2CCA23F7400C2FB01466694@S2010EXCH1.ad.local> <8D23D4052ABE7A4490E77B1A012B6307751D5774@mbx-01.win.nominum.com> <786F13AA11E69F4DB2CCA23F7400C2FB01467296@S2010EXCH1.ad.local> <8D23D4052ABE7A4490E77B1A012B6307751D73F1@mbx-01.win.nominum.com> <24FC6E06-280D-456B-8434-98D71A38DCA3@employees.org> <8D23D4052ABE7A4490E77B1A012B6307751D75E2@mbx-01.win.nominum.com> To: Ted Lemon X-Mailer: Apple Mail (2.1508) Cc: "dhcwg@ietf.org WG" Subject: Re: [dhcwg] New Version Notification for draft-troan-dhc-dhcpv4osw-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: Fri, 14 Jun 2013 12:37:32 -0000 Ted, >> the BR is the device connecting the MAP domain to the IPv4 Internet. = it has an IPv4 address. >=20 > Is this a given? Of course it will relay packets addressed to client = IPv4 addresses to those clients, but does it have to have its _own_ IPv4 = address? Does it have to have an IPv4 stack? Serious questions=97I = am by no means an expert on this, but I don't see why this would = necessarily be the case. yes, that is a given. please read = http://tools.ietf.org/html/draft-ietf-softwire-map-07 > I guess if you mean that the BR is a router through which all AFTR = traffic is routed, and is not itself necessarily an AFTR, then you'd be = right, but in that case the BR doesn't have access to the IPv6 address = of the client, and doesn't even know which client a particular packet = came from. MAP Border Relay (BR): A MAP enabled router managed by the service provider at the edge of a MAP domain. A Border Relay router has at least an IPv6-enabled interface and an IPv4 interface connected to the native IPv4 network. A MAP BR may also be referred to simply as a "BR" within the context of MAP. cheers, Ole From Ted.Lemon@nominum.com Fri Jun 14 05:47: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 BBA4E21F9C77 for ; Fri, 14 Jun 2013 05:47:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.607 X-Spam-Level: X-Spam-Status: No, score=-106.607 tagged_above=-999 required=5 tests=[AWL=-0.008, 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 7B+GaZOvCu+o for ; Fri, 14 Jun 2013 05:46:54 -0700 (PDT) Received: from exprod7og124.obsmtp.com (exprod7og124.obsmtp.com [64.18.2.26]) by ietfa.amsl.com (Postfix) with ESMTP id 0AE4921F9C76 for ; Fri, 14 Jun 2013 05:46:53 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob124.postini.com ([64.18.6.12]) with SMTP ID DSNKUbsQvcU25ryTxuHrc/JgWGKP/1ZWlOA0@postini.com; Fri, 14 Jun 2013 05:46:54 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 8669F1B81EA for ; Fri, 14 Jun 2013 05:46:53 -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 7BD3719005D; Fri, 14 Jun 2013 05:46:53 -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; Fri, 14 Jun 2013 05:46:53 -0700 From: Ted Lemon To: Ole Troan Thread-Topic: [dhcwg] New Version Notification for draft-troan-dhc-dhcpv4osw-00.txt Thread-Index: AQHOaOtkCBN6Wmd3ZkukPWXFfMZXUZk1ilSAgAAQ+QCAAAKwgA== Date: Fri, 14 Jun 2013 12:46:52 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B6307751D7767@mbx-01.win.nominum.com> References: <20130612112504.2403.22751.idtracker@ietfa.amsl.com> <32536718-0436-4463-A54F-92D484E09B1D@employees.org> <786F13AA11E69F4DB2CCA23F7400C2FB01466694@S2010EXCH1.ad.local> <8D23D4052ABE7A4490E77B1A012B6307751D5774@mbx-01.win.nominum.com> <786F13AA11E69F4DB2CCA23F7400C2FB01467296@S2010EXCH1.ad.local> <8D23D4052ABE7A4490E77B1A012B6307751D73F1@mbx-01.win.nominum.com> <24FC6E06-280D-456B-8434-98D71A38DCA3@employees.org> <8D23D4052ABE7A4490E77B1A012B6307751D75E2@mbx-01.win.nominum.com> <38964714-AD44-4320-BB92-D3823889F044@employees.org> In-Reply-To: <38964714-AD44-4320-BB92-D3823889F044@employees.org> 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: <18939B9381C1AE48BF241B7253487AC2@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dhcwg@ietf.org WG" Subject: Re: [dhcwg] New Version Notification for draft-troan-dhc-dhcpv4osw-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: Fri, 14 Jun 2013 12:47:01 -0000 On Jun 14, 2013, at 8:37 AM, Ole Troan wrote: >> Is this a given? Of course it will relay packets addressed to client I= Pv4 addresses to those clients, but does it have to have its _own_ IPv4 add= ress? Does it have to have an IPv4 stack? Serious questions=97I am by n= o means an expert on this, but I don't see why this would necessarily be th= e case. >=20 > yes, that is a given. please read http://tools.ietf.org/html/draft-ietf-s= oftwire-map-07 How does that work with load balancing? Does the map solution also cover = the lw4over6 application in the unified CPE? From otroan@employees.org Fri Jun 14 05:55:57 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 C134921F9BA0 for ; Fri, 14 Jun 2013 05:55:57 -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 Pf9gcVKufVHl for ; Fri, 14 Jun 2013 05:55:53 -0700 (PDT) Received: from ams-iport-3.cisco.com (ams-iport-3.cisco.com [144.254.224.146]) by ietfa.amsl.com (Postfix) with ESMTP id D09B821F9C78 for ; Fri, 14 Jun 2013 05:55:52 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao0IAJQRu1GQ/khM/2dsb2JhbABagwkwqxuUCIEGFnSCIwEBAQMBJ0QMAhALRlcGLodtBgy6O48VMweCf2EDmGqQGYMROg X-IronPort-AV: E=Sophos;i="4.87,866,1363132800"; d="scan'208";a="14235432" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-3.cisco.com with ESMTP; 14 Jun 2013 12:55:52 +0000 Received: from dhcp-10-61-97-28.cisco.com (dhcp-10-61-97-28.cisco.com [10.61.97.28]) by ams-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r5ECtnAK027463 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 14 Jun 2013 12:55:49 GMT Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Ole Troan In-Reply-To: <8D23D4052ABE7A4490E77B1A012B6307751D7767@mbx-01.win.nominum.com> Date: Fri, 14 Jun 2013 14:55:48 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130612112504.2403.22751.idtracker@ietfa.amsl.com> <32536718-0436-4463-A54F-92D484E09B1D@employees.org> <786F13AA11E69F4DB2CCA23F7400C2FB01466694@S2010EXCH1.ad.local> <8D23D4052ABE7A4490E77B1A012B6307751D5774@mbx-01.win.nominum.com> <786F13AA11E69F4DB2CCA23F7400C2FB01467296@S2010EXCH1.ad.local> <8D23D4052ABE7A4490E77B1A012B6307751D73F1@mbx-01.win.nominum.com> <24FC6E06-280D-456B-8434-98D71A38DCA3@employees.org> <8D23D4052ABE7A4490E77B1A012B6307751D75E2@mbx-01.win.nominum.com> <38964714-AD44-4320-BB92-D3823889F044@employees.org> <8D23D4052ABE7A4490E77B1A012B6307751D7767@mbx-01.win.nominum.com> To: Ted Lemon X-Mailer: Apple Mail (2.1508) Cc: "dhcwg@ietf.org WG" Subject: Re: [dhcwg] New Version Notification for draft-troan-dhc-dhcpv4osw-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: Fri, 14 Jun 2013 12:55:57 -0000 Ted, >>> Is this a given? Of course it will relay packets addressed to = client IPv4 addresses to those clients, but does it have to have its = _own_ IPv4 address? Does it have to have an IPv4 stack? Serious = questions=97I am by no means an expert on this, but I don't see why this = would necessarily be the case. >>=20 >> yes, that is a given. please read = http://tools.ietf.org/html/draft-ietf-softwire-map-07 >=20 > How does that work with load balancing? Does the map solution also = cover the lw4over6 application in the unified CPE? yes, to last question. for the first one: in the CE -> BR direction. the BRs use an IPv6 anycast address (the same = address for all BRs) as their tunnel endpoint. i.e the routing system = between the CE and BR determines which BR to send to. (and that's the = reason a stateless DHCP relay would definitely be the safest choice). in the inbound BR direction (from the Internet), multiple BRs advertise = a route for the same IPv4 prefix. given equal routing costs you'll achieve ECMP. cheers, Ole From volz@cisco.com Fri Jun 14 19:17: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 8C9E521F9B42 for ; Fri, 14 Jun 2013 19:17:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.798 X-Spam-Level: X-Spam-Status: No, score=-7.798 tagged_above=-999 required=5 tests=[AWL=-2.800, BAYES_00=-2.599, GB_SUMOF=5, HTML_MESSAGE=0.001, J_CHICKENPOX_28=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 5yOrLVBBJRXI for ; Fri, 14 Jun 2013 19:17:37 -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 F23DD21F9B40 for ; Fri, 14 Jun 2013 19:17:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=29608; q=dns/txt; s=iport; t=1371262657; x=1372472257; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=TAKkDZCQkMIltEDffYj/jM1yPwG4gey5PVI/xb4Mb3o=; b=ZcKBwHPMrVTaKnuRxCToZLttE0qLVE8vjQvIlJ819cha7IEgMdUtV44R iOBVVznUBkgIyr8xI6Gxc5K04SGGD9cFynyr6rZR3JDQTIT2JLTQZU/oW C2sL1KPAOso9AGPdrnk/5SRu3nx2kz48LOxzAmGWOSizGWBVXRqB+MRuB 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AoYFAEfNu1GtJV2d/2dsb2JhbABYA4JFRDBJq0CTBIEMFnSCIwEBAQQnBj8FAQcQAgEIDgMEAQELCgwBBgchERQJBwECAQMBDQUIh3QDDwyxIA2IUoxVDoE+dgYHFBAGAQYDCIJuYQOVWo4FhSSCP1CCKA X-IronPort-AV: E=Sophos;i="4.87,870,1363132800"; d="scan'208,217";a="223093896" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-6.cisco.com with ESMTP; 15 Jun 2013 02:17:35 +0000 Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id r5F2HZqc029115 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 15 Jun 2013 02:17:35 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.77]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.02.0318.004; Fri, 14 Jun 2013 21:17:35 -0500 From: "Bernie Volz (volz)" To: Andre Kostur , Tomek Mrugalski Thread-Topic: [dhcwg] Comments on draft-ietf-dhc-dhcpv6-load-balancing-00 Thread-Index: AQHOaGT5h2Y2cGySzkmuybY9484vhJk2BiJg Date: Sat, 15 Jun 2013 02:17:34 +0000 Message-ID: <489D13FBFA9B3E41812EA89F188F018E185A27A6@xmb-rcd-x04.cisco.com> References: <51B77A69.7010602@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.255.84] Content-Type: multipart/alternative; boundary="_000_489D13FBFA9B3E41812EA89F188F018E185A27A6xmbrcdx04ciscoc_" MIME-Version: 1.0 Cc: DHC WG Subject: Re: [dhcwg] Comments on draft-ietf-dhc-dhcpv6-load-balancing-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: Sat, 15 Jun 2013 02:17:42 -0000 --_000_489D13FBFA9B3E41812EA89F188F018E185A27A6xmbrcdx04ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Andre: The client will retransmit the Renews between T1 and T2. See Section 18.1.3= (of 3315): The client transmits the message according to section 14, using the following parameters: IRT REN_TIMEOUT MRT REN_MAX_RT MRC 0 MRD Remaining time until T2 But this also happens for all of the clients trying to renew with a server = that is down. (And the retransmission rate is somewhat controlled - though = it may be high if you have a LOT of clients.) Perhaps section 3.1.2 of the draft can be reworded to make it clear that a = load balancing implementation has two choices: 1. Process Renews (and Requests) as specified in RFC 3315 (no load ba= lancing). 2. Process Renews (and Requests) as specified in RFC 3315 with load b= alancing (thus the clients are moved back to the "load balancing" server wh= en they Rebind). For v4, we only do #1 in our load balancing/failover implementation. BTW: With DHCPv6 and failover there actually is a "third" choice which coul= d be possible. Use a single server-id for the failover relationship. Then, = load balancing is always used when the failover partners are in "normal" st= ate. This is something worth exploring - I'm not certain that this doesn't = potentially create some problems. It has some nice benefits too in that Rel= ease and Declines would be processed by the "up" partner even if it wasn't = the one that communicated with the client. Though I think this might be be= tter documented in one of the failover documents (though it might need to b= e a new document as failover design considers load balancing out-of-scope). "Relay" is only mentioned once, in the Abstract. I wonder whether that (las= t) sentence should be removed. I don't think the Relay is worth it and prob= ably underspecified given that it is only mentioned once. - Bernie From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of A= ndre Kostur Sent: Thursday, June 13, 2013 2:37 PM To: Tomek Mrugalski Cc: DHC WG Subject: Re: [dhcwg] Comments on draft-ietf-dhc-dhcpv6-load-balancing-00 Some general clarification questions (inline): On Tue, Jun 11, 2013 at 12:28 PM, Tomek Mrugalski > wrote: Section 3.1.2: A question about "A DHCPv6 server receiving a REQUEST or RENEW with the server's Server ID specified MAY answer the request even if the request would normally be ignored by load balancing.". Does it mean that the opposite is true - server MAY chose to not answer if the load balancing says so, even when server-id matches? That's what rest of the first paragraph suggests. If that is what you meant, then I strongly oppose. Here's why: I don't think it says that. The servers are still doing the logic of "If t= he client is supplying a server ID, and it's not me, don't process this pac= ket." (Not including potential logic of discarding an advertised IA as it = has seen that a different DHCP server is being chosen, or other such logic)= . Also barring server policy causing it to ignore that packet for other re= asons. The text mentions a case of 2 servers, with the first one going offline and the second server taking over all clients. The text says that once the first server recovers and the second server ignores RENEWs, eventually the first server will be able to respond clients that start REBINDing. This will cause the clients to constantly go through REQUEST->failed RENEW attempts->REBIND cycles, even when both servers are fine. Nothing really gained, but you just introduced REBINDs to perfectly healthy network (with the extra processing needed for REBINDs and possible warnings all around, as REBIND is usually a sign of troubles). This shouldn't result in a constant cycle, only one cycle (where "primary c= lient" =3D=3D a client which should be answered by the primary server in a = LB+Failover pair, and "secondary client" =3D=3D a client which should be an= swered by the secondary server in a LB+Failover pair): 1) All servers are healthy 2) Primary server fails 3) A set of clients come online. (mix of primary and secondary clients). = The Secondary clients are perfectly happy as the secondary server is still = online. The primary clients get serviced by the secondary server as well, = as the secondary server knows that the primary is offline. 4) Primary server is restored 5) Secondary clients can Renew as the secondary server never went away 6) Primary clients Renewing against the secondary server get ignored 7) Primary clients transition to Rebind, where the primary server then answ= ers them. The clients then remember that the primary server answered and w= ill do future Renews to the primary. This is only one cycle of failed RENEW -> REBIND. Security considerations section is nice, but not sufficient. You also mention that by misconfiguring HBA, administrators can fail to service certain group of users and finding a pattern in such a group would be difficult. As a practical aspect, debugging off-by-1 issues would be tricky e.g. first server handles 1-127 and the second handles 128-255 (who is serving bucket 0?). Some warning about it - that the sum of all Hash Bucket Assignments of all servers must cover the whole range - would be useful. Are these security considerations, or just potential configuration errors? Another concern that security considerations is missing is misconfiguration between relays and servers. If you do load balancing on relays, then you should not do another one on servers. And if you do, you just increase you chances to make configuration error, because load balancing configuration on relays must match load balancing configuration on servers. It would be good to have some trade-offs discussed for LB done on servers vs on relays. Again, are these security considerations, or just potential configuration e= rrors? -- Andre Kostur Distinguished Software Architect & Engineer P: 604-678-2864 E: akostur@incognito.com Toll-Free: 1-800-877-1856 F: 604-678-2864 VoIP: sip:864@sip.incognito.com [Incognito Software Inc.] [http://www.incognito.com/img/sig/banner.gif] --_000_489D13FBFA9B3E41812EA89F188F018E185A27A6xmbrcdx04ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Andre:<= /p>

 <= /p>

<WG cochair hat off>= ;

 <= /p>

The client will retransmi= t the Renews between T1 and T2. See Section 18.1.3 (of 3315):

 <= /p>

   The client tran= smits the message according to section 14, using the

   following param= eters:

 

    &nbs= p; IRT   REN_TIMEOUT

 

    &nbs= p; MRT   REN_MAX_RT

 

    &nbs= p; MRC   0

 

    &nbs= p; MRD   Remaining time until T2

 <= /p>

But this also happens for= all of the clients trying to renew with a server that is down. (And the re= transmission rate is somewhat controlled – though it may be high if you have a LOT of clients.)

 <= /p>

Perhaps section 3.1.2 of = the draft can be reworded to make it clear that a load balancing implementa= tion has two choices:

1. = ;      Process Renews (a= nd Requests) as specified in RFC 3315 (no load balancing).

2. = ;      Process Renews (a= nd Requests) as specified in RFC 3315 with load balancing (thus the clients= are moved back to the “load balancing” server when they Rebind).

 <= /p>

For v4, we only do #1 in = our load balancing/failover implementation.

 <= /p>

BTW: With DHCPv6 and fail= over there actually is a “third” choice which could be possible= . Use a single server-id for the failover relationship. Then, load balancin= g is always used when the failover partners are in “normal” stat= e. This is something worth exploring - I’m not certain that this does= n’t potentially create some problems. It has some nice benefits too i= n that Release and Declines would be processed by the “up” partner even if it wasn’t the one that communicated with the client.=  Though I think this might be better documented in one of the failove= r documents (though it might need to be a new document as failover design c= onsiders load balancing out-of-scope).

 

 <= /p>

“Relay” is on= ly mentioned once, in the Abstract. I wonder whether that (last) sentence s= hould be removed. I don’t think the Relay is worth it and probably un= derspecified given that it is only mentioned once.

 <= /p>

- =          Bernie=

 <= /p>

From: dhcwg-bo= unces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of Andre Kostur
Sent: Thursday, June 13, 2013 2:37 PM
To: Tomek Mrugalski
Cc: DHC WG
Subject: Re: [dhcwg] Comments on draft-ietf-dhc-dhcpv6-load-balancin= g-00

 

Some general clarification questions (inline):<= /o:p>

 

On Tue, Jun 11, 2013 at 12:28 PM, Tomek Mrugalski &l= t;tomasz.mr= ugalski@gmail.com> wrote:

 

Section 3.1.2: A question about "A DHCPv6 serve= r receiving a REQUEST or
RENEW with the server's Server ID specified MAY answer the request even
if the request would normally be ignored by load balancing.". Does it<= br> mean that the opposite is true - server MAY chose to not answer if the
load balancing says so, even when server-id matches? That's what rest of the first paragraph suggests. If that is what you meant, then I strongly oppose. Here's why:

 

I don't think it says that.  The servers are st= ill doing the logic of "If the client is supplying a server ID, and it= 's not me, don't process this packet."  (Not including potential = logic of discarding an advertised IA as it has seen that a different DHCP server is being chosen, or other such logic).  Also = barring server policy causing it to ignore that packet for other reasons.

 

The text mentions a case of 2 servers, with the firs= t one going offline
and the second server taking over all clients. The text says that once
the first server recovers and the second server ignores RENEWs,
eventually the first server will be able to respond clients that start
REBINDing. This will cause the clients to constantly go through
REQUEST->failed RENEW attempts->REBIND cycles, even when both servers=
are fine. Nothing really gained, but you just introduced REBINDs to
perfectly healthy network (with the extra processing needed for REBINDs
and possible warnings all around, as REBIND is usually a sign of troubles).=

 

This shouldn't result in a constant cycle, only one = cycle (where "primary client" =3D=3D a client which should be ans= wered by the primary server in a LB+Failover pair, and "secondary = client" =3D=3D a client which should be answered by the secondary server in a LB+Failover pair):

1) All servers are healthy

2) Primary server fails

3) A set of clients come online.  (mix of prima= ry and secondary clients).  The Secondary clients are perfectly happy = as the secondary server is still online.  The primary clients get serv= iced by the secondary server as well, as the secondary server knows that the primary is offline.

4) Primary server is restored

5) Secondary clients can Renew as the secondary serv= er never went away

6) Primary clients Renewing against the secondary se= rver get ignored

7) Primary clients transition to Rebind, where the p= rimary server then answers them.  The clients then remember that the p= rimary server answered and will do future Renews to the primary.=

 

This is only one cycle of failed RENEW -> REBIND.=

 

Security considerations section is nice, but not suf= ficient. You also
mention that by misconfiguring HBA, administrators can fail to service
certain group of users and finding a pattern in such a group would be
difficult. As a practical aspect, debugging off-by-1 issues would be
tricky e.g. first server handles 1-127 and the second handles 128-255
(who is serving bucket 0?). Some warning about it - that the sum of all
Hash Bucket Assignments of all servers must cover the whole range -
would be useful.

 

Are these security considerations, or just potential= configuration errors?

 

Another concern that security considerations is miss= ing is
misconfiguration between relays and servers. If you do load balancing on relays, then you should not do another one on servers. And if you do,
you just increase you chances to make configuration error, because load
balancing configuration on relays must match load balancing
configuration on servers. It would be good to have some trade-offs
discussed for LB done on servers vs on relays.

 

Again, are these security considerations, or just po= tential configuration errors?

 

--

Andre Kostur
Distinguished Software Architect & Engineer
P: 604-678-2864 E: akostu= r@incognito.com
Toll-Free: 1-800-87= 7-1856



F: 604-678-2864 VoIP: sip:864@sip.incognito.co= m


3D"Incogn=


 

--_000_489D13FBFA9B3E41812EA89F188F018E185A27A6xmbrcdx04ciscoc_-- From otroan@employees.org Tue Jun 18 02:08: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 7F58F21F9BFA for ; Tue, 18 Jun 2013 02:08:50 -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_53=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 uaQqDYIgn4mH for ; Tue, 18 Jun 2013 02:08:44 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 5D81E21F99F6 for ; Tue, 18 Jun 2013 02:08:44 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjMFAEMjwFGQ/khL/2dsb2JhbABZgwnAAn4WdIIjAQEBAwFuCQIFCwsSNEkONIdtBrpSjg2BBTMHgn9hA5NvlRWDETqBLA X-IronPort-AV: E=Sophos;i="4.87,887,1363132800"; d="scan'208";a="83436613" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-2.cisco.com with ESMTP; 18 Jun 2013 09:08:35 +0000 Received: from dhcp-10-61-111-107.cisco.com (dhcp-10-61-111-107.cisco.com [10.61.111.107]) by ams-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r5I98Wf2005447 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 18 Jun 2013 09:08:33 GMT Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Ole Troan In-Reply-To: Date: Tue, 18 Jun 2013 11:08:32 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <4F4DD2A3-A7B4-4D43-ADA1-95A107472EBD@employees.org> References: To: ian.farrer@telekom.de X-Mailer: Apple Mail (2.1508) Cc: dhcwg@ietf.org Subject: Re: [dhcwg] New Version Notification for draft-troan-dhc-dhcpv4osw-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: Tue, 18 Jun 2013 09:08:50 -0000 Ian, > I'm just doing an update to draft-ietf-dhc-v4configuration. Could you = have > a look through the DHCPv4oSW relevant sections and see if you think = that > any changes need to be made based on your draft / this discussion? let me give it a try. (with my limited knowledge of DHCPv4). from the draft: 3.3. DHCPv4oSW Based Provisioning 3.3.1. Pros 1. Once implemented, all existing DHCPv4 options will be be available with no further ongoing development work necessary. 2. Uses the existing DHCPv4 and DHCPv6 architectures in order to provide IPv4 configuration in an IPv6 only environment. 3. DHCPv4 and DHCPv6 based provisioning can be separated from each other if required, allowing flexibility in network design. * correct, but there might be an issue where the IPv4 address is = configured both in DHCPv4 and with the DHCPv6 MAP option. 3.3.2. Cons 1. More complex, in that there are more new functional elements within the architecture than are necessary in DHCPv6 based provisioning. * my position is that it is less new function elements. in that it just = reuses DHCPv4 as is. then we can argue over how big the tweaks actually turn = out to be of course. clearly it is more complex than just running DHCPv6 and not doing = anything additional with DHCPv4, but that's not what this draft is about right. 2. IPv4 over IPv6 softwire approaches which distribute NAT to the CPE and allow for IP address sharing (MAP-E & LW4o6) forbid the use of reserved TCP/UDP ports (e.g. 0-1024). Every DHCPv4 client sharing the same address needs to have a UDP listener running on UDP port 68. To resolve this would require significant rework to either the softwire mechanisms and/or the DHCPv4 client implementation. it is as simple as making the DHCPv4 client, relay and server port = aware. e.g. the ISC client supports setting port with a command line option = already. 3. =46rom the current specification, DHCPINFORM is not suitable for use over a softwire. Additional work, such as the development of 'shims' would be necessary I was suggesting to support full blown DHCPv4, including DHCPINFORM of = course. isn't this point applicable to _any_ use of DHCPINFORM, if how it is = supposed to work isn't clear? 4. The current DHCPINFORM specification has a number of unclear points, such as those described in [I-D.ietf-dhc-dhcpinform-clarify]. Substantial work would be required to resolve this. again is this specific to DHCPv4 over softwire, or does it apply to the other DHCPv4 encaps as well? 5. Links the deployment of IPv4 configuration over IPv6 to a softwire implementation (e.g. requiring a softwire concentrator to act as a DHCPv4 relay). Whilst softwires are the only application for this functionality at the moment, this may not always be the case. yes, I view that as a good thing. that the provisioning path follow the = forwarding path. and it is equivalent to how DHCPv4 is configured today. the PE is a = DHCPv4 relay. 6. A new mechanism must be defined in order to provide the DHCPv4 client with the IPv4 address of the DHCPv4 server so that unicast DHCPINFORM messages can be sent. the biggest change to this draft, is that all DHCPv4 messages are = supported. 7. As only DHCPINFORM/DHCPACK DHCPv4 message types are supported, dynamic IPv4 address leasing (using DHCPDISCOVER messages) can not be used. again, this point should be removed. all messages can be supported. 8. The approach is unproven as no existing implementations exist. partly true. given that we don't have the MAP DHCPv6 option yet. as I said on the mailing list I did try DHCPv4 over a public 4over6 = tunnel, and that worked without changes. that's not fully applicable to a shared IPv4 = tunnel obviously. regardless of solution here, some new work is required, so point 8 = probably applies to all mechanisms in your analysis. cheers, Ole= From sunqi.csnet.thu@gmail.com Tue Jun 18 18:14: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 8DF2521E805A for ; Tue, 18 Jun 2013 18:14:40 -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 743anmQR-0UX for ; Tue, 18 Jun 2013 18:14:35 -0700 (PDT) Received: from mail-pd0-f178.google.com (mail-pd0-f178.google.com [209.85.192.178]) by ietfa.amsl.com (Postfix) with ESMTP id 4FDCD11E8116 for ; Tue, 18 Jun 2013 18:14:35 -0700 (PDT) Received: by mail-pd0-f178.google.com with SMTP id w11so4500269pde.37 for ; Tue, 18 Jun 2013 18:14:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=JuP62j4A4NyX6ozreElDsjce7SbOQXl+coIocp7fLRk=; b=ruj653y8GrIfChjlfO2SBTO5AR8grXqFjA+Zrynl98eR3Cfu0MnHbWpK6tld70bVUU FzWx0ld/flXdnwXxLrqyvdQcnz77kdxkwiZmpRXlj8cts8zM0NbSt1A4Ulm3oIVfrUxE Oy/4bdSqOd9zzYZiShSJZPUgeYBtOaSov2q5iKGECw0jAI51LBTy4l85OJb8ZysuTiPP W+qw1ic4Xoiz0WMzB4LFNkV0oZHmHIAJQLIEz8LnXRyG7sZpjtgrAOThB5QiQyXYcFn6 pCf6wn/5XyPdw2kNBlt+jq2Bh86kmpbXPKZ1439zRRgARV5o8GNWQKGXa7yn616dORbM mQZw== X-Received: by 10.68.247.101 with SMTP id yd5mr458910pbc.57.1371604474981; Tue, 18 Jun 2013 18:14:34 -0700 (PDT) Received: from [192.168.0.107] ([114.255.40.13]) by mx.google.com with ESMTPSA id ka16sm15689869pad.14.2013.06.18.18.14.32 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 18 Jun 2013 18:14:34 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=windows-1252 From: Qi Sun In-Reply-To: Date: Wed, 19 Jun 2013 09:14:25 +0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130612112504.2403.22751.idtracker@ietfa.amsl.com> <32536718-0436-4463-A54F-92D484E09B1D@employees.org> <786F13AA11E69F4DB2CCA23F7400C2FB01466694@S2010EXCH1.ad.local> <8D23D4052ABE7A4490E77B1A012B6307751D5774@mbx-01.win.nominum.com> <786F13AA11E69F4DB2CCA23F7400C2FB01467296@S2010EXCH1.ad.local> <8D23D4052ABE7A4490E77B1A012B6307751D73F1@mbx-01.win.nominum.com> <24FC6E06-280D-456B-8434-98D71A38DCA3@employees.org> <8D23D4052ABE7A4490E77B1A012B6307751D75E2@mbx-01.win.nominum.com> <38964714-AD44-4320-BB92-D3823889F044@employees.org> <8D23D4052ABE7A4490E77B1A012B6307751D7767@mbx-01.win.nominum.com> To: Ole Troan X-Mailer: Apple Mail (2.1084) Cc: "dhcwg@ietf.org WG" , Ted Lemon Subject: Re: [dhcwg] New Version Notification for draft-troan-dhc-dhcpv4osw-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, 19 Jun 2013 01:14:40 -0000 Hi Ole, >>>> Is this a given? Of course it will relay packets addressed to = client IPv4 addresses to those clients, but does it have to have its = _own_ IPv4 address? Does it have to have an IPv4 stack? Serious = questions=97I am by no means an expert on this, but I don't see why this = would necessarily be the case. >>>=20 >>> yes, that is a given. please read = http://tools.ietf.org/html/draft-ietf-softwire-map-07 >>=20 >> How does that work with load balancing? Does the map solution also = cover the lw4over6 application in the unified CPE? >=20 > yes, to last question. [Qi] Just to be clear, I do NOT intend to initiate the debates between = lw4over6 and MAP, which happened in the Softwire WG. Just tell the WG = what is lw4over6 from my understanding. IMO, lw4over6 is designed to keep IPv4 and IPv6 addressing independent. = So it doesn't relay on IPv6 prefix delegation. Additionally, it supports = on-demand IPv4-over-IPv6 service, while MAP advocates a static mapping = (determined by MAP rules). I think that's why lw4over6 intends to use = DHCPv4-over-IPv6 (currently it SHOULD use DHCPv4-over-DHCPv6), PCP, = etc., which can maintain IPv4 leases dynamically. > for the first one: > in the CE -> BR direction. the BRs use an IPv6 anycast address (the = same address for all BRs) as their tunnel endpoint. i.e the routing = system between the CE and BR determines which BR to send to. (and that's = the reason a stateless DHCP relay would definitely be the safest = choice). > in the inbound BR direction (from the Internet), multiple BRs = advertise a route for the same IPv4 prefix. >=20 > given equal routing costs you'll achieve ECMP. >=20 > cheers, > Ole >=20 > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg From Carl.Wuyts@technicolor.com Thu Jun 20 06: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 CBA1921F9C46 for ; Thu, 20 Jun 2013 06:37:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.109 X-Spam-Level: X-Spam-Status: No, score=-5.109 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, HTML_MESSAGE=0.001, 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 2La9CWxyRsza for ; Thu, 20 Jun 2013 06:36:54 -0700 (PDT) Received: from na3sys009aog136.obsmtp.com (na3sys009aog136.obsmtp.com [74.125.149.85]) by ietfa.amsl.com (Postfix) with ESMTP id 3FD3421F9B52 for ; Thu, 20 Jun 2013 06:36:54 -0700 (PDT) Received: from mopesedge02.eu.thmulti.com ([129.35.174.203]) (using TLSv1) by na3sys009aob136.postini.com ([74.125.148.12]) with SMTP ID DSNKUcMFdRO4oHQ+MAnUeDwPaxihSlZxjUEJ@postini.com; Thu, 20 Jun 2013 06:36:54 PDT Received: from MOPESMAILHC03.eu.thmulti.com (141.11.100.132) by mopesedge02.eu.thmulti.com (141.11.253.23) with Microsoft SMTP Server (TLS) id 8.3.297.1; Thu, 20 Jun 2013 15:36:36 +0200 Received: from MOPESMBX01.eu.thmulti.com ([169.254.1.119]) by MOPESMAILHC03.eu.thmulti.com ([141.11.100.132]) with mapi; Thu, 20 Jun 2013 15:36:41 +0200 From: Wuyts Carl To: dhc WG Date: Thu, 20 Jun 2013 15:36:40 +0200 Thread-Topic: SOL_MAX_RT Thread-Index: Ac5tuzIYxeZC9ZDHS/CUJRT7Dqteog== Message-ID: <3135C2851EB6764BACEF35D8B495596806E7DAB304@MOPESMBX01.eu.thmulti.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_3135C2851EB6764BACEF35D8B495596806E7DAB304MOPESMBX01eut_" MIME-Version: 1.0 Subject: [dhcwg] SOL_MAX_RT 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, 20 Jun 2013 13:37:00 -0000 --_000_3135C2851EB6764BACEF35D8B495596806E7DAB304MOPESMBX01eut_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I think I've popped up the question already some months ago, but I don't th= ink there's any progress on this. The SOL_MAX_RT document is still draft-only, and the assigned option is sti= ll '"TBD". The RFC6204-12 says: WAA-8: The CE router must support the SOL_MAX_RT option [I-D.droms-dhc-dhcpv6-solmaxrt-update] and request the SOL_MAX_RT option in an ORO. This is kind of "tricky" as lots of times you can see that implementations = must be compliant with RFC6204-versionXX, but one cannot be compliant as th= e option number is still not assigned, so in fact, no single router can be = compliant with RFc6204 today. So, today, only possibility is to include support in a proprietary option o= r something? Thx for the feedback. Regs Carl --_000_3135C2851EB6764BACEF35D8B495596806E7DAB304MOPESMBX01eut_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

I think I&= #8217;ve popped up the question already some months ago, but I don’t = think there’s any progress on this.

The SOL_MAX_RT document is still draft-only, and the assigned option is s= till ‘”TBD”.

&nbs= p;

The RFC6204-12 says:

WAA-8:   The CE router mus= t support the SOL_MAX_RT option

        &nb= sp;   [I-D.droms-dhc-dhcpv6-solmaxrt-update] and request the=

  =          SOL_MAX_RT option in= an ORO.

 

This is kind of “tricky” as lots of times you= can see that implementations must be compliant with RFC6204-versionXX, but= one cannot be compliant as the option number is still not assigned, so in = fact, no single router can be compliant with RFc6204 today.

<= p class=3DMsoNormal>So, today, only possibility is to include support in a = proprietary option or something?

&n= bsp;

Thx for the feedback.

 

Regs<= /p>

Carl

= --_000_3135C2851EB6764BACEF35D8B495596806E7DAB304MOPESMBX01eut_-- From tomasz.mrugalski@gmail.com Thu Jun 20 07:23: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 2A0E121F9BFA for ; Thu, 20 Jun 2013 07:23:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.099 X-Spam-Level: X-Spam-Status: No, score=-0.099 tagged_above=-999 required=5 tests=[AWL=2.500, 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 ZG-jXGS6E-C8 for ; Thu, 20 Jun 2013 07:23:51 -0700 (PDT) Received: from mail-bk0-x230.google.com (mail-bk0-x230.google.com [IPv6:2a00:1450:4008:c01::230]) by ietfa.amsl.com (Postfix) with ESMTP id 186B421F9C07 for ; Thu, 20 Jun 2013 07:23:40 -0700 (PDT) Received: by mail-bk0-f48.google.com with SMTP id jf17so2899024bkc.7 for ; Thu, 20 Jun 2013 07:23:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=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=8jw9F7cC5dUAmAbO7AFkV+djb9Ye1QXYzzBC9VatpN8=; b=aJR7IwTSxOuCoYcyu+Sy4DWikKO5Tf3J2Q+CFpsz4GGIvZNpac0MJv6RS3Srg71L3M qAA5m4QBkns/fqawr2aPL9QyfKfzzVKzm5+elfVK1Xfb6naQZQQvG+x12h5Ap6Bm6ig/ n6Qo8OVhfXhFtzAs2a3dsb/lEK73u9IAaqmVLjHtl42XVfXMckkefvpDbXMbYVAYEoem 4dQeNZyo1AQgWkN9xOb1nvxeot+2cfNe3z8p/dmTgdYfSNMFx+nAuN3Hc8jk78Cxkhuy 1naxnfuuUM1bhN5VUWUbwYM9pk6SQyVmyXr2xPSDFAZ3rGiLF3S4Dfih+rIfzdkqS08q SEqA== X-Received: by 10.204.228.207 with SMTP id jf15mr1163125bkb.16.1371738219481; Thu, 20 Jun 2013 07:23:39 -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 fz10sm303697bkc.9.2013.06.20.07.23.37 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 20 Jun 2013 07:23:38 -0700 (PDT) Message-ID: <51C31065.8040804@gmail.com> Date: Thu, 20 Jun 2013 16:23:33 +0200 From: Tomek Mrugalski User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: dhcwg@ietf.org References: <3135C2851EB6764BACEF35D8B495596806E7DAB304@MOPESMBX01.eu.thmulti.com> In-Reply-To: <3135C2851EB6764BACEF35D8B495596806E7DAB304@MOPESMBX01.eu.thmulti.com> X-Enigmail-Version: 1.4.6 X-TagToolbar-Keys: D20130620162333943 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Subject: Re: [dhcwg] SOL_MAX_RT 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, 20 Jun 2013 14:23:52 -0000 On 20.06.2013 15:36, Wuyts Carl wrote: > Hi, > > I think I’ve popped up the question already some months ago, but I don’t > think there’s any progress on this. > > The SOL_MAX_RT document is still draft-only, and the assigned option is > still ‘”TBD”. > > The RFC6204-12 says: There's no such thing as RFC6204-12. RFCs do not have revision numbers. What I think you are referring to is draft-ietf-v6ops-6204bis-12, right? Thats an internet draft, not a published RFC. > WAA-8: The CE router must support the SOL_MAX_RT option > > [I-D.droms-dhc-dhcpv6-solmaxrt-update] and request the > > SOL_MAX_RT option in an ORO. > > > > This is kind of “tricky” as lots of times you can see that > implementations must be compliant with RFC6204-versionXX, but one cannot This statement is incorrect. There is only one version of RFC6204. What you are likely talking about is rfc6204bis - a nickname that was given for an internet draft that will eventually be published as updated version of RFC6204. It is currently a draft revision 12. It is not yet published as RFC and it not a standard. There are couple issues here. Let me explain them one by one: 1. draft-ietf-v6ops-6204bis-12 has normative reference to droms-dhc-dhcpv6-solmaxrt-update. That draft was replaced by draft-ietf-dhc-dhcpv6-solmaxrt-update. Note the difference in name - it is a working group item now. draft-ietf-v6ops-6204bis-13 (if published) should have that reference updated. 2. RFC editor will not publish draft-ietf-v6ops-6204bis-XY as RFC until all its normative references are published or ready for publication. That is the case with draft-ietf-dhc-dhcpv6-solmaxrt-update here. This process is called clustering. See http://www.rfc-editor.org/cluster_def.html. 3. Ralph plans to present draft-ietf-dhc-dhcpv6-solmaxrt-update in Berlin (July/August 2013) during DHC meeting. It is likely that the WGLC will follow shortly afterwards. If you want to speed up the process, I encourage you to actively participate in draft-ietf-dhc-dhcpv6-solmaxrt-update review. Please review it and post your comments. Make sure you show your support (or objections) during WGLC. 4. IANA typically does not assign option numbers for drafts that are not ready for publication. There's very good practical reason for it. Up until publication, the draft could change or even be abandoned completely in some cases. If IANA had assigned option codes too early, people would end up with implementations based on different versions of the same option spec. In extreme cases, that would be true even if IETF decided to not standardize a given option after all. > So, today, only possibility is to include support in a proprietary > option or something? This is done strictly with my chair hat off. I'm saying this as a long time developer of DHCP server and client implementation. This worked for me well, but may not work for you. In a general case you should not release a code or product that implements draft version of a standard. If you choose to release that, put a big fat disclaimer that the option implementation is a work in progress, may not work or the behavior may change, so it may not interoperate with other implementations that happen to use later revision of the spec. For lab and interop sessions, it is ok to come up with artificial high number (e.g. 300) and use it for testing. Once the option is standardized and assuming there were no other changes in the spec, you need to only update one constant in your code and it is ready to go. Tomek From Ted.Lemon@nominum.com Thu Jun 20 07:30:57 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 9E26B21F92B7 for ; Thu, 20 Jun 2013 07:30:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.601 X-Spam-Level: X-Spam-Status: No, score=-106.601 tagged_above=-999 required=5 tests=[AWL=-0.002, 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 MX63W6fiCTA5 for ; Thu, 20 Jun 2013 07:30:51 -0700 (PDT) Received: from exprod7og109.obsmtp.com (exprod7og109.obsmtp.com [64.18.2.171]) by ietfa.amsl.com (Postfix) with ESMTP id DE0EA21F84AA for ; Thu, 20 Jun 2013 07:30:50 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob109.postini.com ([64.18.6.12]) with SMTP ID DSNKUcMSGvbxl5Tcs5nP95MDlNiGm2y2qJHl@postini.com; Thu, 20 Jun 2013 07:30:50 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 2F1FF1B81DA for ; Thu, 20 Jun 2013 07:30:50 -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 285F019005D; Thu, 20 Jun 2013 07:30:50 -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, 20 Jun 2013 07:30:44 -0700 From: Ted Lemon To: Tomek Mrugalski Thread-Topic: [dhcwg] SOL_MAX_RT Thread-Index: Ac5tuzIYxeZC9ZDHS/CUJRT7DqteogAQTiiAAAA/x4A= Date: Thu, 20 Jun 2013 14:30:43 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B6307751E2D82@mbx-01.win.nominum.com> References: <3135C2851EB6764BACEF35D8B495596806E7DAB304@MOPESMBX01.eu.thmulti.com> <51C31065.8040804@gmail.com> In-Reply-To: <51C31065.8040804@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="Windows-1252" Content-ID: <0C0295374C97C3498C9C533692423AE3@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [dhcwg] SOL_MAX_RT 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, 20 Jun 2013 14:30:57 -0000 Do we need a SOL_MAX_RT presentation in Berlin? Why not just last-call it= now? From john_brzozowski@cable.comcast.com Thu Jun 20 07:58: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 D19D121F9B34 for ; Thu, 20 Jun 2013 07:58:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.307 X-Spam-Level: X-Spam-Status: No, score=-104.307 tagged_above=-999 required=5 tests=[AWL=0.924, BAYES_00=-2.599, HOST_EQ_MODEMCABLE=1.368, 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 iODz3posQ8qz for ; Thu, 20 Jun 2013 07:58:19 -0700 (PDT) Received: from cable.comcast.com (copdcavout01.cable.comcast.com [76.96.32.253]) by ietfa.amsl.com (Postfix) with ESMTP id A638321F9B57 for ; Thu, 20 Jun 2013 07:58:03 -0700 (PDT) Received: from ([24.40.56.114]) by copdcavout01.cable.comcast.com with ESMTP id C7WM3M1.78358160; Thu, 20 Jun 2013 08:57:18 -0600 Received: from PACDCEXHUB04.cable.comcast.com (24.40.56.121) by PACDCEXHUB01.cable.comcast.com (24.40.56.114) with Microsoft SMTP Server (TLS) id 14.2.318.1; Thu, 20 Jun 2013 10:57:54 -0400 Received: from PACDCEXMB01.cable.comcast.com ([169.254.1.141]) by pacdcexhub04.cable.comcast.com ([fe80::1532:d330:f9a5:c8a1%18]) with mapi id 14.02.0318.001; Thu, 20 Jun 2013 10:57:54 -0400 From: "Brzozowski, John" Thread-Topic: [dhcwg] SOL_MAX_RT Thread-Index: Ac5tuzIYxeZC9ZDHS/CUJRT7DqteogAKBNSAAABAFID//8TVgA== Date: Thu, 20 Jun 2013 14:57:54 +0000 Message-ID: In-Reply-To: <8D23D4052ABE7A4490E77B1A012B6307751E2D82@mbx-01.win.nominum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.5.130515 x-originating-ip: [68.87.16.247] Content-Type: text/plain; charset="us-ascii" Content-ID: <24ACBA49408A1D4C9F31926476AD99C7@cable.comcast.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 To: Ted Lemon , Tomek Mrugalski Cc: "" Subject: Re: [dhcwg] SOL_MAX_RT 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, 20 Jun 2013 14:58:24 -0000 Ted I support a WGLC now. This work is very much needed still and can be advanced before Berlin. In particular the back off timers are of particular importance. I believe this work is tied into 6204bis which also needs to advance. John =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 John Jason Brzozowski Comcast Cable m) 484-962-0060 o) 609-377-6594 w) www.comcast6.net e) john_brzozowski@cable.comcast.com =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 -----Original Message----- From: Ted Lemon Date: Thursday, June 20, 2013 10:30 AM To: Tomasz Mrugalski Cc: dhc WG Subject: Re: [dhcwg] SOL_MAX_RT >Do we need a SOL_MAX_RT presentation in Berlin? Why not just last-call >it now? > >_______________________________________________ >dhcwg mailing list >dhcwg@ietf.org >https://www.ietf.org/mailman/listinfo/dhcwg From rdroms.ietf@gmail.com Thu Jun 20 08:11: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 158E121F9CF3 for ; Thu, 20 Jun 2013 08:11:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[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 moeFrfV-DoEW for ; Thu, 20 Jun 2013 08:11:45 -0700 (PDT) Received: from mail-qc0-x22e.google.com (mail-qc0-x22e.google.com [IPv6:2607:f8b0:400d:c01::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 6B35521F9AD7 for ; Thu, 20 Jun 2013 08:11:37 -0700 (PDT) Received: by mail-qc0-f174.google.com with SMTP id m15so3753140qcq.19 for ; Thu, 20 Jun 2013 08:11:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=vh6PUBRYzaTdCB7cHE3WZZo9dPWRg8QMuzmMeJeDeUY=; b=Ir1I6eDW1SvmxFicnRoOGUmmS+GayqMqLu6ZLKE0akNCRCKKbuWz0ZNH9HH63I4PRK xyjN+Gl7zBg0bFYqurzxEehg+vdJglCDsAzqjZKODcxC+ecTcwlCeRs7NieT29qyUIPI cFX3FUkN+j7n40frglBI9ZdRsPSQ0l9WZXvBK5B/kpbn1jiMRVzoVhZFUYMDQJmzfSd6 rhOHO6CeZsZQqs/IyDBMNdzYeDwci0LuqULtVOApraJzeck9m9o3VYB4ebSvM909mxFf soe4rwaRdlZmxLJwcoBTsk6JetHAZ4HYQ8Bvu9rYYmoisgyDlFKAr34ix0ly2y3neZQs LT8g== X-Received: by 10.49.82.115 with SMTP id h19mr9850742qey.62.1371741084484; Thu, 20 Jun 2013 08:11:24 -0700 (PDT) Received: from ?IPv6:2001:420:2481:20:5d57:45e7:c1d2:4e00? ([2001:420:2481:20:5d57:45e7:c1d2:4e00]) by mx.google.com with ESMTPSA id a8sm1254064qae.11.2013.06.20.08.11.20 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 20 Jun 2013 08:11:21 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Ralph Droms In-Reply-To: <8D23D4052ABE7A4490E77B1A012B6307751E2D82@mbx-01.win.nominum.com> Date: Thu, 20 Jun 2013 11:11:18 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <3135C2851EB6764BACEF35D8B495596806E7DAB304@MOPESMBX01.eu.thmulti.com> <51C31065.8040804@gmail.com> <8D23D4052ABE7A4490E77B1A012B6307751E2D82@mbx-01.win.nominum.com> To: Ted Lemon X-Mailer: Apple Mail (2.1503) Cc: "dhcwg@ietf.org WG" Subject: Re: [dhcwg] SOL_MAX_RT 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, 20 Jun 2013 15:11:59 -0000 On Jun 20, 2013, at 10:30 AM 6/20/13, Ted Lemon = wrote: > Do we need a SOL_MAX_RT presentation in Berlin? Why not just = last-call it now? OK with me. I suggested the presentation in Berlin to prompt a = discussion of two issues that were raised during the previous WG last = call: sending >1 Solicit or Information-Request after the back-off timer = expires and clarifying whether a host has to remain actively listening = for a response while waiting for the back-off timer to expire. I didn't see any declaration of consensus around either of those topics = and did not address them in -01. Personally, I would prefer to see the document proceed in its current = form and consider the other two issues in a separate document. In my = opinion, the document is ready for WG last call in its current state. At some point, I see the title should be updated to "Modification to = Default Value of SOL_MAX_RT and INF_MAX_RT". That change probably = doesn't need a presentation in Berlin. - Ralph >=20 > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg From tomasz.mrugalski@gmail.com Thu Jun 20 09:23:27 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 BCF2921F9E2B for ; Thu, 20 Jun 2013 09:23:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.049 X-Spam-Level: X-Spam-Status: No, score=-1.049 tagged_above=-999 required=5 tests=[AWL=0.950, BAYES_00=-2.599, J_CHICKENPOX_13=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 IAoRbEXPibEj for ; Thu, 20 Jun 2013 09:23:26 -0700 (PDT) Received: from mail-bk0-x22a.google.com (mail-bk0-x22a.google.com [IPv6:2a00:1450:4008:c01::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 36CFF21F9E03 for ; Thu, 20 Jun 2013 09:23:25 -0700 (PDT) Received: by mail-bk0-f42.google.com with SMTP id jk13so3042918bkc.15 for ; Thu, 20 Jun 2013 09:23:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:x-tagtoolbar-keys :content-type:content-transfer-encoding; bh=vAv5Q/VyhhnshUtn8wQCQZl03NBcZCZz89yH6NSqKIc=; b=bg8/c9cdTKBYZ88ao0rFvFgxGcf5snci8Up7fVtymULGSRZGzDjoIUyG3a2+2R4M/J 2Jwb23GASZ4IUq6RWMZSFr+1chqgVrCDoJlhhJkMH0H8xN5EsMzqsGrWvBqwEi1gSFB4 0hfbYFHDtSTzpXPHIsHGNBkaaSBEysg5eOwugp+n8KhjIotDukPpWGPtqHQZmxYVQ3nT +34bGC997TDNbgcohArwAMXhEjviYIu5WHpGElSTBCNY095+Ry991wxXupxq6ysiW47L 154LDy/JnK4U+FprfRbraZqLX9xqODuco3q8rWHPkoX4It/Nwxjajz3nSc9P04cg1wTs Kc8A== X-Received: by 10.205.66.129 with SMTP id xq1mr1187519bkb.118.1371745401461; Thu, 20 Jun 2013 09:23:21 -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 rj6sm528383bkb.12.2013.06.20.09.23.18 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 20 Jun 2013 09:23:19 -0700 (PDT) Message-ID: <51C32C73.1010203@gmail.com> Date: Thu, 20 Jun 2013 18:23:15 +0200 From: Tomek Mrugalski User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: "dhcwg@ietf.org WG" References: <3135C2851EB6764BACEF35D8B495596806E7DAB304@MOPESMBX01.eu.thmulti.com> <51C31065.8040804@gmail.com> <8D23D4052ABE7A4490E77B1A012B6307751E2D82@mbx-01.win.nominum.com> In-Reply-To: X-Enigmail-Version: 1.4.6 X-TagToolbar-Keys: D20130620182315199 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Ralph Droms , Ted Lemon Subject: [dhcwg] WGLC on draft-ietf-dhc-dhcpv6-solmaxrt-update-01 - respond by July 4 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, 20 Jun 2013 16:23:28 -0000 On 20.06.2013 17:11, Ralph Droms wrote: > On Jun 20, 2013, at 10:30 AM 6/20/13, Ted Lemon wrote: >> Do we need a SOL_MAX_RT presentation in Berlin? Why not just >> last-call it now? > > OK with me. My understanding is that under normal circumstances chairs cannot just announce WGLC on their own. They can do so if authors or editors state the the draft is ready and chairs concur with that opinion. Anyway, here it goes: Folks, the author of draft-ietf-dhc-dhcpv6-solmaxrt-update-01 (http://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-solmaxrt-update-01) feels it's ready for work group last call. Please review this draft and indicate whether or not you feel it is ready to be published. This document redefines two timers (SOL_MAX_RT and INF_MAX_RT) that control SOLICIT and INFORMATION-REQUEST message retransmissions and define a mechanism for server to override client's default values. There is a document in v6ops about basic requirements for IPv6 CE routers that depends on this work. At the time of this writing, there is no IPR reported against this draft. Bernie and I will evaluate consensus after 2013-07-04. Thanks, Bernie & Tomek From bs7652@att.com Thu Jun 20 09:47: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 B5E8721F9D01 for ; Thu, 20 Jun 2013 09:47:18 -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 IuK8aTCrfZrt for ; Thu, 20 Jun 2013 09:47:12 -0700 (PDT) Received: from nbfkord-smmo05.seg.att.com (nbfkord-smmo05.seg.att.com [209.65.160.92]) by ietfa.amsl.com (Postfix) with ESMTP id BAF2F21F9CEB for ; Thu, 20 Jun 2013 09:47:12 -0700 (PDT) Received: from unknown [144.160.20.145] (EHLO nbfkord-smmo05.seg.att.com) by nbfkord-smmo05.seg.att.com(mxl_mta-6.15.0-1) with ESMTP id 01233c15.2aaafa843940.1242241.00-583.3464371.nbfkord-smmo05.seg.att.com (envelope-from ); Thu, 20 Jun 2013 16:47:12 +0000 (UTC) X-MXL-Hash: 51c332103a8e41df-6f778c18be05c35dd981d90f1d06faa6291a76ec Received: from unknown [144.160.20.145] (EHLO mlpd192.enaf.sfdc.sbc.com) by nbfkord-smmo05.seg.att.com(mxl_mta-6.15.0-1) over TLS secured channel with ESMTP id f0233c15.0.1242221.00-419.3464309.nbfkord-smmo05.seg.att.com (envelope-from ); Thu, 20 Jun 2013 16:47:12 +0000 (UTC) X-MXL-Hash: 51c3321006e5b6dc-04245c4059fb3ac68258925d47602d9e53f2aafb Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r5KGlA2M017801; Thu, 20 Jun 2013 12:47:11 -0400 Received: from alpi132.aldc.att.com (alpi132.aldc.att.com [130.8.217.2]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r5KGl19x017671 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 20 Jun 2013 12:47:06 -0400 Received: from GAALPA1MSGHUB9F.ITServices.sbc.com (gaalpa1msghub9f.itservices.sbc.com [130.8.36.92]) by alpi132.aldc.att.com (RSA Interceptor); Thu, 20 Jun 2013 16:46:38 GMT Received: from GAALPA1MSGUSR9L.ITServices.sbc.com ([130.8.36.69]) by GAALPA1MSGHUB9F.ITServices.sbc.com ([130.8.36.92]) with mapi id 14.02.0342.003; Thu, 20 Jun 2013 12:46:45 -0400 From: "STARK, BARBARA H" To: Ralph Droms , Ted Lemon Thread-Topic: [dhcwg] SOL_MAX_RT Thread-Index: Ac5tuzIYxeZC9ZDHS/CUJRT7DqteogAKBNSAAABAFIAAAWrXAAAFIm7g Date: Thu, 20 Jun 2013 16:46:43 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E611302E4181@GAALPA1MSGUSR9L.ITServices.sbc.com> References: <3135C2851EB6764BACEF35D8B495596806E7DAB304@MOPESMBX01.eu.thmulti.com> <51C31065.8040804@gmail.com> <8D23D4052ABE7A4490E77B1A012B6307751E2D82@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: [135.70.90.82] 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.20.145] X-AnalysisOut: [v=2.0 cv=A9DbydqG c=1 sm=0 a=ZRNLZ4dFUbCvG8UMqPvVAA==:17 a] X-AnalysisOut: [=p7vvTG6fPqoA:10 a=ofMgfj31e3cA:10 a=BLceEmwcHowA:10 a=kj9] X-AnalysisOut: [zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=XIqpo32RAAAA:8 a=iJzOR4kyh] X-AnalysisOut: [FgA:10 a=48vgC7mUAAAA:8 a=DGbFYnXxAAAA:8 a=rzH14qPrW1hziU8] X-AnalysisOut: [oE7sA:9 a=CjuIK1q_8ugA:10 a=lZB815dzVvQA:10 a=bSyc6FVMW0oA] X-AnalysisOut: [:10 a=-GUCM6S8nMqY-TpR:21 a=PSWcX0iaGcs3-4AJ:21] Cc: "dhcwg@ietf.org WG" Subject: Re: [dhcwg] SOL_MAX_RT 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, 20 Jun 2013 16:47:18 -0000 +1 for what Ralph suggests. I've seen some strong demand for a published 6204bis. And, as has been poin= ted out, that won't happen till the dependencies are published. So we need = the dependencies published. Barbara > -----Original Message----- > From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf > Of Ralph Droms > Sent: Thursday, June 20, 2013 11:11 AM > To: Ted Lemon > Cc: dhcwg@ietf.org WG > Subject: Re: [dhcwg] SOL_MAX_RT >=20 >=20 > On Jun 20, 2013, at 10:30 AM 6/20/13, Ted Lemon > wrote: >=20 > > Do we need a SOL_MAX_RT presentation in Berlin? Why not just last-cal= l it > now? >=20 > OK with me. I suggested the presentation in Berlin to prompt a discussio= n of > two issues that were raised during the previous WG last call: sending >1 > Solicit or Information-Request after the back-off timer expires and clari= fying > whether a host has to remain actively listening for a response while wait= ing > for the back-off timer to expire. >=20 > I didn't see any declaration of consensus around either of those topics a= nd > did not address them in -01. >=20 > Personally, I would prefer to see the document proceed in its current for= m > and consider the other two issues in a separate document. In my opinion, > the document is ready for WG last call in its current state. >=20 > At some point, I see the title should be updated to "Modification to Defa= ult > Value of SOL_MAX_RT and INF_MAX_RT". That change probably doesn't > need a presentation in Berlin. >=20 > - Ralph >=20 > > > > _______________________________________________ > > dhcwg mailing list > > dhcwg@ietf.org > > https://www.ietf.org/mailman/listinfo/dhcwg >=20 > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg From volz@cisco.com Thu Jun 20 10:13: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 5F82021F9D08 for ; Thu, 20 Jun 2013 10:13:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.899 X-Spam-Level: X-Spam-Status: No, score=-8.899 tagged_above=-999 required=5 tests=[AWL=1.101, BAYES_00=-2.599, J_CHICKENPOX_13=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 S2XSH7v-hrc4 for ; Thu, 20 Jun 2013 10:13:46 -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 471BF21F9CBB for ; Thu, 20 Jun 2013 10:13:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3563; q=dns/txt; s=iport; t=1371748426; x=1372958026; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=QpDAV+tFByzvNlCUK8iCdkOIz3Y0a/0K6N2OpEwFlXU=; b=WwgFybk5jQBERQF22SuPs0ZO31WAVRaXm2F6zr9onqHypshoQfhtnpSt 8KU7Sz99u7IfOzssMYHDpmjaXoOJjmmk20QkgoGkFiJBnnXzPIM9rF9ec xyhukYkcfE5Wkgd8epQ2+ssDe3MNHczaHm4fYnVUttM3Gs41sedg8LVCi s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgcFAEE3w1GtJXG9/2dsb2JhbABbgwkxSb82fBZ0giMBAQEEAQEBNzQLDAQCAQgOAwQBAQEKFAkHJwsUCQgCBAENBQiIBgy8IY4YgQAGKwcCBIJ6YQOYbJAbgViBN4Io X-IronPort-AV: E=Sophos;i="4.87,906,1363132800"; d="scan'208";a="225426534" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-6.cisco.com with ESMTP; 20 Jun 2013 17:13:17 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id r5KHDGTC021651 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 20 Jun 2013 17:13:16 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.77]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.02.0318.004; Thu, 20 Jun 2013 12:13:15 -0500 From: "Bernie Volz (volz)" To: Tomek Mrugalski , "dhcwg@ietf.org WG" Thread-Topic: [dhcwg] WGLC on draft-ietf-dhc-dhcpv6-solmaxrt-update-01 - respond by July 4 Thread-Index: AQHObdKJVMeT/vzt/EmS3DMQ2BpdK5k+0AWA Date: Thu, 20 Jun 2013 17:13:15 +0000 Message-ID: <489D13FBFA9B3E41812EA89F188F018E185A9B6F@xmb-rcd-x04.cisco.com> References: <3135C2851EB6764BACEF35D8B495596806E7DAB304@MOPESMBX01.eu.thmulti.com> <51C31065.8040804@gmail.com> <8D23D4052ABE7A4490E77B1A012B6307751E2D82@mbx-01.win.nominum.com> <51C32C73.1010203@gmail.com> In-Reply-To: <51C32C73.1010203@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.245.10] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Ralph Droms , Ted Lemon Subject: Re: [dhcwg] WGLC on draft-ietf-dhc-dhcpv6-solmaxrt-update-01 - respond by July 4 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, 20 Jun 2013 17:13:51 -0000 I don't yet support this document moving forward - I think the issues raise= d earlier need to be 'resolved'. The ND cache timeout is a concern if there are relays (routers) or servers = (kernel stacks) that do not save the packet needing ND resolution. The DHCPv6 client will send 1 packet every hour to the relay or server. Thi= s is MULTICAST and there is no ND exchange since the mac address is known. = When the relay or server then UNICASTs the response, it will need to do ND = (of the link-local address) to determine the mac address. And, if the DHCP = reply is not saved while this ND resolution takes place, nothing will end u= p being transmitted to the client when the ND resolution completes. An hour later, the same thing could happen. Hence, the client never gets th= e ADVERTISE. The old maximum retransmission timer was more likely within bounds of the e= xpiration of the ND cache entry (except in cases where the cache grew large= and some entries might be prematurely removed if not recently used). I know this negates some of the benefits of the longer time if the client w= ere to retransmit several times. And, if we simply want to point out this i= ssue and recommend that ND implementations assure that they retain these (D= HCPv6) packets when doing a resolution, that is fine by me. I'm also not sure why stating the a client is only required to wait for a '= reasonable' time for a response wasn't addressed. This could be something l= ike: A client SHOULD wait TTL * 2 (which is like close to the 120 which was the = old SOL_MAX_RT so perhaps we should just use that) with a MAY wait for less= if, for example, power consumption is a key concern. I had though Ralph proposed to discuss these issues at Berlin and resolve t= hem -- then we'd do the WGLC. I'm fine with trying to resolve these issues = on the list. - Bernie -----Original Message----- From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of T= omek Mrugalski Sent: Thursday, June 20, 2013 12:23 PM To: dhcwg@ietf.org WG Cc: Ralph Droms; Ted Lemon Subject: [dhcwg] WGLC on draft-ietf-dhc-dhcpv6-solmaxrt-update-01 - respond= by July 4 On 20.06.2013 17:11, Ralph Droms wrote: > On Jun 20, 2013, at 10:30 AM 6/20/13, Ted Lemon wrote: >> Do we need a SOL_MAX_RT presentation in Berlin? Why not just >> last-call it now? >=20 > OK with me. My understanding is that under normal circumstances chairs cannot just anno= unce WGLC on their own. They can do so if authors or editors state the the = draft is ready and chairs concur with that opinion. Anyway, here it goes: Folks, the author of draft-ietf-dhc-dhcpv6-solmaxrt-update-01 (http://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-solmaxrt-update-01) feels it's ready for work group last call. Please review this draft and ind= icate whether or not you feel it is ready to be published. This document redefines two timers (SOL_MAX_RT and INF_MAX_RT) that control= SOLICIT and INFORMATION-REQUEST message retransmissions and define a mecha= nism for server to override client's default values. There is a document in= v6ops about basic requirements for IPv6 CE routers that depends on this wo= rk. At the time of this writing, there is no IPR reported against this draft. Bernie and I will evaluate consensus after 2013-07-04. Thanks, Bernie & Tomek _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From hansliu@gmail.com Fri Jun 21 05:56:03 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 29C1921E8109 for ; Fri, 21 Jun 2013 05:56:03 -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 jIMeiDMNw9l4 for ; Fri, 21 Jun 2013 05:56:02 -0700 (PDT) Received: from mail-ie0-x236.google.com (mail-ie0-x236.google.com [IPv6:2607:f8b0:4001:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id 54BA821E8106 for ; Fri, 21 Jun 2013 05:56:02 -0700 (PDT) Received: by mail-ie0-f182.google.com with SMTP id s9so19535967iec.27 for ; Fri, 21 Jun 2013 05:56:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=fKc3jmgcs2g8jAGYvnGTmQwt/6Xn5xg5hiLzIuZLlpk=; b=ZZOayPgLrKSpFZ7EoMqxCYNSTad8F/aFi3NNZFO7M4FdMXgAnoHpCTG7oCoiEt++w0 TjzDkmVS8UbMYI4divXcECF00b71gu1sxEkaX0fPQUDyRkHEZJPUN3SauJAddO/m3/H4 srYYYQkoQu/RE1BYEOSw63ho+v0KN99vmm/ObMYM0nULrI1tfmvWePXAthZ/MvSrnHDx V8QYTnp40TAAs0VNaWSM4PprARauJhRzuEBU49S6Dj3h0tG3Sq27b7rErGLaU0z2ca1y FEcvr5rDZE4CkOezoP0V5M7QDhPe89tcDkU1ONdA826hZAgAzH+yZtMgrCXUEnrQcVGd h1Tw== MIME-Version: 1.0 X-Received: by 10.50.129.8 with SMTP id ns8mr2332815igb.25.1371819360610; Fri, 21 Jun 2013 05:56:00 -0700 (PDT) Received: by 10.64.136.44 with HTTP; Fri, 21 Jun 2013 05:56:00 -0700 (PDT) In-Reply-To: <2D09D61DDFA73D4C884805CC7865E611302E4181@GAALPA1MSGUSR9L.ITServices.sbc.com> References: <3135C2851EB6764BACEF35D8B495596806E7DAB304@MOPESMBX01.eu.thmulti.com> <51C31065.8040804@gmail.com> <8D23D4052ABE7A4490E77B1A012B6307751E2D82@mbx-01.win.nominum.com> <2D09D61DDFA73D4C884805CC7865E611302E4181@GAALPA1MSGUSR9L.ITServices.sbc.com> Date: Fri, 21 Jun 2013 20:56:00 +0800 Message-ID: From: Hans Liu To: "STARK, BARBARA H" Content-Type: multipart/alternative; boundary=047d7b2e0d73af704d04dfa9951f Cc: "dhcwg@ietf.org WG" , Claire Cheng , Ralph Droms , Ted Lemon Subject: Re: [dhcwg] SOL_MAX_RT 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, 21 Jun 2013 12:56:03 -0000 --047d7b2e0d73af704d04dfa9951f Content-Type: text/plain; charset=UTF-8 +1 too! >From a vendor point of view, we sincerely would like to see a publish of 6204bis, so we have something solid to follow up. Best regards, Hans On Fri, Jun 21, 2013 at 12:46 AM, STARK, BARBARA H wrote: > +1 for what Ralph suggests. > I've seen some strong demand for a published 6204bis. And, as has been > pointed out, that won't happen till the dependencies are published. So we > need the dependencies published. > Barbara > > > -----Original Message----- > > From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf > > Of Ralph Droms > > Sent: Thursday, June 20, 2013 11:11 AM > > To: Ted Lemon > > Cc: dhcwg@ietf.org WG > > Subject: Re: [dhcwg] SOL_MAX_RT > > > > > > On Jun 20, 2013, at 10:30 AM 6/20/13, Ted Lemon > > wrote: > > > > > Do we need a SOL_MAX_RT presentation in Berlin? Why not just > last-call it > > now? > > > > OK with me. I suggested the presentation in Berlin to prompt a > discussion of > > two issues that were raised during the previous WG last call: sending >1 > > Solicit or Information-Request after the back-off timer expires and > clarifying > > whether a host has to remain actively listening for a response while > waiting > > for the back-off timer to expire. > > > > I didn't see any declaration of consensus around either of those topics > and > > did not address them in -01. > > > > Personally, I would prefer to see the document proceed in its current > form > > and consider the other two issues in a separate document. In my opinion, > > the document is ready for WG last call in its current state. > > > > At some point, I see the title should be updated to "Modification to > Default > > Value of SOL_MAX_RT and INF_MAX_RT". That change probably doesn't > > need a presentation in Berlin. > > > > - Ralph > > > > > > > > _______________________________________________ > > > 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 > -- Instead of following the fashion, we lead it through. --047d7b2e0d73af704d04dfa9951f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
+1 too!=C2=A0
From a vendor point of view, we sincerel= y would like to see a publish of 6204bis, so we have something solid to fol= low up.=C2=A0

Best regards,
Hans


On Fri, Jun 21, 2013 at 12:46 AM, STARK,= BARBARA H <bs7652@att.com> wrote:
+1 for what Ralph suggests.
I've seen some strong demand for a published 6204bis. And, as has been = pointed out, that won't happen till the dependencies are published. So = we need the dependencies published.
Barbara

> -----Original Message-----
> From: dhcwg-bounces@ietf.org= [mailto:dhcwg-bounces@ietf.o= rg] On Behalf
> Of Ralph Droms
> Sent: Thursday, June 20, 2013 11:11 AM
> To: Ted Lemon
> Cc: dhcwg@ietf.org WG
> Subject: Re: [dhcwg] SOL_MAX_RT
>
>
> On Jun 20, 2013, at 10:30 AM 6/20/13, Ted Lemon
> <Ted.Lemon@nominum.com= > wrote:
>
> > Do we need a SOL_MAX_RT presentation in Berlin? =C2=A0 Why not ju= st last-call it
> now?
>
> OK with me. =C2=A0I suggested the presentation in Berlin to prompt a d= iscussion of
> two issues that were raised during the previous WG last call: sending = >1
> Solicit or Information-Request after the back-off timer expires and cl= arifying
> whether a host has to remain actively listening for a response while w= aiting
> for the back-off timer to expire.
>
> I didn't see any declaration of consensus around either of those t= opics and
> did not address them in -01.
>
> Personally, I would prefer to see the document proceed in its current = form
> and consider the other two issues in a separate document. =C2=A0In my = opinion,
> the document is ready for WG last call in its current state.
>
> At some point, I see the title should be updated to "Modification= to Default
> Value of SOL_MAX_RT and INF_MAX_RT". =C2=A0That change probably d= oesn't
> need a presentation in Berlin.
>
> - Ralph
>
> >
> > _______________________________________________
> > 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
h= ttps://www.ietf.org/mailman/listinfo/dhcwg



--
= Instead of following the fashion, we lead it through.
--047d7b2e0d73af704d04dfa9951f-- From rdroms.ietf@gmail.com Fri Jun 21 07:29:10 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 4669421F9ECC for ; Fri, 21 Jun 2013 07:29:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.225 X-Spam-Level: X-Spam-Status: No, score=-102.225 tagged_above=-999 required=5 tests=[AWL=-0.225, BAYES_00=-2.599, J_CHICKENPOX_13=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 WSUAIetzjAba for ; Fri, 21 Jun 2013 07:29:09 -0700 (PDT) Received: from mail-qc0-x22c.google.com (mail-qc0-x22c.google.com [IPv6:2607:f8b0:400d:c01::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 6C48921F9EC0 for ; Fri, 21 Jun 2013 07:29:09 -0700 (PDT) Received: by mail-qc0-f172.google.com with SMTP id j10so4704375qcx.31 for ; Fri, 21 Jun 2013 07:29:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=EQovCn3eeanIYFok6ksPYJ+wMuIXUJoyh1tDFjciU3M=; b=tACwN+bI1ylu/5OO7OImjSuk2N2Az3ayKa55+1vZDRWSMwL7XycNKU+i8Q6rEFK7xW rkKtWJRSxU4Ztr1tsyAAa5xFp8fsIXUcuOvqNdDvqxe7pKZ/yi+8SIF0wQ3kswEOIJaR w4FxMoaOD8B3SUgkFiFKmUG1t7lcb72FpwP/3ModzD2OlwQLgeLPLICfSQlJ4JlIME0D HktiME4DW3oADKdGyGeMqsX04B9/rYBWve5MN/TCH0sFDo9HNDY3VdflGs2q22UHO5gZ nrpeecgQkC9F7TNxnfIsoFHwLXtEgj5TMSAbiD/kH+B5b1jduhiDTquowttQc64LU0e3 Ggog== X-Received: by 10.224.60.133 with SMTP id p5mr5623543qah.101.1371824948810; Fri, 21 Jun 2013 07:29:08 -0700 (PDT) Received: from ?IPv6:2001:420:2481:20:bd33:7c3c:a8e9:6b95? ([2001:420:2481:20:bd33:7c3c:a8e9:6b95]) by mx.google.com with ESMTPSA id a8sm6662780qae.11.2013.06.21.07.29.06 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 21 Jun 2013 07:29:07 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Ralph Droms In-Reply-To: <489D13FBFA9B3E41812EA89F188F018E185A9B6F@xmb-rcd-x04.cisco.com> Date: Fri, 21 Jun 2013 10:29:04 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <90C4B43B-4EF6-40DD-A5F1-DBF82402F191@gmail.com> References: <3135C2851EB6764BACEF35D8B495596806E7DAB304@MOPESMBX01.eu.thmulti.com> <51C31065.8040804@gmail.com> <8D23D4052ABE7A4490E77B1A012B6307751E2D82@mbx-01.win.nominum.com> <51C32C73.1010203@gmail.com> <489D13FBFA9B3E41812EA89F188F018E185A9B6F@xmb-rcd-x04.cisco.com> To: Bernie Volz (volz) X-Mailer: Apple Mail (2.1508) Cc: "dhcwg@ietf.org WG" , Lemon Ted Subject: Re: [dhcwg] WGLC on draft-ietf-dhc-dhcpv6-solmaxrt-update-01 - respond by July 4 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, 21 Jun 2013 14:29:10 -0000 On Jun 20, 2013, at 1:13 PM 6/20/13, Bernie Volz (volz) = wrote: > >=20 > I don't yet support this document moving forward - I think the issues = raised earlier need to be 'resolved'. >=20 > The ND cache timeout is a concern if there are relays (routers) or = servers (kernel stacks) that do not save the packet needing ND = resolution. That behavior is not RFC-compliant; from section 7.2.2 of RFC 4861: While waiting for address resolution to complete, the sender MUST, for each neighbor, retain a small queue of packets waiting for address resolution to complete. The queue MUST hold at least one packet, and MAY contain more. >=20 > The DHCPv6 client will send 1 packet every hour to the relay or = server. This is MULTICAST and there is no ND exchange since the mac = address is known. When the relay or server then UNICASTs the response, = it will need to do ND (of the link-local address) to determine the mac = address. And, if the DHCP reply is not saved while this ND resolution = takes place, nothing will end up being transmitted to the client when = the ND resolution completes. >=20 > An hour later, the same thing could happen. Hence, the client never = gets the ADVERTISE. >=20 > The old maximum retransmission timer was more likely within bounds of = the expiration of the ND cache entry (except in cases where the cache = grew large and some entries might be prematurely removed if not recently = used). >=20 > I know this negates some of the benefits of the longer time if the = client were to retransmit several times. And, if we simply want to point = out this issue and recommend that ND implementations assure that they = retain these (DHCPv6) packets when doing a resolution, that is fine by = me. >=20 >=20 > I'm also not sure why stating the a client is only required to wait = for a 'reasonable' time for a response wasn't addressed. This could be = something like: >=20 > A client SHOULD wait TTL * 2 (which is like close to the 120 which was = the old SOL_MAX_RT so perhaps we should just use that) with a MAY wait = for less if, for example, power consumption is a key concern. I wasn't given any indication of consensus supporting that change, so I = didn't include it. >=20 >=20 > I had though Ralph proposed to discuss these issues at Berlin and = resolve them -- then we'd do the WGLC. I'm fine with trying to resolve = these issues on the list. IMHO, we should first determine consensus for publishing = draft-ietf-dhc-dhcpv6-solmaxrt-update-01 as is and addressing these = additional issues in a separate document or holding = draft-ietf-dhc-dhcpv6-solmaxrt-update-01 until these additional issues = are discussed. While the question has not been posed explicitly on the = list, there seems to be support for going ahead with = draft-ietf-dhc-dhcpv6-solmaxrt-update-01 in its current form. >=20 > - Bernie - Ralph >=20 > -----Original Message----- > From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf = Of Tomek Mrugalski > Sent: Thursday, June 20, 2013 12:23 PM > To: dhcwg@ietf.org WG > Cc: Ralph Droms; Ted Lemon > Subject: [dhcwg] WGLC on draft-ietf-dhc-dhcpv6-solmaxrt-update-01 - = respond by July 4 >=20 > On 20.06.2013 17:11, Ralph Droms wrote: >> On Jun 20, 2013, at 10:30 AM 6/20/13, Ted Lemon wrote: >>> Do we need a SOL_MAX_RT presentation in Berlin? Why not just >>> last-call it now? >>=20 >> OK with me. > My understanding is that under normal circumstances chairs cannot just = announce WGLC on their own. They can do so if authors or editors state = the the draft is ready and chairs concur with that opinion. Anyway, here = it goes: >=20 > Folks, the author of draft-ietf-dhc-dhcpv6-solmaxrt-update-01 > (http://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-solmaxrt-update-01) > feels it's ready for work group last call. Please review this draft = and indicate whether or not you feel it is ready to be published. >=20 > This document redefines two timers (SOL_MAX_RT and INF_MAX_RT) that = control SOLICIT and INFORMATION-REQUEST message retransmissions and = define a mechanism for server to override client's default values. There = is a document in v6ops about basic requirements for IPv6 CE routers that = depends on this work. >=20 > At the time of this writing, there is no IPR reported against this = draft. >=20 > Bernie and I will evaluate consensus after 2013-07-04. >=20 > Thanks, > Bernie & Tomek > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg From volz@cisco.com Fri Jun 21 08:24: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 748EF11E819F for ; Fri, 21 Jun 2013 08:24:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.999 X-Spam-Level: X-Spam-Status: No, score=-9.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=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 qpLSJIZ06UjT for ; Fri, 21 Jun 2013 08:24:09 -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 4927611E819D for ; Fri, 21 Jun 2013 08:24:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7295; q=dns/txt; s=iport; t=1371828249; x=1373037849; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=foLUsjINB1WD+VcJKz5fX6PXrgEJpWGpCHyTHrKmWkc=; b=OAH6OEzUAfx6He/wTpsRJEu4rSBbghvy4c5t+ewrwZKo64uRFJIFFvNU OK20i9XEmK536nykHl1ymC2w9Udogv2188c0ahpgY2hfVy9oImPSplfVe ZQLSF4RatM4zZU43tcnWtR+jPiWkkW8W0+zfewb0OWkkhTuD5Ez3fqeLx Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgcFADpvxFGtJV2d/2dsb2JhbABbgwkxSb81gQIWdIIjAQEBAwEBAQE3NAsFBwQCAQgOAwQBAQEKFAkHJwsUCQgCBA4FCIgABgy8KI4HEYEABisHAgSCemEDmGyQG4FYgTeBcTc X-IronPort-AV: E=Sophos;i="4.87,913,1363132800"; d="scan'208";a="225816905" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-2.cisco.com with ESMTP; 21 Jun 2013 15:24:08 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id r5LFO8Yi001599 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 21 Jun 2013 15:24:08 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; Fri, 21 Jun 2013 10:24:08 -0500 From: "Bernie Volz (volz)" To: Ralph Droms Thread-Topic: [dhcwg] WGLC on draft-ietf-dhc-dhcpv6-solmaxrt-update-01 - respond by July 4 Thread-Index: AQHObou1prYNDbW740Kic8Ebir1FV5lAPRiw Date: Fri, 21 Jun 2013 15:24:07 +0000 Message-ID: <489D13FBFA9B3E41812EA89F188F018E185AC7F1@xmb-rcd-x04.cisco.com> References: <3135C2851EB6764BACEF35D8B495596806E7DAB304@MOPESMBX01.eu.thmulti.com> <51C31065.8040804@gmail.com> <8D23D4052ABE7A4490E77B1A012B6307751E2D82@mbx-01.win.nominum.com> <51C32C73.1010203@gmail.com> <489D13FBFA9B3E41812EA89F188F018E185A9B6F@xmb-rcd-x04.cisco.com> <90C4B43B-4EF6-40DD-A5F1-DBF82402F191@gmail.com> In-Reply-To: <90C4B43B-4EF6-40DD-A5F1-DBF82402F191@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.245.10] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dhcwg@ietf.org WG" , Lemon Ted Subject: Re: [dhcwg] WGLC on draft-ietf-dhc-dhcpv6-solmaxrt-update-01 - respond by July 4 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, 21 Jun 2013 15:24:14 -0000 Hi Ralph: OK, great that the ND issue isn't real. I had looked for something like tha= t at one point but didn't find it. As that is the case, that is no longer a= n issue. Too bad this wasn't found earlier (or if it was mentioned, I misse= d it - sorry). So I withdraw that objection. Regarding the issue about how long the receiver needs to wait for a packet,= I think there was some discussion and support for that during some of the = email exchange. I don't believe anyone was against adding something to NOT = require waiting the full time (given the longer solmax) for a response from= the DHCP server. That makes no sense to wait an hour or even many minutes. It seems silly to have a completely separate draft mention that. We didn't = have a need to mention this when RFC 3315 was written since the times were = assumed to be reasonable for 'waiting'. Does anyone have an OBJECTION to adding something close to: > A client SHOULD wait TTL * 2 (which is like close to the 120 which was th= e old SOL_MAX_RT so perhaps we should just use that) with a MAY wait for le= ss if, for example, power consumption is a key concern. A more formal clarification (actual text) might be: Add to section 3 of the draft (end of existing text): Also, with this change, a new parameter is need to cap the time a client must wait for a response from the server as waiting for the new SOL_MAX_RT seems excessive. Hence, the following is added: NEW: MAX_RCV_TIME 120 secs Max time to wait for a response Add to section 6 of the draft (probably first): Add to section 14 of RFC 3315 (at end of existing text): RT specifies the retransmission interval and not necessarily the time a client listens for a response from the server. Clients SHOULD wait for responses for at least the shorter of the RT and MAX_RCV_TIME. There MAY be situations where a shorter MAX_RCV_TIME is appropriate - such as when power consumption is a key concern. Optional: Document the source of MAX_RCV_TIME which came from old SOL_MAX_R= T and also is the TCP Maximum Segment Lifetime, RFC 792. - Bernie -----Original Message----- From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of R= alph Droms Sent: Friday, June 21, 2013 10:29 AM To: Bernie Volz (volz) Cc: dhcwg@ietf.org WG; Lemon Ted Subject: Re: [dhcwg] WGLC on draft-ietf-dhc-dhcpv6-solmaxrt-update-01 - res= pond by July 4 On Jun 20, 2013, at 1:13 PM 6/20/13, Bernie Volz (volz) wr= ote: > >=20 > I don't yet support this document moving forward - I think the issues rai= sed earlier need to be 'resolved'. >=20 > The ND cache timeout is a concern if there are relays (routers) or server= s (kernel stacks) that do not save the packet needing ND resolution. That behavior is not RFC-compliant; from section 7.2.2 of RFC 4861: While waiting for address resolution to complete, the sender MUST, for each neighbor, retain a small queue of packets waiting for address resolution to complete. The queue MUST hold at least one packet, and MAY contain more. >=20 > The DHCPv6 client will send 1 packet every hour to the relay or server. T= his is MULTICAST and there is no ND exchange since the mac address is known= . When the relay or server then UNICASTs the response, it will need to do N= D (of the link-local address) to determine the mac address. And, if the DHC= P reply is not saved while this ND resolution takes place, nothing will end= up being transmitted to the client when the ND resolution completes. >=20 > An hour later, the same thing could happen. Hence, the client never gets = the ADVERTISE. >=20 > The old maximum retransmission timer was more likely within bounds of the= expiration of the ND cache entry (except in cases where the cache grew lar= ge and some entries might be prematurely removed if not recently used). >=20 > I know this negates some of the benefits of the longer time if the client= were to retransmit several times. And, if we simply want to point out this= issue and recommend that ND implementations assure that they retain these = (DHCPv6) packets when doing a resolution, that is fine by me. >=20 >=20 > I'm also not sure why stating the a client is only required to wait for a= 'reasonable' time for a response wasn't addressed. This could be something= like: >=20 > A client SHOULD wait TTL * 2 (which is like close to the 120 which was th= e old SOL_MAX_RT so perhaps we should just use that) with a MAY wait for le= ss if, for example, power consumption is a key concern. I wasn't given any indication of consensus supporting that change, so I did= n't include it. >=20 >=20 > I had though Ralph proposed to discuss these issues at Berlin and resolve= them -- then we'd do the WGLC. I'm fine with trying to resolve these issue= s on the list. IMHO, we should first determine consensus for publishing draft-ietf-dhc-dhc= pv6-solmaxrt-update-01 as is and addressing these additional issues in a se= parate document or holding draft-ietf-dhc-dhcpv6-solmaxrt-update-01 until t= hese additional issues are discussed. While the question has not been pose= d explicitly on the list, there seems to be support for going ahead with dr= aft-ietf-dhc-dhcpv6-solmaxrt-update-01 in its current form. >=20 > - Bernie - Ralph >=20 > -----Original Message----- > From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of= Tomek Mrugalski > Sent: Thursday, June 20, 2013 12:23 PM > To: dhcwg@ietf.org WG > Cc: Ralph Droms; Ted Lemon > Subject: [dhcwg] WGLC on draft-ietf-dhc-dhcpv6-solmaxrt-update-01 - respo= nd by July 4 >=20 > On 20.06.2013 17:11, Ralph Droms wrote: >> On Jun 20, 2013, at 10:30 AM 6/20/13, Ted Lemon wrote: >>> Do we need a SOL_MAX_RT presentation in Berlin? Why not just >>> last-call it now? >>=20 >> OK with me. > My understanding is that under normal circumstances chairs cannot just an= nounce WGLC on their own. They can do so if authors or editors state the th= e draft is ready and chairs concur with that opinion. Anyway, here it goes: >=20 > Folks, the author of draft-ietf-dhc-dhcpv6-solmaxrt-update-01 > (http://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-solmaxrt-update-01) > feels it's ready for work group last call. Please review this draft and i= ndicate whether or not you feel it is ready to be published. >=20 > This document redefines two timers (SOL_MAX_RT and INF_MAX_RT) that contr= ol SOLICIT and INFORMATION-REQUEST message retransmissions and define a mec= hanism for server to override client's default values. There is a document = in v6ops about basic requirements for IPv6 CE routers that depends on this = work. >=20 > At the time of this writing, there is no IPR reported against this draft. >=20 > Bernie and I will evaluate consensus after 2013-07-04. >=20 > Thanks, > 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 ian.farrer@telekom.de Tue Jun 25 09:30: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 88BEA21F9A1A for ; Tue, 25 Jun 2013 09:30:16 -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_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 r3kfX2DXdD+6 for ; Tue, 25 Jun 2013 09:30:10 -0700 (PDT) Received: from tcmail93.telekom.de (tcmail93.telekom.de [80.149.113.205]) by ietfa.amsl.com (Postfix) with ESMTP id 80ABB21E809C for ; Tue, 25 Jun 2013 09:28:29 -0700 (PDT) Received: from he111628.emea1.cds.t-internal.com ([10.134.93.20]) by tcmail91.telekom.de with ESMTP/TLS/AES128-SHA; 25 Jun 2013 18:28:27 +0200 Received: from HE111643.EMEA1.CDS.T-INTERNAL.COM ([10.134.93.12]) by HE111628.emea1.cds.t-internal.com ([::1]) with mapi; Tue, 25 Jun 2013 18:28:27 +0200 From: To: Date: Tue, 25 Jun 2013 18:28:25 +0200 Thread-Topic: New Version Notification for draft-farrer-dhc-shared-address-lease-00.txt Thread-Index: Ac5xwQUdryF49UU0QoiLKofzHF9ljg== 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.5.130515 acceptlanguage: en-US, de-DE Content-Type: multipart/alternative; boundary="_000_CDEF91C97AB1Fianfarrertelekomde_" MIME-Version: 1.0 Subject: [dhcwg] fwd: New Version Notification for draft-farrer-dhc-shared-address-lease-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: Tue, 25 Jun 2013 16:30:17 -0000 --_000_CDEF91C97AB1Fianfarrertelekomde_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable After discussions in Orlando and some other supporting work in draft-ietf-d= hc-dhcpv4-over-dhcpv6 and draft-ietf-dhc-v4configuration , I've written up = a proposal for how dynamic, shared DHCPv4 address lea singing could work fo= r DHCPv4 over DHCPv6 clients. There's also some stuff which is quite softwire specific in there. I put th= is in the draft as it's needed to give the overall solution. It could be mo= ved out to a second draft. Please let me know what you think. Cheers, Ian --_000_CDEF91C97AB1Fianfarrertelekomde_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
After discussions in Orlan= do and some other supporting work in draft-ietf-dhc-dhcpv4-over-dhcpv6= and draft-ietf-dhc-v4configuration , I've written up a proposal = for how dynamic, shared DHCPv4 address lea singing could work for DHCPv4 ov= er DHCPv6 clients.

There's also some stuff which i= s quite softwire specific in there. I put this in the draft as it's needed = to give the overall solution. It could be moved out to a second draft.

Please let me know what you think.

Cheers,
Ian

--_000_CDEF91C97AB1Fianfarrertelekomde_-- From volz@cisco.com Tue Jun 25 12:47:48 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 9ABC721E80CD for ; Tue, 25 Jun 2013 12:47:47 -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 w0z+23cz56Mi for ; Tue, 25 Jun 2013 12:47:31 -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 18A8C21E80DE for ; Tue, 25 Jun 2013 12:47:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=19313; q=dns/txt; s=iport; t=1372189645; x=1373399245; h=from:to:cc:subject:date:message-id:mime-version; bh=D4iyah5B9BJVUOXZqX43RjuMA9aSSMJl3VLOMvh4Ubs=; b=mJRLzxTs6V5hGFZob/enbW/cIQ0wsg50t65I2IRazQEBQEPSf1aFb15U ER8ZoPe/0DupGxrM3vzm6ExfV0/D5AicaNnLXMduFMzNqu6gEOmkJTxTr jV6L5GeEDhWlurrfWLxbdZDbFF7i/ml6hkRVUP38xQoIvDXhs2kGF1s5h Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmEGAOjyyVGtJV2Y/2dsb2JhbABagkVEMUmtPYk1iEaBBhZ0giUBBC1MEgEqFkAmAQQODQyHegy6YY4DgRExgwlhA5hskBuDEIFxNw X-IronPort-AV: E=Sophos;i="4.87,939,1363132800"; d="scan'208,217";a="227303184" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-2.cisco.com with ESMTP; 25 Jun 2013 19:47:24 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r5PJlOI6005492 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 25 Jun 2013 19:47:24 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.56]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.02.0318.004; Tue, 25 Jun 2013 14:47:24 -0500 From: "Bernie Volz (volz)" To: "dhcwg@ietf.org" Thread-Topic: DHC WG Re-Charter Proposal Thread-Index: Ac5x3GsmHSL5mORtSN2Yp6/PNjm/rw== Date: Tue, 25 Jun 2013 19:47:23 +0000 Message-ID: <489D13FBFA9B3E41812EA89F188F018E185C32AD@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.245.27] Content-Type: multipart/alternative; boundary="_000_489D13FBFA9B3E41812EA89F188F018E185C32ADxmbrcdx04ciscoc_" MIME-Version: 1.0 Cc: "Ted Lemon \(Ted.Lemon@nominum.com\)" Subject: [dhcwg] DHC WG Re-Charter Proposal 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, 25 Jun 2013 19:47:48 -0000 --_000_489D13FBFA9B3E41812EA89F188F018E185C32ADxmbrcdx04ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello: The text below is a proposed update of the DHC WG charter that the co-chair= s developed with input and review from Ted Lemon (AD). It assumes a DHCP Di= rectorate is created as well (see separate email). Feedback on the charter = text is appreciated and will also be discussed in Berlin as we hope to fina= lize it shortly thereafter. While the DHC re-charter and DHCP directorate are connected, we'd like to t= ry to separate the discussion (hence the directorate is in a separate email= ). The current charter, which is rather old, can be viewed at http://datatrack= er.ietf.org/wg/dhc/charter/. Proposed DHC WG Charter: The Dynamic Host Configuration working group (DHC WG) has developed DHCP for automated allocation, configuration and management of IP addresses and TCP/IP protocol stack parameters. DHCPv4 is currently a Draft Standard and is documented in RFC 2131 and RFC 2132. DHCPv6 is currently a Proposed Standard and is documented in RFC 3315. Subsequent RFCs document additional options and other enhancements to the specifications. The DHC WG is responsible for defining DHCP protocol extensions. Definitions of new DHCP options that are delivered using standard mechanisms with documented semantics are not considered a protocol extension and thus are outside of scope for DHC WG. Such options should be defined within their respective WGs and reviewed by the DHCP Directorate. However, if such options require protocol extensions or new semantics, the protocol extension work must be done in the DHC WG. The DHC WG has the following main objectives: * Develop extensions to the DHCPv6 infrastructure as required to meet new applications and deployments of DHCP. The topics currently in development are: - DHCPv6 Failover, High Availability and Load Balancing - DNS Update strategies for delegated prefixes (draft-ietf-dhc-dns-pd) - Extend DHCPv6 to work with multiple provisioning domains - DHCP provisioning of IPv4 clients over IPv6 networks - SOLMAXRT counter update - Container option - Address Network Identifier (draft-ietf-dhc-access-network-identifier) - New NTP option to replace OPTION_NTP_SERVER (RFC 5908) - Prefix coloring (draft-bhandari-dhc-class-based-prefix) Additional topics may only be added with approval from the responsible Area Director or by re-chartering. * Specify guidelines for creating new DHCPv6 options. * Develop documents that help explain operational considerations for the wider community. * Advance DHCPv6 (RFC 3315) along the IETF Standards Track. This will include writing analyses, corrections, and clarifications of the DHCPv6 specifications, including RFC 3315, RFC3633, RFC3736 and other RFCs defining additional options, which identifies and resolves ambiguities, contradictory specifications and other obstacles to development of interoperable implementations. END - Tomek & Bernie --_000_489D13FBFA9B3E41812EA89F188F018E185C32ADxmbrcdx04ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello:

 

The text below is a proposed update of the DHC WG ch= arter that the co-chairs developed with input and review from Ted Lemon (AD= ). It assumes a DHCP Directorate is created as well (see separate email). F= eedback on the charter text is appreciated and will also be discussed in Berlin as we hope to finalize it shortly the= reafter.

 

While the DHC re-charter and DHCP directorate are co= nnected, we’d like to try to separate the discussion (hence the direc= torate is in a separate email).

 

The current charter, which is rather old, can be vie= wed at http://datatracker.ietf.org/wg/dhc/charter/.

 

Proposed DHC WG Charter:

 

  The Dynamic Host Configuration working group (DHC W= G) has developed

  DHCP for automated allocation, configuration and ma= nagement of IP

  addresses and TCP/IP protocol stack parameters. DHC= Pv4 is currently

  a Draft Standard and is documented in RFC 2131 and = RFC 2132. DHCPv6

  is currently a Proposed Standard and is documented = in RFC 3315.

  Subsequent RFCs document additional options and oth= er enhancements to

  the specifications.

 

  The DHC WG is responsible for defining DHCP protoco= l extensions.

  Definitions of new DHCP options that are delivered = using standard

  mechanisms with documented semantics are not consid= ered a protocol

  extension and thus are outside of scope for DHC WG.= Such options should

  be defined within their respective WGs and reviewed= by the DHCP

  Directorate. However, if such options require proto= col extensions or new

  semantics, the protocol extension work must be done= in the DHC WG.

 

  The DHC WG has the following main objectives:<= /o:p>

 

  * Develop extensions to the DHCPv6 infrastruct= ure as required to meet

  new applications and deployments of DHCP. The topic= s currently

  in development are:

 

  - DHCPv6 Failover, High Availability and Load = Balancing

  - DNS Update strategies for delegated prefixes (dra= ft-ietf-dhc-dns-pd)

  - Extend DHCPv6 to work with multiple provisioning = domains

  - DHCP provisioning of IPv4 clients over IPv6 netwo= rks

  - SOLMAXRT counter update

  - Container option

  - Address Network Identifier (draft-ietf-dhc-a= ccess-network-identifier)

  - New NTP option to replace OPTION_NTP_SERVER (RFC = 5908)

  - Prefix coloring (draft-bhandari-dhc-class-based-p= refix)

 

    Additional topics may only be added wit= h approval from the responsible

    Area Director or by re-chartering.=

 

  * Specify guidelines for creating new DHCPv6 option= s.

 

  * Develop documents that help explain operational c= onsiderations for

    the wider community.<= /p>

 

  * Advance DHCPv6 (RFC 3315) along the IETF Standard= s Track. This will

  include writing analyses, corrections, and clarific= ations of the DHCPv6

  specifications, including RFC 3315, RFC3633, RFC373= 6 and other RFCs

  defining additional options, which identifies and r= esolves ambiguities,

  contradictory specifications and other obstacles to= development of

  interoperable implementations.

 

END

 

-     &= nbsp;    Tomek & Bernie

 

--_000_489D13FBFA9B3E41812EA89F188F018E185C32ADxmbrcdx04ciscoc_-- From volz@cisco.com Tue Jun 25 12:47: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 3815D21E80DC for ; Tue, 25 Jun 2013 12:47:53 -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 0I6bax4hfzOv for ; Tue, 25 Jun 2013 12:47:48 -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 BF40B21E80DA for ; Tue, 25 Jun 2013 12:47:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=35484; q=dns/txt; s=iport; t=1372189646; x=1373399246; h=from:to:cc:subject:date:message-id:mime-version; bh=c0i+/EWqawdxAdidHUnv1v/Ipl50c/wnLwqYsXiLuSU=; b=PQ1TXrq0CzrqXe8BqYnh/EpFgcUYMSo4Y0E2K+bTbgWgBMOTwXHmggM0 KU5OsI/lOUnZmmD5J9GP1NYT31ugBfoGobST1BR1sMpzTsmTCCviB9kza tq+BevW+p9dsYTU9s7b+JoPSdxYHfs8FcxV5b84fVZw43JEGTXMnEH7c7 s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AssFAOjyyVGtJV2d/2dsb2JhbABagkVEMUm2cohGgQYWdIIlAQQtPgIMEgEqFgE/JgEEDg0BC4d6DLphjgMKAYEGMYMJYQOBTZIkhHuQG4MQgWgBCBcg X-IronPort-AV: E=Sophos;i="4.87,939,1363132800"; d="scan'208,217";a="227351012" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-3.cisco.com with ESMTP; 25 Jun 2013 19:47:25 +0000 Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id r5PJlP3C027390 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 25 Jun 2013 19:47:25 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.56]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.02.0318.004; Tue, 25 Jun 2013 14:47:25 -0500 From: "Bernie Volz (volz)" To: "dhcwg@ietf.org" Thread-Topic: DHCP Directorate Proposal Thread-Index: Ac5x3HNmjTU+PkrUQRe5be06SLqzEA== Date: Tue, 25 Jun 2013 19:47:24 +0000 Message-ID: <489D13FBFA9B3E41812EA89F188F018E185C32B5@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.245.27] Content-Type: multipart/alternative; boundary="_000_489D13FBFA9B3E41812EA89F188F018E185C32B5xmbrcdx04ciscoc_" MIME-Version: 1.0 Cc: "Ted Lemon \(Ted.Lemon@nominum.com\)" Subject: [dhcwg] DHCP Directorate Proposal 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, 25 Jun 2013 19:47:53 -0000 --_000_489D13FBFA9B3E41812EA89F188F018E185C32B5xmbrcdx04ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello: At the Orlando IETF, Ted Lemon (AD) introduced the idea of an IETF DHCP Dir= ectorate to help streamline the DHC WG workload and provide assistance to o= ther working groups developing DHCP options. Ted and the DHC WG co-chairs d= eveloped the following proposal for an DHCP Directorate. As this is tied to= the DHC WG re-charter (see separate email), Ted requested that we share th= is with the DHC WG for feedback. This will also be on the agenda for discus= sion at Berlin, to hopefully finalize it shortly thereafter. While the DHC re-charter and DHCP directorate are connected, we'd like to t= ry to separate the discussion (hence the re-charter) is in a separate email= ). Per http://tools.ietf.org/html/rfc2418: In many areas, the Area Directors have formed an advisory group or directorate. These comprise experienced members of the IETF and the technical community represented by the area. The specific name and the details of the role for each group differ from area to area, but the primary intent is that these groups assist the Area Director(s), e.g., with the review of specifications produced in the area. For a list of existing directorates, see http://www.ietf.org/iesg/directora= te.html. Proposed DHCP Directorate: DHCP Directorate The DHCP Directorate is an advisory group of DHCP experts selected by the Internet Area Directors. The notion of a directorate is defined in RFC 2418 as follows: In many areas, the Area Directors have formed an advisory group or directorate. These comprise experienced members of the IETF and the technical community represented by the area. The specific name and the details of the role for each group differ from area to area, but the primary intent is that these groups assist the Area Director(s), e.g., with the review of specifications produced in the area. What Does the Directorate Do? The main purpose of the DHCP Directorate is to review all documents submitted to the IESG for publication that define new DHCP (DHCPv6 or DHCPv4) options, DHCP messages, or DHCP client, relay agent or server processing. Generally speaking, documents advanced by the DHC WG will have already received review from members of the DHCP Directorate and thus may not require such review. While the DHC WG is active, the DHCP Directorate is responsible for reviewing DHCP options or other extensions (for both IPv4 and IPv6). The Directorate is expected to review all proposed extensions to DHCP to ensure that they are consistent with the DHCP specification and other option formats, that they do not duplicate existing mechanisms, etc. Generally speaking, the Directorate will not be responsible for evaluating the semantic content of proposed options. The tasks performed by the Directorate are: 1. Review all documents submitted to the IESG for publication that have DHCP options, messages, or processing requirements. A review is triggered: - By request for early review (by any AD or by any WG chair) - By a document moving to 'publication requested' state - By entry on the IESG agenda (for other documents) 2. Assist ADs with judgment issues when requested - The ADs may send email to the directorate list when they have issues that they want help with. Examples for judgment issues are: - New option formats. - New client, relay, server agent processing. 3. Try to follow IETF documents related to DHCP as early as possible and provide guidance to authors as early as possible. How is Document Review Organized? 1. The DHCP Directorate Coordinator assigns each document that is triggered for review to at least two (2) reviewers and issues a Review Request. Authors and contributors to a document must not be assigned. The Review Request will include the document and review deadline. 2. The assigned reviewers must acknowledge and agree to review the document within 72 hours and respond with a "can review by deadline" or "can't review". No reply is interpreted as "can't review". 3. If the Coordinator does not receive "can review by deadline" within 72 hours, the Coordinator selects at least one or two additional reviewers. This process is repeated until at least two reviewers are found. 4. The reviewers provide comments as appropriate (IETF Last Call, Area Director, document authors). 5. The Coordinator may decide to call upon additional reviewers if expected review is overdue or the topic under review is a complex one. How is the Directorate Formed? 1. Directorate members are assigned to the Directorate by the Internet Area Directors. 2. There is an expectation that Directorate membership will not be limited to 'old-time DHCP gods from years past'. It is assumed that the Directorate will include younger and newer participants who are interested in 'learning while doing work'. 3. Each assignment is for a three year term, unless the member or Internet Area Director requests a shorter term. 4. The terms are staggered so that approximately 1/3 of the directorate members have their term end each year. 5. When the Directorate is first established members of the Directorate will be assigned either one year, two years, or three years in their first term. 6. When a member's term expires, the Internet ADs may replace the person whose term expires, may reappoint the same person, or may reduce the size of the Directorate. There is no expectation that the same person will either want to be returned, or will be returned. 7. The three year term serves as the limit of the commitment of a Directorate member, but also serves as a way to return Directorate members to the community. 8. In deciding whether to reappoint a member whose term has expired, the Internet ADs may consider the quantity of work that they have done, the ADs' impression of the quality of the work, and the comments from the authors and other Directorate members regarding the reviews. 9. If a member resigns before the member's term expires, the Internet Area Directors may appoint a replacement. 10. The Internet Area Directors may remove a member before the member's term expires, and may appoint a replacement. 11. Internet ADs can assign additional members to the Directorate whenever they want to, subject to willingness of people to serve. 12. Both ADs need to agree in order to assign a member to the Directorate. 13. Both ADs select one of the Directorate members as the DHCP Directorate Coordinator on a yearly basis. END - Ted, Tomek, & Bernie --_000_489D13FBFA9B3E41812EA89F188F018E185C32B5xmbrcdx04ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello:

 

At the Orlando IETF, Ted Lemon (AD) introduced the i= dea of an IETF DHCP Directorate to help streamline the DHC WG workload and = provide assistance to other working groups developing DHCP options. Ted and= the DHC WG co-chairs developed the following proposal for an DHCP Directorate. As this is tied to the DHC WG = re-charter (see separate email), Ted requested that we share this with the = DHC WG for feedback. This will also be on the agenda for discussion at Berl= in, to hopefully finalize it shortly thereafter.

 

While the DHC re-charter and DHCP directorate are co= nnected, we’d like to try to separate the discussion (hence the re-ch= arter) is in a separate email).

 

Per h= ttp://tools.ietf.org/html/rfc2418:

 

  = ; In many areas, the Area Directors have formed an advisory group or

  = ; directorate.  These comprise experienced members of the IETF and the=

  = ; technical community represented by the area.  The specific name and<= o:p>

  = ; the details of the role for each group differ from area to area, but=

  = ; the primary intent is that these groups assist the Area Director(s),=

  = ; e.g., with the review of specifications produced in the area.<= /span>

 

For a list of existing directorates, see http://www.ietf.org/iesg/directorate.html.

 

Proposed DHCP Directorate:

 

DHCP Directorate

 

The DHCP Directorate is an advisory group of DHCP experts = selected by the

Internet Area Directors.

 

The notion of a directorate is defined in RFC 2418 as foll= ows:

 

  In many areas, the Area Directors have formed an ad= visory group or

  directorate. These comprise experienced members of = the IETF and the

  technical community represented by the area. The sp= ecific name and the

  details of the role for each group differ from area= to area, but the

  primary intent is that these groups assist the Area= Director(s), e.g.,

  with the review of specifications produced in the a= rea.

 

 

What Does the Directorate Do?

 

The main purpose of the DHCP Directorate is to review all = documents

submitted to the IESG for publication that define new DHCP= (DHCPv6 or

DHCPv4) options, DHCP messages, or DHCP client, relay agen= t or server

processing. Generally speaking, documents advanced by the = DHC WG will

have already received review from members of the DHCP Dire= ctorate and

thus may not require such review.

 

While the DHC WG is active, the DHCP Directorate is respon= sible for

reviewing DHCP options or other extensions (for both IPv4 = and IPv6). The

Directorate is expected to review all proposed extensions = to DHCP to

ensure that they are consistent with the DHCP specificatio= n and other

option formats, that they do not duplicate existing mechan= isms, etc.

Generally speaking, the Directorate will not be responsibl= e for evaluating

the semantic content of proposed options.

 

The tasks performed by the Directorate are:

 

1. Review all documents submitted to the IESG for publicat= ion that have

   DHCP options, messages, or processing require= ments. A review is

   triggered:

 

   - By request for early review (by any AD or b= y any WG chair)

   - By a document moving to 'publication reques= ted' state

   - By entry on the IESG agenda (for other docu= ments)

 

2. Assist ADs with judgment issues when requested - The AD= s may send email

   to the directorate list when they have issues= that they want help with.

   Examples for judgment issues are:<= /span>

 

   - New option formats.

   - New client, relay, server agent processing.=

 

3. Try to follow IETF documents related to DHCP as early a= s possible and

   provide guidance to authors as early as possi= ble.

 

 

How is Document Review Organized?

 

1. The DHCP Directorate Coordinator assigns each document = that is

   triggered for review to at least two (2) revi= ewers and issues a Review

   Request. Authors and contributors to a docume= nt must not be assigned.

   The Review Request will include the document = and review deadline.

2. The assigned reviewers must acknowledge and agree to re= view the

   document within 72 hours and respond with a &= quot;can review by deadline" or

   "can't review". No reply is interpr= eted as "can't review".

3. If the Coordinator does not receive "can review by= deadline" within 72

   hours, the Coordinator selects at least one o= r two additional reviewers.

   This process is repeated until at least two r= eviewers are found.

4. The reviewers provide comments as appropriate (IETF Las= t Call, Area

   Director, document authors).

5. The Coordinator may decide to call upon additional revi= ewers if

   expected review is overdue or the topic under= review is a complex one.

 

 

How is the Directorate Formed?

 

1. Directorate members are assigned to the Directorate by = the Internet

    Area Directors.

2. There is an expectation that Directorate membership wil= l not be

    limited to 'old-time DHCP gods from yea= rs past'. It is assumed that

    the Directorate will include younger an= d newer participants who are

    interested in 'learning while doing wor= k'.

3. Each assignment is for a three year term, unless the me= mber or Internet

    Area Director requests a shorter term.<= o:p>

4. The terms are staggered so that approximately 1/3 of th= e directorate

    members have their term end each year.<= o:p>

5. When the Directorate is first established members of th= e Directorate

    will be assigned either one year, two y= ears, or three years in their

    first term.

6. When a member's term expires, the Internet ADs may repl= ace the person

    whose term expires, may reappoint the s= ame person, or may reduce the

    size of the Directorate. There is no ex= pectation that the same person

    will either want to be returned, or wil= l be returned.

7. The three year term serves as the limit of the commitme= nt of a

    Directorate member, but also serves as = a way to return Directorate

    members to the community.

8. In deciding whether to reappoint a member whose term ha= s expired, the

    Internet ADs may consider the quantity = of work that they have done,

    the ADs' impression of the quality of t= he work, and the comments from

    the authors and other Directorate membe= rs regarding the reviews.

9. If a member resigns before the member's term expires, t= he Internet

    Area Directors may appoint a replacemen= t.

10. The Internet Area Directors may remove a member before= the member's

    term expires, and may appoint a replace= ment.

11. Internet ADs can assign additional members to the Dire= ctorate whenever

    they want to, subject to willingness of= people to serve.

12. Both ADs need to agree in order to assign a member to = the Directorate.

13. Both ADs select one of the Directorate members as the = DHCP Directorate

    Coordinator on a yearly basis.

 

END

 

-     &= nbsp;    Ted, Tomek, & Bernie

 

--_000_489D13FBFA9B3E41812EA89F188F018E185C32B5xmbrcdx04ciscoc_-- From john_brzozowski@cable.comcast.com Tue Jun 25 18:27: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 DE78911E8189 for ; Tue, 25 Jun 2013 18:27:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.897 X-Spam-Level: X-Spam-Status: No, score=-100.897 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HOST_EQ_MODEMCABLE=1.368, IP_NOT_FRIENDLY=0.334, 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 M+HdpUkDd86S for ; Tue, 25 Jun 2013 18:27:14 -0700 (PDT) Received: from cable.comcast.com (pacdcavout01.cable.comcast.com [69.241.43.119]) by ietfa.amsl.com (Postfix) with ESMTP id 1B27211E818C for ; Tue, 25 Jun 2013 18:27:13 -0700 (PDT) Received: from ([24.40.56.115]) by pacdcavout01.cable.comcast.com with ESMTP id 97wm3m1.56673526; Tue, 25 Jun 2013 21:25:47 -0400 Received: from PACDCEXHUB04.cable.comcast.com (24.40.56.121) by PACDCEXHUB02.cable.comcast.com (24.40.56.115) with Microsoft SMTP Server (TLS) id 14.2.318.1; Tue, 25 Jun 2013 21:27:08 -0400 Received: from PACDCEXMB01.cable.comcast.com ([169.254.1.141]) by pacdcexhub04.cable.comcast.com ([fe80::1532:d330:f9a5:c8a1%18]) with mapi id 14.02.0318.001; Tue, 25 Jun 2013 21:27:07 -0400 From: "Brzozowski, John" Thread-Topic: [dhcwg] DHCP Directorate Proposal Thread-Index: Ac5x3HNmjTU+PkrUQRe5be06SLqzEAAL/2EA Date: Wed, 26 Jun 2013 01:27:06 +0000 Message-ID: In-Reply-To: <489D13FBFA9B3E41812EA89F188F018E185C32B5@xmb-rcd-x04.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.5.130515 x-originating-ip: [68.87.16.249] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 To: "dhcwg@ietf.org" Cc: "Bernie Volz \(volz\)" , "Ted Lemon \(ted.lemon@nominum.com\)" , Tomasz Mrugalski Subject: Re: [dhcwg] DHCP Directorate Proposal 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, 26 Jun 2013 01:27:23 -0000 Ted, Bernie, Tomek, This is a great idea and something that has been discussed for some time. Glad to see you moving this forward. The concept seems straight forward as such I do not have a great deal of feedback on the text below. John =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 John Jason Brzozowski Comcast Cable m) 484-962-0060 o) 609-377-6594 w) www.comcast6.net e) john_brzozowski@cable.comcast.com =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 -----Original Message----- From: Bernie Volz Date: Tuesday, June 25, 2013 3:47 PM To: dhc WG Cc: Ted Lemon Subject: [dhcwg] DHCP Directorate Proposal >Hello: >=20 >At the Orlando IETF, Ted Lemon (AD) introduced the idea of an IETF DHCP >Directorate to help streamline the DHC WG workload and provide assistance >to other working groups developing DHCP options. Ted and the DHC WG >co-chairs developed the > following proposal for an DHCP Directorate. As this is tied to the DHC >WG re-charter (see separate email), Ted requested that we share this with >the DHC WG for feedback. This will also be on the agenda for discussion >at Berlin, to hopefully finalize it shortly > thereafter. >=20 >While the DHC re-charter and DHCP directorate are connected, we=B9d like t= o >try to separate the discussion (hence the re-charter) is in a separate >email). >=20 >Per http://tools.ietf.org/html/rfc2418: >=20 > In many areas, the Area Directors have formed an advisory group or > directorate. These comprise experienced members of the IETF and the > technical community represented by the area. The specific name and > the details of the role for each group differ from area to area, but > the primary intent is that these groups assist the Area Director(s), > e.g., with the review of specifications produced in the area. >=20 >For a list of existing directorates, see >http://www.ietf.org/iesg/directorate.html >. >=20 >Proposed DHCP Directorate: >=20 >DHCP Directorate >=20 >The DHCP Directorate is an advisory group of DHCP experts selected by the >Internet Area Directors. >=20 >The notion of a directorate is defined in RFC 2418 as follows: >=20 > In many areas, the Area Directors have formed an advisory group or > directorate. These comprise experienced members of the IETF and the > technical community represented by the area. The specific name and the > details of the role for each group differ from area to area, but the > primary intent is that these groups assist the Area Director(s), e.g., > with the review of specifications produced in the area. >=20 >=20 >What Does the Directorate Do? >=20 >The main purpose of the DHCP Directorate is to review all documents >submitted to the IESG for publication that define new DHCP (DHCPv6 or > >DHCPv4) options, DHCP messages, or DHCP client, relay agent or server >processing. Generally speaking, documents advanced by the DHC WG will >have already received review from members of the DHCP Directorate and >thus may not require such review. >=20 >While the DHC WG is active, the DHCP Directorate is responsible for >reviewing DHCP options or other extensions (for both IPv4 and IPv6). The >Directorate is expected to review all proposed extensions to DHCP to >ensure that they are consistent with the DHCP specification and other >option formats, that they do not duplicate existing mechanisms, etc. >Generally speaking, the Directorate will not be responsible for evaluating >the semantic content of proposed options. >=20 >The tasks performed by the Directorate are: >=20 >1. Review all documents submitted to the IESG for publication that have > DHCP options, messages, or processing requirements. A review is > triggered: >=20 > - By request for early review (by any AD or by any WG chair) > - By a document moving to 'publication requested' state > - By entry on the IESG agenda (for other documents) >=20 >2. Assist ADs with judgment issues when requested - The ADs may send email > to the directorate list when they have issues that they want help with. > Examples for judgment issues are: >=20 > - New option formats. > - New client, relay, server agent processing. >=20 >3. Try to follow IETF documents related to DHCP as early as possible and > provide guidance to authors as early as possible. >=20 >=20 >How is Document Review Organized? >=20 >1. The DHCP Directorate Coordinator assigns each document that is > triggered for review to at least two (2) reviewers and issues a Review > Request. Authors and contributors to a document must not be assigned. > The Review Request will include the document and review deadline. >2. The assigned reviewers must acknowledge and agree to review the > document within 72 hours and respond with a "can review by deadline" or > "can't review". No reply is interpreted as "can't review". >3. If the Coordinator does not receive "can review by deadline" within 72 > hours, the Coordinator selects at least one or two additional >reviewers. > This process is repeated until at least two reviewers are found. >4. The reviewers provide comments as appropriate (IETF Last Call, Area > Director, document authors). >5. The Coordinator may decide to call upon additional reviewers if > expected review is overdue or the topic under review is a complex one. >=20 >=20 >How is the Directorate Formed? >=20 >1. Directorate members are assigned to the Directorate by the Internet > Area Directors. >2. There is an expectation that Directorate membership will not be > limited to 'old-time DHCP gods from years past'. It is assumed that > the Directorate will include younger and newer participants who are > interested in 'learning while doing work'. >3. Each assignment is for a three year term, unless the member or Internet > Area Director requests a shorter term. >4. The terms are staggered so that approximately 1/3 of the directorate > members have their term end each year. >5. When the Directorate is first established members of the Directorate > will be assigned either one year, two years, or three years in their > first term. >6. When a member's term expires, the Internet ADs may replace the person > whose term expires, may reappoint the same person, or may reduce the > size of the Directorate. There is no expectation that the same person > will either want to be returned, or will be returned. >7. The three year term serves as the limit of the commitment of a > Directorate member, but also serves as a way to return Directorate > members to the community. >8. In deciding whether to reappoint a member whose term has expired, the > Internet ADs may consider the quantity of work that they have done, > the ADs' impression of the quality of the work, and the comments from > the authors and other Directorate members regarding the reviews. >9. If a member resigns before the member's term expires, the Internet > Area Directors may appoint a replacement. >10. The Internet Area Directors may remove a member before the member's > term expires, and may appoint a replacement. >11. Internet ADs can assign additional members to the Directorate whenever > they want to, subject to willingness of people to serve. >12. Both ADs need to agree in order to assign a member to the Directorate. >13. Both ADs select one of the Directorate members as the DHCP Directorate > Coordinator on a yearly basis. >=20 >END >=20 >- =20 >Ted, Tomek, & Bernie >=20 > From john_brzozowski@cable.comcast.com Tue Jun 25 18:51: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 9AD4121E810A for ; Tue, 25 Jun 2013 18:51:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.597 X-Spam-Level: X-Spam-Status: No, score=-100.597 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HOST_EQ_MODEMCABLE=1.368, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_13=0.6, 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 giKA4IO9Y4DN for ; Tue, 25 Jun 2013 18:51:08 -0700 (PDT) Received: from cable.comcast.com (pacdcavout01.cable.comcast.com [69.241.43.119]) by ietfa.amsl.com (Postfix) with ESMTP id DC9DD21F99D3 for ; Tue, 25 Jun 2013 18:51:07 -0700 (PDT) Received: from ([24.40.56.115]) by pacdcavout01.cable.comcast.com with ESMTP id 97wm3m1.56674667; Tue, 25 Jun 2013 21:49:32 -0400 Received: from PACDCEXHUB05.cable.comcast.com (24.40.56.122) by PACDCEXHUB02.cable.comcast.com (24.40.56.115) with Microsoft SMTP Server (TLS) id 14.2.318.1; Tue, 25 Jun 2013 21:50:52 -0400 Received: from PACDCEXMB01.cable.comcast.com ([169.254.1.141]) by pacdcexhub05.cable.comcast.com ([fe80::3d40:bdea:7266:7f5a%18]) with mapi id 14.02.0318.001; Tue, 25 Jun 2013 21:50:52 -0400 From: "Brzozowski, John" Thread-Topic: [dhcwg] WGLC on draft-ietf-dhc-dhcpv6-solmaxrt-update-01 - respond by July 4 Thread-Index: AQHOcg+WIWE2uikNb0WXxOL2X1sd1A== Date: Wed, 26 Jun 2013 01:50:51 +0000 Message-ID: In-Reply-To: <489D13FBFA9B3E41812EA89F188F018E185A9B6F@xmb-rcd-x04.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.5.130515 x-originating-ip: [68.87.16.249] Content-Type: text/plain; charset="us-ascii" Content-ID: <31B3FA457DB35E4EA5120BC322DCD3E0@cable.comcast.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 To: "Bernie Volz (volz)" , Tomek Mrugalski , "dhcwg@ietf.org WG" Cc: Ralph Droms , Ted Lemon Subject: Re: [dhcwg] WGLC on draft-ietf-dhc-dhcpv6-solmaxrt-update-01 - respond by July 4 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, 26 Jun 2013 01:51:14 -0000 Bernie, Are you expecting the DHCPv6 SOL_MAX_RT draft to include text about the ND cache considerations? This seems out of context for a DHCWG ID. I think it is worth noting but certainly not something that delay advancing the draft. Alternatively are you think each retransmission should include multiple attempts? If yes I think we need to be careful not to recreate the original problem that we are trying to resolve. Regarding the client wait time for responses, are we trying to address a security concern or simply trying to provide some guidance for client implementers? In general I am not opposed to the text, however, I wonder if it is completely necessary. John -----Original Message----- From: Bernie Volz Date: Thursday, June 20, 2013 1:13 PM To: Tomasz Mrugalski , dhc WG Cc: Ralph Droms , Ted Lemon Subject: Re: [dhcwg] WGLC on draft-ietf-dhc-dhcpv6-solmaxrt-update-01 - respond by July 4 > > >I don't yet support this document moving forward - I think the issues >raised earlier need to be 'resolved'. > >The ND cache timeout is a concern if there are relays (routers) or >servers (kernel stacks) that do not save the packet needing ND resolution. > >The DHCPv6 client will send 1 packet every hour to the relay or server. >This is MULTICAST and there is no ND exchange since the mac address is >known. When the relay or server then UNICASTs the response, it will need >to do ND (of the link-local address) to determine the mac address. And, >if the DHCP reply is not saved while this ND resolution takes place, >nothing will end up being transmitted to the client when the ND >resolution completes. > >An hour later, the same thing could happen. Hence, the client never gets >the ADVERTISE. > >The old maximum retransmission timer was more likely within bounds of the >expiration of the ND cache entry (except in cases where the cache grew >large and some entries might be prematurely removed if not recently used). > >I know this negates some of the benefits of the longer time if the client >were to retransmit several times. And, if we simply want to point out >this issue and recommend that ND implementations assure that they retain >these (DHCPv6) packets when doing a resolution, that is fine by me. > > >I'm also not sure why stating the a client is only required to wait for a >'reasonable' time for a response wasn't addressed. This could be >something like: > >A client SHOULD wait TTL * 2 (which is like close to the 120 which was >the old SOL_MAX_RT so perhaps we should just use that) with a MAY wait >for less if, for example, power consumption is a key concern. > > >I had though Ralph proposed to discuss these issues at Berlin and resolve >them -- then we'd do the WGLC. I'm fine with trying to resolve these >issues on the list. > >- Bernie > >-----Original Message----- >From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of >Tomek Mrugalski >Sent: Thursday, June 20, 2013 12:23 PM >To: dhcwg@ietf.org WG >Cc: Ralph Droms; Ted Lemon >Subject: [dhcwg] WGLC on draft-ietf-dhc-dhcpv6-solmaxrt-update-01 - >respond by July 4 > >On 20.06.2013 17:11, Ralph Droms wrote: >> On Jun 20, 2013, at 10:30 AM 6/20/13, Ted Lemon wrote: >>> Do we need a SOL_MAX_RT presentation in Berlin? Why not just >>> last-call it now? >>=20 >> OK with me. >My understanding is that under normal circumstances chairs cannot just >announce WGLC on their own. They can do so if authors or editors state >the the draft is ready and chairs concur with that opinion. Anyway, here >it goes: > >Folks, the author of draft-ietf-dhc-dhcpv6-solmaxrt-update-01 >(http://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-solmaxrt-update-01) >feels it's ready for work group last call. Please review this draft and >indicate whether or not you feel it is ready to be published. > >This document redefines two timers (SOL_MAX_RT and INF_MAX_RT) that >control SOLICIT and INFORMATION-REQUEST message retransmissions and >define a mechanism for server to override client's default values. There >is a document in v6ops about basic requirements for IPv6 CE routers that >depends on this work. > >At the time of this writing, there is no IPR reported against this draft. > >Bernie and I will evaluate consensus after 2013-07-04. > >Thanks, >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 john_brzozowski@cable.comcast.com Tue Jun 25 18:56: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 7123011E80F9 for ; Tue, 25 Jun 2013 18:56:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.914 X-Spam-Level: X-Spam-Status: No, score=-102.914 tagged_above=-999 required=5 tests=[AWL=2.317, BAYES_00=-2.599, HOST_EQ_MODEMCABLE=1.368, 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 moWS0fW2ZET9 for ; Tue, 25 Jun 2013 18:56:06 -0700 (PDT) Received: from cable.comcast.com (copdcavout01.cable.comcast.com [76.96.32.253]) by ietfa.amsl.com (Postfix) with ESMTP id 2CC0F21F99D4 for ; Tue, 25 Jun 2013 18:56:06 -0700 (PDT) Received: from ([24.40.56.115]) by copdcavout01.cable.comcast.com with ESMTP id C7WM3M1.79351089; Tue, 25 Jun 2013 19:55:07 -0600 Received: from PACDCEXMB01.cable.comcast.com ([169.254.1.141]) by PACDCEXHUB02.cable.comcast.com ([fe80::492e:3fa1:c2ad:e04e%13]) with mapi id 14.02.0318.001; Tue, 25 Jun 2013 21:56:01 -0400 From: "Brzozowski, John" Thread-Topic: [dhcwg] WGLC on draft-ietf-dhc-dhcpv6-solmaxrt-update-01 - respond by July 4 Thread-Index: AQHOchBOfAvWxTi/3kuwYinF4LLgqg== Date: Wed, 26 Jun 2013 01:55:59 +0000 Message-ID: In-Reply-To: <489D13FBFA9B3E41812EA89F188F018E185AC7F1@xmb-rcd-x04.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.5.130515 x-originating-ip: [68.87.16.249] Content-Type: text/plain; charset="us-ascii" Content-ID: <84D237594B0DC04E950A0BF13F0A8BC2@cable.comcast.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 To: "Bernie Volz (volz)" , Ralph Droms Cc: "dhcwg@ietf.org WG" , Lemon Ted Subject: Re: [dhcwg] WGLC on draft-ietf-dhc-dhcpv6-solmaxrt-update-01 - respond by July 4 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, 26 Jun 2013 01:56:12 -0000 Regarding the below I for one have no objections. However, I could just as easily see the work advancing as-is. Providing the below allows us to move forward I support the edits. John -----Original Message----- From: Bernie Volz Date: Friday, June 21, 2013 11:24 AM To: Ralph Droms Cc: dhc WG , Ted Lemon Subject: Re: [dhcwg] WGLC on draft-ietf-dhc-dhcpv6-solmaxrt-update-01 - respond by July 4 >Does anyone have an OBJECTION to adding something close to: > >>A client SHOULD wait TTL * 2 (which is like close to the 120 which was >>the old SOL_MAX_RT so perhaps we should just use that) with a MAY wait >>for less if, for example, power consumption is a key concern. > >A more formal clarification (actual text) might be: > >Add to section 3 of the draft (end of existing text): > > Also, with this change, a new parameter is need to cap the time a client > must wait for a response from the server as waiting for the new > SOL_MAX_RT seems excessive. Hence, the following is added: > > NEW: > MAX_RCV_TIME 120 secs Max time to wait for a response > >Add to section 6 of the draft (probably first): > > Add to section 14 of RFC 3315 (at end of existing text): > > RT specifies the retransmission interval and not necessarily the time a > client listens for a response from the server. Clients SHOULD wait for > responses for at least the shorter of the RT and MAX_RCV_TIME. There > MAY be situations where a shorter MAX_RCV_TIME is appropriate - such > as when power consumption is a key concern. > >Optional: Document the source of MAX_RCV_TIME which came from old >SOL_MAX_RT and also is the TCP Maximum Segment Lifetime, RFC 792. > >- Bernie From volz@cisco.com Tue Jun 25 18:58: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 79E9D11E80BA for ; Tue, 25 Jun 2013 18:58:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.999 X-Spam-Level: X-Spam-Status: No, score=-9.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=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 CgWKqYbOEyAW for ; Tue, 25 Jun 2013 18:58:19 -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 75AB111E8189 for ; Tue, 25 Jun 2013 18:58:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5438; q=dns/txt; s=iport; t=1372211899; x=1373421499; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=gxzSqjBDCFoNnJ0mpvJF4O7CC+clxMsuwMvTKzmSnnQ=; b=NloXk7lStlw4eot4wAZ4gEafaib9idASEpMG48uZug4WUjRFpDg5zuiL DSMpED0o7gOYFIwvz2db+eoUVWIdH63InUJT9I/XDm8A7ayrNBRIt/6LH gaLI0S+3S7u9KivcazJ/YKTGo8/MmXAEc8K+aKKFTjpXUXufZ/VPXtyNh M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUFAMlJylGtJXHB/2dsb2JhbABagwkxSb84gQkWdIIjAQEBBAEBATc0CwwEAgEIEQMBAQEBChQJByEGCxQJCAIEAQ0FCId0Aw8MsWANiFKMYoE3gQAGKwcCBIJ8YQOVXIMQineFJYFYgTmCKA X-IronPort-AV: E=Sophos;i="4.87,940,1363132800"; d="scan'208";a="227443128" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-3.cisco.com with ESMTP; 26 Jun 2013 01:58:18 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id r5Q1wHxb031405 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 26 Jun 2013 01:58:18 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.56]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.02.0318.004; Tue, 25 Jun 2013 20:58:17 -0500 From: "Bernie Volz (volz)" To: "Brzozowski, John" , Tomek Mrugalski , "dhcwg@ietf.org WG" Thread-Topic: [dhcwg] WGLC on draft-ietf-dhc-dhcpv6-solmaxrt-update-01 - respond by July 4 Thread-Index: AQHObdKJVMeT/vzt/EmS3DMQ2BpdK5k+0AWAgAjHU4D//631gA== Date: Wed, 26 Jun 2013 01:58:16 +0000 Message-ID: <489D13FBFA9B3E41812EA89F188F018E185C3C77@xmb-rcd-x04.cisco.com> References: <489D13FBFA9B3E41812EA89F188F018E185A9B6F@xmb-rcd-x04.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.245.30] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Ralph Droms , Ted Lemon Subject: Re: [dhcwg] WGLC on draft-ietf-dhc-dhcpv6-solmaxrt-update-01 - respond by July 4 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, 26 Jun 2013 01:58:24 -0000 This issue was already addressed - Ralph found text in the ND document that= 'requires' the node to retain packet(s) while doing ND to send them once t= he ND is successful. So, it is a non-issue and I removed my objection. -----Original Message----- From: Brzozowski, John [mailto:John_Brzozowski@Cable.Comcast.com]=20 Sent: Tuesday, June 25, 2013 9:51 PM To: Bernie Volz (volz); Tomek Mrugalski; dhcwg@ietf.org WG Cc: Ralph Droms; Ted Lemon Subject: Re: [dhcwg] WGLC on draft-ietf-dhc-dhcpv6-solmaxrt-update-01 - res= pond by July 4 Bernie, Are you expecting the DHCPv6 SOL_MAX_RT draft to include text about the ND = cache considerations? This seems out of context for a DHCWG ID. I think i= t is worth noting but certainly not something that delay advancing the draf= t. Alternatively are you think each retransmission should include multiple= attempts? If yes I think we need to be careful not to recreate the origin= al problem that we are trying to resolve. Regarding the client wait time for responses, are we trying to address a se= curity concern or simply trying to provide some guidance for client impleme= nters? In general I am not opposed to the text, however, I wonder if it is= completely necessary. John -----Original Message----- From: Bernie Volz Date: Thursday, June 20, 2013 1:13 PM To: Tomasz Mrugalski , dhc WG Cc: Ralph Droms , Ted Lemon Subject: Re: [dhcwg] WGLC on draft-ietf-dhc-dhcpv6-solmaxrt-update-01 - res= pond by July 4 > > >I don't yet support this document moving forward - I think the issues=20 >raised earlier need to be 'resolved'. > >The ND cache timeout is a concern if there are relays (routers) or=20 >servers (kernel stacks) that do not save the packet needing ND resolution. > >The DHCPv6 client will send 1 packet every hour to the relay or server. >This is MULTICAST and there is no ND exchange since the mac address is=20 >known. When the relay or server then UNICASTs the response, it will=20 >need to do ND (of the link-local address) to determine the mac address.=20 >And, if the DHCP reply is not saved while this ND resolution takes=20 >place, nothing will end up being transmitted to the client when the ND=20 >resolution completes. > >An hour later, the same thing could happen. Hence, the client never=20 >gets the ADVERTISE. > >The old maximum retransmission timer was more likely within bounds of=20 >the expiration of the ND cache entry (except in cases where the cache=20 >grew large and some entries might be prematurely removed if not recently u= sed). > >I know this negates some of the benefits of the longer time if the=20 >client were to retransmit several times. And, if we simply want to=20 >point out this issue and recommend that ND implementations assure that=20 >they retain these (DHCPv6) packets when doing a resolution, that is fine b= y me. > > >I'm also not sure why stating the a client is only required to wait for=20 >a 'reasonable' time for a response wasn't addressed. This could be=20 >something like: > >A client SHOULD wait TTL * 2 (which is like close to the 120 which was=20 >the old SOL_MAX_RT so perhaps we should just use that) with a MAY wait=20 >for less if, for example, power consumption is a key concern. > > >I had though Ralph proposed to discuss these issues at Berlin and=20 >resolve them -- then we'd do the WGLC. I'm fine with trying to resolve=20 >these issues on the list. > >- Bernie > >-----Original Message----- >From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf=20 >Of Tomek Mrugalski >Sent: Thursday, June 20, 2013 12:23 PM >To: dhcwg@ietf.org WG >Cc: Ralph Droms; Ted Lemon >Subject: [dhcwg] WGLC on draft-ietf-dhc-dhcpv6-solmaxrt-update-01 -=20 >respond by July 4 > >On 20.06.2013 17:11, Ralph Droms wrote: >> On Jun 20, 2013, at 10:30 AM 6/20/13, Ted Lemon wrote: >>> Do we need a SOL_MAX_RT presentation in Berlin? Why not just >>> last-call it now? >>=20 >> OK with me. >My understanding is that under normal circumstances chairs cannot just=20 >announce WGLC on their own. They can do so if authors or editors state=20 >the the draft is ready and chairs concur with that opinion. Anyway,=20 >here it goes: > >Folks, the author of draft-ietf-dhc-dhcpv6-solmaxrt-update-01 >(http://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-solmaxrt-update-01) >feels it's ready for work group last call. Please review this draft and=20 >indicate whether or not you feel it is ready to be published. > >This document redefines two timers (SOL_MAX_RT and INF_MAX_RT) that=20 >control SOLICIT and INFORMATION-REQUEST message retransmissions and=20 >define a mechanism for server to override client's default values.=20 >There is a document in v6ops about basic requirements for IPv6 CE=20 >routers that depends on this work. > >At the time of this writing, there is no IPR reported against this draft. > >Bernie and I will evaluate consensus after 2013-07-04. > >Thanks, >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 volz@cisco.com Tue Jun 25 19:18: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 DA01C21E804E for ; Tue, 25 Jun 2013 19:18:03 -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 WiDPUgi1bngt for ; Tue, 25 Jun 2013 19:17:47 -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 0325A21E8109 for ; Tue, 25 Jun 2013 19:17:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=23051; q=dns/txt; s=iport; t=1372213067; x=1373422667; h=from:to:cc:subject:date:message-id:mime-version; bh=q5KC9Qpx5iCDTzK+Dm7mCsZum+0HC8ZpsToqforixHs=; b=d/AV1zJfKl2sDTI9bxA/Elz1OIKfo9wK5o0LeUSMTKcxohmyQCCfyG6H O4Zi9NQ+zoJXjPsBwDCKwxlF1elcFqa53cGl7Ct+kBp9nrX74vvmf0SV+ N+IWicCZsbFMbcQNHFhc5ULo3rGBL8sb9PmNzKrkGMBBWg2Z5HthHbW1+ I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgYFALdOylGtJXG8/2dsb2JhbABagkVEMUm2dIhEgQkWdIIjAQEBBB0QQQsSARkEAQELFkAdCQEEDgUIAYgFDLo7jgiBETGDCWEDiGmQA5AcgxGBcTc X-IronPort-AV: E=Sophos;i="4.87,941,1363132800"; d="scan'208,217";a="224448118" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-9.cisco.com with ESMTP; 26 Jun 2013 02:17:46 +0000 Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id r5Q2Hjwm003610 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 26 Jun 2013 02:17:45 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.56]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.02.0318.004; Tue, 25 Jun 2013 21:17:45 -0500 From: "Bernie Volz (volz)" To: "dhcwg@ietf.org" Thread-Topic: Draft WG Agenda (for IETF-87, Berlin) Thread-Index: Ac5yEt02RiYWAvTvQNKm94wee3JbgQ== Date: Wed, 26 Jun 2013 02:17:44 +0000 Message-ID: <489D13FBFA9B3E41812EA89F188F018E185C3D18@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.245.30] Content-Type: multipart/alternative; boundary="_000_489D13FBFA9B3E41812EA89F188F018E185C3D18xmbrcdx04ciscoc_" MIME-Version: 1.0 Cc: "Dhc Chairs \(dhc-chairs@tools.ietf.org\)" Subject: [dhcwg] Draft WG Agenda (for IETF-87, Berlin) 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, 26 Jun 2013 02:18:04 -0000 --_000_489D13FBFA9B3E41812EA89F188F018E185C3D18xmbrcdx04ciscoc_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Here's the current list of items on the agenda for the Berlin IETF DHC WG m= eeting. If you sent a request and I missed it (or it was incomplete) or you= would like some time, please let the co-chairs know! (See below - earlier = email - for what's needed.) 0. Administrivia. Time 10 min 1. Co-Chairs & AD - DHC Re-Charter and DHCP Directorate. Time: 30 min 2. Tomek Mrugalski - DHCPv6 Options guidelines. Time: 10 min 3. Ralph Droms - draft-ietf-dhc-dhcpv6-solmaxrt-update. Time: 10 min [might= not be needed if WG last-call passed] 4. Ralph Droms - draft-ietf-dhc-container-opt. Time: 10 min 5. Bernie Volz - draft-ietf-dhc-stateful-issues. Time: 10 min 6. Qi Sun - draft-ietf-dhc-dhcpv4-over-dhcpv6. Time: 10 min 7. Qi Sun - draft-ietf-dhc-dhcpv6-unknown-msg. Time: 5 min 8. Ian Farrer - draft-ietf-dhc-v4configuration. Time: 10 min 9. Prashanth Patil - draft-wing-dhc-dns-reconfigure - Time: 10-15 min We'll also add some discussion time to "resolve" the v4-over-v6 issues. We don't yet know when this session will be and whether it will occur befor= e or after the joint Sunset4/DHC WG session; if after, we'll include a few = minutes for summary and follow up from that session. - Tomek & Bernie From: Bernie Volz (volz) Sent: Thursday, May 23, 2013 4:26 PM To: dhcwg@ietf.org Cc: Dhc Chairs (dhc-chairs@tools.ietf.org) Subject: IETF-87 (Berlin) Call for Agenda Items 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_489D13FBFA9B3E41812EA89F188F018E185C3D18xmbrcdx04ciscoc_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Here’s the curre= nt list of items on the agenda for the Berlin IETF DHC WG meeting. If you s= ent a request and I missed it (or it was incomplete) or you would like some= time, please let the co-chairs know! (See below – earlier email – for what’s needed.)

 

0. Administrivia. Time= 10 min

 

1. Co-Chairs & AD = - DHC Re-Charter and DHCP Directorate. Time: 30 min

 

2. Tomek Mrugalski - D= HCPv6 Options guidelines. Time: 10 min

 

3. Ralph Droms - draft= -ietf-dhc-dhcpv6-solmaxrt-update. Time: 10 min [might not be needed if WG l= ast-call passed]

 

4. Ralph Droms - draft= -ietf-dhc-container-opt. Time: 10 min

 

5. Bernie Volz - draft= -ietf-dhc-stateful-issues. Time: 10 min

 

6. Qi Sun - draft-ietf= -dhc-dhcpv4-over-dhcpv6. Time: 10 min

 

7. Qi Sun - draft-ietf= -dhc-dhcpv6-unknown-msg. Time: 5 min

 

8. Ian Farrer - draft-= ietf-dhc-v4configuration. Time: 10 min

 

9. Prashanth Patil - d= raft-wing-dhc-dns-reconfigure - Time: 10-15 min

 

We’ll also add s= ome discussion time to “resolve” the v4-over-v6 issues.

 

We don’t yet kno= w when this session will be and whether it will occur before or after the j= oint Sunset4/DHC WG session; if after, we’ll include a few minutes fo= r summary and follow up from that session.

 

-&nb= sp;         Tomek & Be= rnie

 

From: Bernie V= olz (volz)
Sent: Thursday, May 23, 2013 4:26 PM
To: dhcwg@ietf.org
Cc: Dhc Chairs (dhc-chairs@tools.ietf.org)
Subject: IETF-87 (Berlin) Call for Agenda Items

 

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_489D13FBFA9B3E41812EA89F188F018E185C3D18xmbrcdx04ciscoc_-- From Ted.Lemon@nominum.com Tue Jun 25 22:03: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 2DFC421E8053 for ; Tue, 25 Jun 2013 22:03:01 -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 K9HvO2Jv+0Mb for ; Tue, 25 Jun 2013 22:02:54 -0700 (PDT) Received: from exprod7og114.obsmtp.com (exprod7og114.obsmtp.com [64.18.2.215]) by ietfa.amsl.com (Postfix) with ESMTP id 74B0121E8084 for ; Tue, 25 Jun 2013 22:02:53 -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 DSNKUcp1/apM0bUJyJSGYBlJiPWiF6iHhX/q@postini.com; Tue, 25 Jun 2013 22:02:54 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 410941B8221 for ; Tue, 25 Jun 2013 22:02:53 -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 93A4B19005D; Tue, 25 Jun 2013 22:02:52 -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, 25 Jun 2013 22:02:40 -0700 From: Ted Lemon To: "Brzozowski, John" Thread-Topic: [dhcwg] WGLC on draft-ietf-dhc-dhcpv6-solmaxrt-update-01 - respond by July 4 Thread-Index: AQHObdJ8tdho1Ps1m0miuvIzDaHtnZk/TJqAgAhsRoCAADWXAA== Date: Wed, 26 Jun 2013 05:02:40 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B6307751EBE59@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: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dhcwg@ietf.org WG" , "Bernie Volz \(volz\)" , Ralph Droms Subject: Re: [dhcwg] WGLC on draft-ietf-dhc-dhcpv6-solmaxrt-update-01 - respond by July 4 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, 26 Jun 2013 05:03:01 -0000 On Jun 25, 2013, at 9:50 PM, "Brzozowski, John" wrote: > Are you expecting the DHCPv6 SOL_MAX_RT draft to include text about the N= D > cache considerations? This seems out of context for a DHCWG ID. It looks like a device that doesn't keep the DHCP response long enough to g= et an answer from neighbor discovery and correctly forward it is out of spe= c, so we don't need to worry about this. From rdroms.ietf@gmail.com Wed Jun 26 05:12:46 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 472C421F9AAD for ; Wed, 26 Jun 2013 05:12:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102 X-Spam-Level: X-Spam-Status: No, score=-102 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=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 0lLpUUGcS60S for ; Wed, 26 Jun 2013 05:12:45 -0700 (PDT) Received: from mail-qa0-x22d.google.com (mail-qa0-x22d.google.com [IPv6:2607:f8b0:400d:c00::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 3F33521F9C79 for ; Wed, 26 Jun 2013 05:12:44 -0700 (PDT) Received: by mail-qa0-f45.google.com with SMTP id ci6so1507561qab.11 for ; Wed, 26 Jun 2013 05:12:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to:x-mailer; bh=wBCtoO6ISvxfS6xFVHEIWg0282V8qUHGL1rKGn51T9c=; b=J8WDHc/f1ep2egLCys3/x3TQVUM/+tlp2IUblFLSNjEPobFDz2IY1xElbuC5zhLaID rNoXiOSJNea95dV+UEdQvOIhilYWlS7r63RM1uzrmg2YeeAFr3szwZcYoxRg2JAK/igM 86MEemA7hgqbVPNgOnAdlf5qo67tR03+MX6W/is944GGhK26SlZJ5d154POoC1p/AOM6 tE3tvRn4+ZwEQ3r5LfmaVJ+hbki/ARjjJUGBoXGC6yIvmgDpk6daOj3I96cWHYelmqiQ NVH8AdoXrZcgbZ1bZNKhIJJMnA9jHD+cnu1T0QTplh44QcDDiHaw4436jZggjMWd2hx+ DXWw== X-Received: by 10.49.30.104 with SMTP id r8mr4183120qeh.27.1372248764261; Wed, 26 Jun 2013 05:12:44 -0700 (PDT) Received: from ?IPv6:2001:420:2481:20:24c4:aca9:455c:f0d2? ([2001:420:2481:20:24c4:aca9:455c:f0d2]) by mx.google.com with ESMTPSA id j9sm32840459qas.3.2013.06.26.05.12.40 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 26 Jun 2013 05:12:41 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Ralph Droms In-Reply-To: <489D13FBFA9B3E41812EA89F188F018E185AC7F1@xmb-rcd-x04.cisco.com> Date: Wed, 26 Jun 2013 08:12:39 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <1DF6792F-30B9-4C38-808C-DD6D1D37A099@gmail.com> References: <3135C2851EB6764BACEF35D8B495596806E7DAB304@MOPESMBX01.eu.thmulti.com> <51C31065.8040804@gmail.com> <8D23D4052ABE7A4490E77B1A012B6307751E2D82@mbx-01.win.nominum.com> <51C32C73.1010203@gmail.com> <489D13FBFA9B3E41812EA89F188F018E185A9B6F@xmb-rcd-x04.cisco.com> <90C4B43B-4EF6-40DD-A5F1-DBF82402F191@gmail.com> <489D13FBFA9B3E41812EA89F188F018E185AC7F1@xmb-rcd-x04.cisco.com> To: "dhcwg@ietf.org WG" X-Mailer: Apple Mail (2.1508) Subject: Re: [dhcwg] WGLC on draft-ietf-dhc-dhcpv6-solmaxrt-update-01 - respond by July 4 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, 26 Jun 2013 12:12:46 -0000 I haven't seen any additional discussion of Bernie's suggestion to add = text to this draft clarifying client behavior regarding listening for = responses. We need some indication of consensus before changing the = document. Minor editorial comments in line... - Ralph On Jun 21, 2013, at 11:24 AM 6/21/13, Bernie Volz (volz) = wrote: > Hi Ralph: >=20 > OK, great that the ND issue isn't real. I had looked for something = like that at one point but didn't find it. As that is the case, that is = no longer an issue. Too bad this wasn't found earlier (or if it was = mentioned, I missed it - sorry). So I withdraw that objection. >=20 >=20 > Regarding the issue about how long the receiver needs to wait for a = packet, I think there was some discussion and support for that during = some of the email exchange. I don't believe anyone was against adding = something to NOT require waiting the full time (given the longer solmax) = for a response from the DHCP server. That makes no sense to wait an hour = or even many minutes. >=20 > It seems silly to have a completely separate draft mention that. We = didn't have a need to mention this when RFC 3315 was written since the = times were assumed to be reasonable for 'waiting'. >=20 > Does anyone have an OBJECTION to adding something close to: >=20 >> A client SHOULD wait TTL * 2 (which is like close to the 120 which = was the old SOL_MAX_RT so perhaps we should just use that) with a MAY = wait for less if, for example, power consumption is a key concern. >=20 > A more formal clarification (actual text) might be: >=20 > Add to section 3 of the draft (end of existing text): >=20 > Also, with this change, a new parameter is need to cap the time a = client > must wait for a response from the server as waiting for the new s/wait/listen/ > SOL_MAX_RT seems excessive. Hence, the following is added: s/seems/may, in some situations, be unnecessary and expensive. s/following is added/the following change to RFC 3315 is made/ >=20 > NEW: > MAX_RCV_TIME 120 secs Max time to wait for a response >=20 > Add to section 6 of the draft (probably first): >=20 > Add to section 14 of RFC 3315 (at end of existing text): >=20 > RT specifies the retransmission interval and not necessarily the = time a > client listens for a response from the server. Clients SHOULD wait = for s/wait/listens/ > responses for at least the shorter of the RT and MAX_RCV_TIME. There > MAY be situations where a shorter MAX_RCV_TIME is appropriate - such s/MAY/may/ > as when power consumption is a key concern. >=20 > Optional: Document the source of MAX_RCV_TIME which came from old = SOL_MAX_RT and also is the TCP Maximum Segment Lifetime, RFC 792. >=20 > - Bernie >=20 > -----Original Message----- > From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf = Of Ralph Droms > Sent: Friday, June 21, 2013 10:29 AM > To: Bernie Volz (volz) > Cc: dhcwg@ietf.org WG; Lemon Ted > Subject: Re: [dhcwg] WGLC on draft-ietf-dhc-dhcpv6-solmaxrt-update-01 = - respond by July 4 >=20 >=20 > On Jun 20, 2013, at 1:13 PM 6/20/13, Bernie Volz (volz) = wrote: >=20 >> >>=20 >> I don't yet support this document moving forward - I think the issues = raised earlier need to be 'resolved'. >>=20 >> The ND cache timeout is a concern if there are relays (routers) or = servers (kernel stacks) that do not save the packet needing ND = resolution. >=20 > That behavior is not RFC-compliant; from section 7.2.2 of RFC 4861: >=20 > While waiting for address resolution to complete, the sender MUST, > for each neighbor, retain a small queue of packets waiting for > address resolution to complete. The queue MUST hold at least one > packet, and MAY contain more. >=20 >>=20 >> The DHCPv6 client will send 1 packet every hour to the relay or = server. This is MULTICAST and there is no ND exchange since the mac = address is known. When the relay or server then UNICASTs the response, = it will need to do ND (of the link-local address) to determine the mac = address. And, if the DHCP reply is not saved while this ND resolution = takes place, nothing will end up being transmitted to the client when = the ND resolution completes. >>=20 >> An hour later, the same thing could happen. Hence, the client never = gets the ADVERTISE. >>=20 >> The old maximum retransmission timer was more likely within bounds of = the expiration of the ND cache entry (except in cases where the cache = grew large and some entries might be prematurely removed if not recently = used). >>=20 >> I know this negates some of the benefits of the longer time if the = client were to retransmit several times. And, if we simply want to point = out this issue and recommend that ND implementations assure that they = retain these (DHCPv6) packets when doing a resolution, that is fine by = me. >>=20 >>=20 >> I'm also not sure why stating the a client is only required to wait = for a 'reasonable' time for a response wasn't addressed. This could be = something like: >>=20 >> A client SHOULD wait TTL * 2 (which is like close to the 120 which = was the old SOL_MAX_RT so perhaps we should just use that) with a MAY = wait for less if, for example, power consumption is a key concern. >=20 > I wasn't given any indication of consensus supporting that change, so = I didn't include it. >>=20 >>=20 >> I had though Ralph proposed to discuss these issues at Berlin and = resolve them -- then we'd do the WGLC. I'm fine with trying to resolve = these issues on the list. >=20 > IMHO, we should first determine consensus for publishing = draft-ietf-dhc-dhcpv6-solmaxrt-update-01 as is and addressing these = additional issues in a separate document or holding = draft-ietf-dhc-dhcpv6-solmaxrt-update-01 until these additional issues = are discussed. While the question has not been posed explicitly on the = list, there seems to be support for going ahead with = draft-ietf-dhc-dhcpv6-solmaxrt-update-01 in its current form. >=20 >>=20 >> - Bernie >=20 > - Ralph >=20 >>=20 >> -----Original Message----- >> From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On = Behalf Of Tomek Mrugalski >> Sent: Thursday, June 20, 2013 12:23 PM >> To: dhcwg@ietf.org WG >> Cc: Ralph Droms; Ted Lemon >> Subject: [dhcwg] WGLC on draft-ietf-dhc-dhcpv6-solmaxrt-update-01 - = respond by July 4 >>=20 >> On 20.06.2013 17:11, Ralph Droms wrote: >>> On Jun 20, 2013, at 10:30 AM 6/20/13, Ted Lemon wrote: >>>> Do we need a SOL_MAX_RT presentation in Berlin? Why not just >>>> last-call it now? >>>=20 >>> OK with me. >> My understanding is that under normal circumstances chairs cannot = just announce WGLC on their own. They can do so if authors or editors = state the the draft is ready and chairs concur with that opinion. = Anyway, here it goes: >>=20 >> Folks, the author of draft-ietf-dhc-dhcpv6-solmaxrt-update-01 >> (http://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-solmaxrt-update-01) >> feels it's ready for work group last call. Please review this draft = and indicate whether or not you feel it is ready to be published. >>=20 >> This document redefines two timers (SOL_MAX_RT and INF_MAX_RT) that = control SOLICIT and INFORMATION-REQUEST message retransmissions and = define a mechanism for server to override client's default values. There = is a document in v6ops about basic requirements for IPv6 CE routers that = depends on this work. >>=20 >> At the time of this writing, there is no IPR reported against this = draft. >>=20 >> Bernie and I will evaluate consensus after 2013-07-04. >>=20 >> Thanks, >> Bernie & Tomek >> _______________________________________________ >> 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 rdroms.ietf@gmail.com Wed Jun 26 05:16: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 1268411E80E3 for ; Wed, 26 Jun 2013 05:16:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102 X-Spam-Level: X-Spam-Status: No, score=-102 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=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 zVsuwXQZrNYv for ; Wed, 26 Jun 2013 05:16:38 -0700 (PDT) Received: from mail-qc0-x234.google.com (mail-qc0-x234.google.com [IPv6:2607:f8b0:400d:c01::234]) by ietfa.amsl.com (Postfix) with ESMTP id 39FAD21F8AD5 for ; Wed, 26 Jun 2013 05:16:38 -0700 (PDT) Received: by mail-qc0-f180.google.com with SMTP id a1so8030308qcx.25 for ; Wed, 26 Jun 2013 05:16:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=cP6IKw8jIWf90Yvo2jXWNB0Pn/Z4idSkN8yO+7ndYOs=; b=x0Xz0y2b98sHwgvFYFTUPIRA5qU/kj1wFwpCPJ+aELW+AX9t0QK4NzlPJWWXiGmI2w OeO6An+TsYDs7LfcG3yNG9MIruDqNZPlRmvjVzrYMMohyY1Z4tihLOp/sac56+9SHUX2 Qc9EErVJ4bHV6n7U0REv3yKt7kGLEeG3kSqNE94R3JBAGDmwN7oPeWM3bvnEIyuWPBJv Jg/CQWojhjqTZVPxn9A/QlmnEsOYsXUBblcHKgUL+Dh+EwAtDzuQO4EufpP+m37GhBWi H16RtJXkWOlfTn3g7dDVP2DTxyILbijxos0MSCf+MXws6Ozyind23GZkCCrgT1vOEFZi PwMg== X-Received: by 10.49.16.197 with SMTP id i5mr4067055qed.58.1372248997642; Wed, 26 Jun 2013 05:16:37 -0700 (PDT) Received: from ?IPv6:2001:420:2481:20:24c4:aca9:455c:f0d2? ([2001:420:2481:20:24c4:aca9:455c:f0d2]) by mx.google.com with ESMTPSA id ds7sm33066067qab.13.2013.06.26.05.16.35 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 26 Jun 2013 05:16:36 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Ralph Droms In-Reply-To: Date: Wed, 26 Jun 2013 08:16:34 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <8CE45C4C-19DF-403B-A57D-9C0BD1D2502A@gmail.com> References: To: "Brzozowski, John" X-Mailer: Apple Mail (2.1508) Cc: "dhcwg@ietf.org WG" , "Bernie Volz \(volz\)" , Lemon Ted Subject: Re: [dhcwg] WGLC on draft-ietf-dhc-dhcpv6-solmaxrt-update-01 - respond by July 4 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, 26 Jun 2013 12:16:39 -0000 John... On Jun 25, 2013, at 9:50 PM 6/25/13, "Brzozowski, John" = wrote: > Bernie, >=20 >=20 > Are you expecting the DHCPv6 SOL_MAX_RT draft to include text about = the ND > cache considerations? This seems out of context for a DHCWG ID. I = think > it is worth noting but certainly not something that delay advancing = the > draft. Alternatively are you think each retransmission should include > multiple attempts? If yes I think we need to be careful not to = recreate > the original problem that we are trying to resolve. >=20 > Regarding the client wait time for responses, are we trying to address = a > security concern or simply trying to provide some guidance for client > implementers? That text is intended to clarify that a client can stop listening for a = response and, for example, go to sleep before sending the next = retransmission of a specific message. The immediate purpose is to allow = resource conservation in constrained devices while remaining compliant = with the DHCPv6 specification. - Ralph > In general I am not opposed to the text, however, I wonder > if it is completely necessary. >=20 > John >=20 > -----Original Message----- > From: Bernie Volz > Date: Thursday, June 20, 2013 1:13 PM > To: Tomasz Mrugalski , dhc WG = > Cc: Ralph Droms , Ted Lemon = > Subject: Re: [dhcwg] WGLC on draft-ietf-dhc-dhcpv6-solmaxrt-update-01 = - > respond by July 4 >=20 >> >>=20 >> I don't yet support this document moving forward - I think the issues >> raised earlier need to be 'resolved'. >>=20 >> The ND cache timeout is a concern if there are relays (routers) or >> servers (kernel stacks) that do not save the packet needing ND = resolution. >>=20 >> The DHCPv6 client will send 1 packet every hour to the relay or = server. >> This is MULTICAST and there is no ND exchange since the mac address = is >> known. When the relay or server then UNICASTs the response, it will = need >> to do ND (of the link-local address) to determine the mac address. = And, >> if the DHCP reply is not saved while this ND resolution takes place, >> nothing will end up being transmitted to the client when the ND >> resolution completes. >>=20 >> An hour later, the same thing could happen. Hence, the client never = gets >> the ADVERTISE. >>=20 >> The old maximum retransmission timer was more likely within bounds of = the >> expiration of the ND cache entry (except in cases where the cache = grew >> large and some entries might be prematurely removed if not recently = used). >>=20 >> I know this negates some of the benefits of the longer time if the = client >> were to retransmit several times. And, if we simply want to point out >> this issue and recommend that ND implementations assure that they = retain >> these (DHCPv6) packets when doing a resolution, that is fine by me. >>=20 >>=20 >> I'm also not sure why stating the a client is only required to wait = for a >> 'reasonable' time for a response wasn't addressed. This could be >> something like: >>=20 >> A client SHOULD wait TTL * 2 (which is like close to the 120 which = was >> the old SOL_MAX_RT so perhaps we should just use that) with a MAY = wait >> for less if, for example, power consumption is a key concern. >>=20 >>=20 >> I had though Ralph proposed to discuss these issues at Berlin and = resolve >> them -- then we'd do the WGLC. I'm fine with trying to resolve these >> issues on the list. >>=20 >> - Bernie >>=20 >> -----Original Message----- >> From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On = Behalf Of >> Tomek Mrugalski >> Sent: Thursday, June 20, 2013 12:23 PM >> To: dhcwg@ietf.org WG >> Cc: Ralph Droms; Ted Lemon >> Subject: [dhcwg] WGLC on draft-ietf-dhc-dhcpv6-solmaxrt-update-01 - >> respond by July 4 >>=20 >> On 20.06.2013 17:11, Ralph Droms wrote: >>> On Jun 20, 2013, at 10:30 AM 6/20/13, Ted Lemon wrote: >>>> Do we need a SOL_MAX_RT presentation in Berlin? Why not just >>>> last-call it now? >>>=20 >>> OK with me. >> My understanding is that under normal circumstances chairs cannot = just >> announce WGLC on their own. They can do so if authors or editors = state >> the the draft is ready and chairs concur with that opinion. Anyway, = here >> it goes: >>=20 >> Folks, the author of draft-ietf-dhc-dhcpv6-solmaxrt-update-01 >> (http://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-solmaxrt-update-01) >> feels it's ready for work group last call. Please review this draft = and >> indicate whether or not you feel it is ready to be published. >>=20 >> This document redefines two timers (SOL_MAX_RT and INF_MAX_RT) that >> control SOLICIT and INFORMATION-REQUEST message retransmissions and >> define a mechanism for server to override client's default values. = There >> is a document in v6ops about basic requirements for IPv6 CE routers = that >> depends on this work. >>=20 >> At the time of this writing, there is no IPR reported against this = draft. >>=20 >> Bernie and I will evaluate consensus after 2013-07-04. >>=20 >> Thanks, >> 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 From john_brzozowski@cable.comcast.com Wed Jun 26 06:12: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 18A7921F9F02 for ; Wed, 26 Jun 2013 06:12:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.386 X-Spam-Level: X-Spam-Status: No, score=-103.386 tagged_above=-999 required=5 tests=[AWL=1.245, BAYES_00=-2.599, HOST_EQ_MODEMCABLE=1.368, J_CHICKENPOX_13=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 vkwYXfmwwpeu for ; Wed, 26 Jun 2013 06:12:15 -0700 (PDT) Received: from cable.comcast.com (copdcavout01.cable.comcast.com [76.96.32.253]) by ietfa.amsl.com (Postfix) with ESMTP id 27F5921F9FD9 for ; Wed, 26 Jun 2013 06:12:15 -0700 (PDT) Received: from ([24.40.56.116]) by copdcavout01.cable.comcast.com with ESMTP id C7WM3M1.79412929; Wed, 26 Jun 2013 07:11:17 -0600 Received: from PACDCEXMB01.cable.comcast.com ([169.254.1.141]) by pacdcexhub03.cable.comcast.com ([fe80::5527:6d6b:29a7:f414%13]) with mapi id 14.02.0318.001; Wed, 26 Jun 2013 09:12:12 -0400 From: "Brzozowski, John" To: Ralph Droms Thread-Topic: [dhcwg] WGLC on draft-ietf-dhc-dhcpv6-solmaxrt-update-01 - respond by July 4 Thread-Index: AQHOcg+WIWE2uikNb0WXxOL2X1sd1JlILO4A///M1QA= Date: Wed, 26 Jun 2013 13:12:10 +0000 Message-ID: In-Reply-To: <8CE45C4C-19DF-403B-A57D-9C0BD1D2502A@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.5.130515 x-originating-ip: [68.87.16.246] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dhcwg@ietf.org WG" , "Bernie Volz \(volz\)" , Lemon Ted Subject: Re: [dhcwg] WGLC on draft-ietf-dhc-dhcpv6-solmaxrt-update-01 - respond by July 4 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, 26 Jun 2013 13:12:20 -0000 Understood, thanks. =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 John Jason Brzozowski Comcast Cable m) 484-962-0060 o) 609-377-6594 w) www.comcast6.net e) john_brzozowski@cable.comcast.com =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 -----Original Message----- From: Ralph Droms Date: Wednesday, June 26, 2013 8:16 AM To: John Jason Brzozowski Cc: Bernie Volz , Tomasz Mrugalski , dhc WG , Ted Lemon Subject: Re: [dhcwg] WGLC on draft-ietf-dhc-dhcpv6-solmaxrt-update-01 - respond by July 4 >John... > >On Jun 25, 2013, at 9:50 PM 6/25/13, "Brzozowski, John" > wrote: > >> Bernie, >>=20 >>=20 >> Are you expecting the DHCPv6 SOL_MAX_RT draft to include text about the >>ND >> cache considerations? This seems out of context for a DHCWG ID. I >>think >> it is worth noting but certainly not something that delay advancing the >> draft. Alternatively are you think each retransmission should include >> multiple attempts? If yes I think we need to be careful not to recreate >> the original problem that we are trying to resolve. >>=20 >> Regarding the client wait time for responses, are we trying to address a >> security concern or simply trying to provide some guidance for client >> implementers? > >That text is intended to clarify that a client can stop listening for a >response and, for example, go to sleep before sending the next >retransmission of a specific message. The immediate purpose is to allow >resource conservation in constrained devices while remaining compliant >with the DHCPv6 specification. > >- Ralph > >> In general I am not opposed to the text, however, I wonder >> if it is completely necessary. >>=20 >> John >>=20 >> -----Original Message----- >> From: Bernie Volz >> Date: Thursday, June 20, 2013 1:13 PM >> To: Tomasz Mrugalski , dhc WG >> >> Cc: Ralph Droms , Ted Lemon >> >> Subject: Re: [dhcwg] WGLC on draft-ietf-dhc-dhcpv6-solmaxrt-update-01 - >> respond by July 4 >>=20 >>> >>>=20 >>> I don't yet support this document moving forward - I think the issues >>> raised earlier need to be 'resolved'. >>>=20 >>> The ND cache timeout is a concern if there are relays (routers) or >>> servers (kernel stacks) that do not save the packet needing ND >>>resolution. >>>=20 >>> The DHCPv6 client will send 1 packet every hour to the relay or server. >>> This is MULTICAST and there is no ND exchange since the mac address is >>> known. When the relay or server then UNICASTs the response, it will >>>need >>> to do ND (of the link-local address) to determine the mac address. And, >>> if the DHCP reply is not saved while this ND resolution takes place, >>> nothing will end up being transmitted to the client when the ND >>> resolution completes. >>>=20 >>> An hour later, the same thing could happen. Hence, the client never >>>gets >>> the ADVERTISE. >>>=20 >>> The old maximum retransmission timer was more likely within bounds of >>>the >>> expiration of the ND cache entry (except in cases where the cache grew >>> large and some entries might be prematurely removed if not recently >>>used). >>>=20 >>> I know this negates some of the benefits of the longer time if the >>>client >>> were to retransmit several times. And, if we simply want to point out >>> this issue and recommend that ND implementations assure that they >>>retain >>> these (DHCPv6) packets when doing a resolution, that is fine by me. >>>=20 >>>=20 >>> I'm also not sure why stating the a client is only required to wait >>>for a >>> 'reasonable' time for a response wasn't addressed. This could be >>> something like: >>>=20 >>> A client SHOULD wait TTL * 2 (which is like close to the 120 which was >>> the old SOL_MAX_RT so perhaps we should just use that) with a MAY wait >>> for less if, for example, power consumption is a key concern. >>>=20 >>>=20 >>> I had though Ralph proposed to discuss these issues at Berlin and >>>resolve >>> them -- then we'd do the WGLC. I'm fine with trying to resolve these >>> issues on the list. >>>=20 >>> - Bernie >>>=20 >>> -----Original Message----- >>> From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf >>>Of >>> Tomek Mrugalski >>> Sent: Thursday, June 20, 2013 12:23 PM >>> To: dhcwg@ietf.org WG >>> Cc: Ralph Droms; Ted Lemon >>> Subject: [dhcwg] WGLC on draft-ietf-dhc-dhcpv6-solmaxrt-update-01 - >>> respond by July 4 >>>=20 >>> On 20.06.2013 17:11, Ralph Droms wrote: >>>> On Jun 20, 2013, at 10:30 AM 6/20/13, Ted Lemon wrote: >>>>> Do we need a SOL_MAX_RT presentation in Berlin? Why not just >>>>> last-call it now? >>>>=20 >>>> OK with me. >>> My understanding is that under normal circumstances chairs cannot just >>> announce WGLC on their own. They can do so if authors or editors state >>> the the draft is ready and chairs concur with that opinion. Anyway, >>>here >>> it goes: >>>=20 >>> Folks, the author of draft-ietf-dhc-dhcpv6-solmaxrt-update-01 >>> (http://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-solmaxrt-update-01) >>> feels it's ready for work group last call. Please review this draft and >>> indicate whether or not you feel it is ready to be published. >>>=20 >>> This document redefines two timers (SOL_MAX_RT and INF_MAX_RT) that >>> control SOLICIT and INFORMATION-REQUEST message retransmissions and >>> define a mechanism for server to override client's default values. >>>There >>> is a document in v6ops about basic requirements for IPv6 CE routers >>>that >>> depends on this work. >>>=20 >>> At the time of this writing, there is no IPR reported against this >>>draft. >>>=20 >>> Bernie and I will evaluate consensus after 2013-07-04. >>>=20 >>> Thanks, >>> 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 > From john_brzozowski@cable.comcast.com Wed Jun 26 06:13: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 4B21821E8119 for ; Wed, 26 Jun 2013 06:13:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.698 X-Spam-Level: X-Spam-Status: No, score=-103.698 tagged_above=-999 required=5 tests=[AWL=0.934, BAYES_00=-2.599, HOST_EQ_MODEMCABLE=1.368, J_CHICKENPOX_13=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 0LckGKgc3wcC for ; Wed, 26 Jun 2013 06:13:35 -0700 (PDT) Received: from cable.comcast.com (copdcavout01.cable.comcast.com [76.96.32.253]) by ietfa.amsl.com (Postfix) with ESMTP id EF19321F9FD9 for ; Wed, 26 Jun 2013 06:13:34 -0700 (PDT) Received: from ([24.40.56.115]) by copdcavout01.cable.comcast.com with ESMTP id C7WM3M1.79413174; Wed, 26 Jun 2013 07:12:20 -0600 Received: from PACDCEXHUB04.cable.comcast.com (24.40.56.121) by PACDCEXHUB02.cable.comcast.com (24.40.56.115) with Microsoft SMTP Server (TLS) id 14.2.318.1; Wed, 26 Jun 2013 09:13:18 -0400 Received: from PACDCEXMB01.cable.comcast.com ([169.254.1.141]) by pacdcexhub04.cable.comcast.com ([fe80::1532:d330:f9a5:c8a1%18]) with mapi id 14.02.0318.001; Wed, 26 Jun 2013 09:13:18 -0400 From: "Brzozowski, John" To: Ralph Droms , "dhcwg@ietf.org WG" Thread-Topic: [dhcwg] WGLC on draft-ietf-dhc-dhcpv6-solmaxrt-update-01 - respond by July 4 Thread-Index: AQHOcm7raodzlaIgLEK83/sJeiSLSw== Date: Wed, 26 Jun 2013 13:13:16 +0000 Message-ID: In-Reply-To: <1DF6792F-30B9-4C38-808C-DD6D1D37A099@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.5.130515 x-originating-ip: [68.87.16.249] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dhcwg] WGLC on draft-ietf-dhc-dhcpv6-solmaxrt-update-01 - respond by July 4 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, 26 Jun 2013 13:13:40 -0000 I seem to recall some feedback from Barbara Stark early on, I do not recall the context. Also I assume the authors of 6204bis should have an opinion here. John =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 John Jason Brzozowski Comcast Cable m) 484-962-0060 o) 609-377-6594 w) www.comcast6.net e) john_brzozowski@cable.comcast.com =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 -----Original Message----- From: Ralph Droms Date: Wednesday, June 26, 2013 8:12 AM To: dhc WG Subject: Re: [dhcwg] WGLC on draft-ietf-dhc-dhcpv6-solmaxrt-update-01 - respond by July 4 >I haven't seen any additional discussion of Bernie's suggestion to add >text to this draft clarifying client behavior regarding listening for >responses. We need some indication of consensus before changing the >document. > >Minor editorial comments in line... > >- Ralph > >On Jun 21, 2013, at 11:24 AM 6/21/13, Bernie Volz (volz) >wrote: > >> Hi Ralph: >>=20 >> OK, great that the ND issue isn't real. I had looked for something like >>that at one point but didn't find it. As that is the case, that is no >>longer an issue. Too bad this wasn't found earlier (or if it was >>mentioned, I missed it - sorry). So I withdraw that objection. >>=20 >>=20 >> Regarding the issue about how long the receiver needs to wait for a >>packet, I think there was some discussion and support for that during >>some of the email exchange. I don't believe anyone was against adding >>something to NOT require waiting the full time (given the longer solmax) >>for a response from the DHCP server. That makes no sense to wait an hour >>or even many minutes. >>=20 >> It seems silly to have a completely separate draft mention that. We >>didn't have a need to mention this when RFC 3315 was written since the >>times were assumed to be reasonable for 'waiting'. >>=20 >> Does anyone have an OBJECTION to adding something close to: >>=20 >>> A client SHOULD wait TTL * 2 (which is like close to the 120 which was >>>the old SOL_MAX_RT so perhaps we should just use that) with a MAY wait >>>for less if, for example, power consumption is a key concern. >>=20 >> A more formal clarification (actual text) might be: >>=20 >> Add to section 3 of the draft (end of existing text): >>=20 >> Also, with this change, a new parameter is need to cap the time a >>client >> must wait for a response from the server as waiting for the new > >s/wait/listen/ > >> SOL_MAX_RT seems excessive. Hence, the following is added: > >s/seems/may, in some situations, be unnecessary and expensive. > >s/following is added/the following change to RFC 3315 is made/ >>=20 >> NEW: >> MAX_RCV_TIME 120 secs Max time to wait for a response >>=20 >> Add to section 6 of the draft (probably first): >>=20 >> Add to section 14 of RFC 3315 (at end of existing text): >>=20 >> RT specifies the retransmission interval and not necessarily the time >>a >> client listens for a response from the server. Clients SHOULD wait >>for > >s/wait/listens/ > >> responses for at least the shorter of the RT and MAX_RCV_TIME. There >> MAY be situations where a shorter MAX_RCV_TIME is appropriate - such > >s/MAY/may/ > >> as when power consumption is a key concern. >>=20 >> Optional: Document the source of MAX_RCV_TIME which came from old >>SOL_MAX_RT and also is the TCP Maximum Segment Lifetime, RFC 792. >>=20 >> - Bernie >>=20 >> -----Original Message----- >> From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf >>Of Ralph Droms >> Sent: Friday, June 21, 2013 10:29 AM >> To: Bernie Volz (volz) >> Cc: dhcwg@ietf.org WG; Lemon Ted >> Subject: Re: [dhcwg] WGLC on draft-ietf-dhc-dhcpv6-solmaxrt-update-01 - >>respond by July 4 >>=20 >>=20 >> On Jun 20, 2013, at 1:13 PM 6/20/13, Bernie Volz (volz) >> wrote: >>=20 >>> >>>=20 >>> I don't yet support this document moving forward - I think the issues >>>raised earlier need to be 'resolved'. >>>=20 >>> The ND cache timeout is a concern if there are relays (routers) or >>>servers (kernel stacks) that do not save the packet needing ND >>>resolution. >>=20 >> That behavior is not RFC-compliant; from section 7.2.2 of RFC 4861: >>=20 >> While waiting for address resolution to complete, the sender MUST, >> for each neighbor, retain a small queue of packets waiting for >> address resolution to complete. The queue MUST hold at least one >> packet, and MAY contain more. >>=20 >>>=20 >>> The DHCPv6 client will send 1 packet every hour to the relay or >>>server. This is MULTICAST and there is no ND exchange since the mac >>>address is known. When the relay or server then UNICASTs the response, >>>it will need to do ND (of the link-local address) to determine the mac >>>address. And, if the DHCP reply is not saved while this ND resolution >>>takes place, nothing will end up being transmitted to the client when >>>the ND resolution completes. >>>=20 >>> An hour later, the same thing could happen. Hence, the client never >>>gets the ADVERTISE. >>>=20 >>> The old maximum retransmission timer was more likely within bounds of >>>the expiration of the ND cache entry (except in cases where the cache >>>grew large and some entries might be prematurely removed if not >>>recently used). >>>=20 >>> I know this negates some of the benefits of the longer time if the >>>client were to retransmit several times. And, if we simply want to >>>point out this issue and recommend that ND implementations assure that >>>they retain these (DHCPv6) packets when doing a resolution, that is >>>fine by me. >>>=20 >>>=20 >>> I'm also not sure why stating the a client is only required to wait >>>for a 'reasonable' time for a response wasn't addressed. This could be >>>something like: >>>=20 >>> A client SHOULD wait TTL * 2 (which is like close to the 120 which was >>>the old SOL_MAX_RT so perhaps we should just use that) with a MAY wait >>>for less if, for example, power consumption is a key concern. >>=20 >> I wasn't given any indication of consensus supporting that change, so I >>didn't include it. >>>=20 >>>=20 >>> I had though Ralph proposed to discuss these issues at Berlin and >>>resolve them -- then we'd do the WGLC. I'm fine with trying to resolve >>>these issues on the list. >>=20 >> IMHO, we should first determine consensus for publishing >>draft-ietf-dhc-dhcpv6-solmaxrt-update-01 as is and addressing these >>additional issues in a separate document or holding >>draft-ietf-dhc-dhcpv6-solmaxrt-update-01 until these additional issues >>are discussed. While the question has not been posed explicitly on the >>list, there seems to be support for going ahead with >>draft-ietf-dhc-dhcpv6-solmaxrt-update-01 in its current form. >>=20 >>>=20 >>> - Bernie >>=20 >> - Ralph >>=20 >>>=20 >>> -----Original Message----- >>> From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf >>>Of Tomek Mrugalski >>> Sent: Thursday, June 20, 2013 12:23 PM >>> To: dhcwg@ietf.org WG >>> Cc: Ralph Droms; Ted Lemon >>> Subject: [dhcwg] WGLC on draft-ietf-dhc-dhcpv6-solmaxrt-update-01 - >>>respond by July 4 >>>=20 >>> On 20.06.2013 17:11, Ralph Droms wrote: >>>> On Jun 20, 2013, at 10:30 AM 6/20/13, Ted Lemon wrote: >>>>> Do we need a SOL_MAX_RT presentation in Berlin? Why not just >>>>> last-call it now? >>>>=20 >>>> OK with me. >>> My understanding is that under normal circumstances chairs cannot just >>>announce WGLC on their own. They can do so if authors or editors state >>>the the draft is ready and chairs concur with that opinion. Anyway, >>>here it goes: >>>=20 >>> Folks, the author of draft-ietf-dhc-dhcpv6-solmaxrt-update-01 >>> (http://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-solmaxrt-update-01) >>> feels it's ready for work group last call. Please review this draft >>>and indicate whether or not you feel it is ready to be published. >>>=20 >>> This document redefines two timers (SOL_MAX_RT and INF_MAX_RT) that >>>control SOLICIT and INFORMATION-REQUEST message retransmissions and >>>define a mechanism for server to override client's default values. >>>There is a document in v6ops about basic requirements for IPv6 CE >>>routers that depends on this work. >>>=20 >>> At the time of this writing, there is no IPR reported against this >>>draft. >>>=20 >>> Bernie and I will evaluate consensus after 2013-07-04. >>>=20 >>> Thanks, >>> Bernie & Tomek >>> _______________________________________________ >>> 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 > >_______________________________________________ >dhcwg mailing list >dhcwg@ietf.org >https://www.ietf.org/mailman/listinfo/dhcwg From volz@cisco.com Wed Jun 26 06:32: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 2A06811E81BD for ; Wed, 26 Jun 2013 06:32:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.999 X-Spam-Level: X-Spam-Status: No, score=-9.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=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 FvDav6Q0fD4T for ; Wed, 26 Jun 2013 06:32:12 -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 8C40321E809E for ; Wed, 26 Jun 2013 06:32:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10010; q=dns/txt; s=iport; t=1372253529; x=1373463129; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=+EBLtC9W63gSwNZveHFAkoL14BzNMGOBLQTyTZhvRuw=; b=DPVSVLT6S2s2MouG74WBUSZZAL6tBPVH4Zsh+BENnOjYvZuTAtfikM8g UqODAZaapsji4CuV2t/omKr1hOHGY5D2bCF2murIqfzXh/mZMPQvtmHy2 4RXrHJUB/cpmtvh24w2U5CAiclDydXx5mrDk5Xnnm8zAhW1aOokm14qg0 Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUFAC/sylGtJXHB/2dsb2JhbABXA4MJMUm+e4EDFnSCIwEBAQMBAQEBNw8lFwQCAQgRAwEBAQEKFAkHIQYLFAkIAgQBEgiHdAMJBgyxdA2IUoxjgSYRgQAGGxcCBAuCcWEDlV6DEIp3hSWBWIE5gXE3 X-IronPort-AV: E=Sophos;i="4.87,944,1363132800"; d="scan'208";a="227648362" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-5.cisco.com with ESMTP; 26 Jun 2013 13:32:08 +0000 Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id r5QDW8pa020426 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 26 Jun 2013 13:32:08 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.56]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.02.0318.004; Wed, 26 Jun 2013 08:32:08 -0500 From: "Bernie Volz (volz)" To: "Brzozowski, John" , Ralph Droms , "dhcwg@ietf.org WG" Thread-Topic: [dhcwg] WGLC on draft-ietf-dhc-dhcpv6-solmaxrt-update-01 - respond by July 4 Thread-Index: AQHOcm7rCSRxcYxqs06YWUX5kdNFjplH/OeQ Date: Wed, 26 Jun 2013 13:32:07 +0000 Message-ID: <489D13FBFA9B3E41812EA89F188F018E185C4A81@xmb-rcd-x04.cisco.com> References: <1DF6792F-30B9-4C38-808C-DD6D1D37A099@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.245.30] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dhcwg] WGLC on draft-ietf-dhc-dhcpv6-solmaxrt-update-01 - respond by July 4 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, 26 Jun 2013 13:32:17 -0000 Ralph: Also: >> Also, with this change, a new parameter is need to cap the time a clien= t s/need/needed or s/need/added - Bernie -----Original Message----- From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of B= rzozowski, John Sent: Wednesday, June 26, 2013 9:13 AM To: Ralph Droms; dhcwg@ietf.org WG Subject: Re: [dhcwg] WGLC on draft-ietf-dhc-dhcpv6-solmaxrt-update-01 - res= pond by July 4 I seem to recall some feedback from Barbara Stark early on, I do not recall= the context. Also I assume the authors of 6204bis should have an opinion = here. John =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 John Jason Brzozowski Comcast Cable m) 484-962-0060 o) 609-377-6594 w) www.comcast6.net e) john_brzozowski@cable.comcast.com =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 -----Original Message----- From: Ralph Droms Date: Wednesday, June 26, 2013 8:12 AM To: dhc WG Subject: Re: [dhcwg] WGLC on draft-ietf-dhc-dhcpv6-solmaxrt-update-01 - respond by July 4 >I haven't seen any additional discussion of Bernie's suggestion to add=20 >text to this draft clarifying client behavior regarding listening for=20 >responses. We need some indication of consensus before changing the=20 >document. > >Minor editorial comments in line... > >- Ralph > >On Jun 21, 2013, at 11:24 AM 6/21/13, Bernie Volz (volz)=20 > >wrote: > >> Hi Ralph: >>=20 >> OK, great that the ND issue isn't real. I had looked for something=20 >>like that at one point but didn't find it. As that is the case, that=20 >>is no longer an issue. Too bad this wasn't found earlier (or if it was=20 >>mentioned, I missed it - sorry). So I withdraw that objection. >>=20 >>=20 >> Regarding the issue about how long the receiver needs to wait for a=20 >>packet, I think there was some discussion and support for that during=20 >>some of the email exchange. I don't believe anyone was against adding=20 >>something to NOT require waiting the full time (given the longer=20 >>solmax) for a response from the DHCP server. That makes no sense to=20 >>wait an hour or even many minutes. >>=20 >> It seems silly to have a completely separate draft mention that. We=20 >>didn't have a need to mention this when RFC 3315 was written since the=20 >>times were assumed to be reasonable for 'waiting'. >>=20 >> Does anyone have an OBJECTION to adding something close to: >>=20 >>> A client SHOULD wait TTL * 2 (which is like close to the 120 which=20 >>>was the old SOL_MAX_RT so perhaps we should just use that) with a MAY=20 >>>wait for less if, for example, power consumption is a key concern. >>=20 >> A more formal clarification (actual text) might be: >>=20 >> Add to section 3 of the draft (end of existing text): >>=20 >> Also, with this change, a new parameter is need to cap the time a=20 >>client >> must wait for a response from the server as waiting for the new > >s/wait/listen/ > >> SOL_MAX_RT seems excessive. Hence, the following is added: > >s/seems/may, in some situations, be unnecessary and expensive. > >s/following is added/the following change to RFC 3315 is made/ >>=20 >> NEW: >> MAX_RCV_TIME 120 secs Max time to wait for a response >>=20 >> Add to section 6 of the draft (probably first): >>=20 >> Add to section 14 of RFC 3315 (at end of existing text): >>=20 >> RT specifies the retransmission interval and not necessarily the=20 >>time a >> client listens for a response from the server. Clients SHOULD wait=20 >>for > >s/wait/listens/ > >> responses for at least the shorter of the RT and MAX_RCV_TIME. There >> MAY be situations where a shorter MAX_RCV_TIME is appropriate -=20 >> such > >s/MAY/may/ > >> as when power consumption is a key concern. >>=20 >> Optional: Document the source of MAX_RCV_TIME which came from old=20 >>SOL_MAX_RT and also is the TCP Maximum Segment Lifetime, RFC 792. >>=20 >> - Bernie >>=20 >> -----Original Message----- >> From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On=20 >>Behalf Of Ralph Droms >> Sent: Friday, June 21, 2013 10:29 AM >> To: Bernie Volz (volz) >> Cc: dhcwg@ietf.org WG; Lemon Ted >> Subject: Re: [dhcwg] WGLC on draft-ietf-dhc-dhcpv6-solmaxrt-update-01=20 >>- respond by July 4 >>=20 >>=20 >> On Jun 20, 2013, at 1:13 PM 6/20/13, Bernie Volz (volz)=20 >> wrote: >>=20 >>> >>>=20 >>> I don't yet support this document moving forward - I think the=20 >>>issues raised earlier need to be 'resolved'. >>>=20 >>> The ND cache timeout is a concern if there are relays (routers) or=20 >>>servers (kernel stacks) that do not save the packet needing ND=20 >>>resolution. >>=20 >> That behavior is not RFC-compliant; from section 7.2.2 of RFC 4861: >>=20 >> While waiting for address resolution to complete, the sender MUST, >> for each neighbor, retain a small queue of packets waiting for >> address resolution to complete. The queue MUST hold at least one >> packet, and MAY contain more. >>=20 >>>=20 >>> The DHCPv6 client will send 1 packet every hour to the relay or=20 >>>server. This is MULTICAST and there is no ND exchange since the mac=20 >>>address is known. When the relay or server then UNICASTs the=20 >>>response, it will need to do ND (of the link-local address) to=20 >>>determine the mac address. And, if the DHCP reply is not saved while=20 >>>this ND resolution takes place, nothing will end up being transmitted=20 >>>to the client when the ND resolution completes. >>>=20 >>> An hour later, the same thing could happen. Hence, the client never=20 >>>gets the ADVERTISE. >>>=20 >>> The old maximum retransmission timer was more likely within bounds=20 >>>of the expiration of the ND cache entry (except in cases where the=20 >>>cache grew large and some entries might be prematurely removed if not=20 >>>recently used). >>>=20 >>> I know this negates some of the benefits of the longer time if the=20 >>>client were to retransmit several times. And, if we simply want to=20 >>>point out this issue and recommend that ND implementations assure=20 >>>that they retain these (DHCPv6) packets when doing a resolution, that=20 >>>is fine by me. >>>=20 >>>=20 >>> I'm also not sure why stating the a client is only required to wait=20 >>>for a 'reasonable' time for a response wasn't addressed. This could=20 >>>be something like: >>>=20 >>> A client SHOULD wait TTL * 2 (which is like close to the 120 which=20 >>>was the old SOL_MAX_RT so perhaps we should just use that) with a MAY=20 >>>wait for less if, for example, power consumption is a key concern. >>=20 >> I wasn't given any indication of consensus supporting that change, so=20 >>I didn't include it. >>>=20 >>>=20 >>> I had though Ralph proposed to discuss these issues at Berlin and=20 >>>resolve them -- then we'd do the WGLC. I'm fine with trying to=20 >>>resolve these issues on the list. >>=20 >> IMHO, we should first determine consensus for publishing >>draft-ietf-dhc-dhcpv6-solmaxrt-update-01 as is and addressing these=20 >>additional issues in a separate document or holding >>draft-ietf-dhc-dhcpv6-solmaxrt-update-01 until these additional issues=20 >>are discussed. While the question has not been posed explicitly on=20 >>the list, there seems to be support for going ahead with >>draft-ietf-dhc-dhcpv6-solmaxrt-update-01 in its current form. >>=20 >>>=20 >>> - Bernie >>=20 >> - Ralph >>=20 >>>=20 >>> -----Original Message----- >>> From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On=20 >>>Behalf Of Tomek Mrugalski >>> Sent: Thursday, June 20, 2013 12:23 PM >>> To: dhcwg@ietf.org WG >>> Cc: Ralph Droms; Ted Lemon >>> Subject: [dhcwg] WGLC on draft-ietf-dhc-dhcpv6-solmaxrt-update-01 -=20 >>>respond by July 4 >>>=20 >>> On 20.06.2013 17:11, Ralph Droms wrote: >>>> On Jun 20, 2013, at 10:30 AM 6/20/13, Ted Lemon wrote: >>>>> Do we need a SOL_MAX_RT presentation in Berlin? Why not just >>>>> last-call it now? >>>>=20 >>>> OK with me. >>> My understanding is that under normal circumstances chairs cannot=20 >>>just announce WGLC on their own. They can do so if authors or editors=20 >>>state the the draft is ready and chairs concur with that opinion.=20 >>>Anyway, here it goes: >>>=20 >>> Folks, the author of draft-ietf-dhc-dhcpv6-solmaxrt-update-01 >>>=20 >>>(http://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-solmaxrt-update-01) >>> feels it's ready for work group last call. Please review this draft=20 >>>and indicate whether or not you feel it is ready to be published. >>>=20 >>> This document redefines two timers (SOL_MAX_RT and INF_MAX_RT) that=20 >>>control SOLICIT and INFORMATION-REQUEST message retransmissions and=20 >>>define a mechanism for server to override client's default values. >>>There is a document in v6ops about basic requirements for IPv6 CE=20 >>>routers that depends on this work. >>>=20 >>> At the time of this writing, there is no IPR reported against this=20 >>>draft. >>>=20 >>> Bernie and I will evaluate consensus after 2013-07-04. >>>=20 >>> Thanks, >>> Bernie & Tomek >>> _______________________________________________ >>> 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 > >_______________________________________________ >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 Ted.Lemon@nominum.com Wed Jun 26 06:44: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 2233F21F91BC for ; Wed, 26 Jun 2013 06:44:58 -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 2k1TcLcPCuuZ for ; Wed, 26 Jun 2013 06:44:51 -0700 (PDT) Received: from exprod7og120.obsmtp.com (exprod7og120.obsmtp.com [64.18.2.18]) by ietfa.amsl.com (Postfix) with ESMTP id 2707921E8167 for ; Wed, 26 Jun 2013 06:44:46 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob120.postini.com ([64.18.6.12]) with SMTP ID DSNKUcrwTRHxkiG3liYf017nrBveQaSZIsfC@postini.com; Wed, 26 Jun 2013 06:44:46 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 8D5C51B806F for ; Wed, 26 Jun 2013 06:44:45 -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 E4A6919005D; Wed, 26 Jun 2013 06:44:44 -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, 26 Jun 2013 06:44:44 -0700 From: Ted Lemon To: Ralph Droms Thread-Topic: [dhcwg] WGLC on draft-ietf-dhc-dhcpv6-solmaxrt-update-01 - respond by July 4 Thread-Index: AQHObpNgEhcCw+4sXUCzmqDFMiS9SplIZRiAgAAZuoA= Date: Wed, 26 Jun 2013 13:44:43 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B6307751EC6FF@mbx-01.win.nominum.com> References: <3135C2851EB6764BACEF35D8B495596806E7DAB304@MOPESMBX01.eu.thmulti.com> <51C31065.8040804@gmail.com> <8D23D4052ABE7A4490E77B1A012B6307751E2D82@mbx-01.win.nominum.com> <51C32C73.1010203@gmail.com> <489D13FBFA9B3E41812EA89F188F018E185A9B6F@xmb-rcd-x04.cisco.com> <90C4B43B-4EF6-40DD-A5F1-DBF82402F191@gmail.com> <489D13FBFA9B3E41812EA89F188F018E185AC7F1@xmb-rcd-x04.cisco.com> <1DF6792F-30B9-4C38-808C-DD6D1D37A099@gmail.com> In-Reply-To: <1DF6792F-30B9-4C38-808C-DD6D1D37A099@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: <70DB556F863BFD4D8C58A8CCBB73C84D@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dhcwg@ietf.org WG" Subject: Re: [dhcwg] WGLC on draft-ietf-dhc-dhcpv6-solmaxrt-update-01 - respond by July 4 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, 26 Jun 2013 13:44:58 -0000 I think it's relatively harmless to leave power saving behavior as unspecif= ied. I don't think we have data to support an assertion as to how long th= e client should leave the radio on, and in the absence of data, we'd be mor= e likely to do harm than good. From internet-drafts@ietf.org Wed Jun 26 07:37: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 6380C21E80AB; Wed, 26 Jun 2013 07:37:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.477 X-Spam-Level: X-Spam-Status: No, score=-102.477 tagged_above=-999 required=5 tests=[AWL=0.123, 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 ndsSgF9LQ2In; Wed, 26 Jun 2013 07:37:06 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E16BB11E811B; Wed, 26 Jun 2013 07:37:06 -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.51.p2 Message-ID: <20130626143706.6810.13783.idtracker@ietfa.amsl.com> Date: Wed, 26 Jun 2013 07:37:06 -0700 Cc: dhcwg@ietf.org Subject: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-unknown-msg-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: Wed, 26 Jun 2013 14:37:07 -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 : Handling Unknown DHCPv6 Messages Author(s) : Yong Cui Qi Sun Ted Lemon Filename : draft-ietf-dhc-dhcpv6-unknown-msg-01.txt Pages : 7 Date : 2013-06-26 Abstract: Dynamic Host Configuration Protocol version 6 (DHCPv6) isn't specific about handling messages with unknown types. This memo describes the problems and defines how a DHCPv6 function node should behave in this case. This document updates RFC3315. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv6-unknown-msg There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-unknown-msg-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dhc-dhcpv6-unknown-msg-01 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From bs7652@att.com Wed Jun 26 07:43: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 134A811E81B8 for ; Wed, 26 Jun 2013 07:43:59 -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 eyYkdDKSjIGp for ; Wed, 26 Jun 2013 07:43:52 -0700 (PDT) Received: from nbfkord-smmo07.seg.att.com (nbfkord-smmo07.seg.att.com [209.65.160.93]) by ietfa.amsl.com (Postfix) with ESMTP id DE1FD11E81C0 for ; Wed, 26 Jun 2013 07:43:47 -0700 (PDT) Received: from unknown [144.160.20.145] (EHLO nbfkord-smmo07.seg.att.com) by nbfkord-smmo07.seg.att.com(mxl_mta-6.15.0-1) with ESMTP id 32efac15.61584940.142511.00-556.401948.nbfkord-smmo07.seg.att.com (envelope-from ); Wed, 26 Jun 2013 14:43:47 +0000 (UTC) X-MXL-Hash: 51cafe233fe17b0f-99eda1c79f55eb8ec145c2892fe743a1c13a5b60 Received: from unknown [144.160.20.145] (EHLO mlpd192.enaf.sfdc.sbc.com) by nbfkord-smmo07.seg.att.com(mxl_mta-6.15.0-1) over TLS secured channel with ESMTP id 71efac15.0.142502.00-474.401499.nbfkord-smmo07.seg.att.com (envelope-from ); Wed, 26 Jun 2013 14:43:35 +0000 (UTC) X-MXL-Hash: 51cafe175491dfcd-13489dce8435d643d145e3e69e094a7da1cd5943 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r5QEhYIF009653; Wed, 26 Jun 2013 10:43:35 -0400 Received: from alpi131.aldc.att.com (alpi131.aldc.att.com [130.8.218.69]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r5QEhQ23009527 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 26 Jun 2013 10:43:26 -0400 Received: from GAALPA1MSGHUB9D.ITServices.sbc.com (gaalpa1msghub9d.itservices.sbc.com [130.8.36.90]) by alpi131.aldc.att.com (RSA Interceptor); Wed, 26 Jun 2013 14:42:58 GMT Received: from GAALPA1MSGUSR9L.ITServices.sbc.com ([130.8.36.69]) by GAALPA1MSGHUB9D.ITServices.sbc.com ([130.8.36.90]) with mapi id 14.02.0342.003; Wed, 26 Jun 2013 10:43:06 -0400 From: "STARK, BARBARA H" To: Ted Lemon , Ralph Droms Thread-Topic: [dhcwg] WGLC on draft-ietf-dhc-dhcpv6-solmaxrt-update-01 - respond by July 4 Thread-Index: AQHOcnNmkL7BWKsy1kaqYb6Kw3Deh5lID/6Q Date: Wed, 26 Jun 2013 14:43:05 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E611302F1356@GAALPA1MSGUSR9L.ITServices.sbc.com> References: <3135C2851EB6764BACEF35D8B495596806E7DAB304@MOPESMBX01.eu.thmulti.com> <51C31065.8040804@gmail.com> <8D23D4052ABE7A4490E77B1A012B6307751E2D82@mbx-01.win.nominum.com> <51C32C73.1010203@gmail.com> <489D13FBFA9B3E41812EA89F188F018E185A9B6F@xmb-rcd-x04.cisco.com> <90C4B43B-4EF6-40DD-A5F1-DBF82402F191@gmail.com> <489D13FBFA9B3E41812EA89F188F018E185AC7F1@xmb-rcd-x04.cisco.com> <1DF6792F-30B9-4C38-808C-DD6D1D37A099@gmail.com> <8D23D4052ABE7A4490E77B1A012B6307751EC6FF@mbx-01.win.nominum.com> In-Reply-To: <8D23D4052ABE7A4490E77B1A012B6307751EC6FF@mbx-01.win.nominum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.131.2] 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.20.145] X-AnalysisOut: [v=2.0 cv=Ecp/toaC c=1 sm=0 a=ZRNLZ4dFUbCvG8UMqPvVAA==:17 a] X-AnalysisOut: [=w6-zJku-bBgA:10 a=ms22tfHDJvsA:10 a=ofMgfj31e3cA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=kj9zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=XIqpo32R] X-AnalysisOut: [AAAA:8 a=Q47MkUNJBF8A:10 a=mtOhyXPb5V0J8iG7GccA:9 a=CjuIK1] X-AnalysisOut: [q_8ugA:10] Cc: "dhcwg@ietf.org WG" Subject: Re: [dhcwg] WGLC on draft-ietf-dhc-dhcpv6-solmaxrt-update-01 - respond by July 4 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, 26 Jun 2013 14:43:59 -0000 > From: Ted Lemon > >=20 > I think it's relatively harmless to leave power saving behavior as unspec= ified. > I don't think we have data to support an assertion as to how long the cli= ent > should leave the radio on, and in the absence of data, we'd be more likel= y to > do harm than good. +1 I would prefer to leave power saving behavior unspecified. As long as it is= n't precluded, it's my experience that the various radio interface speciali= sts tend to figure out what works best for their environments. Also, given = that doze intervals for Wi-Fi interfaces (and some other radio interfaces) = are often in the range of ~200ms, I see no reason why such an interface cou= ldn't doze while waiting. Barbara From rdroms.ietf@gmail.com Wed Jun 26 07:57: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 5062221F9AE5 for ; Wed, 26 Jun 2013 07:57:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.3 X-Spam-Level: X-Spam-Status: No, score=-102.3 tagged_above=-999 required=5 tests=[AWL=0.300, 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 0bn4hDoAy52h for ; Wed, 26 Jun 2013 07:57:31 -0700 (PDT) Received: from mail-qa0-x22d.google.com (mail-qa0-x22d.google.com [IPv6:2607:f8b0:400d:c00::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 83F2621E80BB for ; Wed, 26 Jun 2013 07:57:28 -0700 (PDT) Received: by mail-qa0-f45.google.com with SMTP id ci6so1658599qab.11 for ; Wed, 26 Jun 2013 07:57:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to:x-mailer; bh=cxEPv0t9s2ucvkrnpdArTF6LML4KAz2SrxKLqXMaAec=; b=w21tURl6Tmrv9xX10hw8NUYgYddquXPOEx5OplnuxPZ6DiGhvd4ZUv2gtisD8I0+vv aOQYMi5A9HeXAge2CznlWAszL6RBAMW+NRYbs7nOgI8H65D/yEPTKgj1LR9mIckhqf/N xdglKpLD3dgLKrSlzHi1TkGlAZ2ELvH2laAz3n7gCsfzkvi5UjoTUF92rVObrLFTAmfP makLUVJikY9N1LXpDfEnXms/2JHHHyq939zQF7vpnGBhTSxZSjvXtnpUFOnPny7IcdMv 38vflGmWucUrNGUEtb6nwDATF0doGcx0W5KwBkMEB+GFe1Mb9OKUH3iyXq2uDBd/FEMd SDeQ== X-Received: by 10.224.80.4 with SMTP id r4mr6096347qak.63.1372258646510; Wed, 26 Jun 2013 07:57:26 -0700 (PDT) Received: from [192.168.1.134] (c-24-62-231-127.hsd1.ma.comcast.net. [24.62.231.127]) by mx.google.com with ESMTPSA id gn4sm33751553qab.8.2013.06.26.07.57.24 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 26 Jun 2013 07:57:24 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Ralph Droms In-Reply-To: <8D23D4052ABE7A4490E77B1A012B6307751EC6FF@mbx-01.win.nominum.com> Date: Wed, 26 Jun 2013 10:57:24 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <3135C2851EB6764BACEF35D8B495596806E7DAB304@MOPESMBX01.eu.thmulti.com> <51C31065.8040804@gmail.com> <8D23D4052ABE7A4490E77B1A012B6307751E2D82@mbx-01.win.nominum.com> <51C32C73.1010203@gmail.com> <489D13FBFA9B3E41812EA89F188F018E185A9B6F@xmb-rcd-x04.cisco.com> <90C4B43B-4EF6-40DD-A5F1-DBF82402F191@gmail.com> <489D13FBFA9B3E41812EA89F188F018E185AC7F1@xmb-rcd-x04.cisco.com> <1DF6792F-30B9-4C38-808C-DD6D1D37A099@gmail.com> <8D23D4052ABE7A4490E77B1A012B6307751EC6FF@mbx-01.win.nominum.com> To: "dhcwg@ietf.org WG" X-Mailer: Apple Mail (2.1508) Subject: Re: [dhcwg] WGLC on draft-ietf-dhc-dhcpv6-solmaxrt-update-01 - respond by July 4 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, 26 Jun 2013 14:57:32 -0000 On Jun 26, 2013, at 9:44 AM 6/26/13, Ted Lemon = wrote: > >=20 > I think it's relatively harmless to leave power saving behavior as = unspecified. I don't think we have data to support an assertion as to = how long the client should leave the radio on, and in the absence of = data, we'd be more likely to do harm than good. Is there any chance some diligent specification compliance organization = will interpret the current unspecified behavior as "the client MUST = continue to listen actively"? I don't think so; just making sure the question is asked explicitly. - Ralph >=20 From Ted.Lemon@nominum.com Wed Jun 26 08:02: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 877FD11E811B for ; Wed, 26 Jun 2013 08:02:02 -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 SLSJ6nyvlixa for ; Wed, 26 Jun 2013 08:01:55 -0700 (PDT) Received: from exprod7og114.obsmtp.com (exprod7og114.obsmtp.com [64.18.2.215]) by ietfa.amsl.com (Postfix) with ESMTP id B94AB11E811A for ; Wed, 26 Jun 2013 08:01:54 -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 DSNKUcsCYisYD1D5kFv/NxiXTw9C8vRmVRGK@postini.com; Wed, 26 Jun 2013 08:01:54 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 020E41B81FA for ; Wed, 26 Jun 2013 08:01:54 -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 AB09319005D; Wed, 26 Jun 2013 08:01:52 -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, 26 Jun 2013 08:01:52 -0700 From: Ted Lemon To: Ralph Droms Thread-Topic: [dhcwg] WGLC on draft-ietf-dhc-dhcpv6-solmaxrt-update-01 - respond by July 4 Thread-Index: AQHObpNgEhcCw+4sXUCzmqDFMiS9SplIZRiAgAAZuoCAABROAIAAAUAA Date: Wed, 26 Jun 2013 15:01:52 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B6307751EC9AB@mbx-01.win.nominum.com> References: <3135C2851EB6764BACEF35D8B495596806E7DAB304@MOPESMBX01.eu.thmulti.com> <51C31065.8040804@gmail.com> <8D23D4052ABE7A4490E77B1A012B6307751E2D82@mbx-01.win.nominum.com> <51C32C73.1010203@gmail.com> <489D13FBFA9B3E41812EA89F188F018E185A9B6F@xmb-rcd-x04.cisco.com> <90C4B43B-4EF6-40DD-A5F1-DBF82402F191@gmail.com> <489D13FBFA9B3E41812EA89F188F018E185AC7F1@xmb-rcd-x04.cisco.com> <1DF6792F-30B9-4C38-808C-DD6D1D37A099@gmail.com> <8D23D4052ABE7A4490E77B1A012B6307751EC6FF@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 WG" Subject: Re: [dhcwg] WGLC on draft-ietf-dhc-dhcpv6-solmaxrt-update-01 - respond by July 4 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, 26 Jun 2013 15:02:02 -0000 On Jun 26, 2013, at 10:57 AM, Ralph Droms wrote: > Is there any chance some diligent specification compliance organization w= ill interpret the current unspecified behavior as "the client MUST continue= to listen actively"? I don't think it's wrong to say that some clients may choose to turn off th= eir radios after some interval. Saying that would address this concern. = I just think we should leave the interval as an implementation-dependent va= lue. There is a concern here that an implementation will never actually t= est this scenario, in which case it may use a too-short interval. But I j= ust don't think we have enough information to be able to make a determinati= on as to what the interval should be, so we have to accept that this failur= e mode is a possibility. From rdroms.ietf@gmail.com Wed Jun 26 08:36: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 0017611E80EF for ; Wed, 26 Jun 2013 08:36:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[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 onezBv8pFtCS for ; Wed, 26 Jun 2013 08:36:48 -0700 (PDT) Received: from mail-qe0-x230.google.com (mail-qe0-x230.google.com [IPv6:2607:f8b0:400d:c02::230]) by ietfa.amsl.com (Postfix) with ESMTP id 2045511E81C7 for ; Wed, 26 Jun 2013 08:36:48 -0700 (PDT) Received: by mail-qe0-f48.google.com with SMTP id 2so983202qea.21 for ; Wed, 26 Jun 2013 08:36:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to:x-mailer; bh=IpoK8+vupXDyTWYzZ5IgxeIkGWU8JCg1IaCQNk/Smv8=; b=AeUYKAOmEiDtpZ1dar6O4A74axxrMX6hd97RPU134LxFkjqEetgpU132n2sQzX7Y/V 6WKHqVIBVCojySNXZJn1SEjWQVCutNi4PtxPq4UHFNbJg/ROLT/TF3iSf6KvVw0SRwEB yDsNrTdwef9i+W/gy1+vKIin309rb0EU6mXyY1UEzc7OzLtKmdbu+euw6D6e3lJlB2ZL 18Rqu1teNevBm08rov2uLLNz1yI4nXMIinr17HwMz4bMOoytn1xGZrd/9is4gKWvg36b AClvJmmgKW25bDZRqNwWYaTaLpDWx3wKP6a4q/ctv5YwP8as6vFFzkR/HzEmw4JAuSVI outQ== X-Received: by 10.224.22.143 with SMTP id n15mr6205208qab.93.1372261005777; Wed, 26 Jun 2013 08:36:45 -0700 (PDT) Received: from ?IPv6:2001:420:2481:20:c522:57d8:10e8:c60a? ([2001:420:2481:20:c522:57d8:10e8:c60a]) by mx.google.com with ESMTPSA id r10sm33345218qeu.4.2013.06.26.08.36.43 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 26 Jun 2013 08:36:44 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Ralph Droms In-Reply-To: <8D23D4052ABE7A4490E77B1A012B6307751EC9AB@mbx-01.win.nominum.com> Date: Wed, 26 Jun 2013 11:36:43 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <78B903E6-CA57-4E02-954A-6D44B12D692A@gmail.com> References: <3135C2851EB6764BACEF35D8B495596806E7DAB304@MOPESMBX01.eu.thmulti.com> <51C31065.8040804@gmail.com> <8D23D4052ABE7A4490E77B1A012B6307751E2D82@mbx-01.win.nominum.com> <51C32C73.1010203@gmail.com> <489D13FBFA9B3E41812EA89F188F018E185A9B6F@xmb-rcd-x04.cisco.com> <90C4B43B-4EF6-40DD-A5F1-DBF82402F191@gmail.com> <489D13FBFA9B3E41812EA89F188F018E185AC7F1@xmb-rcd-x04.cisco.com> <1DF6792F-30B9-4C38-808C-DD6D1D37A099@gmail.com> <8D23D4052ABE7A4490E77B1A012B6307751EC6FF@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751EC9AB@mbx-01.win.nominum.com> To: "dhcwg@ietf.org WG" X-Mailer: Apple Mail (2.1508) Subject: Re: [dhcwg] WGLC on draft-ietf-dhc-dhcpv6-solmaxrt-update-01 - respond by July 4 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, 26 Jun 2013 15:36:49 -0000 On Jun 26, 2013, at 11:01 AM 6/26/13, Ted Lemon = wrote: > On Jun 26, 2013, at 10:57 AM, Ralph Droms = wrote: >> Is there any chance some diligent specification compliance = organization will interpret the current unspecified behavior as "the = client MUST continue to listen actively"? >=20 > I don't think it's wrong to say that some clients may choose to turn = off their radios after some interval. Saying that would address this = concern. I just think we should leave the interval as an = implementation-dependent value. There is a concern here that an = implementation will never actually test this scenario, in which case it = may use a too-short interval. But I just don't think we have enough = information to be able to make a determination as to what the interval = should be, so we have to accept that this failure mode is a possibility. >=20 Suggested text to be added at the end of section 3 of = draft-ietf-dhc-dhcpv6-solmaxrt-update: To accommodate resource constrained devices such as battery-powered sensor nodes, the following text is added as the last sentence in section 14 of RFC 3315: NEW: Some client devices may choose to stop listening for responses from the server before RT expires. For example, a battery-powered device may choose to turn off its radio after actively listening for a response for an appropriate period of time.= From sunqi.csnet.thu@gmail.com Wed Jun 26 08:39: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 27C5211E81C6 for ; Wed, 26 Jun 2013 08:39:04 -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 qD38-XQslT0H for ; Wed, 26 Jun 2013 08:39:03 -0700 (PDT) Received: from mail-pb0-x229.google.com (mail-pb0-x229.google.com [IPv6:2607:f8b0:400e:c01::229]) by ietfa.amsl.com (Postfix) with ESMTP id 7310111E81C5 for ; Wed, 26 Jun 2013 08:39:03 -0700 (PDT) Received: by mail-pb0-f41.google.com with SMTP id rp16so14384009pbb.14 for ; Wed, 26 Jun 2013 08:39:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to:x-mailer; bh=kVzvZ5MZOxl+gHgLt4FvYI96+enKYqTg9AkoYQW1/eQ=; b=X7LEvtbhAvKtr7KVMeXrSFX/2jnu30OaCwqmCQJkEFQG1EEZViJhRv+/4jZktKho24 DxXMkmchLI5O62f8We5xjoTh9TkE/u4T7lj3OSshMaFknd/hV3f2GIyPAzaH4y0wyOnW Woa412i8hY9zOrOHBBWZ0iXXXxyb2vrG30+GGmFRL4zmefj8bTzlB01YwLQNhSA7uP58 UtjWSU1aryCPo+xWdG1RlgmlhLBYOdnpSn5T8YItIeqy0caseTElEG1Ty1LVCHNRaJDc xdm7VWqI8GP7gRfKLZcW4fryKcTBgjm015EcvxmtU11DIgjt7EgZyBdNM6S+cKwNK8hx ns8w== X-Received: by 10.66.191.40 with SMTP id gv8mr1279262pac.19.1372261143236; Wed, 26 Jun 2013 08:39:03 -0700 (PDT) Received: from [192.168.0.111] ([114.255.40.13]) by mx.google.com with ESMTPSA id dg3sm28811774pbc.24.2013.06.26.08.39.00 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 26 Jun 2013 08:39:02 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Apple Message framework v1084) From: Qi Sun In-Reply-To: <20130626143706.6810.13783.idtracker@ietfa.amsl.com> Date: Wed, 26 Jun 2013 23:38:52 +0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130626143706.6810.13783.idtracker@ietfa.amsl.com> To: "dhcwg@ietf.org WG" X-Mailer: Apple Mail (2.1084) Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-unknown-msg-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: Wed, 26 Jun 2013 15:39:04 -0000 Dear all, A new version of draft-ietf-dhc-dhcpv6-unknown-msg is available now. The = major changes since -00 version are: 1) Give some detailed descriptions about how a relay agent makes the = decision on the direction of relaying; 2) Update the definition of 'a valid message' for a relay agent; 3) Specify the reasons for the definition; 4) Correct a couple of typos. Comments on the draft are welcome. Best Regards, Qi Sun On 2013-6-26, at =E4=B8=8B=E5=8D=8810:37, internet-drafts@ietf.org = wrote: >=20 > 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. >=20 > Title : Handling Unknown DHCPv6 Messages > Author(s) : Yong Cui > Qi Sun > Ted Lemon > Filename : draft-ietf-dhc-dhcpv6-unknown-msg-01.txt > Pages : 7 > Date : 2013-06-26 >=20 > Abstract: > Dynamic Host Configuration Protocol version 6 (DHCPv6) isn't = specific > about handling messages with unknown types. This memo describes the > problems and defines how a DHCPv6 function node should behave in = this > case. This document updates RFC3315. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv6-unknown-msg >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-unknown-msg-01 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dhc-dhcpv6-unknown-msg-01 >=20 >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg From john_brzozowski@cable.comcast.com Wed Jun 26 11:37:57 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 613EB11E81DA for ; Wed, 26 Jun 2013 11:37:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.184 X-Spam-Level: X-Spam-Status: No, score=-104.184 tagged_above=-999 required=5 tests=[AWL=1.047, BAYES_00=-2.599, HOST_EQ_MODEMCABLE=1.368, 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 u+Om9Ido9HHh for ; Wed, 26 Jun 2013 11:37:52 -0700 (PDT) Received: from cable.comcast.com (copdcavout01.cable.comcast.com [76.96.32.253]) by ietfa.amsl.com (Postfix) with ESMTP id 8BDFD11E8120 for ; Wed, 26 Jun 2013 11:37:52 -0700 (PDT) Received: from ([24.40.56.114]) by copdcavout01.cable.comcast.com with ESMTP id C7WM3M1.79509976; Wed, 26 Jun 2013 12:36:51 -0600 Received: from PACDCEXMB01.cable.comcast.com ([169.254.1.141]) by PACDCEXHUB01.cable.comcast.com ([fe80::84e8:95f3:f13b:169e%12]) with mapi id 14.02.0318.001; Wed, 26 Jun 2013 14:37:46 -0400 From: "Brzozowski, John" To: Ralph Droms , "dhcwg@ietf.org WG" Thread-Topic: [dhcwg] WGLC on draft-ietf-dhc-dhcpv6-solmaxrt-update-01 - respond by July 4 Thread-Index: AQHOcpxAZ+e49ull+0GeG9Xcgg5KyA== Date: Wed, 26 Jun 2013 18:37:45 +0000 Message-ID: In-Reply-To: <78B903E6-CA57-4E02-954A-6D44B12D692A@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.5.130515 x-originating-ip: [68.87.16.246] Content-Type: text/plain; charset="us-ascii" Content-ID: <809FF7BE83F5A349BA2522B48A70CF31@cable.comcast.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dhcwg] WGLC on draft-ietf-dhc-dhcpv6-solmaxrt-update-01 - respond by July 4 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, 26 Jun 2013 18:37:57 -0000 Seems like reasonable text. John =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 John Jason Brzozowski Comcast Cable m) 484-962-0060 o) 609-377-6594 w) www.comcast6.net e) john_brzozowski@cable.comcast.com =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 -----Original Message----- From: Ralph Droms Date: Wednesday, June 26, 2013 11:36 AM To: dhc WG Subject: Re: [dhcwg] WGLC on draft-ietf-dhc-dhcpv6-solmaxrt-update-01 - respond by July 4 > >On Jun 26, 2013, at 11:01 AM 6/26/13, Ted Lemon >wrote: > >> On Jun 26, 2013, at 10:57 AM, Ralph Droms wrote: >>> Is there any chance some diligent specification compliance >>>organization will interpret the current unspecified behavior as "the >>>client MUST continue to listen actively"? >>=20 >> I don't think it's wrong to say that some clients may choose to turn >>off their radios after some interval. Saying that would address this >>concern. I just think we should leave the interval as an >>implementation-dependent value. There is a concern here that an >>implementation will never actually test this scenario, in which case it >>may use a too-short interval. But I just don't think we have enough >>information to be able to make a determination as to what the interval >>should be, so we have to accept that this failure mode is a possibility. >>=20 >Suggested text to be added at the end of section 3 of >draft-ietf-dhc-dhcpv6-solmaxrt-update: > > To accommodate resource constrained devices such as battery-powered > sensor nodes, the following text is added as the last sentence in > section 14 of RFC 3315: > > NEW: > > Some client devices may choose to stop listening for responses from > the server before RT expires. For example, a battery-powered device > may choose to turn off its radio after actively listening for a > response for an appropriate period of time. >_______________________________________________ >dhcwg mailing list >dhcwg@ietf.org >https://www.ietf.org/mailman/listinfo/dhcwg From bs7652@att.com Wed Jun 26 11:51: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 9E4D911E8122 for ; Wed, 26 Jun 2013 11:51:36 -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 49JFvQU8hcle for ; Wed, 26 Jun 2013 11:51:30 -0700 (PDT) Received: from nbfkord-smmo07.seg.att.com (nbfkord-smmo07.seg.att.com [209.65.160.93]) by ietfa.amsl.com (Postfix) with ESMTP id 355FF21F8FA1 for ; Wed, 26 Jun 2013 11:51:26 -0700 (PDT) Received: from unknown [144.160.20.145] (EHLO nbfkord-smmo07.seg.att.com) by nbfkord-smmo07.seg.att.com(mxl_mta-6.15.0-1) with ESMTP id e283bc15.2aaae2429940.318644.00-527.904988.nbfkord-smmo07.seg.att.com (envelope-from ); Wed, 26 Jun 2013 18:51:26 +0000 (UTC) X-MXL-Hash: 51cb382e017382b2-ae109892a61a15bb032a622d2dcca26f5e9b79f8 Received: from unknown [144.160.20.145] (EHLO mlpd192.enaf.sfdc.sbc.com) by nbfkord-smmo07.seg.att.com(mxl_mta-6.15.0-1) over TLS secured channel with ESMTP id c283bc15.0.318631.00-276.904934.nbfkord-smmo07.seg.att.com (envelope-from ); Wed, 26 Jun 2013 18:51:25 +0000 (UTC) X-MXL-Hash: 51cb382d6801ca04-3339d837249a909d9ab61c71b07a51f2c47d001c Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r5QIpOHE008427; Wed, 26 Jun 2013 14:51:24 -0400 Received: from alpi132.aldc.att.com (alpi132.aldc.att.com [130.8.217.2]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r5QIpNNJ008409 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 26 Jun 2013 14:51:23 -0400 Received: from GAALPA1MSGHUB9A.ITServices.sbc.com (gaalpa1msghub9a.itservices.sbc.com [130.8.36.87]) by alpi132.aldc.att.com (RSA Interceptor); Wed, 26 Jun 2013 18:51:11 GMT Received: from GAALPA1MSGUSR9L.ITServices.sbc.com ([130.8.36.69]) by GAALPA1MSGHUB9A.ITServices.sbc.com ([130.8.36.87]) with mapi id 14.02.0342.003; Wed, 26 Jun 2013 14:51:19 -0400 From: "STARK, BARBARA H" To: Ralph Droms , "dhcwg@ietf.org WG" Thread-Topic: [dhcwg] WGLC on draft-ietf-dhc-dhcpv6-solmaxrt-update-01 - respond by July 4 Thread-Index: AQHOcoMFCLpbkuOYGEahgs1fK0xXeplIVrgw Date: Wed, 26 Jun 2013 18:51:18 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E611302F1604@GAALPA1MSGUSR9L.ITServices.sbc.com> References: <3135C2851EB6764BACEF35D8B495596806E7DAB304@MOPESMBX01.eu.thmulti.com> <51C31065.8040804@gmail.com> <8D23D4052ABE7A4490E77B1A012B6307751E2D82@mbx-01.win.nominum.com> <51C32C73.1010203@gmail.com> <489D13FBFA9B3E41812EA89F188F018E185A9B6F@xmb-rcd-x04.cisco.com> <90C4B43B-4EF6-40DD-A5F1-DBF82402F191@gmail.com> <489D13FBFA9B3E41812EA89F188F018E185AC7F1@xmb-rcd-x04.cisco.com> <1DF6792F-30B9-4C38-808C-DD6D1D37A099@gmail.com> <8D23D4052ABE7A4490E77B1A012B6307751EC6FF@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751EC9AB@mbx-01.win.nominum.com> <78B903E6-CA57-4E02-954A-6D44B12D692A@gmail.com> In-Reply-To: <78B903E6-CA57-4E02-954A-6D44B12D692A@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.131.2] 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.20.145] X-AnalysisOut: [v=2.0 cv=Ecp/toaC c=1 sm=0 a=ZRNLZ4dFUbCvG8UMqPvVAA==:17 a] X-AnalysisOut: [=w6-zJku-bBgA:10 a=8D1Zlw_bSjwA:10 a=ofMgfj31e3cA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=kj9zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=XIqpo32R] X-AnalysisOut: [AAAA:8 a=Q47MkUNJBF8A:10 a=48vgC7mUAAAA:8 a=DGbFYnXxAAAA:8] X-AnalysisOut: [ a=pGLkceISAAAA:8 a=gnDg92SchgoBiUw2nx0A:9 a=CjuIK1q_8ugA:] X-AnalysisOut: [10 a=lZB815dzVvQA:10 a=bSyc6FVMW0oA:10 a=MSl-tDqOz04A:10 a] X-AnalysisOut: [=-xAQcgxKkbdUhgQi:21 a=kRJqKv_64qHtH7_t:21] Subject: Re: [dhcwg] WGLC on draft-ietf-dhc-dhcpv6-solmaxrt-update-01 - respond by July 4 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, 26 Jun 2013 18:51:36 -0000 Is the "may" in the proposed text normative? If not, could it be "might" to= avoid confusion? If yes, could it look normative? I'm ok either way and have no (other than this nit) problem with the propos= ed text. Barbara > -----Original Message----- > From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf > Of Ralph Droms > Sent: Wednesday, June 26, 2013 11:37 AM > To: dhcwg@ietf.org WG > Subject: Re: [dhcwg] WGLC on draft-ietf-dhc-dhcpv6-solmaxrt-update-01 - > respond by July 4 >=20 >=20 > On Jun 26, 2013, at 11:01 AM 6/26/13, Ted Lemon > wrote: >=20 > > On Jun 26, 2013, at 10:57 AM, Ralph Droms > wrote: > >> Is there any chance some diligent specification compliance organizatio= n > will interpret the current unspecified behavior as "the client MUST conti= nue > to listen actively"? > > > > I don't think it's wrong to say that some clients may choose to turn of= f their > radios after some interval. Saying that would address this concern. I = just > think we should leave the interval as an implementation-dependent value. > There is a concern here that an implementation will never actually test t= his > scenario, in which case it may use a too-short interval. But I just don= 't think > we have enough information to be able to make a determination as to what > the interval should be, so we have to accept that this failure mode is a > possibility. > > > Suggested text to be added at the end of section 3 of draft-ietf-dhc-dhcp= v6- > solmaxrt-update: >=20 > To accommodate resource constrained devices such as battery-powered > sensor nodes, the following text is added as the last sentence in > section 14 of RFC 3315: >=20 > NEW: >=20 > Some client devices may choose to stop listening for responses from > the server before RT expires. For example, a battery-powered device > may choose to turn off its radio after actively listening for a > response for an appropriate period of time. > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg From rdroms.ietf@gmail.com Wed Jun 26 11:55: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 0601B11E8125 for ; Wed, 26 Jun 2013 11:55:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[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 oNLT3-dBCrn8 for ; Wed, 26 Jun 2013 11:55:21 -0700 (PDT) Received: from mail-qc0-x231.google.com (mail-qc0-x231.google.com [IPv6:2607:f8b0:400d:c01::231]) by ietfa.amsl.com (Postfix) with ESMTP id 5BC5D11E8122 for ; Wed, 26 Jun 2013 11:55:04 -0700 (PDT) Received: by mail-qc0-f177.google.com with SMTP id n1so8326613qcx.8 for ; Wed, 26 Jun 2013 11:55:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to:x-mailer; bh=AxpFzspktIMKJea70GDCwmYnyFmDDRcME5FFrro5cdA=; b=OvQ5e62y7E4rG+/4QepWI9VWQf6FLzMGUI23yI9x0ZnWz3P+fwQnhnTi7+8L9Ae44e Up3C48V/pNrtsB2rjro23BzBJkP9HZdVNXd+RAYAZnGrCtZrYulyyupEbORJSVBSNcI2 8Sx38LE/MCY3xbcS+eDq9zHBFTiwA4pYF3Q1cSYNrKzTAE53m8m5J1ahnSVwuNceoV7j UUtcS03TiDXAP70YpcgO7XtCy0/V3A5i84E+zEuHSdYD3BFfiLAqKU7ZTUlx2F5GnHB0 tTlZgFMq8fkeY+uF/PEP4bmkLWfepoyLL14tyjaYdHBb5JA4v2FT+W9z6ICYqJyRXECz FJIg== X-Received: by 10.49.107.201 with SMTP id he9mr6499862qeb.74.1372272903804; Wed, 26 Jun 2013 11:55:03 -0700 (PDT) Received: from ?IPv6:2001:420:2481:20:e045:144:a37f:4a18? ([2001:420:2481:20:e045:144:a37f:4a18]) by mx.google.com with ESMTPSA id s9sm28101329qeo.3.2013.06.26.11.55.02 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 26 Jun 2013 11:55:03 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Ralph Droms In-Reply-To: <2D09D61DDFA73D4C884805CC7865E611302F1604@GAALPA1MSGUSR9L.ITServices.sbc.com> Date: Wed, 26 Jun 2013 14:55:00 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <9592A516-65AF-4596-B432-FBE8EE319A5C@gmail.com> References: <3135C2851EB6764BACEF35D8B495596806E7DAB304@MOPESMBX01.eu.thmulti.com> <51C31065.8040804@gmail.com> <8D23D4052ABE7A4490E77B1A012B6307751E2D82@mbx-01.win.nominum.com> <51C32C73.1010203@gmail.com> <489D13FBFA9B3E41812EA89F188F018E185A9B6F@xmb-rcd-x04.cisco.com> <90C4B43B-4EF6-40DD-A5F1-DBF82402F191@gmail.com> <489D13FBFA9B3E41812EA89F188F018E185AC7F1@xmb-rcd-x04.cisco.com> <1DF6792F-30B9-4C38-808C-DD6D1D37A099@gmail.com> <8D23D4052ABE7A4490E77B1A012B6307751EC6FF@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751EC9AB@mbx-01.win.nominum.com> <78B903E6-CA57-4E02-954A-6D44B12D692A@gmail.com> <2D09D61DDFA73D4C884805CC7865E611302F1604@GAALPA1MSGUSR9L.ITServices.sbc.com> To: "dhcwg@ietf.org WG" X-Mailer: Apple Mail (2.1508) Subject: Re: [dhcwg] WGLC on draft-ietf-dhc-dhcpv6-solmaxrt-update-01 - respond by July 4 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, 26 Jun 2013 18:55:22 -0000 On Jun 26, 2013, at 2:51 PM 6/26/13, "STARK, BARBARA H" = wrote: > Is the "may" in the proposed text normative? If not, could it be = "might" to avoid confusion? If yes, could it look normative? > I'm ok either way and have no (other than this nit) problem with the = proposed text. Author hat off, I would prefer to avoid normative text and would be ok = with s/may/might/ - Ralph > Barbara >=20 >> -----Original Message----- >> From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On = Behalf >> Of Ralph Droms >> Sent: Wednesday, June 26, 2013 11:37 AM >> To: dhcwg@ietf.org WG >> Subject: Re: [dhcwg] WGLC on draft-ietf-dhc-dhcpv6-solmaxrt-update-01 = - >> respond by July 4 >>=20 >>=20 >> On Jun 26, 2013, at 11:01 AM 6/26/13, Ted Lemon >> wrote: >>=20 >>> On Jun 26, 2013, at 10:57 AM, Ralph Droms >> wrote: >>>> Is there any chance some diligent specification compliance = organization >> will interpret the current unspecified behavior as "the client MUST = continue >> to listen actively"? >>>=20 >>> I don't think it's wrong to say that some clients may choose to turn = off their >> radios after some interval. Saying that would address this concern. = I just >> think we should leave the interval as an implementation-dependent = value. >> There is a concern here that an implementation will never actually = test this >> scenario, in which case it may use a too-short interval. But I just = don't think >> we have enough information to be able to make a determination as to = what >> the interval should be, so we have to accept that this failure mode = is a >> possibility. >>>=20 >> Suggested text to be added at the end of section 3 of = draft-ietf-dhc-dhcpv6- >> solmaxrt-update: >>=20 >> To accommodate resource constrained devices such as battery-powered >> sensor nodes, the following text is added as the last sentence in >> section 14 of RFC 3315: >>=20 >> NEW: >>=20 >> Some client devices may choose to stop listening for responses from >> the server before RT expires. For example, a battery-powered = device >> may choose to turn off its radio after actively listening for a >> response for an appropriate period of time. >> _______________________________________________ >> dhcwg mailing list >> dhcwg@ietf.org >> https://www.ietf.org/mailman/listinfo/dhcwg From Ted.Lemon@nominum.com Wed Jun 26 12:20: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 99F4711E8122 for ; Wed, 26 Jun 2013 12:20:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.495 X-Spam-Level: X-Spam-Status: No, score=-106.495 tagged_above=-999 required=5 tests=[AWL=0.104, 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 XFGll5radH-n for ; Wed, 26 Jun 2013 12:20:08 -0700 (PDT) Received: from exprod7og122.obsmtp.com (exprod7og122.obsmtp.com [64.18.2.22]) by ietfa.amsl.com (Postfix) with ESMTP id 553C211E81DC for ; Wed, 26 Jun 2013 12:20:05 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob122.postini.com ([64.18.6.12]) with SMTP ID DSNKUcs+5FNidzDYJ03CFtzpMoyZ8MUAhp5a@postini.com; Wed, 26 Jun 2013 12:20: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 E3C981B8229 for ; Wed, 26 Jun 2013 12:20:03 -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 D5D1E19005D; Wed, 26 Jun 2013 12:20:03 -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, 26 Jun 2013 12:19:57 -0700 From: Ted Lemon To: Ralph Droms Thread-Topic: [dhcwg] WGLC on draft-ietf-dhc-dhcpv6-solmaxrt-update-01 - respond by July 4 Thread-Index: AQHOcp633h0waKlVHkW3jDevF6vGeZlI1GMA Date: Wed, 26 Jun 2013 19:19:56 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B6307751ED151@mbx-01.win.nominum.com> References: <3135C2851EB6764BACEF35D8B495596806E7DAB304@MOPESMBX01.eu.thmulti.com> <51C31065.8040804@gmail.com> <8D23D4052ABE7A4490E77B1A012B6307751E2D82@mbx-01.win.nominum.com> <51C32C73.1010203@gmail.com> <489D13FBFA9B3E41812EA89F188F018E185A9B6F@xmb-rcd-x04.cisco.com> <90C4B43B-4EF6-40DD-A5F1-DBF82402F191@gmail.com> <489D13FBFA9B3E41812EA89F188F018E185AC7F1@xmb-rcd-x04.cisco.com> <1DF6792F-30B9-4C38-808C-DD6D1D37A099@gmail.com> <8D23D4052ABE7A4490E77B1A012B6307751EC6FF@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751EC9AB@mbx-01.win.nominum.com> <78B903E6-CA57-4E02-954A-6D44B12D692A@gmail.com> <2D09D61DDFA73D4C884805CC7865E611302F1604@GAALPA1MSGUSR9L.ITServices.sbc.com> <9592A516-65AF-4596-B432-FBE8EE319A5C@gmail.com> In-Reply-To: <9592A516-65AF-4596-B432-FBE8EE319A5C@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: <35516D99EDDC7B47AB012B94B0914950@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dhcwg@ietf.org WG" Subject: Re: [dhcwg] WGLC on draft-ietf-dhc-dhcpv6-solmaxrt-update-01 - respond by July 4 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, 26 Jun 2013 19:20:15 -0000 On Jun 26, 2013, at 2:55 PM, Ralph Droms wrote: > Author hat off, I would prefer to avoid normative text and would be ok wi= th s/may/might/ You can also put in the RFC 2119 section that only capitalized keywords are= normative, and then just use regular english. The IESG has been seeing a= lot of tortured english as a result of people assuming that lowercase vers= ions of RFC2119 keywords have to be normative, and we think it damages the = quality of the documents. From C.Donley@cablelabs.com Thu Jun 27 07:49:46 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 663F221F9AA1 for ; Thu, 27 Jun 2013 07:49:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.463 X-Spam-Level: X-Spam-Status: No, score=-0.463 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] 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 t5sWb7ihh7VS for ; Thu, 27 Jun 2013 07:49:42 -0700 (PDT) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by ietfa.amsl.com (Postfix) with ESMTP id 3CF6A21F9A81 for ; Thu, 27 Jun 2013 07:49:42 -0700 (PDT) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.5/8.14.5) with ESMTP id r5REne2b008474; Thu, 27 Jun 2013 08:49:40 -0600 Received: from exchange.cablelabs.com (10.5.0.19) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/407/kyzyl.cablelabs.com); Thu, 27 Jun 2013 08:49:40 -0600 (MDT) X-Virus-Status: clean(F-Secure/fsigk_smtp/407/kyzyl.cablelabs.com) Received: from EXCHANGE.cablelabs.com ([fe80::797a:96d1:3c53:18ee]) by EXCHANGE.cablelabs.com ([fe80::797a:96d1:3c53:18ee%11]) with mapi id 14.03.0123.003; Thu, 27 Jun 2013 08:49:40 -0600 From: Chris Donley To: Ralph Droms , "dhcwg@ietf.org WG" Thread-Topic: [dhcwg] WGLC on draft-ietf-dhc-dhcpv6-solmaxrt-update-01 - respond by July 4 Thread-Index: AQHOc0WN4vWmRdqVsEaucEWE+zPhpA== Date: Thu, 27 Jun 2013 14:49:40 +0000 Message-ID: In-Reply-To: <9592A516-65AF-4596-B432-FBE8EE319A5C@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.4.130416 x-originating-ip: [10.4.10.131] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <907059A68E69A94BA936DEFAC0E86EBA@cablelabs.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Approved: ondar Subject: Re: [dhcwg] WGLC on draft-ietf-dhc-dhcpv6-solmaxrt-update-01 - respond by July 4 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, 27 Jun 2013 14:49:46 -0000 Works for me. Chris --=20 Chris Donley CCIE, CISSP, SCiPM Director - Network Technologies CableLabs=AE 858 Coal Creek Circle Louisville, CO 80027 303-661-3480 (v) On 6/26/13 12:55 PM, "Ralph Droms" wrote: > >On Jun 26, 2013, at 2:51 PM 6/26/13, "STARK, BARBARA H" >wrote: > >> Is the "may" in the proposed text normative? If not, could it be >>"might" to avoid confusion? If yes, could it look normative? >> I'm ok either way and have no (other than this nit) problem with the >>proposed text. > >Author hat off, I would prefer to avoid normative text and would be ok >with s/may/might/ > >- Ralph > >> Barbara >>=20 >>> -----Original Message----- >>> From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf >>> Of Ralph Droms >>> Sent: Wednesday, June 26, 2013 11:37 AM >>> To: dhcwg@ietf.org WG >>> Subject: Re: [dhcwg] WGLC on draft-ietf-dhc-dhcpv6-solmaxrt-update-01 - >>> respond by July 4 >>>=20 >>>=20 >>> On Jun 26, 2013, at 11:01 AM 6/26/13, Ted Lemon >>> wrote: >>>=20 >>>> On Jun 26, 2013, at 10:57 AM, Ralph Droms >>> wrote: >>>>> Is there any chance some diligent specification compliance >>>>>organization >>> will interpret the current unspecified behavior as "the client MUST >>>continue >>> to listen actively"? >>>>=20 >>>> I don't think it's wrong to say that some clients may choose to turn >>>>off their >>> radios after some interval. Saying that would address this concern. >>>I just >>> think we should leave the interval as an implementation-dependent >>>value. >>> There is a concern here that an implementation will never actually >>>test this >>> scenario, in which case it may use a too-short interval. But I just >>>don't think >>> we have enough information to be able to make a determination as to >>>what >>> the interval should be, so we have to accept that this failure mode is >>>a >>> possibility. >>>>=20 >>> Suggested text to be added at the end of section 3 of >>>draft-ietf-dhc-dhcpv6- >>> solmaxrt-update: >>>=20 >>> To accommodate resource constrained devices such as battery-powered >>> sensor nodes, the following text is added as the last sentence in >>> section 14 of RFC 3315: >>>=20 >>> NEW: >>>=20 >>> Some client devices may choose to stop listening for responses from >>> the server before RT expires. For example, a battery-powered device >>> may choose to turn off its radio after actively listening for a >>> response for an appropriate period of time. >>> _______________________________________________ >>> 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 rdroms.ietf@gmail.com Thu Jun 27 07:58: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 EC41221F9DAE for ; Thu, 27 Jun 2013 07:58:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.45 X-Spam-Level: X-Spam-Status: No, score=-102.45 tagged_above=-999 required=5 tests=[AWL=0.150, 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 JkU-sW2PiaP3 for ; Thu, 27 Jun 2013 07:58:18 -0700 (PDT) Received: from mail-qe0-x22e.google.com (mail-qe0-x22e.google.com [IPv6:2607:f8b0:400d:c02::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 925C121F9D95 for ; Thu, 27 Jun 2013 07:58:08 -0700 (PDT) Received: by mail-qe0-f46.google.com with SMTP id nd7so263821qeb.5 for ; Thu, 27 Jun 2013 07:58:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=i7oi8sgj55jyvjUoVpVHoAmY9UMMrCUmDjptsiBJCBA=; b=TtL7Q/1yKUlXKImYn3WCpIKm5j79FxU0bLlz5v/eGNjS+ixdHfJ/kTQAXkcolFBZnL eoUmO4adptzL51ZmMi9f3sQyHr+iBJOPyuLhXGPtmR3fqC9+fG1tU+UFQXKz1gc0hOT2 oHzdrpXFPDDfCtRl98NAFQWxVNeG6FAaxZXAYchO9cSmYgZ+xn/8RJ3udweBPURFJmO5 OmssTGAkAVq8Ep4NoZuv89MizSYvL9aUW2jaDr1FF/4Y8WTaYrLSMh+ixctf8W5OPM8t s7ys8Qpmqmo7K1ua1AdaQvJPeIP+njCyi7vWGidolXPsDOtLXflsSbBWFPYFoMzPJFyd XFgw== X-Received: by 10.229.139.79 with SMTP id d15mr2659757qcu.82.1372345082222; Thu, 27 Jun 2013 07:58:02 -0700 (PDT) Received: from dhcp-i7prhfzrgrwle.d.cisco.com ([2001:420:2c52:1316:f9c6:c3df:d81:5cf6]) by mx.google.com with ESMTPSA id ng3sm4320044qeb.0.2013.06.27.07.58.00 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 27 Jun 2013 07:58:01 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Ralph Droms In-Reply-To: <8D23D4052ABE7A4490E77B1A012B6307751ED151@mbx-01.win.nominum.com> Date: Thu, 27 Jun 2013 10:57:56 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <4765B8B7-09D3-4650-8262-7069DE9D4E49@gmail.com> References: <3135C2851EB6764BACEF35D8B495596806E7DAB304@MOPESMBX01.eu.thmulti.com> <51C31065.8040804@gmail.com> <8D23D4052ABE7A4490E77B1A012B6307751E2D82@mbx-01.win.nominum.com> <51C32C73.1010203@gmail.com> <489D13FBFA9B3E41812EA89F188F018E185A9B6F@xmb-rcd-x04.cisco.com> <90C4B43B-4EF6-40DD-A5F1-DBF82402F191@gmail.com> <489D13FBFA9B3E41812EA89F188F018E185AC7F1@xmb-rcd-x04.cisco.com> <1DF6792F-30B9-4C38-808C-DD6D1D37A099@gmail.com> <8D23D4052ABE7A4490E77B1A012B6307751EC6FF@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751EC9AB@mbx-01.win.nominum.com> <78B903E6-CA57-4E02-954A-6D44B12D692A@gmail.com> <2D09D61DDFA73D4C884805CC7865E611302F1604@GAALPA1MSGUSR9L.ITServices.sbc.com> <9592A516-65AF-4596-B432-FBE8EE319A5C@gmail.com> <8D23D4052ABE7A4490E77B1A012B6307751ED151@mbx-01.win.nominum.com> To: Ted Lemon X-Mailer: Apple Mail (2.1508) Cc: "dhcwg@ietf.org WG" Subject: Re: [dhcwg] WGLC on draft-ietf-dhc-dhcpv6-solmaxrt-update-01 - respond by July 4 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, 27 Jun 2013 14:58:23 -0000 On Jun 26, 2013, at 3:19 PM 6/26/13, Ted Lemon = wrote: > On Jun 26, 2013, at 2:55 PM, Ralph Droms = wrote: >> Author hat off, I would prefer to avoid normative text and would be = ok with s/may/might/ >=20 > You can also put in the RFC 2119 section that only capitalized = keywords are normative, and then just use regular english. The IESG = has been seeing a lot of tortured english as a result of people assuming = that lowercase versions of RFC2119 keywords have to be normative, and we = think it damages the quality of the documents. OK, but wouldn't that paint a big target on this draft with a caption = "ADs, shoot here"? :-) Seriously, I agree with you, and I'm willing to join the fight, but = maybe not with this doc... - Ralph >=20 From volz@cisco.com Thu Jun 27 10:37: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 6C1B121F9EC3 for ; Thu, 27 Jun 2013 10:37:06 -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 lTH0Mo8NqtgC for ; Thu, 27 Jun 2013 10:37:01 -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 B266F21F9EC9 for ; Thu, 27 Jun 2013 10:37:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2767; q=dns/txt; s=iport; t=1372354621; x=1373564221; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=5YQO6b/vBpfdEw8kYL/715TbXct7BK2fN87xyfKi/QU=; b=Ie4Jn69a/gwe3RVlsPsRoaquRra1t9CZQUG4c3lc56zACPfClnQBx0U3 2DPGyigFpTnYKiz13HQxZ4ozwFxoJk+Sym72P81WgOAjAnX0oF6Mpru23 s5TbMc1mZjuuoOUWUsiSqzlFw6FzbBg6aJNm1OZZK7nZbsZkNY5s8LHu3 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah0FAFR3zFGtJV2Z/2dsb2JhbABYA4MJMUm/C4EBFnSCIwEBAQEDAQEBNw8lFwQCAQgRAwEBAQEKFAkHIQYLFAkIAgQBEgiHdAMPDLI2DYhSjG2BIIEXBhsXAgQLgnFjA5VejgeFJYFYgTmCKA X-IronPort-AV: E=Sophos;i="4.87,953,1363132800"; d="scan'208";a="228261489" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-8.cisco.com with ESMTP; 27 Jun 2013 17:37:01 +0000 Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r5RHb1bN003571 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 27 Jun 2013 17:37:01 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.56]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.02.0318.004; Thu, 27 Jun 2013 12:37:00 -0500 From: "Bernie Volz (volz)" To: "Brzozowski, John" , Ralph Droms , "dhcwg@ietf.org WG" Thread-Topic: [dhcwg] WGLC on draft-ietf-dhc-dhcpv6-solmaxrt-update-01 - respond by July 4 Thread-Index: AQHOcpxACSRxcYxqs06YWUX5kdNFjplJ1GrQ Date: Thu, 27 Jun 2013 17:37:00 +0000 Message-ID: <489D13FBFA9B3E41812EA89F188F018E185C6F17@xmb-rcd-x04.cisco.com> References: <78B903E6-CA57-4E02-954A-6D44B12D692A@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.240.26] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dhcwg] WGLC on draft-ietf-dhc-dhcpv6-solmaxrt-update-01 - respond by July 4 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, 27 Jun 2013 17:37:06 -0000 I'm OK with it. - Bernie -----Original Message----- From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of B= rzozowski, John Sent: Wednesday, June 26, 2013 2:38 PM To: Ralph Droms; dhcwg@ietf.org WG Subject: Re: [dhcwg] WGLC on draft-ietf-dhc-dhcpv6-solmaxrt-update-01 - res= pond by July 4 Seems like reasonable text. John =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 John Jason Brzozowski Comcast Cable m) 484-962-0060 o) 609-377-6594 w) www.comcast6.net e) john_brzozowski@cable.comcast.com =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 -----Original Message----- From: Ralph Droms Date: Wednesday, June 26, 2013 11:36 AM To: dhc WG Subject: Re: [dhcwg] WGLC on draft-ietf-dhc-dhcpv6-solmaxrt-update-01 - respond by July 4 > >On Jun 26, 2013, at 11:01 AM 6/26/13, Ted Lemon >wrote: > >> On Jun 26, 2013, at 10:57 AM, Ralph Droms wrote: >>> Is there any chance some diligent specification compliance=20 >>>organization will interpret the current unspecified behavior as "the=20 >>>client MUST continue to listen actively"? >>=20 >> I don't think it's wrong to say that some clients may choose to turn=20 >>off their radios after some interval. Saying that would address this >>concern. I just think we should leave the interval as an >>implementation-dependent value. There is a concern here that an >>implementation will never actually test this scenario, in which case it >>may use a too-short interval. But I just don't think we have enough >>information to be able to make a determination as to what the interval=20 >>should be, so we have to accept that this failure mode is a possibility. >>=20 >Suggested text to be added at the end of section 3 of >draft-ietf-dhc-dhcpv6-solmaxrt-update: > > To accommodate resource constrained devices such as battery-powered > sensor nodes, the following text is added as the last sentence in > section 14 of RFC 3315: > > NEW: > > Some client devices may choose to stop listening for responses from > the server before RT expires. For example, a battery-powered device > may choose to turn off its radio after actively listening for a > response for an appropriate period of time. >_______________________________________________ >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 Ted.Lemon@nominum.com Thu Jun 27 11:19: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 D3CC821F9E8F for ; Thu, 27 Jun 2013 11:19:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.3 X-Spam-Level: X-Spam-Status: No, score=-103.3 tagged_above=-999 required=5 tests=[AWL=3.299, 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 3MA+79rj3Je3 for ; Thu, 27 Jun 2013 11:19:25 -0700 (PDT) Received: from exprod7og115.obsmtp.com (exprod7og115.obsmtp.com [64.18.2.217]) by ietfa.amsl.com (Postfix) with ESMTP id 06F1221F9E26 for ; Thu, 27 Jun 2013 11:19:25 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob115.postini.com ([64.18.6.12]) with SMTP ID DSNKUcyCLAhYBfCuWetHyFTHogyAPCGQcwI3@postini.com; Thu, 27 Jun 2013 11:19:25 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 808011B81ED for ; Thu, 27 Jun 2013 11:19:24 -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 6678719005D; Thu, 27 Jun 2013 11:19:24 -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, 27 Jun 2013 11:19:24 -0700 From: Ted Lemon To: Ralph Droms Thread-Topic: [dhcwg] WGLC on draft-ietf-dhc-dhcpv6-solmaxrt-update-01 - respond by July 4 Thread-Index: AQHOc0a5S3e6Q94/wU2bHfUAXUXv35lKVH2A Date: Thu, 27 Jun 2013 18:19:24 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B6307751EF47F@mbx-01.win.nominum.com> References: <3135C2851EB6764BACEF35D8B495596806E7DAB304@MOPESMBX01.eu.thmulti.com> <51C31065.8040804@gmail.com> <8D23D4052ABE7A4490E77B1A012B6307751E2D82@mbx-01.win.nominum.com> <51C32C73.1010203@gmail.com> <489D13FBFA9B3E41812EA89F188F018E185A9B6F@xmb-rcd-x04.cisco.com> <90C4B43B-4EF6-40DD-A5F1-DBF82402F191@gmail.com> <489D13FBFA9B3E41812EA89F188F018E185AC7F1@xmb-rcd-x04.cisco.com> <1DF6792F-30B9-4C38-808C-DD6D1D37A099@gmail.com> <8D23D4052ABE7A4490E77B1A012B6307751EC6FF@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751EC9AB@mbx-01.win.nominum.com> <78B903E6-CA57-4E02-954A-6D44B12D692A@gmail.com> <2D09D61DDFA73D4C884805CC7865E611302F1604@GAALPA1MSGUSR9L.ITServices.sbc.com> <9592A516-65AF-4596-B432-FBE8EE319A5C@gmail.com> <8D23D4052ABE7A4490E77B1A012B6307751ED151@mbx-01.win.nominum.com> <4765B8B7-09D3-4650-8262-7069DE9D4E49@gmail.com> In-Reply-To: <4765B8B7-09D3-4650-8262-7069DE9D4E49@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: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dhcwg@ietf.org WG" Subject: Re: [dhcwg] WGLC on draft-ietf-dhc-dhcpv6-solmaxrt-update-01 - respond by July 4 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, 27 Jun 2013 18:19:32 -0000 On Jun 27, 2013, at 10:57 AM, Ralph Droms wrote: > OK, but wouldn't that paint a big target on this draft with a caption "AD= s, shoot here"? :-) No, I don't think so. When we discussed this in the informal telechat, pe= ople seemed to think it was a good idea. None of us like to read a docume= nt that says "the foo needs to bar" when it should say "the foo should bar"= just because someone was afraid of getting shot by an AD. From rdroms.ietf@gmail.com Thu Jun 27 11:52:37 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 F2D3A21F9A80 for ; Thu, 27 Jun 2013 11:52:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.001 X-Spam-Level: X-Spam-Status: No, score=-101.001 tagged_above=-999 required=5 tests=[AWL=1.599, 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 rHuLFVzZLDKx for ; Thu, 27 Jun 2013 11:52:36 -0700 (PDT) Received: from mail-qa0-x22d.google.com (mail-qa0-x22d.google.com [IPv6:2607:f8b0:400d:c00::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 649E421F9A58 for ; Thu, 27 Jun 2013 11:52:36 -0700 (PDT) Received: by mail-qa0-f45.google.com with SMTP id ci6so15805qab.11 for ; Thu, 27 Jun 2013 11:52:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=DcybYH8GBK+CgdOgDp1xxg9bkM7FmWxG89mXe6Z+Au0=; b=b2tZrhqdfrQMUqe73Cm1TuEenGPEcVEYvt6/WBUrs68px38Vd8tR1FpBhWLFZz5cZ8 cRw8iEeLrnls/PUPFqyByal+okYJw4buMkYsoIM47ove0u0zMV7nfNO89OxNJUwC12c3 4zRkejnim2YGyaG9nZ8WXs3q8MhD41uYPOmw2PetB5oZ3jzBNriJvT3lVLt/KCH00nFK b6ypVjXsho2C5PwYAR6MGqyu1QAajZ0mgItyizF6Z3ET2JvFcNBOsU30BBj3OtCDOVYI /7Y80n+vkoBTJJNFXPsAgF/Nz+6m55HUl4NitqRx48TBAtKJ8JJjxY/ijbULm1xJzmvy ru3w== X-Received: by 10.49.71.14 with SMTP id q14mr12320036qeu.90.1372359155826; Thu, 27 Jun 2013 11:52:35 -0700 (PDT) Received: from dhcp-i7prhfzrgrwle.d.cisco.com ([2001:420:2c52:1316:f9c6:c3df:d81:5cf6]) by mx.google.com with ESMTPSA id j9sm6335477qas.3.2013.06.27.11.52.34 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 27 Jun 2013 11:52:34 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Ralph Droms In-Reply-To: <8D23D4052ABE7A4490E77B1A012B6307751EF47F@mbx-01.win.nominum.com> Date: Thu, 27 Jun 2013 14:52:27 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <3135C2851EB6764BACEF35D8B495596806E7DAB304@MOPESMBX01.eu.thmulti.com> <51C31065.8040804@gmail.com> <8D23D4052ABE7A4490E77B1A012B6307751E2D82@mbx-01.win.nominum.com> <51C32C73.1010203@gmail.com> <489D13FBFA9B3E41812EA89F188F018E185A9B6F@xmb-rcd-x04.cisco.com> <90C4B43B-4EF6-40DD-A5F1-DBF82402F191@gmail.com> <489D13FBFA9B3E41812EA89F188F018E185AC7F1@xmb-rcd-x04.cisco.com> <1DF6792F-30B9-4C38-808C-DD6D1D37A099@gmail.com> <8D23D4052ABE7A4490E77B1A012B6307751EC6FF@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751EC9AB@mbx-01.win.nominum.com> <78B903E6-CA57-4E02-954A-6D44B12D692A@gmail.com> <2D09D61DDFA73D4C884805CC7865E611302F1604@GAALPA1MSGUSR9L.ITServices.sbc.com> <9592A516-65AF-4596-B432-FBE8EE319A5C@gmail.com> <8D23D4052ABE7A4490E77B1A012B6307751ED151@mbx-01.win.nominum.com> <4765B8B7-09D3-4650-8262-7069DE9D4E49@gmail.com> <8D23D4052ABE7A4490E77B1A012B63077 51EF47F@mbx-01.win.nominum.com> To: Ted Lemon X-Mailer: Apple Mail (2.1508) Cc: "dhcwg@ietf.org WG" Subject: Re: [dhcwg] WGLC on draft-ietf-dhc-dhcpv6-solmaxrt-update-01 - respond by July 4 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, 27 Jun 2013 18:52:37 -0000 On Jun 27, 2013, at 2:19 PM 6/27/13, Ted Lemon = wrote: > On Jun 27, 2013, at 10:57 AM, Ralph Droms = wrote: >> OK, but wouldn't that paint a big target on this draft with a caption = "ADs, shoot here"? :-) >=20 > No, I don't think so. When we discussed this in the informal = telechat, people seemed to think it was a good idea. None of us like = to read a document that says "the foo needs to bar" when it should say = "the foo should bar" just because someone was afraid of getting shot by = an AD. Looking hard for potential roadblocks to publication - will the use of = an RFC 2119 statement in this document that is different from the one in = RFC 3315 cause problems, considering that this document updates RFC 3315 = with text that is to be considered part of RFC 3315? - Ralph From Ted.Lemon@nominum.com Thu Jun 27 12:36:10 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 0BBFD21F9ED7 for ; Thu, 27 Jun 2013 12:36:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.95 X-Spam-Level: X-Spam-Status: No, score=-104.95 tagged_above=-999 required=5 tests=[AWL=1.650, 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 OiIQkGG4Lqm4 for ; Thu, 27 Jun 2013 12:36:02 -0700 (PDT) Received: from exprod7og121.obsmtp.com (exprod7og121.obsmtp.com [64.18.2.20]) by ietfa.amsl.com (Postfix) with ESMTP id 35A5221F9ED2 for ; Thu, 27 Jun 2013 12:36:02 -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 DSNKUcyUIQ3CHM/+64+ezknXVQGge/kDk9lY@postini.com; Thu, 27 Jun 2013 12:36:02 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 DF0681B8225 for ; Thu, 27 Jun 2013 12:36: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 C5B5519005D; Thu, 27 Jun 2013 12:36: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; Thu, 27 Jun 2013 12:36:00 -0700 From: Ted Lemon To: Ralph Droms Thread-Topic: [dhcwg] WGLC on draft-ietf-dhc-dhcpv6-solmaxrt-update-01 - respond by July 4 Thread-Index: AQHOc0a5S3e6Q94/wU2bHfUAXUXv35lKVH2AgAAJPoCAAAwpgA== Date: Thu, 27 Jun 2013 19:36:00 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B6307751EF6BF@mbx-01.win.nominum.com> References: <3135C2851EB6764BACEF35D8B495596806E7DAB304@MOPESMBX01.eu.thmulti.com> <51C31065.8040804@gmail.com> <8D23D4052ABE7A4490E77B1A012B6307751E2D82@mbx-01.win.nominum.com> <51C32C73.1010203@gmail.com> <489D13FBFA9B3E41812EA89F188F018E185A9B6F@xmb-rcd-x04.cisco.com> <90C4B43B-4EF6-40DD-A5F1-DBF82402F191@gmail.com> <489D13FBFA9B3E41812EA89F188F018E185AC7F1@xmb-rcd-x04.cisco.com> <1DF6792F-30B9-4C38-808C-DD6D1D37A099@gmail.com> <8D23D4052ABE7A4490E77B1A012B6307751EC6FF@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751EC9AB@mbx-01.win.nominum.com> <78B903E6-CA57-4E02-954A-6D44B12D692A@gmail.com> <2D09D61DDFA73D4C884805CC7865E611302F1604@GAALPA1MSGUSR9L.ITServices.sbc.com> <9592A516-65AF-4596-B432-FBE8EE319A5C@gmail.com> <8D23D4052ABE7A4490E77B1A012B6307751ED151@mbx-01.win.nominum.com> <4765B8B7-09D3-4650-8262-7069DE9D4E49@gmail.com> <8D23D4052ABE7A4490E77B1A012B63077 51EF47F@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: <64485F59AC02F2428A54B093622970FE@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dhcwg@ietf.org WG" Subject: Re: [dhcwg] WGLC on draft-ietf-dhc-dhcpv6-solmaxrt-update-01 - respond by July 4 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, 27 Jun 2013 19:36:10 -0000 On Jun 27, 2013, at 2:52 PM, Ralph Droms wrote: > Looking hard for potential roadblocks to publication - will the use of an= RFC 2119 statement in this document that is different from the one in RFC = 3315 cause problems, considering that this document updates RFC 3315 with t= ext that is to be considered part of RFC 3315? If you are stating diffs to RFC3315, that could be an issue. Otherwise no= t. From rdroms.ietf@gmail.com Thu Jun 27 12:57: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 22C0D21F9F65 for ; Thu, 27 Jun 2013 12:57:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.8 X-Spam-Level: X-Spam-Status: No, score=-101.8 tagged_above=-999 required=5 tests=[AWL=0.800, 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 7bK85iCfdPJ7 for ; Thu, 27 Jun 2013 12:57:14 -0700 (PDT) Received: from mail-qe0-x230.google.com (mail-qe0-x230.google.com [IPv6:2607:f8b0:400d:c02::230]) by ietfa.amsl.com (Postfix) with ESMTP id C6A9B21F9F5E for ; Thu, 27 Jun 2013 12:57:02 -0700 (PDT) Received: by mail-qe0-f48.google.com with SMTP id 2so384606qea.7 for ; Thu, 27 Jun 2013 12:56:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=9Uhsz4NLWImA5ZtccDtrNwqyTsuL7Uise0vr0vkGznE=; b=gGtOiEkOdnoN5xPYX9hguUGFoavmOpu5nTeyYoFb6xjKa6okpgajH4lnqd+70leHVu 2VVJlJgyGyrpjRCBumPS2qlsZ79Wt6zoZEm3GkUh2VdLikMlStwGWi+k1cNU1TmEgmOO RSAk53mrSd34+F3mMd2VIt+/IM7ELMzHUsqiltzNpyoui9RwXjyT1rLz3AEx6KPlsuDA BOS0zJijA69+GdMTlaog3/4FWw8oheVHDYY45yVd4ySifApoclDrqIIvCCfq2fFrSmat ymzzpj0LMNtFpwLs4Tcf+3L4sUDth3DMKUiblxDpOzkDN7NcKCUawEm1o0WTB4OWmBsS 5q8g== X-Received: by 10.224.74.72 with SMTP id t8mr13576413qaj.74.1372363019314; Thu, 27 Jun 2013 12:56:59 -0700 (PDT) Received: from dhcp-i7prhfzrgrwle.d.cisco.com ([2001:420:2c52:1316:f9c6:c3df:d81:5cf6]) by mx.google.com with ESMTPSA id a8sm6569336qae.11.2013.06.27.12.56.58 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 27 Jun 2013 12:56:58 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Ralph Droms In-Reply-To: <8D23D4052ABE7A4490E77B1A012B6307751EF6BF@mbx-01.win.nominum.com> Date: Thu, 27 Jun 2013 15:56:52 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <963E4843-157F-4B11-8348-201E7514643D@gmail.com> References: <3135C2851EB6764BACEF35D8B495596806E7DAB304@MOPESMBX01.eu.thmulti.com> <51C31065.8040804@gmail.com> <8D23D4052ABE7A4490E77B1A012B6307751E2D82@mbx-01.win.nominum.com> <51C32C73.1010203@gmail.com> <489D13FBFA9B3E41812EA89F188F018E185A9B6F@xmb-rcd-x04.cisco.com> <90C4B43B-4EF6-40DD-A5F1-DBF82402F191@gmail.com> <489D13FBFA9B3E41812EA89F188F018E185AC7F1@xmb-rcd-x04.cisco.com> <1DF6792F-30B9-4C38-808C-DD6D1D37A099@gmail.com> <8D23D4052ABE7A4490E77B1A012B6307751EC6FF@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751EC9AB@mbx-01.win.nominum.com> <78B903E6-CA57-4E02-954A-6D44B12D692A@gmail.com> <2D09D61DDFA73D4C884805CC7865E611302F1604@GAALPA1MSGUSR9L.ITServices.sbc.com> <9592A516-65AF-4596-B432-FBE8EE319A5C@gmail.com> <8D23D4052ABE7A4490E77B1A012B6307751ED151@mbx-01.win.nominum.com> <4765B8B7-09D3-4650-8262-7069DE9D4E49@gmail.com> <8D23D4052ABE7A4490E77B1A012B63077 51EF47F@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751EF6BF@mbx-01.win.nominum.com> To: Ted Lemon X-Mailer: Apple Mail (2.1508) Cc: "dhcwg@ietf.org WG" Subject: Re: [dhcwg] WGLC on draft-ietf-dhc-dhcpv6-solmaxrt-update-01 - respond by July 4 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, 27 Jun 2013 19:57:34 -0000 On Jun 27, 2013, at 3:36 PM 6/27/13, Ted Lemon = wrote: > On Jun 27, 2013, at 2:52 PM, Ralph Droms = wrote: >> Looking hard for potential roadblocks to publication - will the use = of an RFC 2119 statement in this document that is different from the one = in RFC 3315 cause problems, considering that this document updates RFC = 3315 with text that is to be considered part of RFC 3315? >=20 > If you are stating diffs to RFC3315, that could be an issue. = Otherwise not. I interpret the current text in draft-ietf-dhc-dhcpv6-solmaxrt-update as = publishing diffs to RFC 3315; e.g.: 6. Updates for SOL_MAX_RT and INF_MAX_RT options to RFC 3315 Update to RFC 3315 [RFC3315], section 17.1.3: OLD: The client MUST ignore any Advertise message that includes a Status Code option containing the value NoAddrsAvail, with the exception that the client MAY display the associated status message to the user. NEW: The client MUST ignore any Advertise message that includes a Status Code option containing the value NoAddrsAvail, with the exception that the client MUST process an included SOL_MAX_RT option and/or an included INF_MAX_RT option and MAY display the associated status message to the user. and this new text as a diff, as well: Suggested text to be added at the end of section 3 of = draft-ietf-dhc-dhcpv6- solmaxrt-update: To accommodate resource constrained devices such as battery-powered sensor nodes, the following text is added as the last sentence in section 14 of RFC 3315: NEW: Some client devices may choose to stop listening for responses from the server before RT expires. For example, a battery-powered device may choose to turn off its radio after actively listening for a response for an appropriate period of time. - Ralph From kkinnear@cisco.com Thu Jun 27 13:31:38 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 232DD21F9F5E for ; Thu, 27 Jun 2013 13:31:38 -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 ikvpLOuTnfwb for ; Thu, 27 Jun 2013 13:31:33 -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 7D00121F9AAF for ; Thu, 27 Jun 2013 13:31:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8398; q=dns/txt; s=iport; t=1372365093; x=1373574693; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=0DjPDM1R5E1jwwQrH9gG49sf2tz6zjaJNpoIL4YCRC0=; b=Ys87x29DC9fgZHoaGZ3EddOPWcGslQYyT2iUeFcVcB9TpwnBcMm4JI+M vJ76NNfYT/a6blmp0ZLvf9WS/h2W8IswbIkOIAFCDNUzZxY0StlEdtduA oIZJ3N8zSBCBdvZonkztjCqylsvZ+Bbwz/M0lD/emvywAvkSb5jOjFA4K Y=; X-IronPort-AV: E=Sophos;i="4.87,954,1363132800"; d="scan'208";a="228339384" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-5.cisco.com with ESMTP; 27 Jun 2013 20:31:33 +0000 Received: from [10.131.32.108] ([10.131.32.108]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id r5RKVVAS016657; Thu, 27 Jun 2013 20:31:31 GMT Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=windows-1252 From: Kim Kinnear In-Reply-To: <489D13FBFA9B3E41812EA89F188F018E185C32B5@xmb-rcd-x04.cisco.com> Date: Thu, 27 Jun 2013 16:31:45 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <0424945D-DD09-44AE-9F00-2364C3C1E3D5@cisco.com> References: <489D13FBFA9B3E41812EA89F188F018E185C32B5@xmb-rcd-x04.cisco.com> To: "Bernie Volz (volz)" X-Mailer: Apple Mail (2.1278) Cc: "dhcwg@ietf.org" , "Ted Lemon \(Ted.Lemon@nominum.com\)" , Kim Kinnear Subject: Re: [dhcwg] DHCP Directorate Proposal 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, 27 Jun 2013 20:31:38 -0000 This all seems reasonable to me, except for one issue that seems odd. I would have thought that the DHC WG Chairs would have some role in the selection of individuals for the directorate and the reappointment, etc. of these individuals. I don't know, perhaps it just "isn't done that way" with the other directorates, or perhaps the politics of AD/WG Chair interactions means that AD's don't *want* any official role for the WG chairs when selecting folks for the directorate. I'm not up to speed on all of the subtleties of the interactions in the more rarefied levels of the IETF. But as a long time person in the trenches, it seems like the fact that the DHC WG Chairs are not mentioned at all in this document (except regarding a request for early review of a document) indicates a stratification of control that has an odd feel to me. I would have expected that the DHC WG chairs would play a major role in selecting folks for the DHCP Directorate. Regards -- Kim On Jun 25, 2013, at 3:47 PM, Bernie Volz (volz) wrote: > Hello: > =20 > At the Orlando IETF, Ted Lemon (AD) introduced the idea of an IETF = DHCP Directorate to help streamline the DHC WG workload and provide = assistance to other working groups developing DHCP options. Ted and the = DHC WG co-chairs developed the following proposal for an DHCP = Directorate. As this is tied to the DHC WG re-charter (see separate = email), Ted requested that we share this with the DHC WG for feedback. = This will also be on the agenda for discussion at Berlin, to hopefully = finalize it shortly thereafter. > =20 > While the DHC re-charter and DHCP directorate are connected, we=92d = like to try to separate the discussion (hence the re-charter) is in a = separate email). > =20 > Per http://tools.ietf.org/html/rfc2418: > =20 > In many areas, the Area Directors have formed an advisory group or > directorate. These comprise experienced members of the IETF and = the > technical community represented by the area. The specific name and > the details of the role for each group differ from area to area, = but > the primary intent is that these groups assist the Area = Director(s), > e.g., with the review of specifications produced in the area. > =20 > For a list of existing directorates, see = http://www.ietf.org/iesg/directorate.html. > =20 > Proposed DHCP Directorate: > =20 > DHCP Directorate > =20 > The DHCP Directorate is an advisory group of DHCP experts selected by = the > Internet Area Directors. > =20 > The notion of a directorate is defined in RFC 2418 as follows: > =20 > In many areas, the Area Directors have formed an advisory group or > directorate. These comprise experienced members of the IETF and the > technical community represented by the area. The specific name and = the > details of the role for each group differ from area to area, but the > primary intent is that these groups assist the Area Director(s), = e.g., > with the review of specifications produced in the area. > =20 > =20 > What Does the Directorate Do? > =20 > The main purpose of the DHCP Directorate is to review all documents > submitted to the IESG for publication that define new DHCP (DHCPv6 or > DHCPv4) options, DHCP messages, or DHCP client, relay agent or server > processing. Generally speaking, documents advanced by the DHC WG will > have already received review from members of the DHCP Directorate and > thus may not require such review. > =20 > While the DHC WG is active, the DHCP Directorate is responsible for > reviewing DHCP options or other extensions (for both IPv4 and IPv6). = The > Directorate is expected to review all proposed extensions to DHCP to > ensure that they are consistent with the DHCP specification and other > option formats, that they do not duplicate existing mechanisms, etc. > Generally speaking, the Directorate will not be responsible for = evaluating > the semantic content of proposed options. > =20 > The tasks performed by the Directorate are: > =20 > 1. Review all documents submitted to the IESG for publication that = have > DHCP options, messages, or processing requirements. A review is > triggered: > =20 > - By request for early review (by any AD or by any WG chair) > - By a document moving to 'publication requested' state > - By entry on the IESG agenda (for other documents) > =20 > 2. Assist ADs with judgment issues when requested - The ADs may send = email > to the directorate list when they have issues that they want help = with. > Examples for judgment issues are: > =20 > - New option formats. > - New client, relay, server agent processing. > =20 > 3. Try to follow IETF documents related to DHCP as early as possible = and > provide guidance to authors as early as possible. > =20 > =20 > How is Document Review Organized? > =20 > 1. The DHCP Directorate Coordinator assigns each document that is > triggered for review to at least two (2) reviewers and issues a = Review > Request. Authors and contributors to a document must not be = assigned. > The Review Request will include the document and review deadline. > 2. The assigned reviewers must acknowledge and agree to review the > document within 72 hours and respond with a "can review by = deadline" or > "can't review". No reply is interpreted as "can't review". > 3. If the Coordinator does not receive "can review by deadline" within = 72 > hours, the Coordinator selects at least one or two additional = reviewers. > This process is repeated until at least two reviewers are found. > 4. The reviewers provide comments as appropriate (IETF Last Call, Area > Director, document authors). > 5. The Coordinator may decide to call upon additional reviewers if > expected review is overdue or the topic under review is a complex = one. > =20 > =20 > How is the Directorate Formed? > =20 > 1. Directorate members are assigned to the Directorate by the Internet > Area Directors. > 2. There is an expectation that Directorate membership will not be > limited to 'old-time DHCP gods from years past'. It is assumed = that > the Directorate will include younger and newer participants who = are > interested in 'learning while doing work'. > 3. Each assignment is for a three year term, unless the member or = Internet > Area Director requests a shorter term. > 4. The terms are staggered so that approximately 1/3 of the = directorate > members have their term end each year. > 5. When the Directorate is first established members of the = Directorate > will be assigned either one year, two years, or three years in = their > first term. > 6. When a member's term expires, the Internet ADs may replace the = person > whose term expires, may reappoint the same person, or may reduce = the > size of the Directorate. There is no expectation that the same = person > will either want to be returned, or will be returned. > 7. The three year term serves as the limit of the commitment of a > Directorate member, but also serves as a way to return Directorate > members to the community. > 8. In deciding whether to reappoint a member whose term has expired, = the > Internet ADs may consider the quantity of work that they have = done, > the ADs' impression of the quality of the work, and the comments = from > the authors and other Directorate members regarding the reviews. > 9. If a member resigns before the member's term expires, the Internet > Area Directors may appoint a replacement. > 10. The Internet Area Directors may remove a member before the = member's > term expires, and may appoint a replacement. > 11. Internet ADs can assign additional members to the Directorate = whenever > they want to, subject to willingness of people to serve. > 12. Both ADs need to agree in order to assign a member to the = Directorate. > 13. Both ADs select one of the Directorate members as the DHCP = Directorate > Coordinator on a yearly basis. > =20 > END > =20 > - Ted, Tomek, & Bernie > =20 > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg From kkinnear@cisco.com Thu Jun 27 13:48: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 B1ABE21F9CEC for ; Thu, 27 Jun 2013 13:48:44 -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 AAMsBx-yqKxT for ; Thu, 27 Jun 2013 13:48:39 -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 65F9E21F9C68 for ; Thu, 27 Jun 2013 13:48:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5616; q=dns/txt; s=iport; t=1372366119; x=1373575719; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=21dIzmpGL9q4D20UypRSQRxBiCX1F3NWCsErvlyKiTg=; b=X9h7Tcj7Q8AeSoPKhWdByLBynEQfsRzLlCI889RB6BFdnGMSGZLgbiob g+pUmQAh5A355MerPSWhdPtvA/6rrzcFpaWyCzgkCwMPRlWxR0KQipB5Y DduB5hst5Gk8/Pi9pk8Os/UfpJrPXv+jp2R9P7x7iH4XLUehY1oHzXdZO Y=; X-IronPort-AV: E=Sophos;i="4.87,954,1363132800"; d="scan'208";a="228365679" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-3.cisco.com with ESMTP; 27 Jun 2013 20:48:39 +0000 Received: from [10.131.32.108] ([10.131.32.108]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id r5RKmcPa023399; Thu, 27 Jun 2013 20:48:38 GMT Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=windows-1252 From: Kim Kinnear In-Reply-To: <489D13FBFA9B3E41812EA89F188F018E185C32AD@xmb-rcd-x04.cisco.com> Date: Thu, 27 Jun 2013 16:48:47 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <17841E13-DE68-45F0-9282-AE696A137B30@cisco.com> References: <489D13FBFA9B3E41812EA89F188F018E185C32AD@xmb-rcd-x04.cisco.com> To: "Bernie Volz (volz)" X-Mailer: Apple Mail (2.1278) Cc: "dhcwg@ietf.org" , "Ted Lemon \(Ted.Lemon@nominum.com\)" , Kim Kinnear Subject: Re: [dhcwg] DHC WG Re-Charter Proposal 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, 27 Jun 2013 20:48:46 -0000 I have a major problem with this charter. As I read it, the DHC WG cannot create drafts for new options the are not "protocol options". This is a *huge* change from the past. There is clearly a desire to disconnect the DHC WG from becoming involved in the options proposed by folks from other working groups. Thus, the DHCP Directorate is the place where those options will be reviewed (according to this charter). I can see why this is being done, and while I'm a bit uncomfortable with it, I can understand some of the reasons for this change, and I can live with it. However, that is very different from the constraint in this charter that says that the DHC WG cannot create options that are not protocol options. This places the DHC WG in a *more* restrictive position than other WGs -- *they* can try to create options that are reviewed by the DHCP directorate. But the DHC WG is explicitly chartered to create only protocol options. Period. I think this is wrong. When I raised this at the last IETF, I was told that "consensus isn't necessary for charter approval". I understand, but the fact that I was told that my opinion really isn't interesting doesn't change my opinion. =20 I *still* think that this is a major mistake. I believe that the DHC WG should be able to take on the creation of DHCP options if the WG chairs believe that it is a good idea. I would strongly recommend that we amend this charter to include this statement as the third paragraph: The DHC WG may, at the discretion of any of the chairs of the WG, be considered to be chartered to develop non-protocol DHCP options on a case by case basis. The normal consensus approach to adoption as a WG work item would be used in this case, but would require explicit WG chair approval that the non-protocol option fit within the charter of the working group. These options would undergo the same review as protocol extensions. Absent something like this, if you need a simple non-protocol option, you will have to shop it around to some other working group to get it adopted. Is this going to help the situation? Regards -- Kim On Jun 25, 2013, at 3:47 PM, Bernie Volz (volz) wrote: > Hello: > =20 > The text below is a proposed update of the DHC WG charter that the = co-chairs developed with input and review from Ted Lemon (AD). It = assumes a DHCP Directorate is created as well (see separate email). = Feedback on the charter text is appreciated and will also be discussed = in Berlin as we hope to finalize it shortly thereafter. > =20 > While the DHC re-charter and DHCP directorate are connected, we=92d = like to try to separate the discussion (hence the directorate is in a = separate email). > =20 > The current charter, which is rather old, can be viewed at = http://datatracker.ietf.org/wg/dhc/charter/. > =20 > Proposed DHC WG Charter: > =20 > The Dynamic Host Configuration working group (DHC WG) has developed > DHCP for automated allocation, configuration and management of IP > addresses and TCP/IP protocol stack parameters. DHCPv4 is currently > a Draft Standard and is documented in RFC 2131 and RFC 2132. DHCPv6 > is currently a Proposed Standard and is documented in RFC 3315. > Subsequent RFCs document additional options and other enhancements = to > the specifications. > =20 > The DHC WG is responsible for defining DHCP protocol extensions. > Definitions of new DHCP options that are delivered using standard > mechanisms with documented semantics are not considered a protocol > extension and thus are outside of scope for DHC WG. Such options = should > be defined within their respective WGs and reviewed by the DHCP > Directorate. However, if such options require protocol extensions or = new > semantics, the protocol extension work must be done in the DHC WG. > =20 > The DHC WG has the following main objectives: > =20 > * Develop extensions to the DHCPv6 infrastructure as required to = meet > new applications and deployments of DHCP. The topics currently > in development are: > =20 > - DHCPv6 Failover, High Availability and Load Balancing > - DNS Update strategies for delegated prefixes = (draft-ietf-dhc-dns-pd) > - Extend DHCPv6 to work with multiple provisioning domains > - DHCP provisioning of IPv4 clients over IPv6 networks > - SOLMAXRT counter update > - Container option > - Address Network Identifier = (draft-ietf-dhc-access-network-identifier) > - New NTP option to replace OPTION_NTP_SERVER (RFC 5908) > - Prefix coloring (draft-bhandari-dhc-class-based-prefix) > =20 > Additional topics may only be added with approval from the = responsible > Area Director or by re-chartering. > =20 > * Specify guidelines for creating new DHCPv6 options. > =20 > * Develop documents that help explain operational considerations for > the wider community. > =20 > * Advance DHCPv6 (RFC 3315) along the IETF Standards Track. This = will > include writing analyses, corrections, and clarifications of the = DHCPv6 > specifications, including RFC 3315, RFC3633, RFC3736 and other RFCs > defining additional options, which identifies and resolves = ambiguities, > contradictory specifications and other obstacles to development of > interoperable implementations. > =20 > END > =20 > - Tomek & Bernie > =20 > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg From volz@cisco.com Thu Jun 27 13:54: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 0225211E80D7 for ; Thu, 27 Jun 2013 13:54:22 -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 b-4Eg84P0fLq for ; Thu, 27 Jun 2013 13:54:02 -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 0569A21F9D70 for ; Thu, 27 Jun 2013 13:53:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9064; q=dns/txt; s=iport; t=1372366431; x=1373576031; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=xwzMEUSPYlgJpb+PIC9Ufqi68Nidt6HJ4IlptXKWiqU=; b=DQZDaAk5Ni/AHpY/vykU2zCRyZZDZCdLV2Rzr7Ke2ab0RnzaDirE/O2M Ijb162i+SqWGgvVPtUgntOjMSrsBOqGDvBWIGCpwNJvU/BiW3TkDu4Ifo Gg28fLIvL6WQCNUCxx2GtpAMge9sfqtIMlO1iUIH5HT+pcX4Dph1Ja6wM E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah0FAAWmzFGtJXG//2dsb2JhbABbgwkxSb8MgQIWdIIjAQEBAQIBAQEBNzECAQsFBwQCAQgRBAEBCxQQJwsdCAEBBA4FCAELh3QGDLs0jhMKAYEGMQIFBoJ8YwOTc4R7kByDEYFoAQgXIA X-IronPort-AV: E=Sophos;i="4.87,954,1363132800"; d="scan'208";a="228317368" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-2.cisco.com with ESMTP; 27 Jun 2013 20:53:36 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id r5RKrasL023855 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 27 Jun 2013 20:53:36 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.56]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.02.0318.004; Thu, 27 Jun 2013 15:53:36 -0500 From: "Bernie Volz (volz)" To: "Kim Kinnear (kkinnear)" Thread-Topic: [dhcwg] DHCP Directorate Proposal Thread-Index: Ac5x3HNmjTU+PkrUQRe5be06SLqzEABwsyKAAAnjdNA= Date: Thu, 27 Jun 2013 20:53:35 +0000 Message-ID: <489D13FBFA9B3E41812EA89F188F018E185C7362@xmb-rcd-x04.cisco.com> References: <489D13FBFA9B3E41812EA89F188F018E185C32B5@xmb-rcd-x04.cisco.com> <0424945D-DD09-44AE-9F00-2364C3C1E3D5@cisco.com> In-Reply-To: <0424945D-DD09-44AE-9F00-2364C3C1E3D5@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.240.26] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dhcwg@ietf.org" , "Ted Lemon \(Ted.Lemon@nominum.com\)" Subject: Re: [dhcwg] DHCP Directorate Proposal 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, 27 Jun 2013 20:54:22 -0000 Kim: A key reason for not specifically involving the DHC WG (co-chairs) in the D= HCP Directorate is that the Directorate can outlive the DHC WG :). I would suspect that most ADs would rely on the DHC WG chairs (if active) a= nd "dhcp experts" for recommendations as to potential members. But it will= also depend on the AD - if they were a past DHC chair, they might already = know the potential pool fairly well. - Bernie -----Original Message----- From: Kim Kinnear (kkinnear)=20 Sent: Thursday, June 27, 2013 4:32 PM To: Bernie Volz (volz) Cc: Kim Kinnear (kkinnear); dhcwg@ietf.org; Ted Lemon (Ted.Lemon@nominum.co= m) Subject: Re: [dhcwg] DHCP Directorate Proposal This all seems reasonable to me, except for one issue that seems odd. I would have thought that the DHC WG Chairs would have some role in the sel= ection of individuals for the directorate and the reappointment, etc. of th= ese individuals. I don't know, perhaps it just "isn't done that way" with the other director= ates, or perhaps the politics of AD/WG Chair interactions means that AD's d= on't *want* any official role for the WG chairs when selecting folks for th= e directorate. I'm not up to speed on all of the subtleties of the interactions in the mor= e rarefied levels of the IETF. But as a long time person in the trenches, = it seems like the fact that the DHC WG Chairs are not mentioned at all in t= his document (except regarding a request for early review of a document) in= dicates a stratification of control that has an odd feel to me. I would have expected that the DHC WG chairs would play a major role in sel= ecting folks for the DHCP Directorate. Regards -- Kim On Jun 25, 2013, at 3:47 PM, Bernie Volz (volz) wrote: > Hello: > =20 > At the Orlando IETF, Ted Lemon (AD) introduced the idea of an IETF DHCP D= irectorate to help streamline the DHC WG workload and provide assistance to= other working groups developing DHCP options. Ted and the DHC WG co-chairs= developed the following proposal for an DHCP Directorate. As this is tied = to the DHC WG re-charter (see separate email), Ted requested that we share = this with the DHC WG for feedback. This will also be on the agenda for disc= ussion at Berlin, to hopefully finalize it shortly thereafter. > =20 > While the DHC re-charter and DHCP directorate are connected, we'd like to= try to separate the discussion (hence the re-charter) is in a separate ema= il). > =20 > Per http://tools.ietf.org/html/rfc2418: > =20 > In many areas, the Area Directors have formed an advisory group or > directorate. These comprise experienced members of the IETF and the > technical community represented by the area. The specific name and > the details of the role for each group differ from area to area, but > the primary intent is that these groups assist the Area Director(s), > e.g., with the review of specifications produced in the area. > =20 > For a list of existing directorates, see http://www.ietf.org/iesg/directo= rate.html. > =20 > Proposed DHCP Directorate: > =20 > DHCP Directorate > =20 > The DHCP Directorate is an advisory group of DHCP experts selected by=20 > the Internet Area Directors. > =20 > The notion of a directorate is defined in RFC 2418 as follows: > =20 > In many areas, the Area Directors have formed an advisory group or > directorate. These comprise experienced members of the IETF and the > technical community represented by the area. The specific name and the > details of the role for each group differ from area to area, but the > primary intent is that these groups assist the Area Director(s), e.g., > with the review of specifications produced in the area. > =20 > =20 > What Does the Directorate Do? > =20 > The main purpose of the DHCP Directorate is to review all documents=20 > submitted to the IESG for publication that define new DHCP (DHCPv6 or > DHCPv4) options, DHCP messages, or DHCP client, relay agent or server=20 > processing. Generally speaking, documents advanced by the DHC WG will=20 > have already received review from members of the DHCP Directorate and=20 > thus may not require such review. > =20 > While the DHC WG is active, the DHCP Directorate is responsible for=20 > reviewing DHCP options or other extensions (for both IPv4 and IPv6).=20 > The Directorate is expected to review all proposed extensions to DHCP=20 > to ensure that they are consistent with the DHCP specification and=20 > other option formats, that they do not duplicate existing mechanisms, etc= . > Generally speaking, the Directorate will not be responsible for=20 > evaluating the semantic content of proposed options. > =20 > The tasks performed by the Directorate are: > =20 > 1. Review all documents submitted to the IESG for publication that have > DHCP options, messages, or processing requirements. A review is > triggered: > =20 > - By request for early review (by any AD or by any WG chair) > - By a document moving to 'publication requested' state > - By entry on the IESG agenda (for other documents) > =20 > 2. Assist ADs with judgment issues when requested - The ADs may send emai= l > to the directorate list when they have issues that they want help with= . > Examples for judgment issues are: > =20 > - New option formats. > - New client, relay, server agent processing. > =20 > 3. Try to follow IETF documents related to DHCP as early as possible and > provide guidance to authors as early as possible. > =20 > =20 > How is Document Review Organized? > =20 > 1. The DHCP Directorate Coordinator assigns each document that is > triggered for review to at least two (2) reviewers and issues a Review > Request. Authors and contributors to a document must not be assigned. > The Review Request will include the document and review deadline. > 2. The assigned reviewers must acknowledge and agree to review the > document within 72 hours and respond with a "can review by deadline" o= r > "can't review". No reply is interpreted as "can't review". > 3. If the Coordinator does not receive "can review by deadline" within 72 > hours, the Coordinator selects at least one or two additional reviewer= s. > This process is repeated until at least two reviewers are found. > 4. The reviewers provide comments as appropriate (IETF Last Call, Area > Director, document authors). > 5. The Coordinator may decide to call upon additional reviewers if > expected review is overdue or the topic under review is a complex one. > =20 > =20 > How is the Directorate Formed? > =20 > 1. Directorate members are assigned to the Directorate by the Internet > Area Directors. > 2. There is an expectation that Directorate membership will not be > limited to 'old-time DHCP gods from years past'. It is assumed that > the Directorate will include younger and newer participants who are > interested in 'learning while doing work'. > 3. Each assignment is for a three year term, unless the member or Interne= t > Area Director requests a shorter term. > 4. The terms are staggered so that approximately 1/3 of the directorate > members have their term end each year. > 5. When the Directorate is first established members of the Directorate > will be assigned either one year, two years, or three years in their > first term. > 6. When a member's term expires, the Internet ADs may replace the person > whose term expires, may reappoint the same person, or may reduce the > size of the Directorate. There is no expectation that the same person > will either want to be returned, or will be returned. > 7. The three year term serves as the limit of the commitment of a > Directorate member, but also serves as a way to return Directorate > members to the community. > 8. In deciding whether to reappoint a member whose term has expired, the > Internet ADs may consider the quantity of work that they have done, > the ADs' impression of the quality of the work, and the comments from > the authors and other Directorate members regarding the reviews. > 9. If a member resigns before the member's term expires, the Internet > Area Directors may appoint a replacement. > 10. The Internet Area Directors may remove a member before the member's > term expires, and may appoint a replacement. > 11. Internet ADs can assign additional members to the Directorate wheneve= r > they want to, subject to willingness of people to serve. > 12. Both ADs need to agree in order to assign a member to the Directorate= . > 13. Both ADs select one of the Directorate members as the DHCP Directorat= e > Coordinator on a yearly basis. > =20 > END > =20 > - Ted, Tomek, & Bernie > =20 > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg From volz@cisco.com Thu Jun 27 14:13:37 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 B7B6311E810A for ; Thu, 27 Jun 2013 14:13:37 -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 dhfeWlU38Iqn for ; Thu, 27 Jun 2013 14:13:32 -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 34A9111E80F2 for ; Thu, 27 Jun 2013 14:13:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7671; q=dns/txt; s=iport; t=1372367612; x=1373577212; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=PiWjDu+yzc3GG6EdLrqtstyFZG3PFjF/NMpfrYAmstQ=; b=dgspNxB6ov05nPqM8O6rncYSQBuBZilyi/OKW1/Ur8SkUotQQw789pk+ m96TNiCKpXS0p3MO2JN4+G44zk3UzaIyH/ke2DtJEbI3Qnl7yQKbco6xz cW5bS2yDZOF88vXiljgo29PbXM9kSRTETX8q3BAzo/1pmY2X+31UeuF6n k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah0FALKqzFGtJV2c/2dsb2JhbABbgwkxSb8MgQIWdIIjAQEBAQIBAQEBNzQLBQcEAgEIEQQBAQsUECcLHQgBAQQOBQgMh3QGDLs6jhOBETEHBoJ8YwOYbpAcgxGBcTc X-IronPort-AV: E=Sophos;i="4.87,954,1363132800"; d="scan'208";a="228362327" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-6.cisco.com with ESMTP; 27 Jun 2013 21:13:10 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id r5RLD9S7018631 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 27 Jun 2013 21:13:09 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.56]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.02.0318.004; Thu, 27 Jun 2013 16:13:08 -0500 From: "Bernie Volz (volz)" To: "Kim Kinnear (kkinnear)" Thread-Topic: [dhcwg] DHC WG Re-Charter Proposal Thread-Index: Ac5x3GsmHSL5mORtSN2Yp6/PNjm/rwBxTXyAAAo4YZA= Date: Thu, 27 Jun 2013 21:13:08 +0000 Message-ID: <489D13FBFA9B3E41812EA89F188F018E185C73CC@xmb-rcd-x04.cisco.com> References: <489D13FBFA9B3E41812EA89F188F018E185C32AD@xmb-rcd-x04.cisco.com> <17841E13-DE68-45F0-9282-AE696A137B30@cisco.com> In-Reply-To: <17841E13-DE68-45F0-9282-AE696A137B30@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.240.26] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dhcwg@ietf.org" , "Ted Lemon \(Ted.Lemon@nominum.com\)" Subject: Re: [dhcwg] DHC WG Re-Charter Proposal 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, 27 Jun 2013 21:13:37 -0000 Kim: If we instead leave it too open, it would be too easy to adopt work that is= either better handled by another WG or that should be worked through the D= HCP Directorate (perhaps as an individual submission). Nothing here says yo= u can't mention it on the DHC WG mailing list - it just wouldn't be a DHC W= G work item. I (and I think Tomek too) do agree with you that this is a potential concer= n because there are cases where new "simple" options may best be done by th= e WG. But also note that the WG CAN take on new work: Additional topics may only be added with approval from the responsible Area Director or by re-chartering. We can go to the AD(s) and say we'd like to work on option foo because ... = and if the arguments are reasonable, I don't think the AD(s) would say no. = I believe experience has shown that the AD(s) are reasonable (yes, I know .= .. past performance is not necessarily indicative of future performance). We'd like to try setting the bar a bit higher just now so it is easier to t= ell people to try elsewhere. Also, note that there are already two on the list that fall into the catego= ry of generally not being DHC WG items (under the "new" charter): - Address Network Identifier (draft-ietf-dhc-access-network-identifier) - New NTP option to replace OPTION_NTP_SERVER (RFC 5908) The first was added because there really wasn't another place to do this wo= rk within the IETF (we tried to move it away, but Ted felt we were best to = handle it). The second doesn't yet have a draft (on my plate when time perm= its unless someone else takes it on) and was in discussions with Ted becaus= e the current RFC is not something we want people to follow -- so it is a c= leanup. - Bernie -----Original Message----- From: Kim Kinnear (kkinnear)=20 Sent: Thursday, June 27, 2013 4:49 PM To: Bernie Volz (volz) Cc: Kim Kinnear (kkinnear); dhcwg@ietf.org; Ted Lemon (Ted.Lemon@nominum.co= m) Subject: Re: [dhcwg] DHC WG Re-Charter Proposal I have a major problem with this charter. As I read it, the DHC WG cannot = create drafts for new options the are not "protocol options". This is a *h= uge* change from the past. There is clearly a desire to disconnect the DHC WG from becoming involved i= n the options proposed by folks from other working groups. Thus, the DHCP = Directorate is the place where those options will be reviewed (according to= this charter). I can see why this is being done, and while I'm a bit unco= mfortable with it, I can understand some of the reasons for this change, an= d I can live with it. However, that is very different from the constraint in this charter that sa= ys that the DHC WG cannot create options that are not protocol options. Th= is places the DHC WG in a *more* restrictive position than other WGs -- *th= ey* can try to create options that are reviewed by the DHCP directorate. B= ut the DHC WG is explicitly chartered to create only protocol options. Period. I think this is wrong. When I raised this at the last IETF, I was told tha= t "consensus isn't necessary for charter approval". I understand, but the fact that I was told that my opinion really isn't int= eresting doesn't change my opinion. =20 I *still* think that this is a major mistake. I believe that the DHC WG should be able to take on the creation of DHCP op= tions if the WG chairs believe that it is a good idea. I would strongly recommend that we amend this charter to include this state= ment as the third paragraph: The DHC WG may, at the discretion of any of the chairs of the WG, be considered to be chartered to develop non-protocol DHCP options on a case by case basis. The normal consensus approach to adoption as a WG work item would be used in this case, but would require explicit WG chair approval that the non-protocol option fit within the charter of the working group. These options would undergo the same review as protocol extensions. Absent something like this, if you need a simple non-protocol option, you w= ill have to shop it around to some other working group to get it adopted. = Is this going to help the situation? Regards -- Kim On Jun 25, 2013, at 3:47 PM, Bernie Volz (volz) wrote: > Hello: > =20 > The text below is a proposed update of the DHC WG charter that the co-cha= irs developed with input and review from Ted Lemon (AD). It assumes a DHCP = Directorate is created as well (see separate email). Feedback on the charte= r text is appreciated and will also be discussed in Berlin as we hope to fi= nalize it shortly thereafter. > =20 > While the DHC re-charter and DHCP directorate are connected, we'd like to= try to separate the discussion (hence the directorate is in a separate ema= il). > =20 > The current charter, which is rather old, can be viewed at http://datatra= cker.ietf.org/wg/dhc/charter/. > =20 > Proposed DHC WG Charter: > =20 > The Dynamic Host Configuration working group (DHC WG) has developed > DHCP for automated allocation, configuration and management of IP > addresses and TCP/IP protocol stack parameters. DHCPv4 is currently > a Draft Standard and is documented in RFC 2131 and RFC 2132. DHCPv6 > is currently a Proposed Standard and is documented in RFC 3315. > Subsequent RFCs document additional options and other enhancements to > the specifications. > =20 > The DHC WG is responsible for defining DHCP protocol extensions. > Definitions of new DHCP options that are delivered using standard > mechanisms with documented semantics are not considered a protocol > extension and thus are outside of scope for DHC WG. Such options should > be defined within their respective WGs and reviewed by the DHCP > Directorate. However, if such options require protocol extensions or ne= w > semantics, the protocol extension work must be done in the DHC WG. > =20 > The DHC WG has the following main objectives: > =20 > * Develop extensions to the DHCPv6 infrastructure as required to meet > new applications and deployments of DHCP. The topics currently > in development are: > =20 > - DHCPv6 Failover, High Availability and Load Balancing > - DNS Update strategies for delegated prefixes (draft-ietf-dhc-dns-pd) > - Extend DHCPv6 to work with multiple provisioning domains > - DHCP provisioning of IPv4 clients over IPv6 networks > - SOLMAXRT counter update > - Container option > - Address Network Identifier (draft-ietf-dhc-access-network-identifier) > - New NTP option to replace OPTION_NTP_SERVER (RFC 5908) > - Prefix coloring (draft-bhandari-dhc-class-based-prefix) > =20 > Additional topics may only be added with approval from the responsibl= e > Area Director or by re-chartering. > =20 > * Specify guidelines for creating new DHCPv6 options. > =20 > * Develop documents that help explain operational considerations for > the wider community. > =20 > * Advance DHCPv6 (RFC 3315) along the IETF Standards Track. This will > include writing analyses, corrections, and clarifications of the DHCPv6 > specifications, including RFC 3315, RFC3633, RFC3736 and other RFCs > defining additional options, which identifies and resolves ambiguities, > contradictory specifications and other obstacles to development of > interoperable implementations. > =20 > END > =20 > - Tomek & Bernie > =20 > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg From volz@cisco.com Thu Jun 27 14:16: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 B190611E8106 for ; Thu, 27 Jun 2013 14:16:25 -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 iIBfj50mEnLX for ; Thu, 27 Jun 2013 14:16:20 -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 5792D11E80F2 for ; Thu, 27 Jun 2013 14:16:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=25076; q=dns/txt; s=iport; t=1372367780; x=1373577380; h=from:to:subject:date:message-id:mime-version; bh=MQuKtxF4l2dZtWzclWVQtI715UOqLWjnoOC/vCDBAgY=; b=PoHnLHr9BaN93OxBUfH9l1OTAknoErs5KQ+WfC7wMS/now9Mr5yNxH0O V5GUtnoZj2syLMKyovRUglkrUMvRZwVTknbcLr2v/O8lQaL5CPpXxm4ec /e+txfopAnMXxCg5vUJ0omVaRQaMrVSM5PrX/hJcsckcRQdS/lmh5wANX o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkIFAGWrzFGtJV2Z/2dsb2JhbABbgkVEMUm2UIg8gQIWdIIjAQEBAQMdEEEdAQgRBAEBCxYHORQJCQEEEwgBiAUMmwqgM44TgRE3gwNjA4hqkASQHIMRgXE3 X-IronPort-AV: E=Sophos;i="4.87,954,1363132800"; d="scan'208,217";a="225374460" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-9.cisco.com with ESMTP; 27 Jun 2013 21:16:19 +0000 Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r5RLGJ7q005471 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 27 Jun 2013 21:16:19 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.56]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.02.0318.004; Thu, 27 Jun 2013 16:16:19 -0500 From: "Bernie Volz (volz)" To: "dhcwg@ietf.org" Thread-Topic: Draft WG Agenda (for IETF-87, Berlin) - Session Schedule Thread-Index: Ac5ze3vilcL9puIFRH+RWqP1Z3rhHQ== Date: Thu, 27 Jun 2013 21:16:18 +0000 Message-ID: <489D13FBFA9B3E41812EA89F188F018E185C7402@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.240.26] Content-Type: multipart/alternative; boundary="_000_489D13FBFA9B3E41812EA89F188F018E185C7402xmbrcdx04ciscoc_" MIME-Version: 1.0 Subject: Re: [dhcwg] Draft WG Agenda (for IETF-87, Berlin) - Session Schedule 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, 27 Jun 2013 21:16:25 -0000 --_000_489D13FBFA9B3E41812EA89F188F018E185C7402xmbrcdx04ciscoc_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable FYI: The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request= . dhc Session 1 (2:30:00) Wednesday, Afternoon Session III 1620-1720 Room Name: Bellevue --------------------------------------------- dhc Session 2 (1:00:00) Thursday, Morning Session I 0900-1020 Room Name: Tiergarten 1/2 --------------------------------------------- Session 1 will be the DHC WG meeting. Session 2 will be the joint Sunset4/DHC WG meeting. It is always possible that these may be moved. - Bernie From: Bernie Volz (volz) Sent: Tuesday, June 25, 2013 10:18 PM To: dhcwg@ietf.org Cc: Dhc Chairs (dhc-chairs@tools.ietf.org) Subject: Draft WG Agenda (for IETF-87, Berlin) Here's the current list of items on the agenda for the Berlin IETF DHC WG m= eeting. If you sent a request and I missed it (or it was incomplete) or you= would like some time, please let the co-chairs know! (See below - earlier = email - for what's needed.) 0. Administrivia. Time 10 min 1. Co-Chairs & AD - DHC Re-Charter and DHCP Directorate. Time: 30 min 2. Tomek Mrugalski - DHCPv6 Options guidelines. Time: 10 min 3. Ralph Droms - draft-ietf-dhc-dhcpv6-solmaxrt-update. Time: 10 min [might= not be needed if WG last-call passed] 4. Ralph Droms - draft-ietf-dhc-container-opt. Time: 10 min 5. Bernie Volz - draft-ietf-dhc-stateful-issues. Time: 10 min 6. Qi Sun - draft-ietf-dhc-dhcpv4-over-dhcpv6. Time: 10 min 7. Qi Sun - draft-ietf-dhc-dhcpv6-unknown-msg. Time: 5 min 8. Ian Farrer - draft-ietf-dhc-v4configuration. Time: 10 min 9. Prashanth Patil - draft-wing-dhc-dns-reconfigure - Time: 10-15 min We'll also add some discussion time to "resolve" the v4-over-v6 issues. We don't yet know when this session will be and whether it will occur befor= e or after the joint Sunset4/DHC WG session; if after, we'll include a few = minutes for summary and follow up from that session. - Tomek & Bernie From: Bernie Volz (volz) Sent: Thursday, May 23, 2013 4:26 PM To: dhcwg@ietf.org Cc: Dhc Chairs (dhc-chairs@tools.ietf.org= ) Subject: IETF-87 (Berlin) Call for Agenda Items 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_489D13FBFA9B3E41812EA89F188F018E185C7402xmbrcdx04ciscoc_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

FYI:=

 

The session(s) that you have requested have been = scheduled.

Below is the scheduled session information follow= ed by the original request.

 

dhc Session 1 (2:30:00)

    Wednesday, Afternoon Sess= ion III 1620-1720

    Room Name: Bellevue=

    ------------------------------= ---------------

dhc Session 2 (1:00:00)

    Thursday, Morning Session I 09= 00-1020

    Room Name: Tiergarten 1/2=

    ------------------------------= ---------------

   

Session 1 will be the = DHC WG meeting.

 

Session 2 will be the = joint Sunset4/DHC WG meeting.

 

It is always possible = that these may be moved.

 

-&nb= sp;         Bernie

 

From: Bernie V= olz (volz)
Sent: Tuesday, June 25, 2013 10:18 PM
To: dhcwg@ietf.org
Cc: Dhc Chairs (dhc-chairs@tools.ietf.org)
Subject: Draft WG Agenda (for IETF-87, Berlin)

 

Here’s the curre= nt list of items on the agenda for the Berlin IETF DHC WG meeting. If you s= ent a request and I missed it (or it was incomplete) or you would like some= time, please let the co-chairs know! (See below – earlier email – for what’s needed.)

 

0. Administrivia. Time= 10 min

 

1. Co-Chairs & AD = - DHC Re-Charter and DHCP Directorate. Time: 30 min

 

2. Tomek Mrugalski - D= HCPv6 Options guidelines. Time: 10 min

 

3. Ralph Droms - draft= -ietf-dhc-dhcpv6-solmaxrt-update. Time: 10 min [might not be needed if WG l= ast-call passed]

 

4. Ralph Droms - draft= -ietf-dhc-container-opt. Time: 10 min

 

5. Bernie Volz - draft= -ietf-dhc-stateful-issues. Time: 10 min

 

6. Qi Sun - draft-ietf= -dhc-dhcpv4-over-dhcpv6. Time: 10 min

 

7. Qi Sun - draft-ietf= -dhc-dhcpv6-unknown-msg. Time: 5 min

 

8. Ian Farrer - draft-= ietf-dhc-v4configuration. Time: 10 min

 

9. Prashanth Patil - d= raft-wing-dhc-dns-reconfigure - Time: 10-15 min

 

We’ll also add s= ome discussion time to “resolve” the v4-over-v6 issues.

 

We don’t yet kno= w when this session will be and whether it will occur before or after the j= oint Sunset4/DHC WG session; if after, we’ll include a few minutes fo= r summary and follow up from that session.

 

-&nb= sp;         Tomek & Be= rnie

 

From: Bernie V= olz (volz)
Sent: Thursday, May 23, 2013 4:26 PM
To: dhcwg@ietf.org
Cc: Dhc Chairs (dhc-cha= irs@tools.ietf.org)
Subject: IETF-87 (Berlin) Call for Agenda Items

 

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_489D13FBFA9B3E41812EA89F188F018E185C7402xmbrcdx04ciscoc_-- From volz@cisco.com Thu Jun 27 14:59: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 43BE721F9BD5 for ; Thu, 27 Jun 2013 14:59:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.388 X-Spam-Level: X-Spam-Status: No, score=-9.388 tagged_above=-999 required=5 tests=[AWL=-1.210, BAYES_00=-2.599, EXTRA_MPART_TYPE=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, SARE_GIF_ATTACH=1.42] 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 Ga5MRzTTsh5Y for ; Thu, 27 Jun 2013 14:59:35 -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 CCF4821F9F26 for ; Thu, 27 Jun 2013 14:59:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=39230; q=dns/txt; s=iport; t=1372370375; x=1373579975; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=PQxcm5rH78C5Mis4rbYYbwTYBYpiBFAaCJefLZzAAn0=; b=D5o5qOvtZBQy7KW64sb/SYLBLTT3yPDyoWEqK6P0QHijwLdA7jrsGgCd J9jCyDU8cqC6c21s2wNSSVkqNb2UomFKOFU4HsO4mISMhUWBlGjuS52x4 73k4JdFaH7yX7RzYJjW5LD5HIzsvRZG29lMvO73osCDohbk1gDK2IlFbA U=; X-Files: image001.gif : 102 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkQFAG61zFGtJV2d/2dsb2JhbABbgkVEMUm2UIg8gQIWdIIjAQEBAQMFARcICAE2ChsCAQgRBAEBBgECAhYBBgcCBRABBQkMFAkIAQEEEgEGAgEFiAAMuzeOE4EICRYXCgGDAmMDiGqFAINHAYc8kByDEYFxNw X-IronPort-AV: E=Sophos;i="4.87,954,1363132800"; d="gif'147?scan'147,208,217,147";a="228337032" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-2.cisco.com with ESMTP; 27 Jun 2013 21:59:31 +0000 Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id r5RLxV5Z015362 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 27 Jun 2013 21:59:31 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.56]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.02.0318.004; Thu, 27 Jun 2013 16:59:31 -0500 From: "Bernie Volz (volz)" To: "dhcwg@ietf.org" Thread-Topic: Draft WG Agenda (for IETF-87, Berlin) - Session Schedule Thread-Index: Ac5ze3vilcL9puIFRH+RWqP1Z3rhHQABdI/g Date: Thu, 27 Jun 2013 21:59:30 +0000 Message-ID: <489D13FBFA9B3E41812EA89F188F018E185C75DC@xmb-rcd-x04.cisco.com> References: <489D13FBFA9B3E41812EA89F188F018E185C7402@xmb-rcd-x04.cisco.com> In-Reply-To: <489D13FBFA9B3E41812EA89F188F018E185C7402@xmb-rcd-x04.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.86.240.26] Content-Type: multipart/related; boundary="_004_489D13FBFA9B3E41812EA89F188F018E185C75DCxmbrcdx04ciscoc_"; type="multipart/alternative" MIME-Version: 1.0 Subject: Re: [dhcwg] Draft WG Agenda (for IETF-87, Berlin) - Session Schedule 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, 27 Jun 2013 21:59:40 -0000 --_004_489D13FBFA9B3E41812EA89F188F018E185C75DCxmbrcdx04ciscoc_ Content-Type: multipart/alternative; boundary="_000_489D13FBFA9B3E41812EA89F188F018E185C75DCxmbrcdx04ciscoc_" --_000_489D13FBFA9B3E41812EA89F188F018E185C75DCxmbrcdx04ciscoc_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Ignore that earlier information as it seems to be INCORRECT (I just looked= at the Request Times which aren't the real assigned times): The draft agenda (https://datatracker.ietf.org/meeting/87/agenda.html) has: 1620-1720 CEST Wednesday Afternoon Session III Bellevue INT sunset4 [https://datatracker.ietf.org/images/color-palette-4x4.gif] Sunsetting IPv4 Joint Session with DHC 0900-1020 CEST Thursday Morning Session I Tiergarten 1/2 INT dhc [https://datatracker.ietf.org/images/color-palette-4x4.gif] Dynamic Host Co= nfiguration 1030-1130 CEST Thursday Morning Session II Tiergarten 1/2 INT dhc [https://datatracker.ietf.org/images/color-palette-4x4.gif] Dynamic Host Co= nfiguration - Bernie From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of B= ernie Volz (volz) Sent: Thursday, June 27, 2013 5:16 PM To: dhcwg@ietf.org Subject: Re: [dhcwg] Draft WG Agenda (for IETF-87, Berlin) - Session Schedu= le FYI: The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request= . dhc Session 1 (2:30:00) Wednesday, Afternoon Session III 1620-1720 Room Name: Bellevue --------------------------------------------- dhc Session 2 (1:00:00) Thursday, Morning Session I 0900-1020 Room Name: Tiergarten 1/2 --------------------------------------------- Session 1 will be the DHC WG meeting. Session 2 will be the joint Sunset4/DHC WG meeting. It is always possible that these may be moved. - Bernie From: Bernie Volz (volz) Sent: Tuesday, June 25, 2013 10:18 PM To: dhcwg@ietf.org Cc: Dhc Chairs (dhc-chairs@tools.ietf.org) Subject: Draft WG Agenda (for IETF-87, Berlin) Here's the current list of items on the agenda for the Berlin IETF DHC WG m= eeting. If you sent a request and I missed it (or it was incomplete) or you= would like some time, please let the co-chairs know! (See below - earlier = email - for what's needed.) 0. Administrivia. Time 10 min 1. Co-Chairs & AD - DHC Re-Charter and DHCP Directorate. Time: 30 min 2. Tomek Mrugalski - DHCPv6 Options guidelines. Time: 10 min 3. Ralph Droms - draft-ietf-dhc-dhcpv6-solmaxrt-update. Time: 10 min [might= not be needed if WG last-call passed] 4. Ralph Droms - draft-ietf-dhc-container-opt. Time: 10 min 5. Bernie Volz - draft-ietf-dhc-stateful-issues. Time: 10 min 6. Qi Sun - draft-ietf-dhc-dhcpv4-over-dhcpv6. Time: 10 min 7. Qi Sun - draft-ietf-dhc-dhcpv6-unknown-msg. Time: 5 min 8. Ian Farrer - draft-ietf-dhc-v4configuration. Time: 10 min 9. Prashanth Patil - draft-wing-dhc-dns-reconfigure - Time: 10-15 min We'll also add some discussion time to "resolve" the v4-over-v6 issues. We don't yet know when this session will be and whether it will occur befor= e or after the joint Sunset4/DHC WG session; if after, we'll include a few = minutes for summary and follow up from that session. - Tomek & Bernie From: Bernie Volz (volz) Sent: Thursday, May 23, 2013 4:26 PM To: dhcwg@ietf.org Cc: Dhc Chairs (dhc-chairs@tools.ietf.org= ) Subject: IETF-87 (Berlin) Call for Agenda Items 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_489D13FBFA9B3E41812EA89F188F018E185C75DCxmbrcdx04ciscoc_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Ignore that earlier &n= bsp;information as it seems to be INCORRECT (I just looked at the Request T= imes which aren’t the real assigned times):

 

The draft agenda (https://= datatracker.ietf.org/meeting/87/agenda.html) has:

 

1620-1720 CEST<= span style=3D"font-size:10.0pt;font-family:"Arial","sans-ser= if";color:maroon">

Wednesday Afternoon Session III

= Bellevue=

= INT

= sunset4<= /a>

= 3D"https://datatracker.ietf.org/ima= Sunsetting IPv4 
Joint Session with DHC

 

0900-1020 CEST<= span style=3D"font-size:10.0pt;font-family:"Arial","sans-ser= if";color:maroon">

Thursday Morning Session I

= Tie= rgarten 1/2

= INT

= dhc=

= 3D"https://datatracker.ietf.org/ima= Dynamic Host Configuration

1030-1130 CEST<= span style=3D"font-size:10.0pt;font-family:"Arial","sans-ser= if";color:maroon">

Thursday Morning Session II

= Tie= rgarten 1/2

= INT

= dhc=

= 3D"https://datatracker.ietf.org/ima= Dynamic Host Configuration

 

-&nb= sp;         Bernie

 

From: dhcwg-bo= unces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of Bernie Volz (volz)
Sent: Thursday, June 27, 2013 5:16 PM
To: dhcwg@ietf.org
Subject: Re: [dhcwg] Draft WG Agenda (for IETF-87, Berlin) - Session= Schedule

 

FYI:=

 

The session(s) that you have requested have been = scheduled.

Below is the scheduled session information follow= ed by the original request.

 

dhc Session 1 (2:30:00)

    Wednesday, Afternoon Sess= ion III 1620-1720

    Room Name: Bellevue=

    ------------------------------= ---------------

dhc Session 2 (1:00:00)

    Thursday, Morning Session I 09= 00-1020

    Room Name: Tiergarten 1/2=

    ------------------------------= ---------------

   

Session 1 will be the = DHC WG meeting.

 

Session 2 will be the = joint Sunset4/DHC WG meeting.

 

It is always possible = that these may be moved.

 

-     &= nbsp;    Bernie

 

From: Bernie V= olz (volz)
Sent: Tuesday, June 25, 2013 10:18 PM
To: dhcwg@ietf.org
Cc: Dhc Chairs (dhc-chairs@tools.ietf.org)
Subject: Draft WG Agenda (for IETF-87, Berlin)

 

Here’s the curre= nt list of items on the agenda for the Berlin IETF DHC WG meeting. If you s= ent a request and I missed it (or it was incomplete) or you would like some= time, please let the co-chairs know! (See below – earlier email – for what’s needed.)<= /o:p>

 

0. Administrivia. Time= 10 min

 

1. Co-Chairs & AD = - DHC Re-Charter and DHCP Directorate. Time: 30 min

 

2. Tomek Mrugalski - D= HCPv6 Options guidelines. Time: 10 min

 

3. Ralph Droms - draft= -ietf-dhc-dhcpv6-solmaxrt-update. Time: 10 min [might not be needed if WG l= ast-call passed]

 

4. Ralph Droms - draft= -ietf-dhc-container-opt. Time: 10 min

 

5. Bernie Volz - draft= -ietf-dhc-stateful-issues. Time: 10 min

 

6. Qi Sun - draft-ietf= -dhc-dhcpv4-over-dhcpv6. Time: 10 min

 

7. Qi Sun - draft-ietf= -dhc-dhcpv6-unknown-msg. Time: 5 min

 

8. Ian Farrer - draft-= ietf-dhc-v4configuration. Time: 10 min

 

9. Prashanth Patil - d= raft-wing-dhc-dns-reconfigure - Time: 10-15 min

 

We’ll also add s= ome discussion time to “resolve” the v4-over-v6 issues.<= o:p>

 

We don’t yet kno= w when this session will be and whether it will occur before or after the j= oint Sunset4/DHC WG session; if after, we’ll include a few minutes fo= r summary and follow up from that session.

 

-     &= nbsp;    Tomek & Bernie

 

From: Bernie V= olz (volz)
Sent: Thursday, May 23, 2013 4:26 PM
To: dhcwg@ietf.org
Cc: Dhc Chairs (dhc-cha= irs@tools.ietf.org)
Subject: IETF-87 (Berlin) Call for Agenda Items

 

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_489D13FBFA9B3E41812EA89F188F018E185C75DCxmbrcdx04ciscoc_-- --_004_489D13FBFA9B3E41812EA89F188F018E185C75DCxmbrcdx04ciscoc_ Content-Type: image/gif; name="image001.gif" Content-Description: image001.gif Content-Disposition: inline; filename="image001.gif"; size=102; creation-date="Thu, 27 Jun 2013 21:59:29 GMT"; modification-date="Thu, 27 Jun 2013 21:59:29 GMT" Content-ID: Content-Transfer-Encoding: base64 R0lGODlhEAAQAMIDAAAA//8AAP//AP///6CgoP///////////yH5BAEKAAcALAAAAAAQABAAAAMr eLrc/jA6Qmm4d1aCc9tcp1VdMFpiA6yr4LoO275CLNO1etM2i0vAoLCRAAA7 --_004_489D13FBFA9B3E41812EA89F188F018E185C75DCxmbrcdx04ciscoc_-- From Ted.Lemon@nominum.com Thu Jun 27 18:00:54 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 A274F11E811F for ; Thu, 27 Jun 2013 18:00:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.049 X-Spam-Level: X-Spam-Status: No, score=-106.049 tagged_above=-999 required=5 tests=[AWL=0.550, 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 BhPgbksYWkob for ; Thu, 27 Jun 2013 18:00:48 -0700 (PDT) Received: from exprod7og126.obsmtp.com (exprod7og126.obsmtp.com [64.18.2.206]) by ietfa.amsl.com (Postfix) with ESMTP id D9D7411E8111 for ; Thu, 27 Jun 2013 18:00:47 -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 DSNKUczgP8y+vyd250zm54bJ32PGiudag0VV@postini.com; Thu, 27 Jun 2013 18:00:47 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 734A11B81D0 for ; Thu, 27 Jun 2013 18:00:47 -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 6AF1D19005D; Thu, 27 Jun 2013 18:00:47 -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, 27 Jun 2013 18:00:47 -0700 From: Ted Lemon To: Kim Kinnear Thread-Topic: [dhcwg] DHCP Directorate Proposal Thread-Index: Ac5x3HNmjTU+PkrUQRe5be06SLqzEAB05ASAAAllMgA= Date: Fri, 28 Jun 2013 01:00:46 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B6307751EFD70@mbx-01.win.nominum.com> References: <489D13FBFA9B3E41812EA89F188F018E185C32B5@xmb-rcd-x04.cisco.com> <0424945D-DD09-44AE-9F00-2364C3C1E3D5@cisco.com> In-Reply-To: <0424945D-DD09-44AE-9F00-2364C3C1E3D5@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: <606A86590F241A4D9CFD70B4B170D586@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dhcwg@ietf.org" , "Bernie Volz \(volz\)" Subject: Re: [dhcwg] DHCP Directorate Proposal 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, 28 Jun 2013 01:00:54 -0000 On Jun 27, 2013, at 4:31 PM, Kim Kinnear wrote: > I would have thought that the DHC WG Chairs would have some role > in the selection of individuals for the directorate and the > reappointment, etc. of these individuals. >=20 > I don't know, perhaps it just "isn't done that way" with the > other directorates, or perhaps the politics of AD/WG Chair > interactions means that AD's don't *want* any official role for > the WG chairs when selecting folks for the directorate. Directorates are not associated with working groups, so although the DHC wo= rking group chairs are (a) quite likely to be asked to be members of the di= rectorate and (b) would certainly be consulted, the directorate sits under = the AD in the hierarchy, not under the working group, hence the formal stru= cture. > I'm not up to speed on all of the subtleties of the interactions > in the more rarefied levels of the IETF. But as a long time > person in the trenches, it seems like the fact that the DHC WG > Chairs are not mentioned at all in this document (except > regarding a request for early review of a document) indicates a > stratification of control that has an odd feel to me. >=20 > I would have expected that the DHC WG chairs would play a major > role in selecting folks for the DHCP Directorate. You would be right. :) From Ted.Lemon@nominum.com Thu Jun 27 18:25:27 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 16A8F21F9C63 for ; Thu, 27 Jun 2013 18:25:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.128 X-Spam-Level: X-Spam-Status: No, score=-106.128 tagged_above=-999 required=5 tests=[AWL=0.471, 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 V-p5e7MPovuo for ; Thu, 27 Jun 2013 18:25:20 -0700 (PDT) Received: from exprod7og116.obsmtp.com (exprod7og116.obsmtp.com [64.18.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 32C5421F9DCA for ; Thu, 27 Jun 2013 18:25:20 -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 DSNKUczl/zCdpFKiLxlyRD3C/EkLbNHz4JD4@postini.com; Thu, 27 Jun 2013 18:25:20 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 A69BA1B81B0 for ; Thu, 27 Jun 2013 18:25:19 -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 6D93519005D; Thu, 27 Jun 2013 18:25:19 -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; Thu, 27 Jun 2013 18:25:13 -0700 From: Ted Lemon To: Kim Kinnear Thread-Topic: [dhcwg] DHC WG Re-Charter Proposal Thread-Index: Ac5x3GsmHSL5mORtSN2Yp6/PNjm/rwB1fl6AAAmnXAA= Date: Fri, 28 Jun 2013 01:25:13 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B6307751EFF1B@mbx-01.win.nominum.com> References: <489D13FBFA9B3E41812EA89F188F018E185C32AD@xmb-rcd-x04.cisco.com> <17841E13-DE68-45F0-9282-AE696A137B30@cisco.com> In-Reply-To: <17841E13-DE68-45F0-9282-AE696A137B30@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: <41BCFD3274FB7847867BE540C8E442FA@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dhcwg@ietf.org" , "Bernie Volz \(volz\)" Subject: Re: [dhcwg] DHC WG Re-Charter Proposal 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, 28 Jun 2013 01:25:27 -0000 I won't reiterate what Bernie said, which was correct, but a few points of = my own: On Jun 27, 2013, at 4:48 PM, Kim Kinnear wrote: > I have a major problem with this charter. As I read it, the DHC > WG cannot create drafts for new options the are not "protocol > options". This is a *huge* change from the past. Bernie covered this; let me know if you don't buy his answer. > However, that is very different from the constraint in this > charter that says that the DHC WG cannot create options that are > not protocol options. This places the DHC WG in a *more* > restrictive position than other WGs -- *they* can try to create > options that are reviewed by the DHCP directorate. But the DHC > WG is explicitly chartered to create only protocol options. > Period. This is actually incorrect. Random working groups can't just go off and d= o DHCP options. The work has to appear in their charter. The point of t= his is to raise the visibility of such proposals to the level of the IESG, = so that we can avoid having working groups go off and extend DHCP without e= ver talking to us. Part of what I hope to do to raise awareness of this a= t the IESG level is the text I asked the authors of the option guidelines d= raft to add to the document on the topic of chartering working groups to ad= d options. I don't see that in the current version of the document, but I= 'm hoping the authors will add that text, because it would make clear to yo= u what we are trying to do. > When I raised this at the last IETF, I > was told that "consensus isn't necessary for charter approval". What was said was that consensus does not require that everybody agree. C= onsensus _is_ required in order to propose a new charter, but that's not th= e whole story (see below). > I understand, but the fact that I was told that my opinion really > isn't interesting doesn't change my opinion. =20 Your opinion is certainly interesting. The question is whether it can be = accommodated. I _hope_ that what's been clarified here makes this change = more palatable to you, but please be assured that if it still isn't palatab= le to you, this is not a desired outcome, nor one that anyone will feel ple= asantly comfortable with. > I *still* think that this is a major mistake. >=20 > I believe that the DHC WG should be able to take on the creation > of DHCP options if the WG chairs believe that it is a good idea. >=20 > I would strongly recommend that we amend this charter to include > this statement as the third paragraph: >=20 > The DHC WG may, at the discretion of any of the chairs of the > WG, be considered to be chartered to develop non-protocol DHCP > options on a case by case basis. The normal consensus approach > to adoption as a WG work item would be used in this case, but > would require explicit WG chair approval that the non-protocol > option fit within the charter of the working group. These > options would undergo the same review as protocol extensions. >=20 > Absent something like this, if you need a simple non-protocol > option, you will have to shop it around to some other working > group to get it adopted. Is this going to help the situation? The above text is specifically what the IESG would like taken out of the ch= arter. As Bernie said, the working group can take on a new work item eith= er by agreement with the AD, or by adding that work to the charter. Which= path to take really depends on what work is proposed=97if you want to add = a new option to configure impress servers, that probably doesn't merit a re= charter, but if you want to add a new option to carry SDP configuration inf= ormation, that probably does. The effect that this has is that if someone comes to the chairs and says "w= e want to do a new DHCP option in the DHC working group that effectively mo= difies the IPv6 routing architecture," there are now three levels of notice= that can occur before the working group starts working on something it pro= bably shouldn't. First, the chairs might notice, and either say no themse= lves, or ask their AD to say no, so that they don't have to be the bad guys= . Second, if they don't notice the problem, the responsible AD might noti= ce, and again say "no, sorry, that's not a good idea." Third, if a charte= r change is done, other ADs on the IESG will likely notice the conflict, si= nce it impacts their area. So the point of this is to get cross-area recognition of new, potentially c= onflicting work _before_ the working group spends a year working on the doc= ument and sends it up to the IESG. At the moment, the IESG does not like the DHC working group charter, becaus= e the way it's written, it's got a wildcard in it that's big enough to driv= e a truck through, and trucks have been driven through it in the past, some= times with painful consequences. This change is not intended to prevent t= he DHC working group ever working on new options. The purpose of the chan= ge is very specifically to close this loophole. The IESG has some limited influence in making this sort of thing happen, be= cause working groups work for area directors, and consequently for the IESG= . If the IESG is not happy with the charter of a working group, they can'= t make the working group recharter if the working group doesn't want to, bu= t they do have the ultimate nuclear option, which is to simply shut down th= e working group. This doesn't happen very often, but it has been done. Needless to say, this is not a desirable outcome, so this is my motivation = for working with the chairs to try to close this loophole. Certainly nobo= dy on the IESG has proposed shutting down the working group, perhaps due to= the beam-in-the-eye principle, but these sorts of cleanups are something t= he IESG as a whole is keen on right now, and that's where this push is comi= ng from. From Ted.Lemon@nominum.com Thu Jun 27 18:26: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 82A3B21F9C63 for ; Thu, 27 Jun 2013 18:26:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.187 X-Spam-Level: X-Spam-Status: No, score=-106.187 tagged_above=-999 required=5 tests=[AWL=0.412, 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 6ereODZZUzee for ; Thu, 27 Jun 2013 18:26:02 -0700 (PDT) Received: from exprod7og107.obsmtp.com (exprod7og107.obsmtp.com [64.18.2.167]) by ietfa.amsl.com (Postfix) with ESMTP id 9C67A11E8147 for ; Thu, 27 Jun 2013 18:25:57 -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 DSNKUczmJQbbFBpOfUkziZRLuG/i/sjt+K1S@postini.com; Thu, 27 Jun 2013 18:25: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 54D1F1B81AC for ; Thu, 27 Jun 2013 18:25:57 -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 4E48619005D; Thu, 27 Jun 2013 18:25:57 -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, 27 Jun 2013 18:25:57 -0700 From: Ted Lemon To: "Bernie Volz (volz)" Thread-Topic: [dhcwg] Draft WG Agenda (for IETF-87, Berlin) - Session Schedule Thread-Index: Ac5ze3vilcL9puIFRH+RWqP1Z3rhHQABdI/gABXzigA= Date: Fri, 28 Jun 2013 01:25:56 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B6307751EFF49@mbx-01.win.nominum.com> References: <489D13FBFA9B3E41812EA89F188F018E185C7402@xmb-rcd-x04.cisco.com> <489D13FBFA9B3E41812EA89F188F018E185C75DC@xmb-rcd-x04.cisco.com> In-Reply-To: <489D13FBFA9B3E41812EA89F188F018E185C75DC@xmb-rcd-x04.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" Subject: Re: [dhcwg] Draft WG Agenda (for IETF-87, Berlin) - Session Schedule 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, 28 Jun 2013 01:26:09 -0000 On Jun 27, 2013, at 5:59 PM, Bernie Volz (volz) wrote: > Ignore that earlier information as it seems to be INCORRECT (I just look= ed at the Request Times which aren=92t the real assigned times): New tool. Teething pains. :} From lear@cisco.com Fri Jun 28 01:24: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 5E21F21F9D65 for ; Fri, 28 Jun 2013 01:24:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.999 X-Spam-Level: X-Spam-Status: No, score=-107.999 tagged_above=-999 required=5 tests=[AWL=0.001, RCVD_IN_DNSWL_HI=-8, 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 ooTZ+reBd1OE for ; Fri, 28 Jun 2013 01:23:50 -0700 (PDT) Received: from ams-iport-4.cisco.com (ams-iport-4.cisco.com [144.254.224.147]) by ietfa.amsl.com (Postfix) with ESMTP id 7D28321F841E for ; Fri, 28 Jun 2013 01:23:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1188; q=dns/txt; s=iport; t=1372407800; x=1373617400; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=MSnS1z26IVvgXLWurMWaH8js92NBzlpaHxKcUcxcn1k=; b=Jat7hcsOPR8f2TTFVS4TlH5fZRbIHP01LfYbmqXk83/cMWIqoPf0Abee 3dqXH2OtJ9qSMJclV1SOPOm6Aky3H5IaB+N97gSnVP7JZdkN4vuiuiKZ1 Q7hF3Z1WSZi8V5JpGt1WIziN77JnKXcgcL/z5P/EcMN1CexQoAMRFSiwr o=; X-IronPort-AV: E=Sophos;i="4.87,957,1363132800"; d="scan'208";a="15061118" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-4.cisco.com with ESMTP; 28 Jun 2013 08:23:13 +0000 Received: from mctiny.local ([10.61.208.196]) by ams-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r5S8NBuP012594 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 28 Jun 2013 08:23:11 GMT Message-ID: <51CD47EF.6010001@cisco.com> Date: Fri, 28 Jun 2013 10:23:11 +0200 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Ted Lemon References: <489D13FBFA9B3E41812EA89F188F018E185C32AD@xmb-rcd-x04.cisco.com> <17841E13-DE68-45F0-9282-AE696A137B30@cisco.com> <8D23D4052ABE7A4490E77B1A012B6307751EFF1B@mbx-01.win.nominum.com> In-Reply-To: <8D23D4052ABE7A4490E77B1A012B6307751EFF1B@mbx-01.win.nominum.com> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "dhcwg@ietf.org" , "Bernie Volz \(volz\)" , Kim Kinnear Subject: Re: [dhcwg] DHC WG Re-Charter Proposal 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, 28 Jun 2013 08:24:05 -0000 Two points: On 6/28/13 3:25 AM, Ted Lemon wrote: > This is actually incorrect. Random working groups can't just go off > and do DHCP options. The work has to appear in their charter. It is possible to hide a DHCP option in a draft without actually mentioning it in the charter, if the option is in support of whatever additional functionality is being offered. Also, as I read the changes and the intent in your message, Ted, this will have the effect of slowing down new options work. Maybe that's a good thing, but it will happen because right now it's a matter of a call for adoption for a WG draft and then off we go. With the charter change you'd need to first either gain approval of the AD or of the IESG for a charter change, and then proceed to adoption. Moreover, right now all expertise for DHCP has a well known rendezvous point that has authority. Directorates have shown themselves to be a mixed bag. One clear result is that it will shift load to the IESG, because IESG members (probably you) will have to review the output of the directorate. In short I see this as a tradeoff between managing overlap and these other issues. Eliot From alper.yegin@yegin.org Fri Jun 28 02:35:03 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 276BE21F9D79 for ; Fri, 28 Jun 2013 02:35:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.109 X-Spam-Level: X-Spam-Status: No, score=-101.109 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, HTML_MESSAGE=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 rFN28Z+GEoId for ; Fri, 28 Jun 2013 02:34:51 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by ietfa.amsl.com (Postfix) with ESMTP id 0223921F99A9 for ; Fri, 28 Jun 2013 02:34:34 -0700 (PDT) Received: from [192.168.2.49] (88.247.135.202.static.ttnet.com.tr [88.247.135.202]) by mrelay.perfora.net (node=mrus0) with ESMTP (Nemesis) id 0LlD8Y-1UItbY0TbS-00b5et; Fri, 28 Jun 2013 05:34:31 -0400 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_58B1F4CE-F5AE-44C5-AAF5-30FCA8572DAD" From: Alper Yegin In-Reply-To: <489D13FBFA9B3E41812EA89F188F018E185C32AD@xmb-rcd-x04.cisco.com> Date: Fri, 28 Jun 2013 12:34:24 +0300 Message-Id: <2CA013F3-32BC-410F-A4A4-9C908BC12C56@yegin.org> References: <489D13FBFA9B3E41812EA89F188F018E185C32AD@xmb-rcd-x04.cisco.com> To: "Bernie Volz (volz)" X-Mailer: Apple Mail (2.1283) X-Provags-ID: V02:K0:2nlPudr0DDxq7EguTvcCNmE4i8+BVWx1W/w8i/Hh7yn HgT5UZPSJg1Xiqukfj7vIlK3ghjjqxiu5h32zDnd6Y2dmR5BYa lFcYAiVM/CM6TegiQ1nm6sNnjSFqrtEgpPPQYVtM32uMoYSewz qSdiZPA4naZw9X/ryHNr38ZYuEa4XpEWweqB67+eNeRBN+2Yj7 Xaj+lpCCADLv5d0I0d4wpcQBwG0Pg+RZzTJQ3/sGW2K+svXDLs 2FgmUI5fA9O+bKMvcL8gYyqC0k5XYz6cFBnYwv3NmsYp20U3S4 L3VYm/mLbqxuC+Fs18NNEHIGmJfLjlt0Cjn+TaxpG+hSprHdZe RU3a71AFsdvGq26yflohbHUdWU7trToSqSPhoI7nTOiYThMsVM CB0A8/uh8vdCA== Cc: "dhcwg@ietf.org" , "Ted Lemon \(Ted.Lemon@nominum.com\)" Subject: Re: [dhcwg] DHC WG Re-Charter Proposal 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, 28 Jun 2013 09:35:03 -0000 --Apple-Mail=_58B1F4CE-F5AE-44C5-AAF5-30FCA8572DAD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > - DHCP provisioning of IPv4 clients over IPv6 networks >=20 I think we better stick with the "configuration/configuring" term = instead of introducing the "provisioning" term. --Apple-Mail=_58B1F4CE-F5AE-44C5-AAF5-30FCA8572DAD Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
  - DHCP provisioning of IPv4 clients over IPv6 = networks


I think = we better stick with the "configuration/configuring" term instead of = introducing the "provisioning" = term.


= --Apple-Mail=_58B1F4CE-F5AE-44C5-AAF5-30FCA8572DAD-- From volz@cisco.com Fri Jun 28 07:50: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 8995621F9B38 for ; Fri, 28 Jun 2013 07:50:28 -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 NRPVGprVMDQz for ; Fri, 28 Jun 2013 07:50:23 -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 058DC21F91B4 for ; Fri, 28 Jun 2013 07:50:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7008; q=dns/txt; s=iport; t=1372431023; x=1373640623; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=grcTD9ADqJheW17AytoN3OHFj0L59p0dGMHaO0DIp6g=; b=dyYKM7O31wSJq8S70L2iTpXRymd64IFh9IUiHXO/E2FDV+JPp939RtZl ef0Yb2s9alcm0Ik8QoUnfbwPDQsZz+USEFHSHYR9l3JZOxOtx9bs9gXTI 01DbrrqCUk9FnSVxVkDdZfhJzhMAKnWCbmx0LyrQeCuCEaeqtx1Uvyv7Y 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUFAD2izVGtJXHA/2dsb2JhbABbgwkxSb8JgQgWdIIjAQEBAwE6PwUHBAIBCBEBAwEBAQoUCQcyFAMGCAEBBAENBQiIAAYMu24Ejh2BBzEHBoJ8YwOTc5UXgxGBaEA X-IronPort-AV: E=Sophos;i="4.87,958,1363132800"; d="scan'208";a="228607412" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-2.cisco.com with ESMTP; 28 Jun 2013 14:50:17 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id r5SEoHvv028565 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 28 Jun 2013 14:50:17 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.56]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.02.0318.004; Fri, 28 Jun 2013 09:50:17 -0500 From: "Bernie Volz (volz)" To: Ted Lemon , "Kim Kinnear (kkinnear)" Thread-Topic: [dhcwg] DHC WG Re-Charter Proposal Thread-Index: Ac5x3GsmHSL5mORtSN2Yp6/PNjm/rwB1fl6AAAmnXAAADScHkA== Date: Fri, 28 Jun 2013 14:50:16 +0000 Message-ID: <489D13FBFA9B3E41812EA89F188F018E185C9939@xmb-rcd-x04.cisco.com> References: <489D13FBFA9B3E41812EA89F188F018E185C32AD@xmb-rcd-x04.cisco.com> <17841E13-DE68-45F0-9282-AE696A137B30@cisco.com> <8D23D4052ABE7A4490E77B1A012B6307751EFF1B@mbx-01.win.nominum.com> In-Reply-To: <8D23D4052ABE7A4490E77B1A012B6307751EFF1B@mbx-01.win.nominum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.240.26] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dhcwg@ietf.org" Subject: Re: [dhcwg] DHC WG Re-Charter Proposal 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, 28 Jun 2013 14:50:28 -0000 Kim: You might take a look at the 6man charter as an example (https://datatracke= r.ietf.org/wg/6man/charter/), part of which is below: The working group's work items are as follows: o Complete work on RA Flags Option o Complete work on RH0 Deprecation o Complete work on IPv6 over PPP Compression Negotiation o Complete work on Centrally Allocated Unique Local Addresses (ULA-C) All new work items not listed above require the approval of the working group and the sponsoring Area Director before they will be taken on by the working group. The DHC wg has apparently had a very loose leash. Ted is just trying to get= us to the IETF 'norm'. - Bernie -----Original Message----- From: Ted Lemon [mailto:Ted.Lemon@nominum.com]=20 Sent: Thursday, June 27, 2013 9:25 PM To: Kim Kinnear (kkinnear) Cc: Bernie Volz (volz); dhcwg@ietf.org Subject: Re: [dhcwg] DHC WG Re-Charter Proposal I won't reiterate what Bernie said, which was correct, but a few points of = my own: On Jun 27, 2013, at 4:48 PM, Kim Kinnear wrote: > I have a major problem with this charter. As I read it, the DHC WG=20 > cannot create drafts for new options the are not "protocol options". =20 > This is a *huge* change from the past. Bernie covered this; let me know if you don't buy his answer. > However, that is very different from the constraint in this charter=20 > that says that the DHC WG cannot create options that are not protocol=20 > options. This places the DHC WG in a *more* restrictive position than=20 > other WGs -- *they* can try to create options that are reviewed by the=20 > DHCP directorate. But the DHC WG is explicitly chartered to create=20 > only protocol options. > Period. This is actually incorrect. Random working groups can't just go off and d= o DHCP options. The work has to appear in their charter. The point of t= his is to raise the visibility of such proposals to the level of the IESG, = so that we can avoid having working groups go off and extend DHCP without e= ver talking to us. Part of what I hope to do to raise awareness of this a= t the IESG level is the text I asked the authors of the option guidelines d= raft to add to the document on the topic of chartering working groups to ad= d options. I don't see that in the current version of the document, but I= 'm hoping the authors will add that text, because it would make clear to yo= u what we are trying to do. > When I raised this at the last IETF, I was told that "consensus isn't=20 > necessary for charter approval". What was said was that consensus does not require that everybody agree. C= onsensus _is_ required in order to propose a new charter, but that's not th= e whole story (see below). > I understand, but the fact that I was told that my opinion really=20 > isn't interesting doesn't change my opinion. Your opinion is certainly interesting. The question is whether it can be = accommodated. I _hope_ that what's been clarified here makes this change = more palatable to you, but please be assured that if it still isn't palatab= le to you, this is not a desired outcome, nor one that anyone will feel ple= asantly comfortable with. > I *still* think that this is a major mistake. >=20 > I believe that the DHC WG should be able to take on the creation of=20 > DHCP options if the WG chairs believe that it is a good idea. >=20 > I would strongly recommend that we amend this charter to include this=20 > statement as the third paragraph: >=20 > The DHC WG may, at the discretion of any of the chairs of the WG, be=20 > considered to be chartered to develop non-protocol DHCP options on a=20 > case by case basis. The normal consensus approach to adoption as a=20 > WG work item would be used in this case, but would require explicit=20 > WG chair approval that the non-protocol option fit within the charter=20 > of the working group. These options would undergo the same review as=20 > protocol extensions. >=20 > Absent something like this, if you need a simple non-protocol option,=20 > you will have to shop it around to some other working group to get it=20 > adopted. Is this going to help the situation? The above text is specifically what the IESG would like taken out of the ch= arter. As Bernie said, the working group can take on a new work item eith= er by agreement with the AD, or by adding that work to the charter. Which= path to take really depends on what work is proposed-if you want to add a = new option to configure impress servers, that probably doesn't merit a rech= arter, but if you want to add a new option to carry SDP configuration infor= mation, that probably does. The effect that this has is that if someone comes to the chairs and says "w= e want to do a new DHCP option in the DHC working group that effectively mo= difies the IPv6 routing architecture," there are now three levels of notice= that can occur before the working group starts working on something it pro= bably shouldn't. First, the chairs might notice, and either say no themse= lves, or ask their AD to say no, so that they don't have to be the bad guys= . Second, if they don't notice the problem, the responsible AD might noti= ce, and again say "no, sorry, that's not a good idea." Third, if a charte= r change is done, other ADs on the IESG will likely notice the conflict, si= nce it impacts their area. So the point of this is to get cross-area recognition of new, potentially c= onflicting work _before_ the working group spends a year working on the doc= ument and sends it up to the IESG. At the moment, the IESG does not like the DHC working group charter, becaus= e the way it's written, it's got a wildcard in it that's big enough to driv= e a truck through, and trucks have been driven through it in the past, some= times with painful consequences. This change is not intended to prevent t= he DHC working group ever working on new options. The purpose of the chan= ge is very specifically to close this loophole. The IESG has some limited influence in making this sort of thing happen, be= cause working groups work for area directors, and consequently for the IESG= . If the IESG is not happy with the charter of a working group, they can'= t make the working group recharter if the working group doesn't want to, bu= t they do have the ultimate nuclear option, which is to simply shut down th= e working group. This doesn't happen very often, but it has been done. Needless to say, this is not a desirable outcome, so this is my motivation = for working with the chairs to try to close this loophole. Certainly nobo= dy on the IESG has proposed shutting down the working group, perhaps due to= the beam-in-the-eye principle, but these sorts of cleanups are something t= he IESG as a whole is keen on right now, and that's where this push is comi= ng from. From kkinnear@cisco.com Fri Jun 28 08:24: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 D812A21F9C08 for ; Fri, 28 Jun 2013 08:24:53 -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 OqpVKRYl8U2D for ; Fri, 28 Jun 2013 08:24:48 -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 0A13B21F9BAB for ; Fri, 28 Jun 2013 08:24:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7301; q=dns/txt; s=iport; t=1372433083; x=1373642683; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=R3uLxT7EUu1SzDQ0wHsypSjQkCKMKauuy2amYarsBtU=; b=ObwR3hHft9Xql1dx7VhocB+idyrBTiZfXFixVQep9w4m78C0GNvGEdmK oTcj8xCJ3Qieiy5ehJ8KfIEjXcUROKT+4MJCGhEwJYX4Sl9uLH9G/RmXm IgnopAonu6Ea04keNUJrYg75qnbxtN/fwXKm1uQzD+dRIgTfsfFSOstGk A=; X-IronPort-AV: E=Sophos;i="4.87,958,1363132800"; d="scan'208";a="228649350" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-8.cisco.com with ESMTP; 28 Jun 2013 15:24:26 +0000 Received: from printer-xerox-test-5735.cisco.com (printer-xerox-test-5735.cisco.com [161.44.65.115]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r5SFOPuw031860; Fri, 28 Jun 2013 15:24:26 GMT Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=windows-1252 From: Kim Kinnear In-Reply-To: <8D23D4052ABE7A4490E77B1A012B6307751EFF1B@mbx-01.win.nominum.com> Date: Fri, 28 Jun 2013 11:24:38 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <489D13FBFA9B3E41812EA89F188F018E185C32AD@xmb-rcd-x04.cisco.com> <17841E13-DE68-45F0-9282-AE696A137B30@cisco.com> <8D23D4052ABE7A4490E77B1A012B6307751EFF1B@mbx-01.win.nominum.com> To: Ted Lemon X-Mailer: Apple Mail (2.1278) Cc: "dhcwg@ietf.org" , "Bernie Volz \(volz\)" , Kim Kinnear Subject: Re: [dhcwg] DHC WG Re-Charter Proposal 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, 28 Jun 2013 15:24:54 -0000 Ted, I was aware that this change was designed to solve problems that have occurred in the past. The sometimes painful consequences that you refer to have not directly impacted me, so this solution seemed (and still seems, to some degree) out of proportion to the severity of the problems it is designed to solve. But I can see the way the wind is blowing, and that this change is going to happen. It does help that you pointed out that there is a way to still do a necessary non-protocol changing option should the need arise. As I believe the need will arise, I would be more comforted if there were a specific mention of non-protocol options in the "escape clause" (that new work can be taken on with AD approval). However, I am assuming that you don't want to highlight that idea (that being the activity that you want to reduce), so I suppose that idea isn't going to make much progress either. Thank you for explaining the "escape clause" -- I did miss it the first time around.=20 I can live with this as it stands, for what that is worth. Regards -- Kim On Jun 27, 2013, at 9:25 PM, Ted Lemon wrote: > I won't reiterate what Bernie said, which was correct, but a few = points of my own: >=20 > On Jun 27, 2013, at 4:48 PM, Kim Kinnear wrote: >> I have a major problem with this charter. As I read it, the DHC >> WG cannot create drafts for new options the are not "protocol >> options". This is a *huge* change from the past. >=20 > Bernie covered this; let me know if you don't buy his answer. >=20 >> However, that is very different from the constraint in this >> charter that says that the DHC WG cannot create options that are >> not protocol options. This places the DHC WG in a *more* >> restrictive position than other WGs -- *they* can try to create >> options that are reviewed by the DHCP directorate. But the DHC >> WG is explicitly chartered to create only protocol options. >> Period. >=20 > This is actually incorrect. Random working groups can't just go off = and do DHCP options. The work has to appear in their charter. The = point of this is to raise the visibility of such proposals to the level = of the IESG, so that we can avoid having working groups go off and = extend DHCP without ever talking to us. Part of what I hope to do to = raise awareness of this at the IESG level is the text I asked the = authors of the option guidelines draft to add to the document on the = topic of chartering working groups to add options. I don't see that in = the current version of the document, but I'm hoping the authors will add = that text, because it would make clear to you what we are trying to do. >=20 >=20 >> When I raised this at the last IETF, I >> was told that "consensus isn't necessary for charter approval". >=20 > What was said was that consensus does not require that everybody = agree. Consensus _is_ required in order to propose a new charter, but = that's not the whole story (see below). >=20 >> I understand, but the fact that I was told that my opinion really >> isn't interesting doesn't change my opinion. =20 >=20 > Your opinion is certainly interesting. The question is whether it = can be accommodated. I _hope_ that what's been clarified here makes = this change more palatable to you, but please be assured that if it = still isn't palatable to you, this is not a desired outcome, nor one = that anyone will feel pleasantly comfortable with. >=20 >> I *still* think that this is a major mistake. >>=20 >> I believe that the DHC WG should be able to take on the creation >> of DHCP options if the WG chairs believe that it is a good idea. >>=20 >> I would strongly recommend that we amend this charter to include >> this statement as the third paragraph: >>=20 >> The DHC WG may, at the discretion of any of the chairs of the >> WG, be considered to be chartered to develop non-protocol DHCP >> options on a case by case basis. The normal consensus approach >> to adoption as a WG work item would be used in this case, but >> would require explicit WG chair approval that the non-protocol >> option fit within the charter of the working group. These >> options would undergo the same review as protocol extensions. >>=20 >> Absent something like this, if you need a simple non-protocol >> option, you will have to shop it around to some other working >> group to get it adopted. Is this going to help the situation? >=20 > The above text is specifically what the IESG would like taken out of = the charter. As Bernie said, the working group can take on a new work = item either by agreement with the AD, or by adding that work to the = charter. Which path to take really depends on what work is proposed=97if= you want to add a new option to configure impress servers, that = probably doesn't merit a recharter, but if you want to add a new option = to carry SDP configuration information, that probably does. >=20 > The effect that this has is that if someone comes to the chairs and = says "we want to do a new DHCP option in the DHC working group that = effectively modifies the IPv6 routing architecture," there are now three = levels of notice that can occur before the working group starts working = on something it probably shouldn't. First, the chairs might notice, = and either say no themselves, or ask their AD to say no, so that they = don't have to be the bad guys. Second, if they don't notice the = problem, the responsible AD might notice, and again say "no, sorry, = that's not a good idea." Third, if a charter change is done, other ADs = on the IESG will likely notice the conflict, since it impacts their = area. >=20 > So the point of this is to get cross-area recognition of new, = potentially conflicting work _before_ the working group spends a year = working on the document and sends it up to the IESG. >=20 > At the moment, the IESG does not like the DHC working group charter, = because the way it's written, it's got a wildcard in it that's big = enough to drive a truck through, and trucks have been driven through it = in the past, sometimes with painful consequences. This change is not = intended to prevent the DHC working group ever working on new options. = The purpose of the change is very specifically to close this loophole. >=20 > The IESG has some limited influence in making this sort of thing = happen, because working groups work for area directors, and consequently = for the IESG. If the IESG is not happy with the charter of a working = group, they can't make the working group recharter if the working group = doesn't want to, but they do have the ultimate nuclear option, which is = to simply shut down the working group. This doesn't happen very often, = but it has been done. >=20 > Needless to say, this is not a desirable outcome, so this is my = motivation for working with the chairs to try to close this loophole. = Certainly nobody on the IESG has proposed shutting down the working = group, perhaps due to the beam-in-the-eye principle, but these sorts of = cleanups are something the IESG as a whole is keen on right now, and = that's where this push is coming from. >=20 From volz@cisco.com Fri Jun 28 08:36:10 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 362B521F9BF0 for ; Fri, 28 Jun 2013 08:36:10 -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 49TdDWCmfhq8 for ; Fri, 28 Jun 2013 08:36:04 -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 7554E21F9BAA for ; Fri, 28 Jun 2013 08:36:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12934; q=dns/txt; s=iport; t=1372433764; x=1373643364; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=alWm8vCAAEBWPNohXFB50A+qDcGkziTL2AyBMqzG3mY=; b=Y4tT2iMsi07OQ6+V8tYnaP2UBf8arCsYJPdOhLZgfiCAEN4SOMhLUN2W KYTkBCAUs+gzMB/zcrI9MzaHT6kuILKfj2D9c++MQnpk3Pf5wdYhvyD5k va9UKVHpN/lEfTIWqIXh58rPsFpg/1/2AKtBX+Hbh2ivkDs461aisi518 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjkFAMmszVGtJXG//2dsb2JhbABbgkVEMkm/BoEKFnSCIwEBAQQtTBACAQgRBAEBCx0HMhQJCAEBBA4FCIgHu32PJTEGAYMEYwOpCoMRgig X-IronPort-AV: E=Sophos;i="4.87,958,1363132800"; d="scan'208,217";a="228682525" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-3.cisco.com with ESMTP; 28 Jun 2013 15:36:04 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id r5SFa3QB007526 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 28 Jun 2013 15:36:03 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.56]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.02.0318.004; Fri, 28 Jun 2013 10:36:03 -0500 From: "Bernie Volz (volz)" To: Alper Yegin Thread-Topic: [dhcwg] DHC WG Re-Charter Proposal Thread-Index: Ac5x3GsmHSL5mORtSN2Yp6/PNjm/rwCMCqIAAAIPNgA= Date: Fri, 28 Jun 2013 15:36:03 +0000 Message-ID: <489D13FBFA9B3E41812EA89F188F018E185C9BB8@xmb-rcd-x04.cisco.com> References: <489D13FBFA9B3E41812EA89F188F018E185C32AD@xmb-rcd-x04.cisco.com> <2CA013F3-32BC-410F-A4A4-9C908BC12C56@yegin.org> In-Reply-To: <2CA013F3-32BC-410F-A4A4-9C908BC12C56@yegin.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.240.26] Content-Type: multipart/alternative; boundary="_000_489D13FBFA9B3E41812EA89F188F018E185C9BB8xmbrcdx04ciscoc_" MIME-Version: 1.0 Cc: "dhcwg@ietf.org" , "Ted Lemon \(Ted.Lemon@nominum.com\)" Subject: Re: [dhcwg] DHC WG Re-Charter Proposal 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, 28 Jun 2013 15:36:10 -0000 --_000_489D13FBFA9B3E41812EA89F188F018E185C9BB8xmbrcdx04ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Well, one of the drafts is titled: Provisioning IPv4 Configuration Over IPv6 Only Networks draft-ietf-dhc-v4configuration-01 And another draft has: By conveying DHCPv4 messages over DHCPv6 transport, this mechanism can achieve dynamic provisioning of IPv4 address and other configuration parameters. In addition, it is able to leverage existing infrastructure for DHCPv4, e.g. failover, DNS updates, leasequery, etc. This mechanism is suitable for stateful allocation and management of IPv4 addresses and configuration parameters across IPv6 networks. Several approaches for provisioning such information have already been proposed. This document describes alternative approach. So this isn't really introducing new terminology. But, if we have better words to describe this (and it may well extend to on= e or more drafts), I have no issues with using them. - Bernie From: Alper Yegin [mailto:alper.yegin@yegin.org] Sent: Friday, June 28, 2013 5:34 AM To: Bernie Volz (volz) Cc: dhcwg@ietf.org; Ted Lemon (Ted.Lemon@nominum.com) Subject: Re: [dhcwg] DHC WG Re-Charter Proposal - DHCP provisioning of IPv4 clients over IPv6 networks I think we better stick with the "configuration/configuring" term instead o= f introducing the "provisioning" term. --_000_489D13FBFA9B3E41812EA89F188F018E185C9BB8xmbrcdx04ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Well, one of the drafts i= s titled:

 <= /p>

=         Provisioning IPv4 Configuration = Over IPv6 Only Networks

=             &nb= sp;      draft-ietf-dhc-v4configuration-01

 <= /p>

And another draft has:

 <= /p> 

   By conveying DHCPv4 messages over DHCPv6 transport, this m=
echanism
   can achieve dynamic provisioning of IPv4 address and other=

   configuration parameters.  In addition, it is able to=
 leverage
   existing infrastructure for DHCPv4, e.g.  failover, D=
NS updates,
   leasequery, etc.  This mechanism is suitable for stat=
eful allocation
   and management of IPv4 addresses and configuration paramet=
ers across
   IPv6 networks.
 
   Several approaches for provisioning such information have =
already
   been proposed.  This document describes alternative a=
pproach.

 <= /p>

 <= /p>

So this isn’t reall= y introducing new terminology.

 <= /p>

But, if we have better wo= rds to describe this (and it may well extend to one or more drafts), I have= no issues with using them.

 <= /p>

- =          Bernie=

 <= /p>

From: Alper Ye= gin [mailto:alper.yegin@yegin.org]
Sent: Friday, June 28, 2013 5:34 AM
To: Bernie Volz (volz)
Cc: dhcwg@ietf.org; Ted Lemon (Ted.Lemon@nominum.com)
Subject: Re: [dhcwg] DHC WG Re-Charter Proposal

 

 

 

  - DHCP provisioning of IPv4 clients over IPv6 netwo= rks

 

 

I think we better stick with the "configuration= /configuring" term instead of introducing the "provisioning"= term.

 

 

--_000_489D13FBFA9B3E41812EA89F188F018E185C9BB8xmbrcdx04ciscoc_-- From volz@cisco.com Fri Jun 28 10:40: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 6B2EF21F9B64 for ; Fri, 28 Jun 2013 10:40:28 -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 3+9F+paV05Ak for ; Fri, 28 Jun 2013 10:40:23 -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 85DB221F9AD8 for ; Fri, 28 Jun 2013 10:40:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4313; q=dns/txt; s=iport; t=1372441223; x=1373650823; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=s+N5K03upaDFzBzxe9K4RiSeDzW96MegcYO1NPaJU8Q=; b=BxyIFltLzxBBA1DVbCqfO+NbdUEZQgo0lmqfrbu+MMcOcak3u0eFCe4o EFpg45ewoYi39xXJc8OAseVZKo9Ydg3PZ/WZwGPDqdE52G0P98IPqpCbZ muJeRgf926ZIWdLCEc8gDTH1eyIRoAXcjmIJuQNQ6zgVgAEgDBoVuCrC9 g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhQFAMrJzVGtJV2Y/2dsb2JhbABbgmAyQwa/BoEKgQmCIwEBAQQBAQE3NAkCDAQCAQgRBAEBCxQJBycLFAgBCAIEAQ0FCAGIBgcFtACPJTEHBoJ+YwOYbpAcgViBOYIo X-IronPort-AV: E=Sophos;i="4.87,960,1363132800"; d="scan'208";a="228703140" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-2.cisco.com with ESMTP; 28 Jun 2013 17:40:02 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r5SHe1ir016546 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 28 Jun 2013 17:40:01 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.56]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.02.0318.004; Fri, 28 Jun 2013 12:40:01 -0500 From: "Bernie Volz (volz)" To: "Prashanth Patil (praspati)" , "dhcwg@ietf.org" Thread-Topic: [dhcwg] FW: New Version Notification for draft-wing-dhc-dns-reconfigure-01.txt Thread-Index: AQHOY3uM9UALGIVfFEmPJoU9Kl4stpkq4qaAgCCgIMA= Date: Fri, 28 Jun 2013 17:40:01 +0000 Message-ID: <489D13FBFA9B3E41812EA89F188F018E185C9F90@xmb-rcd-x04.cisco.com> References: <20130607123546.18442.28001.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.240.26] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Tirumaleswar Reddy \(tireddy\)" Subject: Re: [dhcwg] FW: New Version Notification for draft-wing-dhc-dns-reconfigure-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: Fri, 28 Jun 2013 17:40:28 -0000 Isn't this also only half the problem? And doesn't it cause more work for t= he relay? What I mean is shouldn't there also be an option for the relay to communica= te this for "normal" client traffic? I.e., all Relay-Forws. There might be = more values (such as unknown) to be considered -- though I guess not includ= ing the option could imply that. Doesn't this also imply that the relay would have to monitor what the serve= r provided the client to know if it was wrong (and hence trigger a reconfig= ure). I guess the relay could just do this when things (regarding the clien= t's provisioning) changed. But what then happens if the client sends requests to the server at a later= time? There's no signaling to the server from the relay as to what to send= then? If the server sends the wrong information, how would the relay know = without monitoring what the server actually delivers to the client (as ther= e may not be a change in the client's connective). While you could require the server to remember this from a Reconfigure-Requ= est, that seems rather onerous and has issues if this state is lost or beco= mes stale (i.e., server misses updates from relay). Also, this mechanism currently requires the clients to support Reconfigure.= Otherwise, the relay's request doesn't cause any change at the client. And, this again is where having this be a normal part of the Relay-Forw wou= ld be useful -- at least the server then has the ability to update the clie= nt at the next communication. Note also that server policy to use perhaps shorter Information-Refresh or = T1 times when this information isn't available or the relay reports it is '= unknown' could be used to 'correct' the information in the client more quic= kly once it is determined? It would also be nice if this was expanded to handle more than DNS -- thoug= h exactly what else would use that information isn't completely clear. Anyway, looks like this work will be discussed in the Sunset4/DHC WG joint = session at Berlin (as well as at the DHC wg session). - Bernie -----Original Message----- From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of P= rashanth Patil (praspati) Sent: Friday, June 07, 2013 8:45 AM To: dhcwg@ietf.org Cc: Tirumaleswar Reddy (tireddy) Subject: [dhcwg] FW: New Version Notification for draft-wing-dhc-dns-reconf= igure-01.txt Hi all, This draft proposes a mechanism to extend DHCPv6 such that a DHCPv6 Relay Agent can dynamically influence priority of DNS servers provided to a host, so that a host can use an optimal DNS server for resolution. Regards, Prashanth On 07/06/13 6:05 PM, "internet-drafts@ietf.org" wrote: > >A new version of I-D, draft-wing-dhc-dns-reconfigure-01.txt >has been successfully submitted by Dan Wing and posted to the >IETF repository. > >Filename: draft-wing-dhc-dns-reconfigure >Revision: 01 >Title: DHCPv6 Dynamic DNS Reconfiguration >Creation date: 2013-06-07 >Group: Individual Submission >Number of pages: 8 >URL: =20 >http://www.ietf.org/internet-drafts/draft-wing-dhc-dns-reconfigure-01.txt >Status: =20 >http://datatracker.ietf.org/doc/draft-wing-dhc-dns-reconfigure >Htmlized: =20 >http://tools.ietf.org/html/draft-wing-dhc-dns-reconfigure-01 >Diff: =20 >http://www.ietf.org/rfcdiff?url2=3Ddraft-wing-dhc-dns-reconfigure-01 > >Abstract: > Some networks are expected to support IPv4-only, dual-stack, and > IPV6-only hosts at the same time. This makes prioritizing the DNS > servers for hosts tricky due to a heterogeneous mix of protocol > stacks causing optimal behavior to occur only when the host stack re- > initializes. The networks infrastructure is usually well equipped to > be aware of single/dual-stack nature of hosts. This specification > extends DHCPv6 so that a DHCPv6 Relay Agent can dynamically influence > the priority of DNS servers provided to the host, so that the host > can use an optimal DNS server for resolution. > > =20 > =20 > > >The IETF Secretariat > _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From Ted.Lemon@nominum.com Fri Jun 28 10:48: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 1A28221F9A77 for ; Fri, 28 Jun 2013 10:48: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 H8wVcRf-lSjB for ; Fri, 28 Jun 2013 10:48:17 -0700 (PDT) Received: from exprod7og129.obsmtp.com (exprod7og129.obsmtp.com [64.18.2.122]) by ietfa.amsl.com (Postfix) with ESMTP id 53B2021F848E for ; Fri, 28 Jun 2013 10:48:17 -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 DSNKUc3MW9STWAFub6G9NsfLVij7/W9nBjJk@postini.com; Fri, 28 Jun 2013 10:48: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 60B501B81D1 for ; Fri, 28 Jun 2013 10:48: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 C118519005D; Fri, 28 Jun 2013 10:48:10 -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; Fri, 28 Jun 2013 10:48:10 -0700 From: Ted Lemon To: "Prashanth Patil (praspati)" Thread-Topic: [dhcwg] New Version Notification for draft-wing-dhc-dns-reconfigure-01.txt Thread-Index: AQHOdCenS2HB7oYtEky7nP+0jJgy+Q== Date: Fri, 28 Jun 2013 17:48:10 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B6307751F0BE8@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: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dhcwg@ietf.org" , "Tirumaleswar Reddy \(tireddy\)" Subject: Re: [dhcwg] New Version Notification for draft-wing-dhc-dns-reconfigure-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: Fri, 28 Jun 2013 17:48:24 -0000 On Jun 7, 2013, at 8:44 AM, Prashanth Patil (praspati) = wrote: > This draft proposes a mechanism to extend DHCPv6 such that a DHCPv6 Relay > Agent can dynamically influence priority of DNS servers provided to a > host, so that a host can use an optimal DNS server for resolution. Why don't you just configure the DHCP server to return DNS servers in a dif= ferent order for different links? Links are identified by relay agent, so= this gets you the precise behavior you want, but with a centralized config= uration file rather than with per-relay configuration. If you really want the relay to be the source of knowledge about DNS, why n= ot return DNS servers via a relay-supplied options option? From Ted.Lemon@nominum.com Fri Jun 28 10:58: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 B1D1C21F9AEF for ; Fri, 28 Jun 2013 10:58:43 -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 yoOCbbJjMzsX for ; Fri, 28 Jun 2013 10:58:36 -0700 (PDT) Received: from exprod7og109.obsmtp.com (exprod7og109.obsmtp.com [64.18.2.171]) by ietfa.amsl.com (Postfix) with ESMTP id EF82E21F8617 for ; Fri, 28 Jun 2013 10:58:35 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob109.postini.com ([64.18.6.12]) with SMTP ID DSNKUc3Oy0OAmxT/HYnCYx36TOQEDsI8O5qE@postini.com; Fri, 28 Jun 2013 10:58:36 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 8066D1B81D1 for ; Fri, 28 Jun 2013 10:58: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 767F219005D; Fri, 28 Jun 2013 10:58: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; Fri, 28 Jun 2013 10:58:35 -0700 From: Ted Lemon To: Eliot Lear Thread-Topic: [dhcwg] DHC WG Re-Charter Proposal Thread-Index: Ac5x3GsmHSL5mORtSN2Yp6/PNjm/rwB1fl6AAAmnXAAADpkQgAAUGFQA Date: Fri, 28 Jun 2013 17:58:34 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B6307751F0D11@mbx-01.win.nominum.com> References: <489D13FBFA9B3E41812EA89F188F018E185C32AD@xmb-rcd-x04.cisco.com> <17841E13-DE68-45F0-9282-AE696A137B30@cisco.com> <8D23D4052ABE7A4490E77B1A012B6307751EFF1B@mbx-01.win.nominum.com> <51CD47EF.6010001@cisco.com> In-Reply-To: <51CD47EF.6010001@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: <698E21C9D82A3C48848ACCAB561A09B2@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dhcwg@ietf.org" , "Bernie Volz \(volz\)" , Kim Kinnear Subject: Re: [dhcwg] DHC WG Re-Charter Proposal 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, 28 Jun 2013 17:58:44 -0000 On Jun 28, 2013, at 4:23 AM, Eliot Lear wrote: > It is possible to hide a DHCP option in a draft without actually > mentioning it in the charter, if the option is in support of whatever > additional functionality is being offered.=20 I suppose that's true, but it's okay=97if a working group decides to do thi= s, then they may just face a late surprise during IETF review. The point = of this effort is to make late surprises less likely, but there's no way to= prevent them entirely. > Also, as I read the changes and the intent in your message, Ted, this > will have the effect of slowing down new options work. Maybe that's a > good thing, but it will happen because right now it's a matter of a call > for adoption for a WG draft and then off we go. With the charter change > you'd need to first either gain approval of the AD or of the IESG for a > charter change, and then proceed to adoption. Yes, this is indeed the intention. There's no need to rush, and the goal = is to provide early feedback and clarity on exactly what it means to develo= p a new DHCP option, when working groups decide to do so. > Moreover, right now all expertise for DHCP has a well known rendezvous > point that has authority. Directorates have shown themselves to be a > mixed bag. One clear result is that it will shift load to the IESG, > because IESG members (probably you) will have to review the output of > the directorate. That's the exact goal. We've had several cases where working groups got D= HCP protocol extensions past the IESG without proper review, because there = was no formal process for reviewing them. The new charter we are discussin= g has a work item to replace a broken draft produced by a working group tha= t bypassed the intended review process. In another case I spent a huge amo= unt of personal time essentially rewriting a document that a working group = had done where they had failed to get proper review, and I only noticed it = when the document was on the verge of publication, years after the working = group had closed. The document had been stalled waiting on a reference fo= r a long time, or it would have become an RFC before the problem got fixed.= The goal of this is to do a better job of review in this situation, and = hopefully avoid repeats of this kind of pain. > In short I see this as a tradeoff between managing overlap and these > other issues. Yup, I think everything you've said here is correct. :) From Ted.Lemon@nominum.com Fri Jun 28 11:04: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 3768921F99A2 for ; Fri, 28 Jun 2013 11:04:29 -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 42K7ZM0PTSYE for ; Fri, 28 Jun 2013 11:04:22 -0700 (PDT) Received: from exprod7og121.obsmtp.com (exprod7og121.obsmtp.com [64.18.2.20]) by ietfa.amsl.com (Postfix) with ESMTP id 20BA221F92B7 for ; Fri, 28 Jun 2013 11:03: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 DSNKUc3QCKnZCCuQg8P3cxKh0Pue/yeqIbEc@postini.com; Fri, 28 Jun 2013 11:03: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 C323B1B81DA for ; Fri, 28 Jun 2013 11:03:52 -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 B98A2190060; Fri, 28 Jun 2013 11:03:52 -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; Fri, 28 Jun 2013 11:03:48 -0700 From: Ted Lemon To: Kim Kinnear Thread-Topic: [dhcwg] DHC WG Re-Charter Proposal Thread-Index: Ac5x3GsmHSL5mORtSN2Yp6/PNjm/rwB1fl6AAAmnXAAAHVEeAAAFjuqA Date: Fri, 28 Jun 2013 18:03:48 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B6307751F0D78@mbx-01.win.nominum.com> References: <489D13FBFA9B3E41812EA89F188F018E185C32AD@xmb-rcd-x04.cisco.com> <17841E13-DE68-45F0-9282-AE696A137B30@cisco.com> <8D23D4052ABE7A4490E77B1A012B6307751EFF1B@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: <4C09AB9A846CF14EA9221815936A50A2@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dhcwg@ietf.org" , "Bernie Volz \(volz\)" Subject: Re: [dhcwg] DHC WG Re-Charter Proposal 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, 28 Jun 2013 18:04:29 -0000 On Jun 28, 2013, at 11:24 AM, Kim Kinnear wrote: > I can live with this as it stands, for what that is worth. Thanks. I will take what I can get on this. Please continue to hold my = feet to the fire if you feel that things aren't going the way they should b= e as a result of this. From volz@cisco.com Fri Jun 28 12:30: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 79B9B21F84E7 for ; Fri, 28 Jun 2013 12:30: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=[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 imE27qoL756c for ; Fri, 28 Jun 2013 12:29: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 A533921F9A74 for ; Fri, 28 Jun 2013 12:29:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=374; q=dns/txt; s=iport; t=1372447795; x=1373657395; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=km+VEIBw4ZVtHOLWacVQB2vJUfs18pT0Aaxe9ajd+Ko=; b=O5LxV7/YnE0dh5j0zFsKlmzJCD4DVU83grTiOdXl8BtdAVKLpBivDAXA T2nMdR76pY8poz5X0erZ+nriWE1oULrKxTsQfzZVjap3f51SaYpb1lppn IGjV0FPeu8BTZugnfLsmWZwj+o+dYZVAe3mRQ0arUCcXUKy8kFBB7I8/P Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhIFAJHizVGtJV2c/2dsb2JhbABbgwkySb8GgQoWdIIkAQEEOk8CAQgiFBAyJQEBBBuIB7pPBI8lOIMEYwOpCoMRgig X-IronPort-AV: E=Sophos;i="4.87,961,1363132800"; d="scan'208";a="228746409" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-2.cisco.com with ESMTP; 28 Jun 2013 19:29:55 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id r5SJTtse010188 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 28 Jun 2013 19:29:55 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.56]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.02.0318.004; Fri, 28 Jun 2013 14:29:54 -0500 From: "Bernie Volz (volz)" To: "dhcwg@ietf.org" Thread-Topic: [dhcwg] DHC WG Re-Charter Proposal Thread-Index: Ac5x3GsmHSL5mORtSN2Yp6/PNjm/rwB1fl6AAAmnXAAAHVEeAAAFjuqAAAu9JLA= Date: Fri, 28 Jun 2013 19:29:54 +0000 Message-ID: <489D13FBFA9B3E41812EA89F188F018E185CA416@xmb-rcd-x04.cisco.com> References: <489D13FBFA9B3E41812EA89F188F018E185C32AD@xmb-rcd-x04.cisco.com> <17841E13-DE68-45F0-9282-AE696A137B30@cisco.com> <8D23D4052ABE7A4490E77B1A012B6307751EFF1B@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751F0D78@mbx-01.win.nominum.com> In-Reply-To: <8D23D4052ABE7A4490E77B1A012B6307751F0D78@mbx-01.win.nominum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.240.202] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dhcwg] DHC WG Re-Charter Proposal 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, 28 Jun 2013 19:30:00 -0000 FYI - The proposed re-charter text can be found at https://datatracker.ietf= .org/doc/charter-ietf-dhc/ (thanks to Ted for uploading it). There was also one minor issue fixed that Kim found: - Address Network Identifier (draft-ietf-dhc-access-network-identifier) Address should be Access: - Access Network Identifier (draft-ietf-dhc-access-network-identifier) From internet-drafts@ietf.org Sat Jun 29 04:53: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 5776721F9989; Sat, 29 Jun 2013 04:53:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[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 Q9L9v5nsEJQt; Sat, 29 Jun 2013 04:53:25 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9244E21F9A04; Sat, 29 Jun 2013 04:53:20 -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.51.p2 Message-ID: <20130629115320.11197.15050.idtracker@ietfa.amsl.com> Date: Sat, 29 Jun 2013 04:53:20 -0700 Cc: dhcwg@ietf.org Subject: [dhcwg] I-D Action: draft-ietf-dhc-option-guidelines-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: Sat, 29 Jun 2013 11:53:25 -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 : Guidelines for Creating New DHCPv6 Options Author(s) : David W. Hankins Tomek Mrugalski Marcin Siodelski Sheng Jiang Suresh Krishnan Filename : draft-ietf-dhc-option-guidelines-12.txt Pages : 29 Date : 2013-06-29 Abstract: This document provides guidance to prospective DHCPv6 Option developers to help them creating option formats that are easily adoptable by existing DHCPv6 software. This document updates RFC3315. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dhc-option-guidelines There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-dhc-option-guidelines-12 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dhc-option-guidelines-12 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From tomasz.mrugalski@gmail.com Sat Jun 29 05:04: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 6002D11E80E4 for ; Sat, 29 Jun 2013 05:04: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 4iTx244feYec for ; Sat, 29 Jun 2013 05:04:44 -0700 (PDT) Received: from mail-bk0-x22f.google.com (mail-bk0-x22f.google.com [IPv6:2a00:1450:4008:c01::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 5089821F9FF8 for ; Sat, 29 Jun 2013 05:04:44 -0700 (PDT) Received: by mail-bk0-f47.google.com with SMTP id jg1so1089997bkc.34 for ; Sat, 29 Jun 2013 05:04:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:x-tagtoolbar-keys :content-type:content-transfer-encoding; bh=mmkkKD0Mzhag1FUqU657ogTSl5orpr7rWKcZfvkIRGY=; b=aVZ/ka7o0czm/dqSuYof/cklZxzVYENX8jyU9CzdZYe8YiNTnqQbRFkDjv9OX2RMc9 0Zsifj1Y+INwoXSzVfcxOAHl9/TNY43/ezx4Ij/OY7aMmCUbE8XelIXlqoIi6frFPrV/ 4HldBi2MiVs7na+McmtujdIYQsONZyose+E1v+C33HygMrrwrq/nnwFiOS6gLbKUP45j FIDmN24ReW7oAef4pwwwCFbKjDgoZIaqbAUKknPHhU7W3g/AoSk8rfSxrlVXDf0mk141 r/ht2je+eEM3YP6xVnyQ/+xu/YFdVwb7fxqHzhtdkTcY42lCjGLM9N0uBhdFcLt+o31G g5VQ== X-Received: by 10.204.230.71 with SMTP id jl7mr2329259bkb.72.1372507483326; Sat, 29 Jun 2013 05:04:43 -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 px7sm4934394bkb.9.2013.06.29.05.04.41 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 29 Jun 2013 05:04:42 -0700 (PDT) Message-ID: <51CECD4F.4000501@gmail.com> Date: Sat, 29 Jun 2013 14:04:31 +0200 From: Tomek Mrugalski User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: dhcwg@ietf.org References: <20130629115320.11197.15050.idtracker@ietfa.amsl.com> In-Reply-To: <20130629115320.11197.15050.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.4.6 X-TagToolbar-Keys: D20130629140431622 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Bernie Volz Subject: [dhcwg] Changes in draft-ietf-dhc-option-guidelines-12 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: Sat, 29 Jun 2013 12:04:45 -0000 Hi, After a long time (sorry about the delay), option-guidelines-12 has been uploaded. It contains quite a few changes proposed during last WGLC and follow-up discussions: - Option format with URI added - Option format with text string added - Section 13 "Chartering Requirements and Advice for Responsible ADs" added - Section 14 "Considerations for Creating New Formats" added - Discussion about option size added - Introduced singleton option concept - Option order irrelevance clarified - Many smaller editorial changes Since the changes are somewhat substantial, a new WGLC is appropriate. As I'm co-author of this draft, I'd like to ask Bernie to call WGLC and gauge consensus once it is finished. Thanks, Tomek On 29.06.2013 13:53, 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 : Guidelines for Creating New DHCPv6 Options > Author(s) : David W. Hankins > Tomek Mrugalski > Marcin Siodelski > Sheng Jiang > Suresh Krishnan > Filename : draft-ietf-dhc-option-guidelines-12.txt > Pages : 29 > Date : 2013-06-29 > > Abstract: > This document provides guidance to prospective DHCPv6 Option > developers to help them creating option formats that are easily > adoptable by existing DHCPv6 software. This document updates > RFC3315. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-dhc-option-guidelines > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-dhc-option-guidelines-12 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-dhc-option-guidelines-12 > > > 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 tomasz.mrugalski@gmail.com Sat Jun 29 05:13: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 9114821F859B for ; Sat, 29 Jun 2013 05:13:16 -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 Uk1zzMXO+oZc for ; Sat, 29 Jun 2013 05:13:16 -0700 (PDT) Received: from mail-bk0-x22c.google.com (mail-bk0-x22c.google.com [IPv6:2a00:1450:4008:c01::22c]) by ietfa.amsl.com (Postfix) with ESMTP id D859D21F84AA for ; Sat, 29 Jun 2013 05:13:15 -0700 (PDT) Received: by mail-bk0-f44.google.com with SMTP id r7so1109157bkg.31 for ; Sat, 29 Jun 2013 05:13:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:x-tagtoolbar-keys :content-type:content-transfer-encoding; bh=xhA2MyNLp2CQVYZf+KSx6VPmLW8asDg7s+jqfJZl5Yo=; b=MAoeGZmZELazNdZOnrjW9J+wHQ8dLJ3F+DSONzx8ktvRwycyr1FsLGNY9ZvZdwGIIe X8BKHCD1fJFkpKsA648InlEx24qe2gdPenss5q0I6VI3widZPYPvrRn1HP5emZS5CjDL N0oEtP3dH6sxkqt0m6qGWU2mABECKteGxTHHkxeZBcWAztHKSbMnqYsxbrquxkB0KEyp 2mW8OkmJzJicRS87XETBTk5IyZzli8AomvwMdUooCow7GRRKxjfWTLZ2+VKQGAHbqdOv 78K765Q91j3hF/uVL+YsAiDPWH5k8bevU38E+FWgve3WFgwJEwqtf4dN+TytYF8hEC+n xejg== X-Received: by 10.204.189.133 with SMTP id de5mr2342764bkb.167.1372507987850; Sat, 29 Jun 2013 05:13:07 -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 m6sm4945300bki.7.2013.06.29.05.13.05 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 29 Jun 2013 05:13:06 -0700 (PDT) Message-ID: <51CECF4A.2000503@gmail.com> Date: Sat, 29 Jun 2013 14:12:58 +0200 From: Tomek Mrugalski User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: Ted Lemon References: <489D13FBFA9B3E41812EA89F188F018E185C32AD@xmb-rcd-x04.cisco.com> <17841E13-DE68-45F0-9282-AE696A137B30@cisco.com> <8D23D4052ABE7A4490E77B1A012B6307751EFF1B@mbx-01.win.nominum.com> In-Reply-To: <8D23D4052ABE7A4490E77B1A012B6307751EFF1B@mbx-01.win.nominum.com> X-Enigmail-Version: 1.4.6 X-TagToolbar-Keys: D20130629141258536 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Cc: "dhcwg@ietf.org" , "Bernie Volz \(volz\)" , Kim Kinnear Subject: Re: [dhcwg] DHC WG Re-Charter Proposal and option-guidelines 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: Sat, 29 Jun 2013 12:13:18 -0000 On 28.06.2013 03:25, Ted Lemon wrote: > Part of what I hope to do to raise awareness of this at the IESG > level is the text I asked the authors of the option guidelines draft > to add to the document on the topic of chartering working groups to > add options. I don't see that in the current version of the > document, but I'm hoping the authors will add that text, because it > would make clear to you what we are trying to do. We did add it in after 11, which was kept unpublished for a while. Option-guidelines-12 is now uploaded. Please check if the text (whole section 13: http://tools.ietf.org/html/draft-ietf-dhc-option-guidelines-12#section-13) is complete and meets your goal. Tomek From Ted.Lemon@nominum.com Sat Jun 29 07:43: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 3798721F9B2E for ; Sat, 29 Jun 2013 07:43: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 TPOJ37opgEkp for ; Sat, 29 Jun 2013 07:43:18 -0700 (PDT) Received: from exprod7og117.obsmtp.com (exprod7og117.obsmtp.com [64.18.2.6]) by ietfa.amsl.com (Postfix) with ESMTP id 7741B21F9A3D for ; Sat, 29 Jun 2013 07:43:18 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob117.postini.com ([64.18.6.12]) with SMTP ID DSNKUc7yhccOY5hy8rQ5BHPb1wOeoLGS/sr6@postini.com; Sat, 29 Jun 2013 07:43:18 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 E19581B81CF for ; Sat, 29 Jun 2013 07:43: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 4280319005D; Sat, 29 Jun 2013 07:43: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; Sat, 29 Jun 2013 07:43:16 -0700 From: Ted Lemon To: Tomek Mrugalski Thread-Topic: [dhcwg] DHC WG Re-Charter Proposal and option-guidelines Thread-Index: AQHOdMIFePyvBm97aU6qVHFPAKKrT5lNOcwA Date: Sat, 29 Jun 2013 14:43:15 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B6307751F34C6@mbx-01.win.nominum.com> References: <489D13FBFA9B3E41812EA89F188F018E185C32AD@xmb-rcd-x04.cisco.com> <17841E13-DE68-45F0-9282-AE696A137B30@cisco.com> <8D23D4052ABE7A4490E77B1A012B6307751EFF1B@mbx-01.win.nominum.com> <51CECF4A.2000503@gmail.com> In-Reply-To: <51CECF4A.2000503@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="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dhcwg@ietf.org" , "Bernie Volz \(volz\)" , Kim Kinnear Subject: Re: [dhcwg] DHC WG Re-Charter Proposal and option-guidelines 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: Sat, 29 Jun 2013 14:43:24 -0000 On Jun 29, 2013, at 8:12 AM, Tomek Mrugalski w= rote: > We did add it in after 11, which was kept unpublished for a while. > Option-guidelines-12 is now uploaded. Please check if the text (whole > section 13: > http://tools.ietf.org/html/draft-ietf-dhc-option-guidelines-12#section-13= ) > is complete and meets your goal. Ah yes, there it is. Thank you! From volz@cisco.com Sat Jun 29 10:13: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 850DA11E8177 for ; Sat, 29 Jun 2013 10:13:59 -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 sOv0jjVerVxq for ; Sat, 29 Jun 2013 10:13:54 -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 BEF5811E8184 for ; Sat, 29 Jun 2013 10:13:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2024; q=dns/txt; s=iport; t=1372526029; x=1373735629; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=/I7rdQi0qsme31xDcKR/QwB1mCIZzKBG4D0AwwqeXlE=; b=WhArE9eAzDb54JlsyVZf/3FygU5Glt3mWpmrrAffM6sY1woXglL6hW2k Wp8OdBAAdH38UgmRtMU32yJQv8sotonxdaXzMmWKRCJELBh4Xpn/u56i5 cbNbG8Rz/WLWuyqPg34sV7ftvYxMbyCpeMZzAzRQjWCHTrBmBW0czfrwT o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFADQUz1GtJXG+/2dsb2JhbABRCoJgMkm/EIEAgQmCIwEBAQQ6PwwEAgEIDgMEAQEBChQJByERFAkIAgQBDQUIh3UDDwyxew2BdIxugSyBCzEHBoJ+YwOVXoMQineFJYMRgig X-IronPort-AV: E=Sophos;i="4.87,966,1363132800"; d="scan'208";a="228995099" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-6.cisco.com with ESMTP; 29 Jun 2013 17:13:47 +0000 Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id r5THDl37025821 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 29 Jun 2013 17:13:47 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.56]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.02.0318.004; Sat, 29 Jun 2013 12:13:46 -0500 From: "Bernie Volz (volz)" To: Tomek Mrugalski , Ted Lemon Thread-Topic: [dhcwg] DHC WG Re-Charter Proposal and option-guidelines Thread-Index: AQHOdMIL3lLWThZwTUaUHd1CPMCk7ZlMyVAQ Date: Sat, 29 Jun 2013 17:13:46 +0000 Message-ID: <489D13FBFA9B3E41812EA89F188F018E185CB711@xmb-rcd-x04.cisco.com> References: <489D13FBFA9B3E41812EA89F188F018E185C32AD@xmb-rcd-x04.cisco.com> <17841E13-DE68-45F0-9282-AE696A137B30@cisco.com> <8D23D4052ABE7A4490E77B1A012B6307751EFF1B@mbx-01.win.nominum.com> <51CECF4A.2000503@gmail.com> In-Reply-To: <51CECF4A.2000503@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.255.107] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dhcwg@ietf.org" , "Kim Kinnear \(kkinnear\)" Subject: Re: [dhcwg] DHC WG Re-Charter Proposal and option-guidelines 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: Sat, 29 Jun 2013 17:13:59 -0000 Tomek: You might want to clean up use of "Area Directors", "area directors", and "= AD". Also, AD isn't necessarily defined (not sure it would need to be) in S= ection 13. There are just nits and may also be dealt with by the RFC-Editor= . This section does seem to be rather long winded, but I didn't identify any = easy changes to shorten it. Note: I haven't done a full pass through the document; just looked at this = Section 13. There is also the question of whether the RFC 3315, 24. IANA Considerations= (which really is more than just IANA), might be 'updated' by this text. Bu= t that may best be left to the 3315-bis work. Unless an issue is raised by Monday that might cause me to reconsider, I wi= ll start the WG Last Call then. I think given the US holiday week and great= er chance that others in Europe and elsewhere are on vacation, I think it b= est to have it be the regular 2 week Last Call (I think we were originally = planning for a shorter 1-week call). - Bernie -----Original Message----- From: Tomek Mrugalski [mailto:tomasz.mrugalski@gmail.com]=20 Sent: Saturday, June 29, 2013 8:13 AM To: Ted Lemon Cc: Kim Kinnear (kkinnear); dhcwg@ietf.org; Bernie Volz (volz) Subject: Re: [dhcwg] DHC WG Re-Charter Proposal and option-guidelines On 28.06.2013 03:25, Ted Lemon wrote: > Part of what I hope to do to raise awareness of this at the IESG level=20 > is the text I asked the authors of the option guidelines draft to add=20 > to the document on the topic of chartering working groups to > add options. I don't see that in the current version of the > document, but I'm hoping the authors will add that text, because it=20 > would make clear to you what we are trying to do. We did add it in after 11, which was kept unpublished for a while. Option-guidelines-12 is now uploaded. Please check if the text (whole secti= on 13: http://tools.ietf.org/html/draft-ietf-dhc-option-guidelines-12#section-13) is complete and meets your goal. Tomek