From dhcwg-bounces@ietf.org Wed Jan 03 15:23:30 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2CdJ-0005aE-PF; Wed, 03 Jan 2007 15:22:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2CdI-0005Zz-BB for dhcwg@ietf.org; Wed, 03 Jan 2007 15:22:44 -0500 Received: from [2001:4f8:3:bb:20c:76ff:fe16:4040] (helo=goliath.isc.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2CdG-0008HF-Qu for dhcwg@ietf.org; Wed, 03 Jan 2007 15:22:44 -0500 Received: by goliath.isc.org (Postfix, from userid 10200) id C00BE5A6EC; Wed, 3 Jan 2007 12:22:35 -0800 (PST) Date: Wed, 3 Jan 2007 12:22:35 -0800 From: "David W. Hankins" To: dhcwg@ietf.org Subject: Re: [dhcwg] Ports clarification on DHCPv6 Message-ID: <20070103202235.GI26055@isc.org> References: <403B5316AD7A254C9024875BAE481D4E3DB29A@zeus.incognito.com> <20061211195047.GA22399@isc.org> Mime-Version: 1.0 In-Reply-To: <20061211195047.GA22399@isc.org> User-Agent: Mutt/1.5.9i X-Spam-Score: -2.8 (--) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1735003563==" Errors-To: dhcwg-bounces@ietf.org --===============1735003563== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="rS8CxjVDS/+yyDmU" Content-Disposition: inline --rS8CxjVDS/+yyDmU Content-Type: text/plain; charset=us-ascii Content-Disposition: inline I haven't seen any further traffic on this topic. > Conversely: Why send a packet from a high source port if you're going > to have to get responses via the low port? It's my understanding that there exists a mechanism (I can't remember if it's .Net or ActiveX) for nonpriveleged software running on Windows machines to transmit, and receive the responses to, DHCPINFORMs. I don't know what the IPv4 source port is in this case, or if this is any indication of what might be done in a DHCPv6 version of the same extensions. I do know that they exist, because we had to fix "bugs" relating to some unrelated-to-source-port oddities of these clients. -- David W. Hankins "If you don't do it right the first time, Software Engineer you'll just have to do it again." Internet Systems Consortium, Inc. -- Jack T. Hankins --rS8CxjVDS/+yyDmU Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFFnBCLcXeLeWu2vmoRAm2JAKCCjhChW8Y1IYZUKj5wk99SwQAt/wCfUQdY tnlc7LsOEcTyu4KzuhNEdqU= =xx4d -----END PGP SIGNATURE----- --rS8CxjVDS/+yyDmU-- --===============1735003563== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg --===============1735003563==-- From dhcwg-bounces@ietf.org Wed Jan 03 18:47:35 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2Fou-00027v-Pf; Wed, 03 Jan 2007 18:46:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2Fos-00027p-Vm for dhcwg@ietf.org; Wed, 03 Jan 2007 18:46:54 -0500 Received: from slb-smtpout-01.boeing.com ([130.76.64.48] helo=slb-smtpout-01.ns.cs.boeing.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2Foq-0004JY-KN for dhcwg@ietf.org; Wed, 03 Jan 2007 18:46:54 -0500 Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [192.42.227.216]) by slb-smtpout-01.ns.cs.boeing.com (8.13.6/8.13.6/TEST_SMTPIN) with ESMTP id l03NkpCH007159 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 3 Jan 2007 15:46:51 -0800 (PST) Received: from blv-av-01.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.13.6/8.13.6/DOWNSTREAM_RELAY) with ESMTP id l03NknUs012848; Wed, 3 Jan 2007 15:46:49 -0800 (PST) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by blv-av-01.boeing.com (8.13.6/8.13.6/UPSTREAM_RELAY) with ESMTP id l03Nkkf0012728; Wed, 3 Jan 2007 15:46:48 -0800 (PST) Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 3 Jan 2007 15:46:47 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [dhcwg] dhc wg last call on agentopt-delegate and srsn-optiondrafts Date: Wed, 3 Jan 2007 15:46:41 -0800 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A101774563@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <45950DDB.3040009@uninett.no> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dhcwg] dhc wg last call on agentopt-delegate and srsn-optiondrafts Thread-Index: AccrR7a/JUmIcCwASxOdoiUxx/pXGAER+ucw From: "Templin, Fred L" To: "Stig Venaas" , "dhcwg" X-OriginalArrivalTime: 03 Jan 2007 23:46:47.0808 (UTC) FILETIME=[6EBE5800:01C72F91] X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Cc: X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org Hi Stig, Going back over the mail archives from the 05/06 timeframe, I see now that this is the second time 'agentopt-delegate' has been announced for wg last call - it would have been nice to know that this is the second time around, plus a reference to the archives from the first time. By my reading of the archives from the previous wglc, it seems that 'srsn-option' was created to address an issue that was raised during the first wglc. Does that mean that all issues raised during the first wglc are now resolved and that this should be seen as a continuation of that wglc? Or, is this an independent second iteration of the wglc even though it wasn't announced as such? In either case, IMHO readers who may not have been actively tracking this in the 05/06 timeframe should be directed to the archived messages. Thanks - Fred fred.l.templin@boeing.com =20 > -----Original Message----- > From: Stig Venaas [mailto:stig.venaas@uninett.no]=20 > Sent: Friday, December 29, 2006 4:45 AM > To: dhcwg > Subject: [dhcwg] dhc wg last call on agentopt-delegate and=20 > srsn-optiondrafts=20 >=20 > This message announces a wg last call on two drafts. They are >=20 > DHCPv6 Relay Agent Assignment Notification (RAAN) Option > >=20 > and >=20 > DHCPv6 Server Reply Sequence Number Option > . >=20 > The last call will conclude at 1700EST on Mon, 2007-01-15. >=20 > Please respond to this WG last call. If you support acceptance of the > documents without change, respond with a simple=20 > acknowledgment, so that > support for the documents can be assessed. Lack of=20 > discussion does not > represent positive support. If there is no expression of support for > acceptance during the WG last call, the documents will not be advanced > to the IESG. >=20 > draft-ietf-dhc-dhcpv6-agentopt-delegate defines an option sent by a > DHCP server to inform a DHCP relay agent of IPv6 addresses or IPv6 > prefixes that have been assigned or delegated to DHCP clients. The > option makes use of the below srsn-option. This draft is available as > http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-agen > topt-delegate-02.txt >=20 > draft-ietf-dhc-dhcpv6-srsn-option defines a Server Reply=20 > Sequence Number > option for DHCPv6. It's sent from server to relay to ensure proper > sequencing of Relay-Reply messages. It's used by the agentopt-delegate > option. This draft is available as > http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-srsn > -option-00.txt >=20 > Stig >=20 > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg >=20 _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Thu Jan 04 03:12:27 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2NhR-0005fG-AC; Thu, 04 Jan 2007 03:11:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2NhP-0005fB-La for dhcwg@ietf.org; Thu, 04 Jan 2007 03:11:43 -0500 Received: from tyholt.uninett.no ([2001:700:1::eecb]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2NhN-0002oc-NZ for dhcwg@ietf.org; Thu, 04 Jan 2007 03:11:43 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by tyholt.uninett.no (Postfix) with ESMTP id 14EA787D07; Thu, 4 Jan 2007 09:11:36 +0100 (CET) Received: from tyholt.uninett.no ([127.0.0.1]) by localhost (tyholt.uninett.no [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 05285-01-54; Thu, 4 Jan 2007 09:11:34 +0100 (CET) Received: from [IPv6?2001?700?1?7?215?f2ff?fe35?307d] (sverresborg.uninett.no [IPv6:2001:700:1:7:215:f2ff:fe35:307d]) by tyholt.uninett.no (Postfix) with ESMTP id E698A87D06; Thu, 4 Jan 2007 09:11:34 +0100 (CET) Message-ID: <459CB6B6.8070802@uninett.no> Date: Thu, 04 Jan 2007 09:11:34 +0100 From: Stig Venaas User-Agent: Mozilla Thunderbird 1.0.7 (X11/20060613) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Templin, Fred L" Subject: Re: [dhcwg] dhc wg last call on agentopt-delegate and srsn-optiondrafts References: <39C363776A4E8C4A94691D2BD9D1C9A101774563@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A101774563@XCH-NW-7V2.nw.nos.boeing.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at uninett.no X-Spam-Score: -2.8 (--) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Cc: dhcwg X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org Templin, Fred L wrote: > Hi Stig, > > Going back over the mail archives from the 05/06 timeframe, > I see now that this is the second time 'agentopt-delegate' > has been announced for wg last call - it would have been > nice to know that this is the second time around, plus a > reference to the archives from the first time. Right, thanks for bringing this up. I should have mentioned that. We did do as last call starting 8th of May 2006, and there were some discussions on the list from 8th until the 15th. As you say srsn-option addresses one issue. It did not pass the last call, and my idea is that this is separate. So people that supported or were against the last draft, should respond again (after reading through the new versions). The idea is also that agentopt-delegate and srsn-option is a package, so the last call is for both of these. Stig > > By my reading of the archives from the previous wglc, it > seems that 'srsn-option' was created to address an issue > that was raised during the first wglc. Does that mean that > all issues raised during the first wglc are now resolved > and that this should be seen as a continuation of that > wglc? Or, is this an independent second iteration of > the wglc even though it wasn't announced as such? > > In either case, IMHO readers who may not have been actively > tracking this in the 05/06 timeframe should be directed to > the archived messages. > > Thanks - Fred > fred.l.templin@boeing.com > > >>-----Original Message----- >>From: Stig Venaas [mailto:stig.venaas@uninett.no] >>Sent: Friday, December 29, 2006 4:45 AM >>To: dhcwg >>Subject: [dhcwg] dhc wg last call on agentopt-delegate and >>srsn-optiondrafts >> >>This message announces a wg last call on two drafts. They are >> >>DHCPv6 Relay Agent Assignment Notification (RAAN) Option >> >> >>and >> >>DHCPv6 Server Reply Sequence Number Option >>. >> >>The last call will conclude at 1700EST on Mon, 2007-01-15. >> >>Please respond to this WG last call. If you support acceptance of the >>documents without change, respond with a simple >>acknowledgment, so that >>support for the documents can be assessed. Lack of >>discussion does not >>represent positive support. If there is no expression of support for >>acceptance during the WG last call, the documents will not be advanced >>to the IESG. >> >>draft-ietf-dhc-dhcpv6-agentopt-delegate defines an option sent by a >>DHCP server to inform a DHCP relay agent of IPv6 addresses or IPv6 >>prefixes that have been assigned or delegated to DHCP clients. The >>option makes use of the below srsn-option. This draft is available as >>http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-agen >>topt-delegate-02.txt >> >>draft-ietf-dhc-dhcpv6-srsn-option defines a Server Reply >>Sequence Number >>option for DHCPv6. It's sent from server to relay to ensure proper >>sequencing of Relay-Reply messages. It's used by the agentopt-delegate >>option. This draft is available as >>http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-srsn >>-option-00.txt >> >>Stig >> >>_______________________________________________ >>dhcwg mailing list >>dhcwg@ietf.org >>https://www1.ietf.org/mailman/listinfo/dhcwg >> > > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Thu Jan 04 12:25:00 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2WKK-0000Fl-SG; Thu, 04 Jan 2007 12:24:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2WKJ-0000Fe-Ex for dhcwg@ietf.org; Thu, 04 Jan 2007 12:24:27 -0500 Received: from stl-smtpout-01.boeing.com ([130.76.96.56] helo=stl-smtpout-01.ns.cs.boeing.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2WKG-0004mi-3b for dhcwg@ietf.org; Thu, 04 Jan 2007 12:24:27 -0500 Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by stl-smtpout-01.ns.cs.boeing.com (8.13.6/8.13.6/TEST_SMTPIN) with ESMTP id l04HOLrM003612 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 4 Jan 2007 11:24:21 -0600 (CST) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.13.6/8.13.6/DOWNSTREAM_RELAY) with ESMTP id l04HOLnJ022289; Thu, 4 Jan 2007 11:24:21 -0600 (CST) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by stl-av-01.boeing.com (8.13.6/8.13.6/UPSTREAM_RELAY) with ESMTP id l04HOBMO021983; Thu, 4 Jan 2007 11:24:21 -0600 (CST) Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 4 Jan 2007 09:24:18 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [dhcwg] dhc wg last call on agentopt-delegate and srsn-optiondrafts Date: Thu, 4 Jan 2007 09:23:29 -0800 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A101774566@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <459CB6B6.8070802@uninett.no> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dhcwg] dhc wg last call on agentopt-delegate and srsn-optiondrafts Thread-Index: Accv1/ZWvfg26zViS1mtouDkqyunhwATIruA From: "Templin, Fred L" To: "Stig Venaas" X-OriginalArrivalTime: 04 Jan 2007 17:24:18.0914 (UTC) FILETIME=[2A8CC420:01C73025] X-Spam-Score: 0.0 (/) X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a Cc: dhcwg X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org Stig,=20 > Templin, Fred L wrote: > > Hi Stig, > >=20 > > Going back over the mail archives from the 05/06 timeframe, > > I see now that this is the second time 'agentopt-delegate' > > has been announced for wg last call - it would have been > > nice to know that this is the second time around, plus a > > reference to the archives from the first time. >=20 > Right, thanks for bringing this up. I should have mentioned > that. We did do as last call starting 8th of May 2006, and > there were some discussions on the list from 8th until the > 15th. As you say srsn-option addresses one issue. OK. Then, can you (or someone who was involved in the earlier discussions) summarize what other issues might remain? Thanks - Fred fred.l.templin@boeing.com=20 > It did > not pass the last call, and my idea is that this is separate. > So people that supported or were against the last draft, > should respond again (after reading through the new versions). >=20 > The idea is also that agentopt-delegate and srsn-option is > a package, so the last call is for both of these. >=20 > Stig >=20 > >=20 > > By my reading of the archives from the previous wglc, it > > seems that 'srsn-option' was created to address an issue > > that was raised during the first wglc. Does that mean that > > all issues raised during the first wglc are now resolved > > and that this should be seen as a continuation of that > > wglc? Or, is this an independent second iteration of > > the wglc even though it wasn't announced as such? > >=20 > > In either case, IMHO readers who may not have been actively > > tracking this in the 05/06 timeframe should be directed to > > the archived messages. > >=20 > > Thanks - Fred > > fred.l.templin@boeing.com =20 > >=20 > >=20 > >>-----Original Message----- > >>From: Stig Venaas [mailto:stig.venaas@uninett.no]=20 > >>Sent: Friday, December 29, 2006 4:45 AM > >>To: dhcwg > >>Subject: [dhcwg] dhc wg last call on agentopt-delegate and=20 > >>srsn-optiondrafts=20 > >> > >>This message announces a wg last call on two drafts. They are > >> > >>DHCPv6 Relay Agent Assignment Notification (RAAN) Option > >> > >> > >>and > >> > >>DHCPv6 Server Reply Sequence Number Option > >>. > >> > >>The last call will conclude at 1700EST on Mon, 2007-01-15. > >> > >>Please respond to this WG last call. If you support=20 > acceptance of the > >>documents without change, respond with a simple=20 > >>acknowledgment, so that > >>support for the documents can be assessed. Lack of=20 > >>discussion does not > >>represent positive support. If there is no expression of=20 > support for > >>acceptance during the WG last call, the documents will not=20 > be advanced > >>to the IESG. > >> > >>draft-ietf-dhc-dhcpv6-agentopt-delegate defines an option sent by a > >>DHCP server to inform a DHCP relay agent of IPv6 addresses or IPv6 > >>prefixes that have been assigned or delegated to DHCP clients. The > >>option makes use of the below srsn-option. This draft is=20 > available as > >>http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-agen > >>topt-delegate-02.txt > >> > >>draft-ietf-dhc-dhcpv6-srsn-option defines a Server Reply=20 > >>Sequence Number > >>option for DHCPv6. It's sent from server to relay to ensure proper > >>sequencing of Relay-Reply messages. It's used by the=20 > agentopt-delegate > >>option. This draft is available as > >>http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-srsn > >>-option-00.txt > >> > >>Stig > >> > >>_______________________________________________ > >>dhcwg mailing list > >>dhcwg@ietf.org > >>https://www1.ietf.org/mailman/listinfo/dhcwg > >> > >=20 > >=20 > > _______________________________________________ > > dhcwg mailing list > > dhcwg@ietf.org > > https://www1.ietf.org/mailman/listinfo/dhcwg >=20 >=20 _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Thu Jan 04 16:25:49 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2a5M-0007JQ-Bg; Thu, 04 Jan 2007 16:25:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2a5L-0007HT-48 for dhcwg@ietf.org; Thu, 04 Jan 2007 16:25:15 -0500 Received: from [2001:4f8:3:bb:20c:76ff:fe16:4040] (helo=goliath.isc.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2a5K-00088w-1A for dhcwg@ietf.org; Thu, 04 Jan 2007 16:25:15 -0500 Received: by goliath.isc.org (Postfix, from userid 10200) id 74B1C5A6EC; Thu, 4 Jan 2007 13:25:09 -0800 (PST) Date: Thu, 4 Jan 2007 13:25:09 -0800 From: "David W. Hankins" To: dhcwg@ietf.org Subject: Re: [dhcwg] dhc wg last call on agentopt-delegate and srsn-optiondrafts Message-ID: <20070104212509.GA3352@isc.org> References: <459CB6B6.8070802@uninett.no> <39C363776A4E8C4A94691D2BD9D1C9A101774566@XCH-NW-7V2.nw.nos.boeing.com> Mime-Version: 1.0 In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A101774566@XCH-NW-7V2.nw.nos.boeing.com> User-Agent: Mutt/1.5.9i X-Spam-Score: -2.8 (--) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1784272890==" Errors-To: dhcwg-bounces@ietf.org --===============1784272890== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="LZvS9be/3tNcYl/X" Content-Disposition: inline --LZvS9be/3tNcYl/X Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Thu, Jan 04, 2007 at 09:23:29AM -0800, Templin, Fred L wrote: > OK. Then, can you (or someone who was involved in the earlier > discussions) summarize what other issues might remain? I think you mean me. Thomas had a complaint about the use of the word 'reliable', which I understand to have been cleared up in the edits that brought SRSN (since that bit was edited to reference the new draft). I think it was only us two who said something, so that just leaves me. The vast exchange between Bernie and myself (throughout the entire history of same) can be summarized I hope without offense: 1) "Turning DHCPv6 into a kind of RIP-like thing" (my critique) is possibly not the most robust network design modern men can invent (alternatives given). a) But it may be the easiest to implement for CMTS people, especially since CMTS already have to implement DHCPv6 relays. b) And isn't specified in this option anyway. The entire question of what you do with the contents of this option are left to implementors. It might just program an ACL for a formal routing protocol (although at least this purpose is one that does not strictly require the SRSN). 2) It falls down in multiple-relay (failsafe, not chained) scenarios. a) But there are no multiple-relay scenarios for CMTS, for which this is being designed. Such network designs have 'cold spares' not 'running peers' for fault tolerance. b) And our volunteer is, understandably, unwilling to design for multiple-relays. So there are arguments either way. For the record, I am abstaining from this WGLC, so nothing I just said or am about to say should be taken in support or objection, I just wanted to sum up for Fred. Overall, I'm a critic of the madness rather than the method. The view these discussions have afforded me into this sort of madness makes me rather glad I never worked for a Cable ISP. I can't imagine actually craving the situation where I ask a "router" to perform its duty without using a formal routing protocol, because the alternative is too horrid to imagine. In networks I have worked at, we've always had the opposite problem: lack of adequate routing protocol support being the horror we wished to escape [1]. But there you have it, and I accept it. That's where these CMTS operators are. I cannot speak in support, for then I am helping lock the cage they are trapped in, even if they say they like the decor. I cannot speak in objection, for then I am holding from them a coping mechanism. [1] On request, I can supply my copy of "OSPF", a song set to the tune of "YMCA" by _The Village People_. It was writ, and oft sung over beer, by a group of people who had the misfortune of working with me for a company with ~300 Ascends (and we RMA'd 30 a month). There is, of course, a much longer (but equally irrelevant) backstory behind its creation. -- David W. Hankins "If you don't do it right the first time, Software Engineer you'll just have to do it again." Internet Systems Consortium, Inc. -- Jack T. Hankins --LZvS9be/3tNcYl/X Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFFnXC1cXeLeWu2vmoRAud5AJ92OqxznEZBJLlMJoJj6V5fKszN3gCfQJq5 1/UDNy1Un4iN7RYPkD+kvaw= =8edt -----END PGP SIGNATURE----- --LZvS9be/3tNcYl/X-- --===============1784272890== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg --===============1784272890==-- From dhcwg-bounces@ietf.org Thu Jan 04 16:50:27 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2aTB-0000xn-IV; Thu, 04 Jan 2007 16:49:53 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2aTA-0000xb-KI for dhcwg@ietf.org; Thu, 04 Jan 2007 16:49:52 -0500 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2aT7-0004CB-7s for dhcwg@ietf.org; Thu, 04 Jan 2007 16:49:52 -0500 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 04 Jan 2007 13:49:49 -0800 X-IronPort-AV: i="4.12,239,1165219200"; d="scan'208"; a="50023435:sNHT45679582" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l04LnmJg024813; Thu, 4 Jan 2007 16:49:48 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l04Lnm7f017919; Thu, 4 Jan 2007 16:49:48 -0500 (EST) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 4 Jan 2007 16:49:48 -0500 Received: from kkinnear-wxp.cisco.com ([161.44.65.238]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 4 Jan 2007 16:49:48 -0500 Message-Id: <4.3.2.7.2.20070104164839.03355480@email.cisco.com> X-Sender: kkinnear@email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 04 Jan 2007 16:49:46 -0500 To: Stig Venaas , dhcwg From: Kim Kinnear Subject: Re: [dhcwg] dhc wg last call on agentopt-delegate and srsn-option drafts In-Reply-To: <45950DDB.3040009@uninett.no> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-OriginalArrivalTime: 04 Jan 2007 21:49:48.0464 (UTC) FILETIME=[414D3300:01C7304A] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1748; t=1167947388; x=1168811388; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=kkinnear@cisco.com; z=From:=20Kim=20Kinnear=20 |Subject:=20Re=3A=20[dhcwg]=20dhc=20wg=20last=20call=20on=20agentopt-dele gate=20and=0A=20=20srsn-option=20drafts=20 |Sender:=20 |To:=20Stig=20Venaas=20, =20dhcwg=20; bh=8ObYUVLCG9omzsBtC9aIE30kbtU8flSZiIllG50Bo28=; b=d1pP2yhRPL3ueu8gtLQ1huh6xiyZr6D8whuOd9OHhyc12pzxSNkiqDG3XdWHpSVbYmGtZb4p TYSuarkIVp8VTGg6i4yoA25tiqRsC2a6uu2X9G1S9fXtIbduY0qV+nS9; Authentication-Results: rtp-dkim-1; header.From=kkinnear@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org I support the acceptance of these documents without change and movement of them forward to the IESG. Cheers -- Kim At 07:45 AM 12/29/2006, Stig Venaas wrote: >This message announces a wg last call on two drafts. They are > >DHCPv6 Relay Agent Assignment Notification (RAAN) Option > > >and > >DHCPv6 Server Reply Sequence Number Option >. > >The last call will conclude at 1700EST on Mon, 2007-01-15. > >Please respond to this WG last call. If you support acceptance of the >documents without change, respond with a simple acknowledgment, so that >support for the documents can be assessed. Lack of discussion does not >represent positive support. If there is no expression of support for >acceptance during the WG last call, the documents will not be advanced >to the IESG. > >draft-ietf-dhc-dhcpv6-agentopt-delegate defines an option sent by a >DHCP server to inform a DHCP relay agent of IPv6 addresses or IPv6 >prefixes that have been assigned or delegated to DHCP clients. The >option makes use of the below srsn-option. This draft is available as >http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-agentopt-delegate-02.txt > >draft-ietf-dhc-dhcpv6-srsn-option defines a Server Reply Sequence Number >option for DHCPv6. It's sent from server to relay to ensure proper >sequencing of Relay-Reply messages. It's used by the agentopt-delegate >option. This draft is available as >http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-srsn-option-00.txt > >Stig > >_______________________________________________ >dhcwg mailing list >dhcwg@ietf.org >https://www1.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Thu Jan 04 17:17:40 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2atl-0001p4-Fg; Thu, 04 Jan 2007 17:17:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2atj-0001oa-Ua for dhcwg@ietf.org; Thu, 04 Jan 2007 17:17:19 -0500 Received: from slb-smtpout-01.boeing.com ([130.76.64.48] helo=slb-smtpout-01.ns.cs.boeing.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2ath-0000Wx-K9 for dhcwg@ietf.org; Thu, 04 Jan 2007 17:17:19 -0500 Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [192.42.227.216]) by slb-smtpout-01.ns.cs.boeing.com (8.13.6/8.13.6/TEST_SMTPIN) with ESMTP id l04MHGbn029230 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 4 Jan 2007 14:17:17 -0800 (PST) Received: from blv-av-01.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.13.6/8.13.6/DOWNSTREAM_RELAY) with ESMTP id l04MHGfP009386; Thu, 4 Jan 2007 14:17:16 -0800 (PST) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by blv-av-01.boeing.com (8.13.6/8.13.6/UPSTREAM_RELAY) with ESMTP id l04MHErF009207; Thu, 4 Jan 2007 14:17:16 -0800 (PST) Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 4 Jan 2007 14:16:28 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [dhcwg] dhc wg last call on agentopt-delegateand srsn-optiondrafts Date: Thu, 4 Jan 2007 14:15:54 -0800 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A101774569@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <20070104212509.GA3352@isc.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dhcwg] dhc wg last call on agentopt-delegateand srsn-optiondrafts Thread-Index: AccwRxh62A9SSxo8ShytPtMC06feRAAA8wmw From: "Templin, Fred L" To: "David W. Hankins" , X-OriginalArrivalTime: 04 Jan 2007 22:16:28.0191 (UTC) FILETIME=[FAD02AF0:01C7304D] X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Cc: X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org Hi David,=20 > On Thu, Jan 04, 2007 at 09:23:29AM -0800, Templin, Fred L wrote: > > OK. Then, can you (or someone who was involved in the earlier > > discussions) summarize what other issues might remain? >=20 > I think you mean me. I wasn't trying to single out anyone; I truthfully was not aware of the 05/06 discussion thread until late yesterday afternoon and then only had time for a quick skim. > The vast exchange between Bernie and myself (throughout the > entire history of same) can be summarized I hope without > offense: >=20 > 1) "Turning DHCPv6 into a kind of RIP-like thing" (my critique) > is possibly not the most robust network design modern men can > invent (alternatives given). > a) But it may be the easiest to implement for CMTS people, > especially since CMTS already have to implement DHCPv6 > relays. > b) And isn't specified in this option anyway. The entire > question of what you do with the contents of this option > are left to implementors. It might just program an ACL > for a formal routing protocol (although at least this > purpose is one that does not strictly require the SRSN). I may have a slightly different slant on this as we have discussed before. My motivation is to reduce churn in the backhaul network routing protocol in the presence of highly mobile nodes (MNs). =20 > 2) It falls down in multiple-relay (failsafe, not chained) scenarios. > a) But there are no multiple-relay scenarios for CMTS, > for which this is being designed. Such network designs > have 'cold spares' not 'running peers' for fault tolerance. > b) And our volunteer is, understandably, unwilling to design > for multiple-relays. My scenario supports (and benefits from) multiple relays on the link, where each relay is co-resident with a router. MNs can use any of the available relays as a default router but the one that actually relayed the DHCP address/prefix delegations will be the one that receives the RAAN and SRSN options. If the MN detects that it can no longer reach this "primary" relay (e.g., via IPv6 NUD), it can treat this as a link change event and issue a DHCPv6 Confirm via a new relay. The server will reply with RAAN/SRSN options via the new relay which will take the place of the old as the MN's "primary" relay.=20 > So there are arguments either way. >=20 >=20 > For the record, I am abstaining from this WGLC, so nothing I just > said or am about to say should be taken in support or objection, I > just wanted to sum up for Fred. Appreciated. Fred fred.l.templin@boeing.com _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Thu Jan 04 19:17:14 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2clO-0007mi-29; Thu, 04 Jan 2007 19:16:50 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2clN-0007md-23 for dhcwg@ietf.org; Thu, 04 Jan 2007 19:16:49 -0500 Received: from slb-smtpout-01.boeing.com ([130.76.64.48] helo=slb-smtpout-01.ns.cs.boeing.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1H2clL-0004K9-JK for dhcwg@ietf.org; Thu, 04 Jan 2007 19:16:48 -0500 Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [192.42.227.216]) by slb-smtpout-01.ns.cs.boeing.com (8.13.6/8.13.6/TEST_SMTPIN) with ESMTP id l050Gk6B029613 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 4 Jan 2007 16:16:46 -0800 (PST) Received: from blv-av-01.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.13.6/8.13.6/DOWNSTREAM_RELAY) with ESMTP id l050GkVa009530; Thu, 4 Jan 2007 16:16:46 -0800 (PST) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by blv-av-01.boeing.com (8.13.6/8.13.6/UPSTREAM_RELAY) with ESMTP id l050Gh8O009365; Thu, 4 Jan 2007 16:16:45 -0800 (PST) Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 4 Jan 2007 16:16:36 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [dhcwg] dhc wg last call on agentopt-delegate and srsn-optiondrafts Date: Thu, 4 Jan 2007 16:16:30 -0800 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A101774570@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <45950DDB.3040009@uninett.no> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dhcwg] dhc wg last call on agentopt-delegate and srsn-optiondrafts Thread-Index: AccrR7a/JUmIcCwASxOdoiUxx/pXGAFFp0tQ From: "Templin, Fred L" To: "Stig Venaas" , "dhcwg" X-OriginalArrivalTime: 05 Jan 2007 00:16:36.0331 (UTC) FILETIME=[C3330BB0:01C7305E] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org The discovery of the previous last-call discussions and the list exchanges today haven't done anything to change my opinion. Yes to both (still). Fred fred.l.templin@boeing.com =20 > -----Original Message----- > From: Stig Venaas [mailto:stig.venaas@uninett.no]=20 > Sent: Friday, December 29, 2006 4:45 AM > To: dhcwg > Subject: [dhcwg] dhc wg last call on agentopt-delegate and=20 > srsn-optiondrafts=20 >=20 > This message announces a wg last call on two drafts. They are >=20 > DHCPv6 Relay Agent Assignment Notification (RAAN) Option > >=20 > and >=20 > DHCPv6 Server Reply Sequence Number Option > . >=20 > The last call will conclude at 1700EST on Mon, 2007-01-15. >=20 > Please respond to this WG last call. If you support acceptance of the > documents without change, respond with a simple=20 > acknowledgment, so that > support for the documents can be assessed. Lack of=20 > discussion does not > represent positive support. If there is no expression of support for > acceptance during the WG last call, the documents will not be advanced > to the IESG. >=20 > draft-ietf-dhc-dhcpv6-agentopt-delegate defines an option sent by a > DHCP server to inform a DHCP relay agent of IPv6 addresses or IPv6 > prefixes that have been assigned or delegated to DHCP clients. The > option makes use of the below srsn-option. This draft is available as > http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-agen > topt-delegate-02.txt >=20 > draft-ietf-dhc-dhcpv6-srsn-option defines a Server Reply=20 > Sequence Number > option for DHCPv6. It's sent from server to relay to ensure proper > sequencing of Relay-Reply messages. It's used by the agentopt-delegate > option. This draft is available as > http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-srsn > -option-00.txt >=20 > Stig >=20 > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg >=20 _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Fri Jan 05 00:56:21 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2i3B-0006mW-AW; Fri, 05 Jan 2007 00:55:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2i3A-0006mR-G1 for dhcwg@ietf.org; Fri, 05 Jan 2007 00:55:32 -0500 Received: from ironmail.infoweapons.com ([58.71.34.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2i37-0006CM-WE for dhcwg@ietf.org; Fri, 05 Jan 2007 00:55:32 -0500 Received: (qmail 80135 invoked by uid 98); 5 Jan 2007 05:55:19 -0000 Received: from 10.3.2.11 by ironmail.cebu.infoweapons.com (envelope-from , uid 82) with qmail-scanner-1.25 (clamdscan: 0.86.1/959. spamassassin: 3.0.4. Clear:RC:1(10.3.2.11):. Processed in 0.12117 secs); 05 Jan 2007 05:55:19 -0000 X-Qmail-Scanner-Mail-From: agaviola@infoweapons.com via ironmail.cebu.infoweapons.com X-Qmail-Scanner: 1.25 (Clear:RC:1(10.3.2.11):. Processed in 0.12117 secs) Received: from archimedes.cebu.infoweapons.com (HELO archimedes) (agaviola@10.3.2.11) by ironmail.infoweapons.com with SMTP; 5 Jan 2007 05:55:19 -0000 From: "Archimedes S. Gaviola" To: Date: Fri, 5 Jan 2007 13:52:54 +0800 MIME-Version: 1.0 Message-ID: <000801c7308d$cdb12890$0b02030a@cebu.infoweapons.com> X-Mailer: Microsoft Office Outlook 11 X-Mimeole: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AccwjbuKg5nL4vjLTIm1QOh42b0lVg== X-Spam-Score: 0.1 (/) X-Scan-Signature: 2ed806e2f53ff1a061ad4f97e00345ac Subject: [dhcwg] RFC 3633 Question X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1360870978==" Errors-To: dhcwg-bounces@ietf.org This is a multi-part message in MIME format. --===============1360870978== Content-Type: multipart/signed; boundary="----=_NextPart_000_0000_01C730D0.C9CC9FF0"; protocol="application/x-pkcs7-signature"; micalg=SHA1 This is a multi-part message in MIME format. ------=_NextPart_000_0000_01C730D0.C9CC9FF0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0001_01C730D0.C9CC9FF0" ------=_NextPart_001_0001_01C730D0.C9CC9FF0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi! Based on RFC 3633 - IPv6 Prefix Options for DHCPv6, the specified nodes involved in the operation are routers such as the requesting router - the router that acts as a DHCP client that is requesting for prefix(es) and a delegating router that acts as the DHCP server. My question are, thus the option (IA_PD) mentioned here is only intended when DHCP is running on a router ( a packet forwarding node) and not on a host ( non-forwarding packet node)? Is there a DHCPv6 option for specifying gateway or router just like in IPv4 when a DHCPv6 is running on a non-forwarding packet node, in which it will provide options for routers? Thank you very much. Archimedes S. Gaviola Network Engineer InfoWeapons Corporation ------=_NextPart_001_0001_01C730D0.C9CC9FF0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi!=20 Based=20 on RFC 3633 - IPv6 Prefix Options for DHCPv6, = the specified nodes=20 involved in the operation are routers such as the requesting router - = the router=20 that acts as a DHCP client that is requesting for prefix(es) and=20 a delegating router that acts as the DHCP server. My question are, = thus the=20 option (IA_PD) mentioned here is only intended when DHCP is = running on=20 a router ( a packet forwarding node) and not on a host ( non-forwarding = packet=20 node)?  Is there a DHCPv6 option for specifying gateway or router = just like=20 in IPv4 when a DHCPv6 is running on a non-forwarding = packet node, in=20 which it will provide options for routers?
 
Thank = you very=20 much.
 
Archimedes S.=20 Gaviola
Network=20 Engineer
InfoWeapons=20 Corporation
------=_NextPart_001_0001_01C730D0.C9CC9FF0-- ------=_NextPart_000_0000_01C730D0.C9CC9FF0 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJYjCCAuow ggJToAMCAQICECmNETAKqQm550Zef1ntdl4wDQYJKoZIhvcNAQEEBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA2MDUwMjA3MTMyNloXDTA3MDUwMjA3MTMy NlowSjEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEnMCUGCSqGSIb3DQEJARYYYWdh dmlvbGFAaW5mb3dlYXBvbnMuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA8PJB ajTVS2g92hOKLubcYz4P9wru799XXKdtZVnsPYbg07N+Nro7h9tSaXwnunfUD9ot+oMjsEnAmdK6 evVqUKr7J9SgAoEWItQDrZ6Bn3OxLExNoKLik2DU4KsWr1n0NFU3lcVip0kGDWJZTyKIgcsk0JCX 8F+htKZefh/zT3ArzwF1rCMRimeIngINW89PfWObOZfj5ZY+Yt0Y+CTCXNmTyHDArid/ZsDTQ98j GLTt/ysiuvL3hUxQ5DZVXxFHiFO+V2zE4zqss1rEmDcQAjyFlYfeZs9Xgy83a2H343OvUn0LG/7p 7mrXqUC8ajmAX9xn2Sz2uX1bBi5GNWPRywIDAQABozUwMzAjBgNVHREEHDAagRhhZ2F2aW9sYUBp bmZvd2VhcG9ucy5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQQFAAOBgQCLxOytH7FV8ZuW kXmUmMqNKaXIDwcYvncUf/1Ds++GSUFAB9uIkFigTc1UlOMDHO8Cjt6MoJdsuf3RsBS/rW+SRE3i kjMJJmgwg/cQRC+vr5Pd6MBnBWquhPxVq0bOetmibhbGj35RuXWwwP0yUFvw6evzKrEO37T5cADL 7GHIqzCCAy0wggKWoAMCAQICAQAwDQYJKoZIhvcNAQEEBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYD VQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENv bnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNV BAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwt ZnJlZW1haWxAdGhhd3RlLmNvbTAeFw05NjAxMDEwMDAwMDBaFw0yMDEyMzEyMzU5NTlaMIHRMQsw CQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xGjAY BgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgwJgYDVQQLEx9DZXJ0aWZpY2F0aW9uIFNlcnZpY2Vz IERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgQ0ExKzApBgkqhkiG 9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRoYXd0ZS5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0A MIGJAoGBANRp19SwlGRbcelH2AxRtupykbCEXn0tDY97Et+FJXUodDpCLGMnn5V7S+9+GYcdhuqj 3bnOlmQawhRuRKx85o/oTQ9xH0A4pgCjh3j2+ZSGXq3qwF5269kUo11uenwMpUtVfwYZKX+emibV ars4JAhqmMex2qOYkf152+VaxBy5AgMBAAGjEzARMA8GA1UdEwEB/wQFMAMBAf8wDQYJKoZIhvcN AQEEBQADgYEAx+ySfk749ZalZ2IqpPBNEWDQb41gWGGsJrtSNVwIzzD7qEqWih9iQiOMFw/0umSc F6xHKd+dmF7SbGBxXKKs3Hnj524ARx+1DSjoAp3kmv0T9KbZfLH43F8jJgmRgHPQFBveQ6mDJfLm nC8Vyv6mq4oHdYsM3VGEa+T40c53ooEwggM/MIICqKADAgECAgENMA0GCSqGSIb3DQEBBQUAMIHR MQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYDVQQHEwlDYXBlIFRvd24x GjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgwJgYDVQQLEx9DZXJ0aWZpY2F0aW9uIFNlcnZp Y2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgQ0ExKzApBgkq hkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRoYXd0ZS5jb20wHhcNMDMwNzE3MDAwMDAwWhcN MTMwNzE2MjM1OTU5WjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcg KFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0Ew gZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMSmPFVzVftOucqZWh5owHUEcJ3f6f+jHuy9zfVb 8hp2vX8MOmHyv1HOAdTlUAow1wJjWiyJFXCO3cnwK4Vaqj9xVsuvPAsH5/EfkTYkKhPPK9Xzgnc9 A74r/rsYPge/QIACZNenprufZdHFKlSFD0gEf6e20TxhBEAeZBlyYLf7AgMBAAGjgZQwgZEwEgYD VR0TAQH/BAgwBgEB/wIBADBDBgNVHR8EPDA6MDigNqA0hjJodHRwOi8vY3JsLnRoYXd0ZS5jb20v VGhhd3RlUGVyc29uYWxGcmVlbWFpbENBLmNybDALBgNVHQ8EBAMCAQYwKQYDVR0RBCIwIKQeMBwx GjAYBgNVBAMTEVByaXZhdGVMYWJlbDItMTM4MA0GCSqGSIb3DQEBBQUAA4GBAEiM0VCD6gsuzA2j ZqxnD3+vrL7CF6FDlpSdf0whuPg2H6otnzYvwPQcUCCTcDz9reFhYsPZOhl+hLGZGwDFGguCdJ4l UJRix9sncVcljd2pnDmOjCBPZV+V2vf3h9bGCE6u9uo05RAaWzVNd+NWIXiC3CEZNd4ksdMdRv9d X2VPMYIDeTCCA3UCAQEwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRp bmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vpbmcg Q0ECECmNETAKqQm550Zef1ntdl4wCQYFKw4DAhoFAKCCAdgwGAYJKoZIhvcNAQkDMQsGCSqGSIb3 DQEHATAcBgkqhkiG9w0BCQUxDxcNMDcwMTA1MDU1MjUwWjAjBgkqhkiG9w0BCQQxFgQUUyzt3xhJ OBznCBmLAMY5le9phVIwZwYJKoZIhvcNAQkPMVowWDAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgIC AIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwBwYFKw4DAhowCgYIKoZI hvcNAgUwgYUGCSsGAQQBgjcQBDF4MHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBD b25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJ c3N1aW5nIENBAhApjREwCqkJuedGXn9Z7XZeMIGHBgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1Ro YXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhApjREwCqkJuedGXn9Z7XZeMA0GCSqG SIb3DQEBAQUABIIBAD8LrGrGGtDrDF9dHudt65TDxpIvNV5aaRKj2BAp1lOCVI5CK68aCpUUvTPA tIwcsFI/vX+3mqm8n30mx/JjgurDm/833GzSETLK+p97aJtGYzkDMCygEMpBAYEMjwu37Sr3gdE/ ybuxj2zaTpRJbuF/FfT/3skahR1nlidta8TZLvZQWJO1oeg5vSVey1QOP13QdigZ3porGrbcUhb/ 4+iAV96bG8VSm0LVHCkowBBNhm5XHMeD9FQWRLOFPYZb/+lO59vWn5H+oOYvm14jXQGJOObmF5vB 9Il5t9490yJhA33WewIyj1XMjsSPtGK6kDI+DM5Lr5Z133SU3PtBV/AAAAAAAAA= ------=_NextPart_000_0000_01C730D0.C9CC9FF0-- --===============1360870978== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg --===============1360870978==-- From dhcwg-bounces@ietf.org Fri Jan 05 01:07:53 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2iEt-0004tZ-At; Fri, 05 Jan 2007 01:07:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2iEr-0004lI-26 for dhcwg@ietf.org; Fri, 05 Jan 2007 01:07:37 -0500 Received: from mail2.infoweapons.com ([58.71.34.141]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2iAC-00086F-3x for dhcwg@ietf.org; Fri, 05 Jan 2007 01:02:49 -0500 Received: from mail2.infoweapons.com (localhost.mail2.infoweapons.com [IPv6:::1]) by mail2.infoweapons.com (Postfix) with ESMTP id 172DE105FC28 for ; Fri, 5 Jan 2007 14:03:48 +0800 (PHT) Received: from 10.3.2.11 (SquirrelMail authenticated user agaviola) by mail2.infoweapons.com with HTTP; Fri, 5 Jan 2007 14:03:48 +0800 (PHT) Message-ID: <1459.10.3.2.11.1167977028.squirrel@mail2.infoweapons.com> Date: Fri, 5 Jan 2007 14:03:48 +0800 (PHT) From: agaviola@infoweapons.com To: dhcwg@ietf.org User-Agent: SquirrelMail/1.4.8 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 X-Priority: 3 (Normal) Importance: Normal Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.2 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Subject: [dhcwg] RFC 3633 Question X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org Hi! Based on RFC 3633 - IPv6 Prefix Options for DHCPv6, the specified nodes involved in the operation are routers such as the requesting router - the router that acts as a DHCP client that is requesting for prefix(es) and a delegating router that acts as the DHCP server. My question are, thus the option (IA_PD) mentioned here is only intended when DHCP is running on a router ( a packet forwarding node) and not on a host ( non-forwarding packet node)? Is there a DHCPv6 option for specifying gateway or router just like in IPv4 when a DHCPv6 is running on a non-forwarding packet node, in which it will provide options for routers? Thank you very much. -------- This email and/or attachments are confidential and may also be legally privileged. If you are not the intended recipient, you are hereby notified, that any review, dissemination, distribution or copying of this email and/or attachments is strictly prohibited. Please notify security@infoweapons.com immediately by email and delete this message and all its attachments. Thank you. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Fri Jan 05 09:31:56 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2q6a-0004lQ-1a; Fri, 05 Jan 2007 09:31:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2q6Y-0004il-Hp for dhcwg@ietf.org; Fri, 05 Jan 2007 09:31:34 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2q6W-00034s-2j for dhcwg@ietf.org; Fri, 05 Jan 2007 09:31:34 -0500 Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-5.cisco.com with ESMTP; 05 Jan 2007 06:31:31 -0800 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-8.cisco.com (8.12.11/8.12.11) with ESMTP id l05EVV3s010841; Fri, 5 Jan 2007 06:31:31 -0800 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l05EVUIl016286; Fri, 5 Jan 2007 06:31:31 -0800 (PST) Received: from xmb-rtp-20a.amer.cisco.com ([64.102.31.15]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 5 Jan 2007 09:31:30 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [dhcwg] dhc wg last call on agentopt-delegateand srsn-optiondrafts Date: Fri, 5 Jan 2007 09:30:27 -0500 Message-ID: <8E296595B6471A4689555D5D725EBB2102EC1D8D@xmb-rtp-20a.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dhcwg] dhc wg last call on agentopt-delegateand srsn-optiondrafts thread-index: AccwRxx9R7oz5DskRUaweFku9rWcaAAjRjwA From: "Bernie Volz \(volz\)" To: "David W. Hankins" , X-OriginalArrivalTime: 05 Jan 2007 14:31:30.0780 (UTC) FILETIME=[3112D1C0:01C730D6] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4067; t=1168007491; x=1168871491; c=relaxed/relaxed; s=sjdkim8002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=volz@cisco.com; z=From:=20=22Bernie=20Volz=20\(volz\)=22=20 |Subject:=20RE=3A=20[dhcwg]=20dhc=20wg=20last=20call=20on=20agentopt-dele gateand=09srsn-optiondrafts |Sender:=20; bh=kM6cCNh2tDthOwXlIdat7fhy6wVMgbLJYHYslxeg6u8=; b=M+vUwirNI94SIFd+lOS+QLemX0o7sBEB3a2jogx5ifWCKx1ff+G3BvDrZY1YaHJp/QFfVepV tr71yW/nB1zYfKowgFwtjR6eecvViCp92fxkq6A1+P8fBpwN/1LDnJlL; Authentication-Results: sj-dkim-8; header.From=volz@cisco.com; dkim=pass (si g from cisco.com/sjdkim8002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b Cc: X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org David: In a multiple relay (well, really router since we're talking about routing) situation, the routers need to have some protocol to communicate with each other and it is assumed that is how that is handled. This is no different than the initial lease (which likely is communicated via only one path); it is no different than other learned routes. If you have multiple partners participating, you need to have some way to distribute the information between them. This is left to the routers and is not up to DHCP to do, IMHO. Unless you have the DHCP server itself participate in the routing protocols, you really have no other options? If you were designing this, what would you do? - Bernie -----Original Message----- From: David W. Hankins [mailto:David_Hankins@isc.org]=20 Sent: Thursday, January 04, 2007 4:25 PM To: dhcwg@ietf.org Subject: Re: [dhcwg] dhc wg last call on agentopt-delegateand srsn-optiondrafts On Thu, Jan 04, 2007 at 09:23:29AM -0800, Templin, Fred L wrote: > OK. Then, can you (or someone who was involved in the earlier > discussions) summarize what other issues might remain? I think you mean me. Thomas had a complaint about the use of the word 'reliable', which I understand to have been cleared up in the edits that brought SRSN (since that bit was edited to reference the new draft). I think it was only us two who said something, so that just leaves me. The vast exchange between Bernie and myself (throughout the entire history of same) can be summarized I hope without offense: 1) "Turning DHCPv6 into a kind of RIP-like thing" (my critique) is possibly not the most robust network design modern men can invent (alternatives given). a) But it may be the easiest to implement for CMTS people, especially since CMTS already have to implement DHCPv6 relays. b) And isn't specified in this option anyway. The entire question of what you do with the contents of this option are left to implementors. It might just program an ACL for a formal routing protocol (although at least this purpose is one that does not strictly require the SRSN). 2) It falls down in multiple-relay (failsafe, not chained) scenarios. a) But there are no multiple-relay scenarios for CMTS, for which this is being designed. Such network designs have 'cold spares' not 'running peers' for fault tolerance. b) And our volunteer is, understandably, unwilling to design for multiple-relays. So there are arguments either way. For the record, I am abstaining from this WGLC, so nothing I just said or am about to say should be taken in support or objection, I just wanted to sum up for Fred. Overall, I'm a critic of the madness rather than the method. The view these discussions have afforded me into this sort of madness makes me rather glad I never worked for a Cable ISP. I can't imagine actually craving the situation where I ask a "router" to perform its duty without using a formal routing protocol, because the alternative is too horrid to imagine. In networks I have worked at, we've always had the opposite problem: lack of adequate routing protocol support being the horror we wished to escape [1]. But there you have it, and I accept it. That's where these CMTS operators are. I cannot speak in support, for then I am helping lock the cage they are trapped in, even if they say they like the decor. I cannot speak in objection, for then I am holding from them a coping mechanism. [1] On request, I can supply my copy of "OSPF", a song set to the tune of "YMCA" by _The Village People_. It was writ, and oft sung over beer, by a group of people who had the misfortune of working with me for a company with ~300 Ascends (and we RMA'd 30 a month). There is, of course, a much longer (but equally irrelevant) backstory behind its creation. --=20 David W. Hankins "If you don't do it right the first time, Software Engineer you'll just have to do it again." Internet Systems Consortium, Inc. -- Jack T. Hankins _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Fri Jan 05 09:31:56 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2q6d-0004yF-BX; Fri, 05 Jan 2007 09:31:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2q6c-0004x8-RH for dhcwg@ietf.org; Fri, 05 Jan 2007 09:31:38 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2q6b-00035A-8p for dhcwg@ietf.org; Fri, 05 Jan 2007 09:31:38 -0500 Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-4.cisco.com with ESMTP; 05 Jan 2007 06:31:36 -0800 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-8.cisco.com (8.12.11/8.12.11) with ESMTP id l05EVaIj010883; Fri, 5 Jan 2007 06:31:36 -0800 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l05EVUIp016286; Fri, 5 Jan 2007 06:31:32 -0800 (PST) Received: from xmb-rtp-20a.amer.cisco.com ([64.102.31.15]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 5 Jan 2007 09:31:31 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [dhcwg] RFC 3633 Question Date: Fri, 5 Jan 2007 09:27:37 -0500 Message-ID: <8E296595B6471A4689555D5D725EBB2102EC1D8E@xmb-rtp-20a.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dhcwg] RFC 3633 Question thread-index: AccwjbuKg5nL4vjLTIm1QOh42b0lVgAR166w From: "Bernie Volz \(volz\)" To: "Archimedes S. Gaviola" , X-OriginalArrivalTime: 05 Jan 2007 14:31:31.0436 (UTC) FILETIME=[3176EAC0:01C730D6] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=5134; t=1168007496; x=1168871496; c=relaxed/relaxed; s=sjdkim8002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=volz@cisco.com; z=From:=20=22Bernie=20Volz=20\(volz\)=22=20 |Subject:=20RE=3A=20[dhcwg]=20RFC=203633=20Question |Sender:=20; bh=eBkJakcVbyebonATiwoTJoQznL1uZqE50loceD7/fFM=; b=qDpSUm4v/UQ0doWLdFnFN1zKn85RzeSdBKRPQ5VqZZ5jm+gIlh1GRton64B4CPadvdVi5Nbz riz8vLJ7grJzH6chTPpBodMeUY2DHoZXUrhfXMGghfOlaTh0cuFWkWNf; Authentication-Results: sj-dkim-8; header.From=volz@cisco.com; dkim=pass (si g from cisco.com/sjdkim8002 verified; ); X-Spam-Score: 0.1 (/) X-Scan-Signature: b2809b6f39decc6de467dcf252f42af1 Cc: X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2127075419==" Errors-To: dhcwg-bounces@ietf.org This is a multi-part message in MIME format. --===============2127075419== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C730D6.3140CA92" This is a multi-part message in MIME format. ------_=_NextPart_001_01C730D6.3140CA92 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable In IPv6, routers communicate the routing information via Routing Advertisements (see RFCs 2461 and 2462). There is no need for DHCPv6 to do this. (And if you don't have a router, why do you need any routing information.) This type of functionality (Routing Advertisements) doesn't really exist in IPv4, hence DHCPv4 needed to communicate this information. =20 Prefix delegation is primarily design for use by routers, not hosts (unless a host is also serving as a router). =20 - Bernie ________________________________ From: Archimedes S. Gaviola [mailto:agaviola@infoweapons.com]=20 Sent: Friday, January 05, 2007 12:53 AM To: dhcwg@ietf.org Subject: [dhcwg] RFC 3633 Question Hi! Based on RFC 3633 - IPv6 Prefix Options for DHCPv6, the specified nodes involved in the operation are routers such as the requesting router - the router that acts as a DHCP client that is requesting for prefix(es) and a delegating router that acts as the DHCP server. My question are, thus the option (IA_PD) mentioned here is only intended when DHCP is running on a router ( a packet forwarding node) and not on a host ( non-forwarding packet node)? Is there a DHCPv6 option for specifying gateway or router just like in IPv4 when a DHCPv6 is running on a non-forwarding packet node, in which it will provide options for routers? =20 Thank you very much. =20 Archimedes S. Gaviola Network Engineer InfoWeapons Corporation ------_=_NextPart_001_01C730D6.3140CA92 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable
In IPv6, routers communicate the routing = information via=20 Routing Advertisements (see RFCs 2461 and 2462). There is no need = for=20 DHCPv6 to do this. (And if you don't have a router, why do you need any = routing=20 information.) This type of functionality (Routing Advertisements) = doesn't really=20 exist in IPv4, hence DHCPv4 needed to communicate this=20 information.
 
Prefix delegation is primarily design for use = by routers,=20 not hosts (unless a host is also serving as a = router).
 
- Bernie

From: Archimedes S. Gaviola=20 [mailto:agaviola@infoweapons.com]
Sent: Friday, January 05, = 2007=20 12:53 AM
To: dhcwg@ietf.org
Subject: [dhcwg] RFC = 3633=20 Question

Hi!=20 Based=20 on RFC 3633 - IPv6 Prefix Options for DHCPv6, = the specified nodes=20 involved in the operation are routers such as the requesting router - = the router=20 that acts as a DHCP client that is requesting for prefix(es) and=20 a delegating router that acts as the DHCP server. My question are, = thus the=20 option (IA_PD) mentioned here is only intended when DHCP is = running on=20 a router ( a packet forwarding node) and not on a host ( non-forwarding = packet=20 node)?  Is there a DHCPv6 option for specifying gateway or router = just like=20 in IPv4 when a DHCPv6 is running on a non-forwarding = packet node, in=20 which it will provide options for routers?
 
Thank = you very=20 much.
 
Archimedes S.=20 Gaviola
Network=20 Engineer
InfoWeapons=20 Corporation
------_=_NextPart_001_01C730D6.3140CA92-- --===============2127075419== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg --===============2127075419==-- From dhcwg-bounces@ietf.org Fri Jan 05 09:31:56 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2q6a-0004lQ-1a; Fri, 05 Jan 2007 09:31:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2q6Y-0004il-Hp for dhcwg@ietf.org; Fri, 05 Jan 2007 09:31:34 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2q6W-00034s-2j for dhcwg@ietf.org; Fri, 05 Jan 2007 09:31:34 -0500 Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-5.cisco.com with ESMTP; 05 Jan 2007 06:31:31 -0800 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-8.cisco.com (8.12.11/8.12.11) with ESMTP id l05EVV3s010841; Fri, 5 Jan 2007 06:31:31 -0800 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l05EVUIl016286; Fri, 5 Jan 2007 06:31:31 -0800 (PST) Received: from xmb-rtp-20a.amer.cisco.com ([64.102.31.15]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 5 Jan 2007 09:31:30 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [dhcwg] dhc wg last call on agentopt-delegateand srsn-optiondrafts Date: Fri, 5 Jan 2007 09:30:27 -0500 Message-ID: <8E296595B6471A4689555D5D725EBB2102EC1D8D@xmb-rtp-20a.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dhcwg] dhc wg last call on agentopt-delegateand srsn-optiondrafts thread-index: AccwRxx9R7oz5DskRUaweFku9rWcaAAjRjwA From: "Bernie Volz \(volz\)" To: "David W. Hankins" , X-OriginalArrivalTime: 05 Jan 2007 14:31:30.0780 (UTC) FILETIME=[3112D1C0:01C730D6] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4067; t=1168007491; x=1168871491; c=relaxed/relaxed; s=sjdkim8002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=volz@cisco.com; z=From:=20=22Bernie=20Volz=20\(volz\)=22=20 |Subject:=20RE=3A=20[dhcwg]=20dhc=20wg=20last=20call=20on=20agentopt-dele gateand=09srsn-optiondrafts |Sender:=20; bh=kM6cCNh2tDthOwXlIdat7fhy6wVMgbLJYHYslxeg6u8=; b=M+vUwirNI94SIFd+lOS+QLemX0o7sBEB3a2jogx5ifWCKx1ff+G3BvDrZY1YaHJp/QFfVepV tr71yW/nB1zYfKowgFwtjR6eecvViCp92fxkq6A1+P8fBpwN/1LDnJlL; Authentication-Results: sj-dkim-8; header.From=volz@cisco.com; dkim=pass (si g from cisco.com/sjdkim8002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b Cc: X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org David: In a multiple relay (well, really router since we're talking about routing) situation, the routers need to have some protocol to communicate with each other and it is assumed that is how that is handled. This is no different than the initial lease (which likely is communicated via only one path); it is no different than other learned routes. If you have multiple partners participating, you need to have some way to distribute the information between them. This is left to the routers and is not up to DHCP to do, IMHO. Unless you have the DHCP server itself participate in the routing protocols, you really have no other options? If you were designing this, what would you do? - Bernie -----Original Message----- From: David W. Hankins [mailto:David_Hankins@isc.org]=20 Sent: Thursday, January 04, 2007 4:25 PM To: dhcwg@ietf.org Subject: Re: [dhcwg] dhc wg last call on agentopt-delegateand srsn-optiondrafts On Thu, Jan 04, 2007 at 09:23:29AM -0800, Templin, Fred L wrote: > OK. Then, can you (or someone who was involved in the earlier > discussions) summarize what other issues might remain? I think you mean me. Thomas had a complaint about the use of the word 'reliable', which I understand to have been cleared up in the edits that brought SRSN (since that bit was edited to reference the new draft). I think it was only us two who said something, so that just leaves me. The vast exchange between Bernie and myself (throughout the entire history of same) can be summarized I hope without offense: 1) "Turning DHCPv6 into a kind of RIP-like thing" (my critique) is possibly not the most robust network design modern men can invent (alternatives given). a) But it may be the easiest to implement for CMTS people, especially since CMTS already have to implement DHCPv6 relays. b) And isn't specified in this option anyway. The entire question of what you do with the contents of this option are left to implementors. It might just program an ACL for a formal routing protocol (although at least this purpose is one that does not strictly require the SRSN). 2) It falls down in multiple-relay (failsafe, not chained) scenarios. a) But there are no multiple-relay scenarios for CMTS, for which this is being designed. Such network designs have 'cold spares' not 'running peers' for fault tolerance. b) And our volunteer is, understandably, unwilling to design for multiple-relays. So there are arguments either way. For the record, I am abstaining from this WGLC, so nothing I just said or am about to say should be taken in support or objection, I just wanted to sum up for Fred. Overall, I'm a critic of the madness rather than the method. The view these discussions have afforded me into this sort of madness makes me rather glad I never worked for a Cable ISP. I can't imagine actually craving the situation where I ask a "router" to perform its duty without using a formal routing protocol, because the alternative is too horrid to imagine. In networks I have worked at, we've always had the opposite problem: lack of adequate routing protocol support being the horror we wished to escape [1]. But there you have it, and I accept it. That's where these CMTS operators are. I cannot speak in support, for then I am helping lock the cage they are trapped in, even if they say they like the decor. I cannot speak in objection, for then I am holding from them a coping mechanism. [1] On request, I can supply my copy of "OSPF", a song set to the tune of "YMCA" by _The Village People_. It was writ, and oft sung over beer, by a group of people who had the misfortune of working with me for a company with ~300 Ascends (and we RMA'd 30 a month). There is, of course, a much longer (but equally irrelevant) backstory behind its creation. --=20 David W. Hankins "If you don't do it right the first time, Software Engineer you'll just have to do it again." Internet Systems Consortium, Inc. -- Jack T. Hankins _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Fri Jan 05 09:31:56 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2q6d-0004yF-BX; Fri, 05 Jan 2007 09:31:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2q6c-0004x8-RH for dhcwg@ietf.org; Fri, 05 Jan 2007 09:31:38 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2q6b-00035A-8p for dhcwg@ietf.org; Fri, 05 Jan 2007 09:31:38 -0500 Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-4.cisco.com with ESMTP; 05 Jan 2007 06:31:36 -0800 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-8.cisco.com (8.12.11/8.12.11) with ESMTP id l05EVaIj010883; Fri, 5 Jan 2007 06:31:36 -0800 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l05EVUIp016286; Fri, 5 Jan 2007 06:31:32 -0800 (PST) Received: from xmb-rtp-20a.amer.cisco.com ([64.102.31.15]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 5 Jan 2007 09:31:31 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [dhcwg] RFC 3633 Question Date: Fri, 5 Jan 2007 09:27:37 -0500 Message-ID: <8E296595B6471A4689555D5D725EBB2102EC1D8E@xmb-rtp-20a.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dhcwg] RFC 3633 Question thread-index: AccwjbuKg5nL4vjLTIm1QOh42b0lVgAR166w From: "Bernie Volz \(volz\)" To: "Archimedes S. Gaviola" , X-OriginalArrivalTime: 05 Jan 2007 14:31:31.0436 (UTC) FILETIME=[3176EAC0:01C730D6] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=5134; t=1168007496; x=1168871496; c=relaxed/relaxed; s=sjdkim8002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=volz@cisco.com; z=From:=20=22Bernie=20Volz=20\(volz\)=22=20 |Subject:=20RE=3A=20[dhcwg]=20RFC=203633=20Question |Sender:=20; bh=eBkJakcVbyebonATiwoTJoQznL1uZqE50loceD7/fFM=; b=qDpSUm4v/UQ0doWLdFnFN1zKn85RzeSdBKRPQ5VqZZ5jm+gIlh1GRton64B4CPadvdVi5Nbz riz8vLJ7grJzH6chTPpBodMeUY2DHoZXUrhfXMGghfOlaTh0cuFWkWNf; Authentication-Results: sj-dkim-8; header.From=volz@cisco.com; dkim=pass (si g from cisco.com/sjdkim8002 verified; ); X-Spam-Score: 0.1 (/) X-Scan-Signature: b2809b6f39decc6de467dcf252f42af1 Cc: X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2127075419==" Errors-To: dhcwg-bounces@ietf.org This is a multi-part message in MIME format. --===============2127075419== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C730D6.3140CA92" This is a multi-part message in MIME format. ------_=_NextPart_001_01C730D6.3140CA92 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable In IPv6, routers communicate the routing information via Routing Advertisements (see RFCs 2461 and 2462). There is no need for DHCPv6 to do this. (And if you don't have a router, why do you need any routing information.) This type of functionality (Routing Advertisements) doesn't really exist in IPv4, hence DHCPv4 needed to communicate this information. =20 Prefix delegation is primarily design for use by routers, not hosts (unless a host is also serving as a router). =20 - Bernie ________________________________ From: Archimedes S. Gaviola [mailto:agaviola@infoweapons.com]=20 Sent: Friday, January 05, 2007 12:53 AM To: dhcwg@ietf.org Subject: [dhcwg] RFC 3633 Question Hi! Based on RFC 3633 - IPv6 Prefix Options for DHCPv6, the specified nodes involved in the operation are routers such as the requesting router - the router that acts as a DHCP client that is requesting for prefix(es) and a delegating router that acts as the DHCP server. My question are, thus the option (IA_PD) mentioned here is only intended when DHCP is running on a router ( a packet forwarding node) and not on a host ( non-forwarding packet node)? Is there a DHCPv6 option for specifying gateway or router just like in IPv4 when a DHCPv6 is running on a non-forwarding packet node, in which it will provide options for routers? =20 Thank you very much. =20 Archimedes S. Gaviola Network Engineer InfoWeapons Corporation ------_=_NextPart_001_01C730D6.3140CA92 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable
In IPv6, routers communicate the routing = information via=20 Routing Advertisements (see RFCs 2461 and 2462). There is no need = for=20 DHCPv6 to do this. (And if you don't have a router, why do you need any = routing=20 information.) This type of functionality (Routing Advertisements) = doesn't really=20 exist in IPv4, hence DHCPv4 needed to communicate this=20 information.
 
Prefix delegation is primarily design for use = by routers,=20 not hosts (unless a host is also serving as a = router).
 
- Bernie

From: Archimedes S. Gaviola=20 [mailto:agaviola@infoweapons.com]
Sent: Friday, January 05, = 2007=20 12:53 AM
To: dhcwg@ietf.org
Subject: [dhcwg] RFC = 3633=20 Question

Hi!=20 Based=20 on RFC 3633 - IPv6 Prefix Options for DHCPv6, = the specified nodes=20 involved in the operation are routers such as the requesting router - = the router=20 that acts as a DHCP client that is requesting for prefix(es) and=20 a delegating router that acts as the DHCP server. My question are, = thus the=20 option (IA_PD) mentioned here is only intended when DHCP is = running on=20 a router ( a packet forwarding node) and not on a host ( non-forwarding = packet=20 node)?  Is there a DHCPv6 option for specifying gateway or router = just like=20 in IPv4 when a DHCPv6 is running on a non-forwarding = packet node, in=20 which it will provide options for routers?
 
Thank = you very=20 much.
 
Archimedes S.=20 Gaviola
Network=20 Engineer
InfoWeapons=20 Corporation
------_=_NextPart_001_01C730D6.3140CA92-- --===============2127075419== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg --===============2127075419==-- From dhcwg-bounces@ietf.org Fri Jan 05 15:28:08 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2vex-00042k-32; Fri, 05 Jan 2007 15:27:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2vev-00041D-KX for dhcwg@ietf.org; Fri, 05 Jan 2007 15:27:25 -0500 Received: from paoakoavas10.cable.comcast.com ([208.17.35.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2veq-0003Bw-CW for dhcwg@ietf.org; Fri, 05 Jan 2007 15:27:25 -0500 Received: from ([24.40.15.92]) by paoakoavas10.cable.comcast.com with ESMTP id KP-TDCH3.29138399; Fri, 05 Jan 2007 15:26:55 -0500 Received: from PACDCEXCMB05.cable.comcast.com ([24.40.15.116]) by PACDCEXCSMTP03.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 5 Jan 2007 15:26:55 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [dhcwg] WG last calls on several WG documents Date: Fri, 5 Jan 2007 15:26:54 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dhcwg] WG last calls on several WG documents Thread-Index: Accizd8ZHcHZpo7BEduE6QARJOT6egOOK67Q From: "Woundy, Richard" To: "dhcwg" X-OriginalArrivalTime: 05 Jan 2007 20:26:55.0290 (UTC) FILETIME=[D778D1A0:01C73107] X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Cc: Stig Venaas , Ralph Droms X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org I support moving forward with all four drafts: draft-ietf-dhc-dhcvp6-leasequery-01 draft-ietf-dhc-dhcpv6-ero-00 draft-ietf-dhc-dhcpv6-agentopt-delegate-02 draft-ietf-dhc-dhcpv6-srsn-option-00 -- Rich -----Original Message----- From: Ralph Droms [mailto:rdroms@cisco.com]=20 Sent: Monday, December 18, 2006 12:57 PM To: dhcwg Cc: Stig Venaas Subject: [dhcwg] WG last calls on several WG documents 3rd try - So far, we've only received responses as summarized below. We need additional positive support (from others than draft authors!) to move forward with these draft. - Ralph =3D=3D=3D=3D=3D We need to confirm WG consensus in support of holding WG last calls on several dhc WG documents that were discussed at the WG meeting in San Diego. The first four of these documents are: draft-ietf-dhc-dhcpv6-agentopt-delegate-01 DHCPv6 Relay Agent Assignment Notification (RAAN) Option Yes - Fred Templin Yes - David Hankins Yes - John Brzozowski Yes - Bernie Volz (author) draft-ietf-dhc-dhcpv6-srsn-option-00 DHCPv6 Server Reply Sequence Number Option Yes - Fred Templin No opinion - David Hankins Yes - John Brzozowski Yes - Bernie Volz (author) draft-ietf-dhc-dhcpv6-ero-00 DHCPv6 Relay Agent Echo Request Option No opinion - Fred Templin Yes - David Hankins Yes - John Brzozowski (author) Yes - Bernie Volz (author) draft-ietf-dhc-dhcvp6-leasequery-00 DHCPv6 Leasequery No opinion - Fred Templin Yes - David Hankins Yes - John Brzozowski (author) Yes - Bernie Volz (author) If you have any objections to a WG last call for any of these documents, please respond to the mailing list. If you are in agreement that these documents are ready for WG last call, send a positive ACK to the mailing list so we can assess support for those last calls. We will review the responses received by Mon, Nov 27 and initiate the supported WG last calls at that time. - Ralph _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Sat Jan 06 04:19:17 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H37gy-0001Nk-4t; Sat, 06 Jan 2007 04:18:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H37gw-0001I8-Mr for dhcwg@ietf.org; Sat, 06 Jan 2007 04:18:18 -0500 Received: from ironmail.infoweapons.com ([58.71.34.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H37gt-00013h-7b for dhcwg@ietf.org; Sat, 06 Jan 2007 04:18:18 -0500 Received: (qmail 13864 invoked by uid 98); 6 Jan 2007 09:18:06 -0000 Received: from 10.3.2.11 by ironmail.cebu.infoweapons.com (envelope-from , uid 82) with qmail-scanner-1.25 (clamdscan: 0.86.1/959. spamassassin: 3.0.4. Clear:RC:1(10.3.2.11):. Processed in 0.170576 secs); 06 Jan 2007 09:18:06 -0000 X-Qmail-Scanner-Mail-From: agaviola@infoweapons.com via ironmail.cebu.infoweapons.com X-Qmail-Scanner: 1.25 (Clear:RC:1(10.3.2.11):. Processed in 0.170576 secs) Received: from archimedes.cebu.infoweapons.com (HELO archimedes) (agaviola@10.3.2.11) by ironmail.infoweapons.com with SMTP; 6 Jan 2007 09:18:06 -0000 From: "Archimedes S. Gaviola" To: "'Bernie Volz \(volz\)'" , Subject: RE: [dhcwg] RFC 3633 Question Date: Sat, 6 Jan 2007 17:15:41 +0800 Message-ID: <002601c73173$4c801150$0b02030a@cebu.infoweapons.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 Thread-Index: AccwjbuKg5nL4vjLTIm1QOh42b0lVgAR166wACdednA= In-Reply-To: <8E296595B6471A4689555D5D725EBB2102EC1D8E@xmb-rtp-20a.amer.cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 0.0 (/) X-Scan-Signature: cdeeb24e6b743a852c396a4af0e53c8f Cc: X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0464037120==" Errors-To: dhcwg-bounces@ietf.org This is a multi-part message in MIME format. --===============0464037120== Content-Type: multipart/signed; boundary="----=_NextPart_000_001E_01C731B6.4AFDE2B0"; protocol="application/x-pkcs7-signature"; micalg=SHA1 This is a multi-part message in MIME format. ------=_NextPart_000_001E_01C731B6.4AFDE2B0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_001F_01C731B6.4AFDE2B0" ------=_NextPart_001_001F_01C731B6.4AFDE2B0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sir Bernie, Thank you very much for answering my question. It's enough for me to know that prefix delegation is design for routers. I really appreciate it. Sincerely Yours, Archimedes S. Gaviola Network Engineer InfoWeapons Corporation _____ From: Bernie Volz (volz) [mailto:volz@cisco.com] Sent: Friday, January 05, 2007 10:28 PM To: Archimedes S. Gaviola; dhcwg@ietf.org Subject: RE: [dhcwg] RFC 3633 Question In IPv6, routers communicate the routing information via Routing Advertisements (see RFCs 2461 and 2462). There is no need for DHCPv6 to do this. (And if you don't have a router, why do you need any routing information.) This type of functionality (Routing Advertisements) doesn't really exist in IPv4, hence DHCPv4 needed to communicate this information. Prefix delegation is primarily design for use by routers, not hosts (unless a host is also serving as a router). - Bernie _____ From: Archimedes S. Gaviola [mailto:agaviola@infoweapons.com] Sent: Friday, January 05, 2007 12:53 AM To: dhcwg@ietf.org Subject: [dhcwg] RFC 3633 Question Hi! Based on RFC 3633 - IPv6 Prefix Options for DHCPv6, the specified nodes involved in the operation are routers such as the requesting router - the router that acts as a DHCP client that is requesting for prefix(es) and a delegating router that acts as the DHCP server. My question are, thus the option (IA_PD) mentioned here is only intended when DHCP is running on a router ( a packet forwarding node) and not on a host ( non-forwarding packet node)? Is there a DHCPv6 option for specifying gateway or router just like in IPv4 when a DHCPv6 is running on a non-forwarding packet node, in which it will provide options for routers? Thank you very much. Archimedes S. Gaviola Network Engineer InfoWeapons Corporation ------=_NextPart_001_001F_01C731B6.4AFDE2B0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Sir Bernie,
 
Thank you very much for answering my question. = It's enough=20 for me to know that prefix delegation is design for routers. I really = appreciate=20 it.
 
Sincerely Yours,
 
Archimedes S. Gaviola
Network Engineer
InfoWeapons Corporation

From: Bernie Volz (volz) = [mailto:volz@cisco.com]=20
Sent: Friday, January 05, 2007 10:28 PM
To: = Archimedes S.=20 Gaviola; dhcwg@ietf.org
Subject: RE: [dhcwg] RFC 3633=20 Question

In IPv6, routers communicate the routing = information via=20 Routing Advertisements (see RFCs 2461 and 2462). There is no need = for=20 DHCPv6 to do this. (And if you don't have a router, why do you need any = routing=20 information.) This type of functionality (Routing Advertisements) = doesn't really=20 exist in IPv4, hence DHCPv4 needed to communicate this=20 information.
 
Prefix delegation is primarily design for use = by routers,=20 not hosts (unless a host is also serving as a = router).
 
- Bernie

From: Archimedes S. Gaviola=20 [mailto:agaviola@infoweapons.com]
Sent: Friday, January 05, = 2007=20 12:53 AM
To: dhcwg@ietf.org
Subject: [dhcwg] RFC = 3633=20 Question

Hi!=20 Based=20 on RFC 3633 - IPv6 Prefix Options for DHCPv6, = the specified nodes=20 involved in the operation are routers such as the requesting router - = the router=20 that acts as a DHCP client that is requesting for prefix(es) and=20 a delegating router that acts as the DHCP server. My question are, = thus the=20 option (IA_PD) mentioned here is only intended when DHCP is = running on=20 a router ( a packet forwarding node) and not on a host ( non-forwarding = packet=20 node)?  Is there a DHCPv6 option for specifying gateway or router = just like=20 in IPv4 when a DHCPv6 is running on a non-forwarding = packet node, in=20 which it will provide options for routers?
 
Thank = you very=20 much.
 
Archimedes S.=20 Gaviola
Network=20 Engineer
InfoWeapons=20 Corporation
------=_NextPart_001_001F_01C731B6.4AFDE2B0-- ------=_NextPart_000_001E_01C731B6.4AFDE2B0 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJYjCCAuow ggJToAMCAQICECmNETAKqQm550Zef1ntdl4wDQYJKoZIhvcNAQEEBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA2MDUwMjA3MTMyNloXDTA3MDUwMjA3MTMy NlowSjEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEnMCUGCSqGSIb3DQEJARYYYWdh dmlvbGFAaW5mb3dlYXBvbnMuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA8PJB ajTVS2g92hOKLubcYz4P9wru799XXKdtZVnsPYbg07N+Nro7h9tSaXwnunfUD9ot+oMjsEnAmdK6 evVqUKr7J9SgAoEWItQDrZ6Bn3OxLExNoKLik2DU4KsWr1n0NFU3lcVip0kGDWJZTyKIgcsk0JCX 8F+htKZefh/zT3ArzwF1rCMRimeIngINW89PfWObOZfj5ZY+Yt0Y+CTCXNmTyHDArid/ZsDTQ98j GLTt/ysiuvL3hUxQ5DZVXxFHiFO+V2zE4zqss1rEmDcQAjyFlYfeZs9Xgy83a2H343OvUn0LG/7p 7mrXqUC8ajmAX9xn2Sz2uX1bBi5GNWPRywIDAQABozUwMzAjBgNVHREEHDAagRhhZ2F2aW9sYUBp bmZvd2VhcG9ucy5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQQFAAOBgQCLxOytH7FV8ZuW kXmUmMqNKaXIDwcYvncUf/1Ds++GSUFAB9uIkFigTc1UlOMDHO8Cjt6MoJdsuf3RsBS/rW+SRE3i kjMJJmgwg/cQRC+vr5Pd6MBnBWquhPxVq0bOetmibhbGj35RuXWwwP0yUFvw6evzKrEO37T5cADL 7GHIqzCCAy0wggKWoAMCAQICAQAwDQYJKoZIhvcNAQEEBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYD VQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENv bnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNV BAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwt ZnJlZW1haWxAdGhhd3RlLmNvbTAeFw05NjAxMDEwMDAwMDBaFw0yMDEyMzEyMzU5NTlaMIHRMQsw CQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xGjAY BgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgwJgYDVQQLEx9DZXJ0aWZpY2F0aW9uIFNlcnZpY2Vz IERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgQ0ExKzApBgkqhkiG 9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRoYXd0ZS5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0A MIGJAoGBANRp19SwlGRbcelH2AxRtupykbCEXn0tDY97Et+FJXUodDpCLGMnn5V7S+9+GYcdhuqj 3bnOlmQawhRuRKx85o/oTQ9xH0A4pgCjh3j2+ZSGXq3qwF5269kUo11uenwMpUtVfwYZKX+emibV ars4JAhqmMex2qOYkf152+VaxBy5AgMBAAGjEzARMA8GA1UdEwEB/wQFMAMBAf8wDQYJKoZIhvcN AQEEBQADgYEAx+ySfk749ZalZ2IqpPBNEWDQb41gWGGsJrtSNVwIzzD7qEqWih9iQiOMFw/0umSc F6xHKd+dmF7SbGBxXKKs3Hnj524ARx+1DSjoAp3kmv0T9KbZfLH43F8jJgmRgHPQFBveQ6mDJfLm nC8Vyv6mq4oHdYsM3VGEa+T40c53ooEwggM/MIICqKADAgECAgENMA0GCSqGSIb3DQEBBQUAMIHR MQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYDVQQHEwlDYXBlIFRvd24x GjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgwJgYDVQQLEx9DZXJ0aWZpY2F0aW9uIFNlcnZp Y2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgQ0ExKzApBgkq hkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRoYXd0ZS5jb20wHhcNMDMwNzE3MDAwMDAwWhcN MTMwNzE2MjM1OTU5WjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcg KFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0Ew gZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMSmPFVzVftOucqZWh5owHUEcJ3f6f+jHuy9zfVb 8hp2vX8MOmHyv1HOAdTlUAow1wJjWiyJFXCO3cnwK4Vaqj9xVsuvPAsH5/EfkTYkKhPPK9Xzgnc9 A74r/rsYPge/QIACZNenprufZdHFKlSFD0gEf6e20TxhBEAeZBlyYLf7AgMBAAGjgZQwgZEwEgYD VR0TAQH/BAgwBgEB/wIBADBDBgNVHR8EPDA6MDigNqA0hjJodHRwOi8vY3JsLnRoYXd0ZS5jb20v VGhhd3RlUGVyc29uYWxGcmVlbWFpbENBLmNybDALBgNVHQ8EBAMCAQYwKQYDVR0RBCIwIKQeMBwx GjAYBgNVBAMTEVByaXZhdGVMYWJlbDItMTM4MA0GCSqGSIb3DQEBBQUAA4GBAEiM0VCD6gsuzA2j ZqxnD3+vrL7CF6FDlpSdf0whuPg2H6otnzYvwPQcUCCTcDz9reFhYsPZOhl+hLGZGwDFGguCdJ4l UJRix9sncVcljd2pnDmOjCBPZV+V2vf3h9bGCE6u9uo05RAaWzVNd+NWIXiC3CEZNd4ksdMdRv9d X2VPMYIDeTCCA3UCAQEwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRp bmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vpbmcg Q0ECECmNETAKqQm550Zef1ntdl4wCQYFKw4DAhoFAKCCAdgwGAYJKoZIhvcNAQkDMQsGCSqGSIb3 DQEHATAcBgkqhkiG9w0BCQUxDxcNMDcwMTA2MDkxNTQxWjAjBgkqhkiG9w0BCQQxFgQUFCzqn2v0 534GFrRDm0qUN05ViOMwZwYJKoZIhvcNAQkPMVowWDAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgIC AIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwBwYFKw4DAhowCgYIKoZI hvcNAgUwgYUGCSsGAQQBgjcQBDF4MHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBD b25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJ c3N1aW5nIENBAhApjREwCqkJuedGXn9Z7XZeMIGHBgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1Ro YXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhApjREwCqkJuedGXn9Z7XZeMA0GCSqG SIb3DQEBAQUABIIBAIK1wbHbbIJ+7gYBe4NisYxP9T1mPuvZlpR94+PKgBd95tCtjrznmXU7mvIE XgzG6c2mavwomD/89TZtKOcfWOKhmbc0qE6reMCp09GL1A/wdu8y32f7sClqjczfV8Q12uFLdWG7 M/Nwdq6+gQAJgyvimVj1BCpWeuMpeQy1hY91pyNGEBnJqChe3pDCT+VSM9jE/NncXxYCC/pKtCVN 4FcJO3t/QnWUH4YEekxZO/QTRbqfiRtek2qsgZdOAq4+oy4VqjriDZkjZWS050o80f1MOf8uAwoo OyPulrVTM1ms699/DkcimOHkwb77hVD5I/18axVPCXCV76kgZWWxF5EAAAAAAAA= ------=_NextPart_000_001E_01C731B6.4AFDE2B0-- --===============0464037120== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg --===============0464037120==-- From dhcwg-bounces@ietf.org Mon Jan 08 18:15:41 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H43hu-0001HI-4d; Mon, 08 Jan 2007 18:15:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H43ht-0001HD-2k for dhcwg@ietf.org; Mon, 08 Jan 2007 18:15:09 -0500 Received: from [2001:4f8:3:bb:20c:76ff:fe16:4040] (helo=goliath.isc.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H43hs-0000Ur-Dh for dhcwg@ietf.org; Mon, 08 Jan 2007 18:15:09 -0500 Received: by goliath.isc.org (Postfix, from userid 10200) id 09AB55A6ED; Mon, 8 Jan 2007 15:15:04 -0800 (PST) Date: Mon, 8 Jan 2007 15:15:03 -0800 From: "David W. Hankins" To: dhcwg@ietf.org Subject: Re: [dhcwg] dhc wg last call on agentopt-delegateand srsn-optiondrafts Message-ID: <20070108231503.GB21620@isc.org> References: <8E296595B6471A4689555D5D725EBB2102EC1D8D@xmb-rtp-20a.amer.cisco.com> Mime-Version: 1.0 In-Reply-To: <8E296595B6471A4689555D5D725EBB2102EC1D8D@xmb-rtp-20a.amer.cisco.com> User-Agent: Mutt/1.5.9i X-Spam-Score: -2.8 (--) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0441329413==" Errors-To: dhcwg-bounces@ietf.org --===============0441329413== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="SLDf9lqlvOQaIe6s" Content-Disposition: inline --SLDf9lqlvOQaIe6s Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Fri, Jan 05, 2007 at 09:30:27AM -0500, Bernie Volz (volz) wrote: > Unless you have the DHCP server itself participate in the routing > protocols, you really have no other options? I'm not aware of a better alternative, no. Having the clients perform the injection of the route is tantalizing, but unrealistic with the current tools available. That does leave only the DHCPv6 server as the last remaining party to perform the injection, and as I think I detailed in past exchanges I would have preferred my own network behave that way. But as you and others have pointed out, that will not work so long as the last leg between your final "router (really)" and "DHCPv6 client" is served by a device that is "a router that doesn't participate in local dynamic routing protocols." Eg the "i" variety of BGP. > If you were designing this, what would you do? Probably go insane! The very requirements you are working with, Bernie, are to effect dynamic routing in a network without using any heretofore widely tested and deployed dynamic routing protocol. It is to me, madness. I would not come out of that sane, and it is a statement to your endurance that you at least appear to have. It is very much like asking someone to drink water from a tap without using any of the array of glasses locked behind the counter, but rather only what you have on your person as you approached the bar. I believe our species did not die of thirst before we learned how to mold glass. So too did we route. I seem to recall living through that era of mankind's digital evolution. But I also don't think we would consider the suggestion that cupped hands might be used to intake liquids to be a keen idea all around, now that we've already experienced more modern contrivances. So too do I look with great suspicion upon this architecture and design. As a dynamic routing protocol, I find it not merely wanting, but reminiscent of historic devices that caused me, personally, ceaseless pain. The idea of operating a network with a dynamic routing protocol that looks remarkably similar to RIP is no more appealing to me than drinking coffee with cupped hands. But really what we should talk about is that the problem your draft solves is symptomatic of a deeper problem. Which is the existence of "routers" that are beneath the task of participating in the local routing protocols, but above the task of merely operating their l2 magics. Obviously I think there are at least two solutions to that problem, one of which I might prefer...but I don't wield any power to influence it, nor do I think any of the rest of us can. And so I abstain (more vocally than I would have liked). -- David W. Hankins "If you don't do it right the first time, Software Engineer you'll just have to do it again." Internet Systems Consortium, Inc. -- Jack T. Hankins --SLDf9lqlvOQaIe6s Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFFotB3cXeLeWu2vmoRAhm9AJ0SiXI2rcQpCZoNtTkKAyI3TNPpIgCgqAOG cZjZ8Fu62XOKSaEt1X5TPEE= =hSsm -----END PGP SIGNATURE----- --SLDf9lqlvOQaIe6s-- --===============0441329413== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg --===============0441329413==-- From dhcwg-bounces@ietf.org Thu Jan 11 07:22:47 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4ywl-0000yZ-0x; Thu, 11 Jan 2007 07:22:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4ywj-0000yF-CV for dhcwg@ietf.org; Thu, 11 Jan 2007 07:22:17 -0500 Received: from tyholt.uninett.no ([2001:700:1::eecb]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H4ywf-0000ce-99 for dhcwg@ietf.org; Thu, 11 Jan 2007 07:22:17 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by tyholt.uninett.no (Postfix) with ESMTP id 62ABC87BF2; Thu, 11 Jan 2007 13:22:05 +0100 (CET) Received: from tyholt.uninett.no ([127.0.0.1]) by localhost (tyholt.uninett.no [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 19064-01-17; Thu, 11 Jan 2007 13:22:05 +0100 (CET) Received: from [192.168.0.186] (unknown [217.206.93.211]) by tyholt.uninett.no (Postfix) with ESMTP id BB50C87BE7; Thu, 11 Jan 2007 13:22:04 +0100 (CET) Message-ID: <45A4FB93.20500@uninett.no> Date: Wed, 10 Jan 2007 15:43:31 +0100 From: Stig Venaas User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: "Woundy, Richard" Subject: Re: [dhcwg] WG last calls on several WG documents References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at uninett.no X-Spam-Score: 0.0 (/) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 Cc: dhcwg , Ralph Droms X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org Woundy, Richard wrote: > I support moving forward with all four drafts: > > draft-ietf-dhc-dhcvp6-leasequery-01 > draft-ietf-dhc-dhcpv6-ero-00 > draft-ietf-dhc-dhcpv6-agentopt-delegate-02 > draft-ietf-dhc-dhcpv6-srsn-option-00 Please note that Ralph asked this to verify consensus for starting last calls. Based on the positive input we got for agentopt-delegate and srsn-option we started a last call for those. Once that is completed we will see if we now also got sufficient support for starting last calls on leasequery and ero. So far we've got pretty positive responses to the last call for agentopt-delegate and srsn-option, but we still need further responses to move forward. So it would be good if you Richard, and also others in the working group, could respond to the last call on those two. See email I sent on Dec 29 with subject: dhc wg last call on agentopt-delegate and srsn-option drafts The deadline for the last call is 1700EST on Mon, 2007-01-15. Stig > > -- Rich > > -----Original Message----- > From: Ralph Droms [mailto:rdroms@cisco.com] > Sent: Monday, December 18, 2006 12:57 PM > To: dhcwg > Cc: Stig Venaas > Subject: [dhcwg] WG last calls on several WG documents > > > 3rd try - So far, we've only received responses as summarized below. We > need additional positive support (from others than draft authors!) to > move forward with these draft. > > - Ralph > > ===== > > We need to confirm WG consensus in support of holding WG last calls on > several dhc WG documents that were discussed at the WG meeting in San > Diego. > > The first four of these documents are: > > draft-ietf-dhc-dhcpv6-agentopt-delegate-01 > DHCPv6 Relay Agent Assignment Notification (RAAN) Option > Yes - Fred Templin > Yes - David Hankins > Yes - John Brzozowski > Yes - Bernie Volz (author) > > draft-ietf-dhc-dhcpv6-srsn-option-00 > DHCPv6 Server Reply Sequence Number Option > > Yes - Fred Templin > No opinion - David Hankins > Yes - John Brzozowski > Yes - Bernie Volz (author) > > draft-ietf-dhc-dhcpv6-ero-00 > DHCPv6 Relay Agent Echo Request Option > > No opinion - Fred Templin > Yes - David Hankins > Yes - John Brzozowski (author) > Yes - Bernie Volz (author) > > draft-ietf-dhc-dhcvp6-leasequery-00 > DHCPv6 Leasequery > > No opinion - Fred Templin > Yes - David Hankins > Yes - John Brzozowski (author) > Yes - Bernie Volz (author) > > If you have any objections to a WG last call for any of these documents, > please respond to the mailing list. If you are in agreement that these > documents are ready for WG last call, send a positive ACK to the mailing > list so we can assess support for those last calls. We will review the > responses received by Mon, Nov 27 and initiate the supported WG last > calls at that time. > > - Ralph > > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Fri Jan 12 17:34:21 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5Uy3-0006jY-VV; Fri, 12 Jan 2007 17:33:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5Uy2-0006if-BY for dhcwg@ietf.org; Fri, 12 Jan 2007 17:33:46 -0500 Received: from shell-ng.nominum.com ([81.200.64.181]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H5Uy0-0007ud-Vq for dhcwg@ietf.org; Fri, 12 Jan 2007 17:33:46 -0500 Received: from mail.nominum.com (mail.nominum.com [81.200.64.186]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by shell-ng.nominum.com (Postfix) with ESMTP id 5341A56875; Fri, 12 Jan 2007 14:33:37 -0800 (PST) (envelope-from Ted.Lemon@nominum.com) X-Spam-Status: No, hits=0.0 required=8.4 tests=AWL: -0.801,BAYES_99: 3.67,USER_IN_WHITELIST: -30, CUSTOM_RULE_FROM: ALLOW,TOTAL_SCORE: -27.131 X-Spam-Level: Received: from [66.93.162.135] ([66.93.162.135]) (authenticated user mellon@nominum.com) by mail.nominum.com (using TLSv1/SSLv3 with cipher AES128-SHA (128 bits)); Fri, 12 Jan 2007 14:33:26 -0800 Message-Id: <7C891B39-A1FA-49B9-A0B5-8936934AA37E@nominum.com> From: Ted Lemon To: Stig Venaas In-Reply-To: <45950DDB.3040009@uninett.no> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes X-Smtp-Server: mail.nominum.com:mellon Mime-Version: 1.0 (Apple Message framework v856) Subject: Re: [dhcwg] dhc wg last call on agentopt-delegate and srsn-option drafts Content-Transfer-Encoding: 7bit Date: Fri, 12 Jan 2007 15:33:16 -0700 References: <45950DDB.3040009@uninett.no> X-Mailer: Apple Mail (2.856) X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: dhcwg X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org On Dec 29, 2006, at 5:45 AM, Stig Venaas wrote: > This message announces a wg last call on two drafts. They are > > DHCPv6 Relay Agent Assignment Notification (RAAN) Option > > > and > > DHCPv6 Server Reply Sequence Number Option > . > > The last call will conclude at 1700EST on Mon, 2007-01-15. I'm against advancing either of these drafts. I think the complexity introduced by the SRSN option is inappropriate for DHCP, and I think using the DHCP protocol as a way to seed routing information is misguided, despite assurances that I've heard that this is no different than the routers option in DHCPv4. I would prefer that if the DHCP server delegates a prefix, it seed the routing tables using a routing protocol, perhaps TBD. I'm sorry for not having given more detailed commentary about this, but the fact is that my objections amount to a queasy feeling about the whole proposal, rather than violent, specific objection. So I've been content to simply watch from the sidelines. But I've been asked privately to comment, so I'm commenting. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Fri Jan 12 17:37:21 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5V1O-00006p-ON; Fri, 12 Jan 2007 17:37:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5V1O-00006k-Cv for dhcwg@ietf.org; Fri, 12 Jan 2007 17:37:14 -0500 Received: from shell-ng.nominum.com ([81.200.64.181]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H5V1N-0000kJ-3p for dhcwg@ietf.org; Fri, 12 Jan 2007 17:37:14 -0500 Received: from mail.nominum.com (mail.nominum.com [81.200.64.186]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by shell-ng.nominum.com (Postfix) with ESMTP id C09C556891; Fri, 12 Jan 2007 14:37:12 -0800 (PST) (envelope-from Ted.Lemon@nominum.com) X-Spam-Status: No, hits=0.0 required=8.4 tests=AWL: -0.788,BAYES_99: 3.67,USER_IN_WHITELIST: -30, CUSTOM_RULE_FROM: ALLOW,TOTAL_SCORE: -27.118 X-Spam-Level: Received: from [66.93.162.135] ([66.93.162.135]) (authenticated user mellon@nominum.com) by mail.nominum.com (using TLSv1/SSLv3 with cipher AES128-SHA (128 bits)); Fri, 12 Jan 2007 14:37:10 -0800 Message-Id: From: Ted Lemon To: Stig Venaas In-Reply-To: <45A4FB93.20500@uninett.no> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes X-Smtp-Server: mail.nominum.com:mellon Mime-Version: 1.0 (Apple Message framework v856) Subject: Re: [dhcwg] WG last calls on several WG documents Content-Transfer-Encoding: 7bit Date: Fri, 12 Jan 2007 15:37:04 -0700 References: <45A4FB93.20500@uninett.no> X-Mailer: Apple Mail (2.856) X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: dhcwg X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org On Jan 10, 2007, at 7:43 AM, Stig Venaas wrote: > Please note that Ralph asked this to verify consensus > for starting last calls. Based on the positive input we > got for agentopt-delegate and srsn-option we started a > last call for those. Once that is completed we will > see if we now also got sufficient support for starting > last calls on leasequery and ero. I'm mildly uncomfortable with leasequery simply because it's a rather complex draft and I haven't had the time to sit down and try to implement it, so I'm worried that there are bugs in it. Also, it seems to leave out discovering Prefix Delegations, which seems like a significant omission. But with those caveats, I'm okay with it going forward to the next step, as long as we understand that it may need fixes if errors are discovered during implementation. Possibly those can be folded in when the solution for Prefix Delegation is described. I'm also fine with ERO going to last call. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Sun Jan 14 08:56:23 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H65pj-0000zn-7i; Sun, 14 Jan 2007 08:55:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H65pi-0000zh-5H for dhcwg@ietf.org; Sun, 14 Jan 2007 08:55:38 -0500 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H65pg-0000Fr-QU for dhcwg@ietf.org; Sun, 14 Jan 2007 08:55:38 -0500 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 14 Jan 2007 05:55:32 -0800 X-IronPort-AV: i="4.13,185,1167638400"; d="scan'208"; a="50780125:sNHT58460428" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l0EDtWbH025112; Sun, 14 Jan 2007 08:55:32 -0500 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l0EDtVVT002677; Sun, 14 Jan 2007 08:55:32 -0500 (EST) Received: from xmb-rtp-20a.amer.cisco.com ([64.102.31.15]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 14 Jan 2007 08:55:31 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [dhcwg] WG last calls on several WG documents Date: Sun, 14 Jan 2007 08:55:31 -0500 Message-ID: <8E296595B6471A4689555D5D725EBB2102FDB2C2@xmb-rtp-20a.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dhcwg] WG last calls on several WG documents Thread-Index: Acc2mkOuhLReZVgBTYiX1sF99gtSQwBSLCzQ From: "Bernie Volz \(volz\)" To: "Ted Lemon" , "Stig Venaas" X-OriginalArrivalTime: 14 Jan 2007 13:55:31.0903 (UTC) FILETIME=[A80014F0:01C737E3] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2678; t=1168782932; x=1169646932; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=volz@cisco.com; z=From:=20=22Bernie=20Volz=20\(volz\)=22=20 |Subject:=20RE=3A=20[dhcwg]=20WG=20last=20calls=20on=20several=20WG=20doc uments |Sender:=20 |To:=20=22Ted=20Lemon=22=20, =0A=20=20=20=20=20=20= 20=20=22Stig=20Venaas=22=20; bh=OICIfTMBSG/Bl49tR581Dso/XgbWDBEjKFUjyUEUNLM=; b=Uv/HKqyhEOA/Nvq5silmfngd95h/NMqkCrkEdKSlH83tW2nHV5HYM0KNl8kqnAgEDScrDRrj +npWPcMAPlq8H6rI8O67J9KLtBT47jjY21raFmWpCgQ8TRfY9QOuwZFf; Authentication-Results: rtp-dkim-1; header.From=volz@cisco.com; dkim=pass (s ig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: dhcwg X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org Ted: It doesn't leave out discovering prefix delegations. When a requestor queries for an address, either the stateful address lease *OR* the delegated prefix that "contains" the queried address is returned, depending on what is "leased". Yes, there is no specific query to ask whether a specific Prefix (prefix + prefix-length) is leased, but I didn't see that that was needed and the requestor might not even know what it is (otherwise, why would it be querying). Remember that the basic model is to support relay agents (such as CMTS's) that have lost "state". The relay agent will attempt to recover state when a packet arrives with a source or destination address (depending on the direction of the traffic) that the router does not have in its tables. As the router only has an address, it would not query for a delegated prefix (and that would perhaps require TWO queries -- one for the address and another for a delegated prefix). So, by querying for the address the relay agent would get back the client and lease information for either the stateful address or the delegated prefix per the draft. We can certainly add a query by prefix if that is desired in the future, but I just find it unlikely that the relay agent would know what the prefix length is in advance. - Bernie -----Original Message----- From: Ted Lemon [mailto:Ted.Lemon@nominum.com]=20 Sent: Friday, January 12, 2007 5:37 PM To: Stig Venaas Cc: dhcwg Subject: Re: [dhcwg] WG last calls on several WG documents On Jan 10, 2007, at 7:43 AM, Stig Venaas wrote: > Please note that Ralph asked this to verify consensus > for starting last calls. Based on the positive input we > got for agentopt-delegate and srsn-option we started a > last call for those. Once that is completed we will > see if we now also got sufficient support for starting > last calls on leasequery and ero. I'm mildly uncomfortable with leasequery simply because it's a rather =20 complex draft and I haven't had the time to sit down and try to =20 implement it, so I'm worried that there are bugs in it. Also, it =20 seems to leave out discovering Prefix Delegations, which seems like a =20 significant omission. But with those caveats, I'm okay with it going =20 forward to the next step, as long as we understand that it may need =20 fixes if errors are discovered during implementation. Possibly those =20 can be folded in when the solution for Prefix Delegation is described. I'm also fine with ERO going to last call. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Mon Jan 15 12:16:46 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6VRN-0006FD-WE; Mon, 15 Jan 2007 12:16:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6VRM-0006Dl-8X for dhcwg@ietf.org; Mon, 15 Jan 2007 12:16:12 -0500 Received: from stl-smtpout-01.boeing.com ([130.76.96.56] helo=stl-smtpout-01.ns.cs.boeing.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H6VRJ-0005PB-St for dhcwg@ietf.org; Mon, 15 Jan 2007 12:16:12 -0500 Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [192.42.227.216]) by stl-smtpout-01.ns.cs.boeing.com (8.13.6/8.13.6/TEST_SMTPIN) with ESMTP id l0FHG8xB006005 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 15 Jan 2007 11:16:08 -0600 (CST) Received: from blv-av-01.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.13.6/8.13.6/DOWNSTREAM_RELAY) with ESMTP id l0FHG7wB022602; Mon, 15 Jan 2007 09:16:07 -0800 (PST) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by blv-av-01.boeing.com (8.13.6/8.13.6/UPSTREAM_RELAY) with ESMTP id l0FHFZY1020649; Mon, 15 Jan 2007 09:15:36 -0800 (PST) Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 15 Jan 2007 09:15:35 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [dhcwg] WG last calls on several WG documents Date: Mon, 15 Jan 2007 09:15:34 -0800 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A10177459F@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <8E296595B6471A4689555D5D725EBB2102FDB2C2@xmb-rtp-20a.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dhcwg] WG last calls on several WG documents Thread-Index: Acc2mkOuhLReZVgBTYiX1sF99gtSQwBSLCzQADlLeNA= From: "Templin, Fred L" To: , , X-OriginalArrivalTime: 15 Jan 2007 17:15:35.0979 (UTC) FILETIME=[C56677B0:01C738C8] X-Spam-Score: 0.0 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Cc: dhcwg@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org Bernie and Ted, Thanks; this gives additional information that would have allowed me to say "yes" instead of "no opinion" to Leasequery and Relay Agent Echo Request Option. Is it too late to change my vote? Fred fred.l.templin@boeing.com=20 > -----Original Message----- > From: Bernie Volz (volz) [mailto:volz@cisco.com]=20 > Sent: Sunday, January 14, 2007 5:56 AM > To: Ted Lemon; Stig Venaas > Cc: dhcwg > Subject: RE: [dhcwg] WG last calls on several WG documents >=20 > Ted: >=20 > It doesn't leave out discovering prefix delegations. When a requestor > queries for an address, either the stateful address lease *OR* the > delegated prefix that "contains" the queried address is returned, > depending on what is "leased". >=20 > Yes, there is no specific query to ask whether a specific=20 > Prefix (prefix > + prefix-length) is leased, but I didn't see that that was needed and > the requestor might not even know what it is (otherwise, why=20 > would it be > querying). >=20 > Remember that the basic model is to support relay agents (such as > CMTS's) that have lost "state". The relay agent will attempt=20 > to recover > state when a packet arrives with a source or destination address > (depending on the direction of the traffic) that the router does not > have in its tables. As the router only has an address, it would not > query for a delegated prefix (and that would perhaps require=20 > TWO queries > -- one for the address and another for a delegated prefix). >=20 > So, by querying for the address the relay agent would get back the > client and lease information for either the stateful address or the > delegated prefix per the draft. >=20 > We can certainly add a query by prefix if that is desired in=20 > the future, > but I just find it unlikely that the relay agent would know what the > prefix length is in advance. >=20 > - Bernie >=20 > -----Original Message----- > From: Ted Lemon [mailto:Ted.Lemon@nominum.com]=20 > Sent: Friday, January 12, 2007 5:37 PM > To: Stig Venaas > Cc: dhcwg > Subject: Re: [dhcwg] WG last calls on several WG documents >=20 > On Jan 10, 2007, at 7:43 AM, Stig Venaas wrote: > > Please note that Ralph asked this to verify consensus > > for starting last calls. Based on the positive input we > > got for agentopt-delegate and srsn-option we started a > > last call for those. Once that is completed we will > > see if we now also got sufficient support for starting > > last calls on leasequery and ero. >=20 > I'm mildly uncomfortable with leasequery simply because it's=20 > a rather =20 > complex draft and I haven't had the time to sit down and try to =20 > implement it, so I'm worried that there are bugs in it. Also, it =20 > seems to leave out discovering Prefix Delegations, which=20 > seems like a =20 > significant omission. But with those caveats, I'm okay with=20 > it going =20 > forward to the next step, as long as we understand that it may need =20 > fixes if errors are discovered during implementation. =20 > Possibly those =20 > can be folded in when the solution for Prefix Delegation is described. >=20 > I'm also fine with ERO going to last call. >=20 >=20 >=20 > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg >=20 > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg >=20 _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Mon Jan 15 14:58:01 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6XxH-0004yo-EH; Mon, 15 Jan 2007 14:57:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6XxG-0004ye-DG for dhcwg@ietf.org; Mon, 15 Jan 2007 14:57:18 -0500 Received: from shell-ng.nominum.com ([81.200.64.181]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H6XxF-0000xb-1l for dhcwg@ietf.org; Mon, 15 Jan 2007 14:57:18 -0500 Received: from mail.nominum.com (mail.nominum.com [81.200.64.186]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by shell-ng.nominum.com (Postfix) with ESMTP id 476125682B for ; Mon, 15 Jan 2007 11:57:08 -0800 (PST) (envelope-from Ted.Lemon@nominum.com) X-Spam-Status: No, hits=0.0 required=8.4 tests=AWL: -0.770,BAYES_99: 3.67,USER_IN_WHITELIST: -30, CUSTOM_RULE_FROM: ALLOW,TOTAL_SCORE: -27.100 X-Spam-Level: Received: from [66.93.162.135] ([66.93.162.135]) (authenticated user mellon@nominum.com) by mail.nominum.com (using TLSv1/SSLv3 with cipher AES128-SHA (128 bits)) for dhcwg@ietf.org; Mon, 15 Jan 2007 11:57:06 -0800 Message-Id: <1F949FC9-38B2-4B6D-A9F2-094DC2263B20@nominum.com> From: Ted Lemon To: dhcwg@ietf.org In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A10177459F@XCH-NW-7V2.nw.nos.boeing.com> Content-Type: text/plain; charset=US-ASCII; format=flowed X-Smtp-Server: mail.nominum.com:mellon Mime-Version: 1.0 (Apple Message framework v856) Subject: Re: [dhcwg] WG last calls on several WG documents Content-Transfer-Encoding: 7bit Date: Mon, 15 Jan 2007 12:57:05 -0700 References: <39C363776A4E8C4A94691D2BD9D1C9A10177459F@XCH-NW-7V2.nw.nos.boeing.com> X-Mailer: Apple Mail (2.856) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org On Jan 15, 2007, at 10:15 AM, Templin, Fred L wrote: > Thanks; this gives additional information that would > have allowed me to say "yes" instead of "no opinion" > to Leasequery and Relay Agent Echo Request Option. Likewise I'm now happier about the Leasequery option. Thanks, Bernie! I support both the Leasequery and ERO options advancing. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Mon Jan 15 16:11:51 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6Z75-0004vi-DS; Mon, 15 Jan 2007 16:11:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6Z73-0004vW-Bk for dhcwg@ietf.org; Mon, 15 Jan 2007 16:11:29 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H6Z71-0004KE-SJ for dhcwg@ietf.org; Mon, 15 Jan 2007 16:11:29 -0500 Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-5.cisco.com with ESMTP; 15 Jan 2007 13:11:26 -0800 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-6.cisco.com (8.12.11/8.12.11) with ESMTP id l0FLBR19004609; Mon, 15 Jan 2007 13:11:27 -0800 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id l0FLBGhu011395; Mon, 15 Jan 2007 13:11:26 -0800 (PST) Received: from xmb-rtp-20a.amer.cisco.com ([64.102.31.15]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 15 Jan 2007 16:11:16 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [dhcwg] WG last calls on several WG documents Date: Mon, 15 Jan 2007 16:11:16 -0500 Message-ID: <8E296595B6471A4689555D5D725EBB2102FDB4AC@xmb-rtp-20a.amer.cisco.com> In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A10177459F@XCH-NW-7V2.nw.nos.boeing.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dhcwg] WG last calls on several WG documents Thread-Index: Acc2mkOuhLReZVgBTYiX1sF99gtSQwBSLCzQADlLeNAACF/ykA== From: "Bernie Volz \(volz\)" To: "Templin, Fred L" , , X-OriginalArrivalTime: 15 Jan 2007 21:11:16.0108 (UTC) FILETIME=[B192ECC0:01C738E9] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3897; t=1168895487; x=1169759487; c=relaxed/simple; s=sjdkim6002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=volz@cisco.com; z=From:=20=22Bernie=20Volz=20\(volz\)=22=20 |Subject:=20RE=3A=20[dhcwg]=20WG=20last=20calls=20on=20several=20WG=20doc uments |Sender:=20; bh=E7UvTb6yzeb7OeSw/aOsqa/WiXWNIQmb4k4hTbaAc4A=; b=WtT87iczaDWKz2SmXHClYiXNrq+3uzay1pScTYsvDzqIHx2Jg1D9ZxjfaBRPgcSXXVquVrbo w4axFwqH5KjaZOdTp7UWN6h2FsN7DhSvL+W8U8NRo27V7s14EMuhiRV2; Authentication-Results: sj-dkim-6; header.From=volz@cisco.com; dkim=pass (si g from cisco.com/sjdkim6002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 Cc: dhcwg@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org Nope ... The last call will conclude at 1700EST on Mon, 2007-01-15.=20 - Bernie -----Original Message----- From: Templin, Fred L [mailto:Fred.L.Templin@boeing.com]=20 Sent: Monday, January 15, 2007 12:16 PM To: Bernie Volz (volz); Ted.Lemon@nominum.com; stig.venaas@uninett.no Cc: dhcwg@ietf.org Subject: RE: [dhcwg] WG last calls on several WG documents Bernie and Ted, Thanks; this gives additional information that would have allowed me to say "yes" instead of "no opinion" to Leasequery and Relay Agent Echo Request Option. Is it too late to change my vote? Fred fred.l.templin@boeing.com=20 > -----Original Message----- > From: Bernie Volz (volz) [mailto:volz@cisco.com]=20 > Sent: Sunday, January 14, 2007 5:56 AM > To: Ted Lemon; Stig Venaas > Cc: dhcwg > Subject: RE: [dhcwg] WG last calls on several WG documents >=20 > Ted: >=20 > It doesn't leave out discovering prefix delegations. When a requestor > queries for an address, either the stateful address lease *OR* the > delegated prefix that "contains" the queried address is returned, > depending on what is "leased". >=20 > Yes, there is no specific query to ask whether a specific=20 > Prefix (prefix > + prefix-length) is leased, but I didn't see that that was needed and > the requestor might not even know what it is (otherwise, why=20 > would it be > querying). >=20 > Remember that the basic model is to support relay agents (such as > CMTS's) that have lost "state". The relay agent will attempt=20 > to recover > state when a packet arrives with a source or destination address > (depending on the direction of the traffic) that the router does not > have in its tables. As the router only has an address, it would not > query for a delegated prefix (and that would perhaps require=20 > TWO queries > -- one for the address and another for a delegated prefix). >=20 > So, by querying for the address the relay agent would get back the > client and lease information for either the stateful address or the > delegated prefix per the draft. >=20 > We can certainly add a query by prefix if that is desired in=20 > the future, > but I just find it unlikely that the relay agent would know what the > prefix length is in advance. >=20 > - Bernie >=20 > -----Original Message----- > From: Ted Lemon [mailto:Ted.Lemon@nominum.com]=20 > Sent: Friday, January 12, 2007 5:37 PM > To: Stig Venaas > Cc: dhcwg > Subject: Re: [dhcwg] WG last calls on several WG documents >=20 > On Jan 10, 2007, at 7:43 AM, Stig Venaas wrote: > > Please note that Ralph asked this to verify consensus > > for starting last calls. Based on the positive input we > > got for agentopt-delegate and srsn-option we started a > > last call for those. Once that is completed we will > > see if we now also got sufficient support for starting > > last calls on leasequery and ero. >=20 > I'm mildly uncomfortable with leasequery simply because it's=20 > a rather =20 > complex draft and I haven't had the time to sit down and try to =20 > implement it, so I'm worried that there are bugs in it. Also, it =20 > seems to leave out discovering Prefix Delegations, which=20 > seems like a =20 > significant omission. But with those caveats, I'm okay with=20 > it going =20 > forward to the next step, as long as we understand that it may need =20 > fixes if errors are discovered during implementation. =20 > Possibly those =20 > can be folded in when the solution for Prefix Delegation is described. >=20 > I'm also fine with ERO going to last call. >=20 >=20 >=20 > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg >=20 > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg >=20 _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Mon Jan 15 16:12:58 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6Z8Q-000571-9U; Mon, 15 Jan 2007 16:12:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6Z8O-00056m-Mf for dhcwg@ietf.org; Mon, 15 Jan 2007 16:12:52 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H6Z8L-0004Yy-BS for dhcwg@ietf.org; Mon, 15 Jan 2007 16:12:52 -0500 Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-5.cisco.com with ESMTP; 15 Jan 2007 13:12:48 -0800 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-6.cisco.com (8.12.11/8.12.11) with ESMTP id l0FLCmOf004887; Mon, 15 Jan 2007 13:12:48 -0800 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id l0FLClhq011667; Mon, 15 Jan 2007 13:12:48 -0800 (PST) Received: from xmb-rtp-20a.amer.cisco.com ([64.102.31.15]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 15 Jan 2007 16:12:47 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [dhcwg] WG last calls on several WG documents Date: Mon, 15 Jan 2007 16:12:34 -0500 Message-ID: <8E296595B6471A4689555D5D725EBB2102FDB4AD@xmb-rtp-20a.amer.cisco.com> In-Reply-To: <1F949FC9-38B2-4B6D-A9F2-094DC2263B20@nominum.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dhcwg] WG last calls on several WG documents Thread-Index: Acc435aP8u0tOpuKQciilB9/+Uw3LAACiNOg From: "Bernie Volz \(volz\)" To: "Ted Lemon" X-OriginalArrivalTime: 15 Jan 2007 21:12:47.0871 (UTC) FILETIME=[E844D8F0:01C738E9] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=745; t=1168895568; x=1169759568; c=relaxed/simple; s=sjdkim6002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=volz@cisco.com; z=From:=20=22Bernie=20Volz=20\(volz\)=22=20 |Subject:=20RE=3A=20[dhcwg]=20WG=20last=20calls=20on=20several=20WG=20doc uments |Sender:=20; bh=hjbQ6JGlfB8o/wsqs/cUNIczXPMS5VdwasDr+2kcgtg=; b=d1inxgvp8GkP0XgXNI6TTDvzO7zxxcwO2amF6hKYb+5qa7on/tMd9QyVJrNEk9o339iNWc1m aBN+KaII0nlIc9T4TVe7XZfh7GQ9p4VrgbTRP4Tolo0ri4XnE3KTJNrG; Authentication-Results: sj-dkim-6; header.From=volz@cisco.com; dkim=pass (si g from cisco.com/sjdkim6002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: dhcwg@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org Thank you and thanks for asking! - Bernie=20 -----Original Message----- From: Ted Lemon [mailto:Ted.Lemon@nominum.com]=20 Sent: Monday, January 15, 2007 2:57 PM To: dhcwg@ietf.org Subject: Re: [dhcwg] WG last calls on several WG documents On Jan 15, 2007, at 10:15 AM, Templin, Fred L wrote: > Thanks; this gives additional information that would > have allowed me to say "yes" instead of "no opinion" > to Leasequery and Relay Agent Echo Request Option. Likewise I'm now happier about the Leasequery option. Thanks, Bernie! I support both the Leasequery and ERO options advancing. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Mon Jan 15 16:36:44 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6ZVE-0007kJ-Pr; Mon, 15 Jan 2007 16:36:28 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6ZVD-0007jV-LP; Mon, 15 Jan 2007 16:36:27 -0500 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1H6ZVD-0003N4-C0; Mon, 15 Jan 2007 16:36:27 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id 4CA162ACAA; Mon, 15 Jan 2007 21:35:57 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1H6ZUj-0005H2-27; Mon, 15 Jan 2007 16:35:57 -0500 X-test-idtracker: no From: The IESG To: IETF-Announce Message-Id: Date: Mon, 15 Jan 2007 16:35:57 -0500 X-Spam-Score: -2.8 (--) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Cc: dhc mailing list , dhc chair , Internet Architecture Board , RFC Editor Subject: [dhcwg] Protocol Action: 'DHCP options for PANA Authentication Agents' to Proposed Standard X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org The IESG has approved the following document: - 'DHCP options for PANA Authentication Agents ' as a Proposed Standard This document is the product of the Dynamic Host Configuration Working Group. The IESG contact persons are Jari Arkko and Mark Townsley. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-paa-option-05.txt Technical Summary The document specifies a DHCPv4 option and a DHCPv6 option that allow a PANA client to learn addresses of PANA Authentication Agents. Working Group Summary There was consensus for adopting this draft at the wg meeting at IETF 63. Consensus was verified on the mailing list, and got adopted in September 2005. After that it has been discussed in both dhc and pana WGs and rev 03 went to a joint WGLC in dhc and pana WGs in August 2006. Based on comments received during last call rev 04 was produced. Protocol Quality The protocol specified in this document specifies new DHCPv4 and DHCPv6 options and as there are no special requirements on option encodings or usage, this should be trivial to implement. This specification was reviewed for the IESG by Jari Arkko. Note to RFC Editor Please change the definition of " PANA Authentication Agent (PAA)" in Section 3 to the following: The protocol entity in the access network whose responsibility is to verify the credentials provided by a PANA client (PaC) and authorize network access to the access device. The PAA and the EAP authenticator (and optionally the EAP server) are co-located in the same node. In Section 7, change a PANA Client could be led to contact a rogue PANA Authentication Agent, possibly one that then intercepts call requests or denies service. to a PANA Client could be led to contact a rogue PANA Authentication Agent, possibly one that then intercepts authentication requests and/or denies network access to the access device. Similarly in Section 7, change In most of the networks, to In most of networks, And finally in Section 8, change Norten to Narten _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Tue Jan 16 03:42:47 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6jtH-0003Vs-LN; Tue, 16 Jan 2007 03:41:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6jtH-0003Vn-0p for dhcwg@ietf.org; Tue, 16 Jan 2007 03:41:59 -0500 Received: from shuttle.wide.toshiba.co.jp ([2001:200:1b1::35]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H6jtD-0000CJ-SK for dhcwg@ietf.org; Tue, 16 Jan 2007 03:41:58 -0500 Received: from impact.jinmei.org (unknown [2001:200:1b1:1010:7cfb:d79f:f5ea:b4ff]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 363881525D; Tue, 16 Jan 2007 17:41:54 +0900 (JST) Date: Tue, 16 Jan 2007 17:41:52 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Stig Venaas Subject: Re: [dhcwg] dhc wg last call on agentopt-delegate and srsn-option drafts In-Reply-To: <45950DDB.3040009@uninett.no> References: <45950DDB.3040009@uninett.no> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Spam-Score: -2.8 (--) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Cc: dhcwg X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org >>>>> On Fri, 29 Dec 2006 13:45:15 +0100, >>>>> Stig Venaas said: > This message announces a wg last call on two drafts. They are > DHCPv6 Relay Agent Assignment Notification (RAAN) Option > > and > DHCPv6 Server Reply Sequence Number Option > . > The last call will conclude at 1700EST on Mon, 2007-01-15. Sorry for the delayed response, but in case it's not too late I'd like to express my agreement with David and Ted, that is, I cannot support this set of drafts. I share the same concerns with them; in general, it seems dangerous to define such general options even though there will be many scenarios where they don't work: - as others pointed out, this approach won't work (or at least will cause troubles/confusion such as creation of an unreachable route or a routing loop) in a multiple-relay environment - this approach will won't work either if the client and server uses unicast communication for Request/Reply and subsequent exchanges. - even with the introduction of the SRSN option, the mechanism is still not really reliable. For example, consider the case where a requesting router of PD was allocated an IPv6 prefix and then has released it, but all Reply messages are somehow lost between the server and the relay (not the requesting router). Then the requesting and delegating routers can successfully remove the binding despite the lost messages, but a stale state about the prefix will still remain in the relay. Also, while the specification is generic (despite many non-workable cases) so that it can be applied to address allocation, I doubt the usefulness of this usage because in that case the relay (=router) should normally know the link prefix anyway and doesn't need the information contained in the RAAN in practice. I'd rather employ an "eviler" approach such as snooping DHCPv6 messages at the relay (just like in an IGMP/MLD snooping swith) for the particular issue that this set of proposal seems to try to address. It won't be fully reliable either, but since the proposed method is also not really reliable as pointed out above, I'd prefer not creating a risky general extension to the standard protocol. Alternatively, the relay and the server may directly communicate using some different protocol than DHCP over a reliable channel about the resources the server has allocated via the relay (of course, this approach would also have a limitation in a multi-relay environment). Having said that, I'd also hesitate to oppose to advancing these document since I understand these drafts are proposed to address a real world issue in an actual deployment scenario of IPv6/PD and I don't want to prevent the deployment by objecting to a key feature to make it happen, especially when there's no possibility for alternatives to be adopted (and that's my understanding). So...like David, the only position I can take seems to be abstention. But if there is a room to add something, I'd like to clarify the intended usage of these options, discouraging or even disallowing other use cases. For example, - relay SHOULD NOT include ORO for RAAN unless it forwards a message directly to the server - server SHOULD NOT sends the Server Unicast option to the client once it uses the RAAN option - restrict the use of RAAN option to PD (not for address allocation) at least for the moment JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Tue Jan 16 10:27:19 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6qD4-0001Jl-QX; Tue, 16 Jan 2007 10:26:50 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6qD3-0001CZ-52; Tue, 16 Jan 2007 10:26:49 -0500 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1H6qD2-0003Xs-Ru; Tue, 16 Jan 2007 10:26:49 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id 7BDDD176E2; Tue, 16 Jan 2007 15:26:18 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1H6qCY-00007F-2t; Tue, 16 Jan 2007 10:26:18 -0500 X-test-idtracker: no From: The IESG To: IETF-Announce Message-Id: Date: Tue, 16 Jan 2007 10:26:18 -0500 X-Spam-Score: -2.8 (--) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Cc: dhc mailing list , dhc chair , Internet Architecture Board , RFC Editor Subject: [dhcwg] Protocol Action: 'A Timezone Option for DHCP' to Proposed Standard X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org The IESG has approved the following document: - 'A Timezone Option for DHCP ' as a Proposed Standard This document is the product of the Dynamic Host Configuration Working Group. The IESG contact persons are Jari Arkko and Mark Townsley. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-timezone-option-05.txt Technical Summary The document specifies two new DHCPv4 options and two new DHCPv6 options. The two options are used to pass a POSIX TZ string, and a TZ database reference respectively. This offers an improvement over the time offset option defined in RFC 2132. Working Group Summary There was consensus for adopting this draft at the wg meeting at IETF 65. Consensus was verified on the mailing list, and got adopted in May 06. After a few revisions and cycles of discussion and feedback on the dhc WG mailing list, as well as feedback from external people, rev 02 went to wglc Aug 06. Based on comments received during last call rev 03 was produced. Finally rev 04 was made, only change being the RFC 2119 boiler plate and reference. Some have argued against deprecating the v4 time offset option since it is still in use. Still, the chairs believe there is rough consensus for deprecating the offset and have this new option replacing it. Protocol Quality The specification has been reviewed for the IESG by Jari Arkko, and reviewed in the timezone mailing list tz@elsie.nci.nih.gov. As a part of the AD review, we also asked for additional reviews from timezone experts. Chris Newman reviewed the specification for this purpose. The protocol specified in this document specifies new DHCPv4 and DHCPv6 options and as there are no special requirements on option encodings or usage, this should be trivial to implement. There are two known client and one server implementations. Note to RFC Editor In the abstract, please change This memo specifies DHCP options each of those methods. to This memo specifies DHCP options for each of those methods. In Section 1, first paragraph, 2nd bullet, change o Reference to the TZ Database to o Reference to the name of a time zone entry in the TZ Database. In Section 5 first paragraph, change TZ Name is the name of a Zone entry in the database commonly referred to as the TZ database. to TZ Name is the name of a Zone entry in the database commonly referred to as the TZ database. Specifically, in the database's textual form, the string refers to the name field of a zone line. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Tue Jan 16 11:15:16 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6qxe-0005kf-Ar; Tue, 16 Jan 2007 11:14:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6qxd-0005kZ-EH for dhcwg@ietf.org; Tue, 16 Jan 2007 11:14:57 -0500 Received: from blv-smtpout-01.boeing.com ([130.76.32.69] helo=blv-smtpout-01.ns.cs.boeing.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H6qxZ-0007jH-Si for dhcwg@ietf.org; Tue, 16 Jan 2007 11:14:57 -0500 Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by blv-smtpout-01.ns.cs.boeing.com (8.13.6/8.13.6/TEST_SMTPIN) with ESMTP id l0GGEc5G027086 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 16 Jan 2007 08:14:38 -0800 (PST) Received: from slb-av-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.13.6/8.13.6/DOWNSTREAM_RELAY) with ESMTP id l0GGEb9M015037; Tue, 16 Jan 2007 08:14:37 -0800 (PST) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by slb-av-01.boeing.com (8.13.6/8.13.6/UPSTREAM_RELAY) with ESMTP id l0GGEUYa014787; Tue, 16 Jan 2007 08:14:37 -0800 (PST) Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 16 Jan 2007 08:14:35 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit Subject: RE: [dhcwg] dhc wg last call on agentopt-delegate andsrsn-option drafts Date: Tue, 16 Jan 2007 08:14:34 -0800 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A1017745AB@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dhcwg] dhc wg last call on agentopt-delegate andsrsn-option drafts Thread-Index: Acc5Sni1xeQmXlEtQ8u+c9RfS2rL3wAOydnw From: "Templin, Fred L" To: , X-OriginalArrivalTime: 16 Jan 2007 16:14:35.0567 (UTC) FILETIME=[6A09ABF0:01C73989] X-Spam-Score: 0.0 (/) X-Scan-Signature: 68ba2b07ef271dba6ee42a93832cfa4c Cc: dhcwg@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org Hello Jinmei, I respect your opinion on this matter and appreciate your careful analysis, but had a few points in follow-up regarding what you said: 1) about multiple relay environments, 'draft-templin-autoconf-netlmm-dhcp' specifies a use case for RAAN/SRSN options with multiple relays. 2) about the use of unicast, I agree that the server should not permit the client to use unicast when RAAN/SRSN are used. 3) about reliability, the DHCP client is responsible for reliability. So, as long as there is operational assurance that all client/server messages will go through the relay, the relay will be updated whenever the client is updated. About your recommendations: > - relay SHOULD NOT include ORO for RAAN unless it forwards a message > directly to the server This seems safe, but might not allow for multiple relays in the path. That's OK with me, but is it OK with others? > - server SHOULD NOT sends the Server Unicast option to the client once > it uses the RAAN option Agree. > - restrict the use of RAAN option to PD (not for address allocation) > at least for the moment I don't understand this one. Why should it be any different for address delegation than prefix delegation? It could be, for example, that the client requires an address to assign to an interface on a link for which there is no prefix for stateless address autoconfiguration. Thanks - Fred fred.l.templin@boeing.com > -----Original Message----- > From: JINMEI Tatuya / $B?@L@C#:H(J [mailto:jinmei@isl.rdc.toshiba.co.jp] > Sent: Tuesday, January 16, 2007 12:42 AM > To: Stig Venaas > Cc: dhcwg > Subject: Re: [dhcwg] dhc wg last call on agentopt-delegate > andsrsn-option drafts > > >>>>> On Fri, 29 Dec 2006 13:45:15 +0100, > >>>>> Stig Venaas said: > > > This message announces a wg last call on two drafts. They are > > DHCPv6 Relay Agent Assignment Notification (RAAN) Option > > > > > and > > > DHCPv6 Server Reply Sequence Number Option > > . > > > The last call will conclude at 1700EST on Mon, 2007-01-15. > > Sorry for the delayed response, but in case it's not too late I'd like > to express my agreement with David and Ted, that is, I cannot support > this set of drafts. > > I share the same concerns with them; in general, it seems dangerous to > define such general options even though there will be many scenarios > where they don't work: > > - as others pointed out, this approach won't work (or at least will > cause troubles/confusion such as creation of an unreachable route or > a routing loop) in a multiple-relay environment > > - this approach will won't work either if the client and server uses > unicast communication for Request/Reply and subsequent exchanges. > > - even with the introduction of the SRSN option, the mechanism is > still not really reliable. For example, consider the case where a > requesting router of PD was allocated an IPv6 prefix and then has > released it, but all Reply messages are somehow lost between the > server and the relay (not the requesting router). Then the > requesting and delegating routers can successfully remove the > binding despite the lost messages, but a stale state about the > prefix will still remain in the relay. > > Also, while the specification is generic (despite many non-workable > cases) so that it can be applied to address allocation, I doubt the > usefulness of this usage because in that case the relay (=router) > should normally know the link prefix anyway and doesn't need the > information contained in the RAAN in practice. > > I'd rather employ an "eviler" approach such as snooping DHCPv6 > messages at the relay (just like in an IGMP/MLD snooping swith) for > the particular issue that this set of proposal seems to try to > address. It won't be fully reliable either, but since the proposed > method is also not really reliable as pointed out above, I'd prefer > not creating a risky general extension to the standard protocol. > Alternatively, the relay and the server may directly communicate using > some different protocol than DHCP over a reliable channel about the > resources the server has allocated via the relay (of course, this > approach would also have a limitation in a multi-relay environment). > > Having said that, I'd also hesitate to oppose to advancing these > document since I understand these drafts are proposed to address a > real world issue in an actual deployment scenario of IPv6/PD and I > don't want to prevent the deployment by objecting to a key feature to > make it happen, especially when there's no possibility for > alternatives to be adopted (and that's my understanding). > > So...like David, the only position I can take seems to be abstention. > But if there is a room to add something, I'd like to clarify the > intended usage of these options, discouraging or even disallowing > other use cases. For example, > > - relay SHOULD NOT include ORO for RAAN unless it forwards a message > directly to the server > - server SHOULD NOT sends the Server Unicast option to the client once > it uses the RAAN option > - restrict the use of RAAN option to PD (not for address allocation) > at least for the moment > > JINMEI, Tatuya > Communication Platform Lab. > Corporate R&D Center, > Toshiba Corp. > jinmei@isl.rdc.toshiba.co.jp > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg > _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Wed Jan 17 06:23:45 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H78sw-0000Yt-2N; Wed, 17 Jan 2007 06:23:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H78sv-0000Yo-4c for dhcwg@ietf.org; Wed, 17 Jan 2007 06:23:17 -0500 Received: from [2001:200:1b1::36] (helo=shuttle-new.wide.toshiba.co.jp) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H78su-0000bp-1M for dhcwg@ietf.org; Wed, 17 Jan 2007 06:23:17 -0500 Received: from impact.jinmei.org (unknown [IPv6:2001:200:1b1:1010:c01b:3d12:a172:45e6]) by shuttle-new.wide.toshiba.co.jp (Postfix) with ESMTP id F11557301B; Wed, 17 Jan 2007 20:23:11 +0900 (JST) Date: Wed, 17 Jan 2007 20:23:09 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: "Templin, Fred L" Subject: Re: [dhcwg] dhc wg last call on agentopt-delegate andsrsn-option drafts In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A1017745AB@XCH-NW-7V2.nw.nos.boeing.com> References: <39C363776A4E8C4A94691D2BD9D1C9A1017745AB@XCH-NW-7V2.nw.nos.boeing.com> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Spam-Score: -2.8 (--) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: dhcwg@ietf.org, stig.venaas@uninett.no X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org >>>>> On Tue, 16 Jan 2007 08:14:34 -0800, >>>>> "Templin, Fred L" said: > Hello Jinmei, > I respect your opinion on this matter and appreciate your careful analysis, > but had a few points in follow-up regarding what you said: > 3) about reliability, the DHCP client is responsible for reliability. So, as > long as there is operational assurance that all client/server messages > will go through the relay, the relay will be updated whenever the client > is updated. That's true in most cases, but as I pointed in my previous message, Release/Reply exchanges are an exception, that is, the server and the client can be successfully synchronized even if some of the messages (Reply in this case) are completely lost. From a quick reread of RFC3315, it also seems to apply to Decline/Reply exchanges. > About your recommendations: >> - relay SHOULD NOT include ORO for RAAN unless it forwards a message >> directly to the server > This seems safe, but might not allow for multiple relays in the path. That's > OK with me, but is it OK with others? >> - server SHOULD NOT sends the Server Unicast option to the client once >> it uses the RAAN option > Agree. >> - restrict the use of RAAN option to PD (not for address allocation) >> at least for the moment > I don't understand this one. Why should it be any different for address > delegation than prefix delegation? It could be, for example, that the > client requires an address to assign to an interface on a link for which > there is no prefix for stateless address autoconfiguration. In the address allocation case, the relay (= router) should normally know the link prefix anyway so that it can advertise the prefix in Router Advertisements (at least with the L flag ON). There may be exceptional cases, of course, and if those are realistic and there's no alternative for some reason, it may make sense to apply RAAN to address allocation. My point is (IMO of course) that operations relying on RAAN (+ SRSN) are pretty dangerous with many pitfalls, and so we should begin with very specific case(s) where we really need RAAN without any possible alternative. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Wed Jan 17 15:07:03 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7H3F-0006ZW-IT; Wed, 17 Jan 2007 15:06:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7H3D-0006Yy-Rn for dhcwg@ietf.org; Wed, 17 Jan 2007 15:06:27 -0500 Received: from stl-smtpout-01.boeing.com ([130.76.96.56] helo=stl-smtpout-01.ns.cs.boeing.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7H30-00054W-OR for dhcwg@ietf.org; Wed, 17 Jan 2007 15:06:18 -0500 Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by stl-smtpout-01.ns.cs.boeing.com (8.13.6/8.13.6/TEST_SMTPIN) with ESMTP id l0HK67hE007634 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 17 Jan 2007 14:06:07 -0600 (CST) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.13.6/8.13.6/DOWNSTREAM_RELAY) with ESMTP id l0HK67Og006945; Wed, 17 Jan 2007 14:06:07 -0600 (CST) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by stl-av-01.boeing.com (8.13.6/8.13.6/UPSTREAM_RELAY) with ESMTP id l0HK60Bd006714; Wed, 17 Jan 2007 14:06:07 -0600 (CST) Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 17 Jan 2007 12:06:06 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [dhcwg] dhc wg last call on agentopt-delegate andsrsn-option drafts Date: Wed, 17 Jan 2007 12:06:05 -0800 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A1017745BB@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dhcwg] dhc wg last call on agentopt-delegate andsrsn-option drafts Thread-Index: Acc6KeFgb37mYuc+TjmBg3ZyPfJ/bQAQKA5w From: "Templin, Fred L" To: X-OriginalArrivalTime: 17 Jan 2007 20:06:06.0469 (UTC) FILETIME=[EC12DB50:01C73A72] X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: dhcwg@ietf.org, stig.venaas@uninett.no X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org > That's true in most cases, but as I pointed in my previous message, > Release/Reply exchanges are an exception, that is, the server and the > client can be successfully synchronized even if some of the messages > (Reply in this case) are completely lost. From a quick reread of > RFC3315, it also seems to apply to Decline/Reply exchanges. In terms of Release/Reply, it sounds like you are referring here to the case of the relay/router being left with stale state. But, if the relay/router also configures a client (as in 'draft-templin-autoconf-netlmm-dhcp-04.txt'), the server can send a Reconfigure to the relay/router's client asking it to perform an Info-Request/Reply exchange that would convey the correct RAAN/SRSN options. I'm sure there are other approaches too. I don't see that Decline/Reply is quite the same, as there is no provision for the client to terminate the retransmission procedure early. But even if it were the same, the same approach described above (or other approaches) could still be used to ensure reliability. > In the address allocation case, the relay (=3D router) should normally > know the link prefix anyway so that it can advertise the prefix in > Router Advertisements (at least with the L flag ON). Some links may have no prefixes, and others may have prefixes with 'A' =3D 'L' =3D 0. Clients should still be able to get an address via = DHCP w/o having to delegate an entire prefix. > There may be > exceptional cases, of course, and if those are realistic and there's > no alternative for some reason, it may make sense to apply RAAN to > address allocation. OK. DHCP address delegation has the advantage that the DHCP server ensures uniqueness. This may be necessary for links on which RFC2462 DAD is unreliable due to message loss, on links with asymmetric reachability, etc. >My point is (IMO of course) that operations > relying on RAAN (+ SRSN) are pretty dangerous with many pitfalls, and > so we should begin with very specific case(s) where we really need > RAAN without any possible alternative. As I said before, I respect your opinion. But, if there are other known pitfalls/dangers IMO we should discuss them here and have them out on the table. Are there others we should know about? Thanks - Fred fred.l.templin@boeing.com _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Sat Jan 20 04:12:07 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H8CFX-0001JM-0A; Sat, 20 Jan 2007 04:10:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H8CFU-0001JG-Ul for dhcwg@ietf.org; Sat, 20 Jan 2007 04:10:56 -0500 Received: from shuttle.wide.toshiba.co.jp ([2001:200:1b1::35]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H8CFS-0005Qv-1o for dhcwg@ietf.org; Sat, 20 Jan 2007 04:10:56 -0500 Received: from impact.jinmei.org (shuttle.wide.toshiba.co.jp [2001:200:1b1::35]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 258C01521E; Sat, 20 Jan 2007 18:10:49 +0900 (JST) Date: Sat, 20 Jan 2007 18:10:46 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: "Templin, Fred L" Subject: Re: [dhcwg] dhc wg last call on agentopt-delegate andsrsn-option drafts In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A1017745BB@XCH-NW-7V2.nw.nos.boeing.com> References: <39C363776A4E8C4A94691D2BD9D1C9A1017745BB@XCH-NW-7V2.nw.nos.boeing.com> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Spam-Score: -2.8 (--) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Cc: dhcwg@ietf.org, stig.venaas@uninett.no X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org >>>>> On Wed, 17 Jan 2007 12:06:05 -0800, >>>>> "Templin, Fred L" said: >> That's true in most cases, but as I pointed in my previous message, >> Release/Reply exchanges are an exception, that is, the server and the >> client can be successfully synchronized even if some of the messages >> (Reply in this case) are completely lost. From a quick reread of >> RFC3315, it also seems to apply to Decline/Reply exchanges. > In terms of Release/Reply, it sounds like you are referring here to the > case of the relay/router being left with stale state. But, if the > relay/router > also configures a client (as in > 'draft-templin-autoconf-netlmm-dhcp-04.txt'), > the server can send a Reconfigure to the relay/router's client asking it > to > perform an Info-Request/Reply exchange that would convey the correct > RAAN/SRSN options. I'm sure there are other approaches too. I'm not sure if I understand how exactly this solves the Release/Reply case, but I won't be surprised that some additional tricks solve the issue. My major point here is that the current set of documents doesn't entirely provide reliability and that achieving it (probably by additional tricks) may not be so trivial. This point also applies to the Decline/Reply case. >> In the address allocation case, the relay (= router) should normally >> know the link prefix anyway so that it can advertise the prefix in >> Router Advertisements (at least with the L flag ON). > Some links may have no prefixes, and others may have prefixes with > 'A' = 'L' = 0. Clients should still be able to get an address via DHCP > w/o having to delegate an entire prefix. Then how is the RAAN option useful for the relay? Since prefix information is not included in address allocation via DHCPv6, I'm not sure how the relay would act by receiving the address via RAAN. Is the relay intended to inject a host route to the core network >> There may be >> exceptional cases, of course, and if those are realistic and there's >> no alternative for some reason, it may make sense to apply RAAN to >> address allocation. > OK. DHCP address delegation has the advantage that the DHCP > server ensures uniqueness. This may be necessary for links on > which RFC2462 DAD is unreliable due to message loss, on links > with asymmetric reachability, etc. I don't understand how this is relevant to this discussion, but allocating an address via DHCP(v6) doesn't ensure address uniqueness anyway; the only thing the server can ensure is that no duplicate address is allocated via DHCPv6, and there may still be other hosts that use the allocated address. That's why RFC2462 (and its bis) requires DAD must be applied to any address whether it's manually configured, configured via stateless autoconf or via DHCPv6. >> My point is (IMO of course) that operations >> relying on RAAN (+ SRSN) are pretty dangerous with many pitfalls, and >> so we should begin with very specific case(s) where we really need >> RAAN without any possible alternative. > As I said before, I respect your opinion. But, if there are other known > pitfalls/dangers IMO we should discuss them here and have them > out on the table. Are there others we should know about? I'm not sure. I guess there are other issues, but I've not thoroughly considered miscellaneous cases. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Sat Jan 20 14:01:28 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H8LSZ-0005kC-OY; Sat, 20 Jan 2007 14:01:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H8LSY-0005jy-Ti for dhcwg@ietf.org; Sat, 20 Jan 2007 14:01:02 -0500 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H8LSX-0007EL-J3 for dhcwg@ietf.org; Sat, 20 Jan 2007 14:01:02 -0500 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 20 Jan 2007 14:01:02 -0500 X-IronPort-AV: i="4.13,216,1167627600"; d="scan'208"; a="112136173:sNHT51470508" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l0KJ108Z020022; Sat, 20 Jan 2007 14:01:00 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l0KJ0wOA013649; Sat, 20 Jan 2007 14:00:58 -0500 (EST) Received: from xmb-rtp-20a.amer.cisco.com ([64.102.31.15]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 20 Jan 2007 14:00:58 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-2022-JP" Content-Transfer-Encoding: 7bit Subject: RE: [dhcwg] dhc wg last call on agentopt-delegate and srsn-option drafts Date: Sat, 20 Jan 2007 14:00:58 -0500 Message-ID: <8E296595B6471A4689555D5D725EBB21030E56BF@xmb-rtp-20a.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dhcwg] dhc wg last call on agentopt-delegate and srsn-option drafts Thread-Index: Acc8c0j9DFsgTjxjQx+pwnjKV09XxwATjU0w From: "Bernie Volz \(volz\)" To: =?ISO-2022-JP?B?SklOTUVJIFRhdHV5YSAvIBskQj9ATEBDIzpIGyhC?= , "Templin, Fred L" X-OriginalArrivalTime: 20 Jan 2007 19:00:58.0717 (UTC) FILETIME=[521C78D0:01C73CC5] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2827; t=1169319660; x=1170183660; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=volz@cisco.com; z=From:=20=22Bernie=20Volz=20\(volz\)=22=20 |Subject:=20RE=3A=20[dhcwg]=20dhc=20wg=20last=20call=20on=20agentopt-dele gate=20and=20srsn-option=20drafts=20 |Sender:=20 |To:=20=3D?ISO-2022-JP?B?SklOTUVJIFRhdHV5YSAvIBskQj9ATEBDIzpIGyhC?=3D=20< jinmei@isl.rdc.toshiba.co.jp>, =0A=20=20=20=20=20=20=20=20=22Templin, =20Fre d=20L=22=20; bh=Upjps/T677ZWdSIM2/0snCFvbgZ6ef5Ba8yM6AVK/rE=; b=E1s+mmkQr6op1CWoc6zTzeKnC09yaGMsSZFBkSTD5i9jwLqfle9KlXSfoUg9Yl+SoQJTHNAX OXuIug5ZT2ijjP/Vk0+9BFN6ANLE+x5o8dvKyX52BxwrYCkYABu6bRW5; Authentication-Results: rtp-dkim-2; header.From=volz@cisco.com; dkim=pass (s ig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: dhcwg@ietf.org, stig.venaas@uninett.no X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org The Release/Reply and Decline/Reply issue I think basically has three cases. This assumes that the client has released or declined the address or prefix and that the server has received that and honored it, but that the Reply failed to get back to the Relay Agent and also client. 1. If the leases are not reused, there is no serious issue. The Relay Agent may continue to advertise the routes and/or allow the traffic to pass. But, as the client isn't using the prefix/address, no significant harm occurs. [This is similar to the case where the client disconnects from the network without having released the leases.] 2. If the leases are reused and delivered to the same Relay Agent (or perhaps another Relay Agent that uses some special communication mechanism with the original Relay Agent), the Relay Agent would hopefully use the client-last-transaction time to determine that the "older" information is incorrect and remove it and use the newer information. But, this is not specified in the draft. Hum ... I thought we had added text about the client-last-transaction time option from the LeaseQuery draft to the RAAN draft, but alas I don't see it. The SRSN can't be used unless the same server sent both messages. The client-last-transaction time doesn't require synchronized clocks because it is a delta time (the only issue is any latency in packet delivery). 3. If the leases are reused and delivered to a different Relay Agent (that has no special communication with the original Relay Agent), multiple routes may be injected into the routing system and the if the old route wins, traffic may be misdirected and perhaps not delivered. 2 can be solved via the client-last-transaction time. 3 is definitely an issue as it may result in a lack of service (or intermittment service) to the client. Without RAAN, the Relay Agents are left to snoop packets which is what we were trying to avoid. The one advantage with snooping is that the Relay can process Release/Decline messages (essentially ignoring the Reply). For other cases, it would need to process the Reply's. But I suspect this will be significantly more complex. I guess one option we could consider is using RAAN but also requiring Relay's to snoop on Release/Decline messages as that would mean the Relay can remove the information (if found) when requested by the client. I'd prefer we not require snooping, but alas that may be needed to retain the RAAN approach. One reason to avoid snooping is that if client uses the Auth Option, there is no way the Relay can validate this (it doesn't have the keys). With snooping for the Release/Decline, we do have a DoS attack - a rogue client can release another's addresses/prefixes. So, looks like any way we slice this there's always going to be a loophole? - Bernie _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Mon Jan 22 11:35:07 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H927g-000487-Ip; Mon, 22 Jan 2007 11:34:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H927f-00047y-Mg for dhcwg@ietf.org; Mon, 22 Jan 2007 11:34:19 -0500 Received: from slb-smtpout-01.boeing.com ([130.76.64.48] helo=slb-smtpout-01.ns.cs.boeing.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H927c-0006S7-CK for dhcwg@ietf.org; Mon, 22 Jan 2007 11:34:19 -0500 Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [192.42.227.216]) by slb-smtpout-01.ns.cs.boeing.com (8.13.6/8.13.6/TEST_SMTPIN) with ESMTP id l0MGY7l5010803 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 22 Jan 2007 08:34:08 -0800 (PST) Received: from blv-av-01.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.13.6/8.13.6/DOWNSTREAM_RELAY) with ESMTP id l0MGY7w1018441; Mon, 22 Jan 2007 08:34:07 -0800 (PST) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by blv-av-01.boeing.com (8.13.6/8.13.6/UPSTREAM_RELAY) with ESMTP id l0MGY3Rf018221; Mon, 22 Jan 2007 08:34:06 -0800 (PST) Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 22 Jan 2007 08:34:03 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [dhcwg] dhc wg last call on agentopt-delegate and srsn-optiondrafts Date: Mon, 22 Jan 2007 08:34:02 -0800 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A1017745DB@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <8E296595B6471A4689555D5D725EBB21030E56BF@xmb-rtp-20a.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dhcwg] dhc wg last call on agentopt-delegate and srsn-optiondrafts Thread-Index: Acc8c0j9DFsgTjxjQx+pwnjKV09XxwATjU0wAF/EdvA= From: "Templin, Fred L" To: , X-OriginalArrivalTime: 22 Jan 2007 16:34:03.0327 (UTC) FILETIME=[208E34F0:01C73E43] X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: dhcwg@ietf.org, stig.venaas@uninett.no X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org Bernie, > 1. If the leases are not reused, there is no serious issue.=20 > The Relay Agent may continue to advertise the routes and/or=20 > allow the traffic to pass. But, as the client isn't using the=20 > prefix/address, no significant harm occurs. [This is similar=20 > to the case where the client disconnects from the network=20 > without having released the leases.] Wouldn't it be preferable if the relay/router could send destination unreachables back to the source instead of just black-holing in that case? =20 > So, looks like any way we slice this there's always going to=20 > be a loophole?=20 There was the idea of the relay/router also configuring a client to ensure reliability in case the true lease-holding client has departed or terminated the Release exchange w/o waiting for a reply. Any problems with that? Another idea is for the relay/router to periodically perform NUD and then purge stale state if the client fails to respond to its delegations. That is what is being recommended in NETLMM at least. Fred fred.l.templin@boeing.com _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Mon Jan 22 11:44:51 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H92Ho-000085-NW; Mon, 22 Jan 2007 11:44:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H92Hn-00006p-3G for dhcwg@ietf.org; Mon, 22 Jan 2007 11:44:47 -0500 Received: from stl-smtpout-01.boeing.com ([130.76.96.56] helo=stl-smtpout-01.ns.cs.boeing.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H92Hk-0000j0-Ri for dhcwg@ietf.org; Mon, 22 Jan 2007 11:44:47 -0500 Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [192.42.227.216]) by stl-smtpout-01.ns.cs.boeing.com (8.13.6/8.13.6/TEST_SMTPIN) with ESMTP id l0MGihOa001341 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 22 Jan 2007 10:44:43 -0600 (CST) Received: from blv-av-01.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.13.6/8.13.6/DOWNSTREAM_RELAY) with ESMTP id l0MGigQ0017330; Mon, 22 Jan 2007 08:44:42 -0800 (PST) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by blv-av-01.boeing.com (8.13.6/8.13.6/UPSTREAM_RELAY) with ESMTP id l0MGidAS017155; Mon, 22 Jan 2007 08:44:42 -0800 (PST) Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 22 Jan 2007 08:44:39 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [dhcwg] dhc wg last call on agentopt-delegate andsrsn-option drafts Date: Mon, 22 Jan 2007 08:44:38 -0800 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A1017745DC@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dhcwg] dhc wg last call on agentopt-delegate andsrsn-option drafts Thread-Index: Acc8cuMiMkwQ7eERQcymMBiy92FBFAB0FDzQ From: "Templin, Fred L" To: X-OriginalArrivalTime: 22 Jan 2007 16:44:39.0296 (UTC) FILETIME=[9B9F6000:01C73E44] X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: dhcwg@ietf.org, stig.venaas@uninett.no X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org > This point also applies to the Decline/Reply case. Can you explain how this is so? > Then how is the RAAN option useful for the relay? Since prefix > information is not included in address allocation via DHCPv6, I'm not > sure how the relay would act by receiving the address via RAAN. Is > the relay intended to inject a host route to the core network To my understanding, RAAN can include IA_NA/IA_TA as well as IA_PD. Not saying it would be desireable in all environments but, yes, there may be cases in which that would entail injecting host routes and some networks may want this. Thanks - Fred fred.l.templin@boeing.com _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Mon Jan 22 12:04:39 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H92ae-0000en-SN; Mon, 22 Jan 2007 12:04:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H92ad-0000ef-G1 for dhcwg@ietf.org; Mon, 22 Jan 2007 12:04:15 -0500 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H92ac-0003bb-5B for dhcwg@ietf.org; Mon, 22 Jan 2007 12:04:15 -0500 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 22 Jan 2007 12:04:14 -0500 X-IronPort-AV: i="4.13,221,1167627600"; d="scan'208"; a="112223666:sNHT57022412" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l0MH4DcW023020; Mon, 22 Jan 2007 12:04:13 -0500 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l0MH4AOG012940; Mon, 22 Jan 2007 12:04:13 -0500 (EST) Received: from xmb-rtp-20a.amer.cisco.com ([64.102.31.15]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 22 Jan 2007 12:04:11 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [dhcwg] dhc wg last call on agentopt-delegate and srsn-optiondrafts Date: Mon, 22 Jan 2007 12:04:12 -0500 Message-ID: <8E296595B6471A4689555D5D725EBB21030E5974@xmb-rtp-20a.amer.cisco.com> In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A1017745DB@XCH-NW-7V2.nw.nos.boeing.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dhcwg] dhc wg last call on agentopt-delegate and srsn-optiondrafts Thread-Index: Acc8c0j9DFsgTjxjQx+pwnjKV09XxwATjU0wAF/EdvAAAZKboA== From: "Bernie Volz \(volz\)" To: "Templin, Fred L" , X-OriginalArrivalTime: 22 Jan 2007 17:04:11.0403 (UTC) FILETIME=[5640B5B0:01C73E47] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2024; t=1169485453; x=1170349453; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=volz@cisco.com; z=From:=20=22Bernie=20Volz=20\(volz\)=22=20 |Subject:=20RE=3A=20[dhcwg]=20dhc=20wg=20last=20call=20on=20agentopt-dele gate=20and=20srsn-optiondrafts=20 |Sender:=20 |To:=20=22Templin, =20Fred=20L=22=20, =0A=20=20= 20=20=20=20=20=20; bh=AtNLbKnH4FN0wNgMdPrkzBEj4btm6NOvsUDOmhPzkFo=; b=KuUXZA3D/dok/zAtN+lZgDKo0stMMqsTQtrmk8s9NQsob5vQWtJNJHLu8XJ8LegcqqJqJevY 8TaixVKmjxCIMh6nsupL9J+Tr568fC+xPa+fhpl9KVUkptg8p8G4v/Uh; Authentication-Results: rtp-dkim-1; header.From=volz@cisco.com; dkim=pass (s ig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: dhcwg@ietf.org, stig.venaas@uninett.no X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org Hi: See below. I was just focusing on the DHCPv6 protocol issues in my analysis. - Bernie=20 -----Original Message----- From: Templin, Fred L [mailto:Fred.L.Templin@boeing.com]=20 Sent: Monday, January 22, 2007 11:34 AM To: Bernie Volz (volz); jinmei@isl.rdc.toshiba.co.jp Cc: dhcwg@ietf.org; stig.venaas@uninett.no Subject: RE: [dhcwg] dhc wg last call on agentopt-delegate and srsn-optiondrafts=20 Bernie, > 1. If the leases are not reused, there is no serious issue.=20 > The Relay Agent may continue to advertise the routes and/or=20 > allow the traffic to pass. But, as the client isn't using the=20 > prefix/address, no significant harm occurs. [This is similar=20 > to the case where the client disconnects from the network=20 > without having released the leases.] Wouldn't it be preferable if the relay/router could send destination unreachables back to the source instead of just black-holing in that case? BV> Certainly the routers should do what they normally do if the destination is unreachable and they know it isn't reachable. But in this case it may not always know or it may take some time before this is detected (ND timers). =20 > So, looks like any way we slice this there's always going to=20 > be a loophole?=20 There was the idea of the relay/router also configuring a client to ensure reliability in case the true lease-holding client has departed or terminated the Release exchange w/o waiting for a reply. Any problems with that? Another idea is for the relay/router to periodically perform NUD and then purge stale state if the client fails to respond to its delegations. That is what is being recommended in NETLMM at least. BV> Yes, the router should certainly use other techniques if possible to determine whether the destination is unreachable or not. For example, the router can always use a routing protocol to assure that the link is up and operational between itself and the client router. Fred fred.l.templin@boeing.com _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Mon Jan 22 12:19:53 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H92pW-0007ld-0p; Mon, 22 Jan 2007 12:19:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H92pU-0007lX-7H for dhcwg@ietf.org; Mon, 22 Jan 2007 12:19:36 -0500 Received: from shuttle.wide.toshiba.co.jp ([2001:200:1b1::35]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H92pR-0006DS-En for dhcwg@ietf.org; Mon, 22 Jan 2007 12:19:36 -0500 Received: from impact.jinmei.org (shuttle.wide.toshiba.co.jp [2001:200:1b1::35]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id E4DF21521E; Tue, 23 Jan 2007 02:19:29 +0900 (JST) Date: Tue, 23 Jan 2007 02:19:27 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: "Templin, Fred L" Subject: Re: [dhcwg] dhc wg last call on agentopt-delegate andsrsn-option drafts In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A1017745DC@XCH-NW-7V2.nw.nos.boeing.com> References: <39C363776A4E8C4A94691D2BD9D1C9A1017745DC@XCH-NW-7V2.nw.nos.boeing.com> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Spam-Score: -2.8 (--) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: dhcwg@ietf.org, stig.venaas@uninett.no X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org >>>>> On Mon, 22 Jan 2007 08:44:38 -0800, >>>>> "Templin, Fred L" said: >> This point also applies to the Decline/Reply case. > Can you explain how this is so? I don't understand why I'm being asked this (seriously), so please let me ask you first: which part of "this point" don't you think applies to the Decline/Reply case? Referring to my previous message: >> My major point here is that the current set of documents >> doesn't entirely provide reliability and that achieving it (probably >> by additional tricks) may not be so trivial. are you asking about - the current set of documents doesn't entirely provide reliability for the Decline/Reply case or - achieving it (probably by additional tricks) for the Decline/Reply case may not be so trivial or both, or something else? (For the first point, I thought it's an obvious analogy with Release/Reply since DEC_MAX_RC is non-zero. For the second point, I admit "trivial" may be a subjective word, but I thought whether it's trivial or not equally applies to Release/Reply and to Decline/Reply). JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Mon Jan 22 13:04:37 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H93WS-00019K-9w; Mon, 22 Jan 2007 13:04:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H93WQ-00018b-Es for dhcwg@ietf.org; Mon, 22 Jan 2007 13:03:58 -0500 Received: from blv-smtpout-01.boeing.com ([130.76.32.69] helo=blv-smtpout-01.ns.cs.boeing.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H93WP-0003C3-6V for dhcwg@ietf.org; Mon, 22 Jan 2007 13:03:58 -0500 Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by blv-smtpout-01.ns.cs.boeing.com (8.13.6/8.13.6/TEST_SMTPIN) with ESMTP id l0MI3jw6005674 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 22 Jan 2007 10:03:45 -0800 (PST) Received: from slb-av-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.13.6/8.13.6/DOWNSTREAM_RELAY) with ESMTP id l0MI3iLR023559; Mon, 22 Jan 2007 10:03:44 -0800 (PST) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by slb-av-01.boeing.com (8.13.6/8.13.6/UPSTREAM_RELAY) with ESMTP id l0MI3bst023193; Mon, 22 Jan 2007 10:03:44 -0800 (PST) Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 22 Jan 2007 10:03:41 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [dhcwg] dhc wg last call on agentopt-delegate andsrsn-option drafts Date: Mon, 22 Jan 2007 10:03:41 -0800 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A1017745DE@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dhcwg] dhc wg last call on agentopt-delegate andsrsn-option drafts Thread-Index: Acc+SXvw59l1s71xSPSgAO8NFuTrHwABSWeA From: "Templin, Fred L" To: X-OriginalArrivalTime: 22 Jan 2007 18:03:41.0796 (UTC) FILETIME=[A65F7240:01C73E4F] X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: dhcwg@ietf.org, stig.venaas@uninett.no X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org > (For the first point, I thought it's an obvious analogy with > Release/Reply since DEC_MAX_RC is non-zero. OK, I see it now and that's all I was asking. I made the wrong assumption that the issue you were pointing up was due only to the fact that the client is permitted to terminate the Release retransmission procedure early but I see now that both Release/Decline have a max retry count. That's fine; both can be handled the same way by the means I have already explained and possibly others. Fred fred.l.templin@boeing.com _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Mon Jan 22 13:16:12 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H93i5-0005ZA-40; Mon, 22 Jan 2007 13:16:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H93i4-0005Yw-0a for dhcwg@ietf.org; Mon, 22 Jan 2007 13:16:00 -0500 Received: from slb-smtpout-01.boeing.com ([130.76.64.48] helo=slb-smtpout-01.ns.cs.boeing.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H93i0-0004km-HX for dhcwg@ietf.org; Mon, 22 Jan 2007 13:15:59 -0500 Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by slb-smtpout-01.ns.cs.boeing.com (8.13.6/8.13.6/TEST_SMTPIN) with ESMTP id l0MIFr2t007588 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 22 Jan 2007 10:15:54 -0800 (PST) Received: from slb-av-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.13.6/8.13.6/DOWNSTREAM_RELAY) with ESMTP id l0MIFqsZ023051; Mon, 22 Jan 2007 10:15:52 -0800 (PST) Received: from XCH-NWBH-10.nw.nos.boeing.com (xch-nwbh-10.nw.nos.boeing.com [130.247.55.83]) by slb-av-01.boeing.com (8.13.6/8.13.6/UPSTREAM_RELAY) with ESMTP id l0MIFj3j022731; Mon, 22 Jan 2007 10:15:51 -0800 (PST) Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-10.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 22 Jan 2007 10:15:41 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [dhcwg] dhc wg last call on agentopt-delegate and srsn-optiondrafts Date: Mon, 22 Jan 2007 10:15:40 -0800 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A1017745DF@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <8E296595B6471A4689555D5D725EBB21030E5974@xmb-rtp-20a.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dhcwg] dhc wg last call on agentopt-delegate and srsn-optiondrafts Thread-Index: Acc8c0j9DFsgTjxjQx+pwnjKV09XxwATjU0wAF/EdvAAAZKboAACP+Lg From: "Templin, Fred L" To: , X-OriginalArrivalTime: 22 Jan 2007 18:15:41.0872 (UTC) FILETIME=[53925300:01C73E51] X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: dhcwg@ietf.org, stig.venaas@uninett.no X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org > For example, > the router can always use a routing protocol to assure that=20 > the link is > up and operational between itself and the client router. I don't necessarily mind your saying "client router", but *must* the client be a router as opposed to a simple host? Thanks - Fred fred.l.templin@boeing.com=20 _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Mon Jan 22 13:33:40 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H93yn-00043k-DX; Mon, 22 Jan 2007 13:33:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H93ym-00043f-8O for dhcwg@ietf.org; Mon, 22 Jan 2007 13:33:16 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H93yj-0008Lc-V9 for dhcwg@ietf.org; Mon, 22 Jan 2007 13:33:16 -0500 Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-4.cisco.com with ESMTP; 22 Jan 2007 10:33:13 -0800 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-6.cisco.com (8.12.11/8.12.11) with ESMTP id l0MIXDll003913; Mon, 22 Jan 2007 10:33:13 -0800 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id l0MIX4hu023572; Mon, 22 Jan 2007 10:33:12 -0800 (PST) Received: from xmb-rtp-20a.amer.cisco.com ([64.102.31.15]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 22 Jan 2007 13:33:06 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [dhcwg] dhc wg last call on agentopt-delegate and srsn-optiondrafts Date: Mon, 22 Jan 2007 13:33:07 -0500 Message-ID: <8E296595B6471A4689555D5D725EBB21030E5A08@xmb-rtp-20a.amer.cisco.com> In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A1017745DF@XCH-NW-7V2.nw.nos.boeing.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dhcwg] dhc wg last call on agentopt-delegate and srsn-optiondrafts Thread-Index: Acc8c0j9DFsgTjxjQx+pwnjKV09XxwATjU0wAF/EdvAAAZKboAACP+LgAADx0RA= From: "Bernie Volz \(volz\)" To: "Templin, Fred L" , X-OriginalArrivalTime: 22 Jan 2007 18:33:06.0974 (UTC) FILETIME=[C2803BE0:01C73E53] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=710; t=1169490793; x=1170354793; c=relaxed/simple; s=sjdkim6002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=volz@cisco.com; z=From:=20=22Bernie=20Volz=20\(volz\)=22=20 |Subject:=20RE=3A=20[dhcwg]=20dhc=20wg=20last=20call=20on=20agentopt-dele gate=20and=20srsn-optiondrafts=20 |Sender:=20; bh=3A/szuaUZ1cw5/E7gswzJMabiMdU1Q8DyzdEBo1xkaY=; b=cJuZvBab0gUgkTk/wdYvRwRVpPwODUjl3pY8r8+B5QHPsDYE6Xp+rQJVYvuFxRO9+9pZKzsA Yh7tv2lNt1nIEwIajleVCJlUfWG1kIJ7OdAkbnhhkfji2tKg/1qMWD/v; Authentication-Results: sj-dkim-6; header.From=volz@cisco.com; dkim=pass (si g from cisco.com/sjdkim6002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: dhcwg@ietf.org, stig.venaas@uninett.no X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org By definition, a host does not run routing protocols? - Bernie -----Original Message----- From: Templin, Fred L [mailto:Fred.L.Templin@boeing.com]=20 Sent: Monday, January 22, 2007 1:16 PM To: Bernie Volz (volz); jinmei@isl.rdc.toshiba.co.jp Cc: dhcwg@ietf.org; stig.venaas@uninett.no Subject: RE: [dhcwg] dhc wg last call on agentopt-delegate and srsn-optiondrafts=20 > For example, > the router can always use a routing protocol to assure that=20 > the link is > up and operational between itself and the client router. I don't necessarily mind your saying "client router", but *must* the client be a router as opposed to a simple host? Thanks - Fred fred.l.templin@boeing.com=20 _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Mon Jan 22 15:01:59 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H95Lo-0005Dr-J5; Mon, 22 Jan 2007 15:01:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H95Ln-0005Dl-95 for dhcwg@ietf.org; Mon, 22 Jan 2007 15:01:07 -0500 Received: from blv-smtpout-01.boeing.com ([130.76.32.69] helo=blv-smtpout-01.ns.cs.boeing.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H95Lj-0005pH-RG for dhcwg@ietf.org; Mon, 22 Jan 2007 15:01:07 -0500 Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [192.42.227.216]) by blv-smtpout-01.ns.cs.boeing.com (8.13.6/8.13.6/TEST_SMTPIN) with ESMTP id l0MK0p9X011217 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 22 Jan 2007 12:00:52 -0800 (PST) Received: from blv-av-01.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.13.6/8.13.6/DOWNSTREAM_RELAY) with ESMTP id l0MK0pmN003622; Mon, 22 Jan 2007 12:00:51 -0800 (PST) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by blv-av-01.boeing.com (8.13.6/8.13.6/UPSTREAM_RELAY) with ESMTP id l0MK0fNC003247; Mon, 22 Jan 2007 12:00:43 -0800 (PST) Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 22 Jan 2007 12:00:41 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [dhcwg] dhc wg last call on agentopt-delegate and srsn-optiondrafts Date: Mon, 22 Jan 2007 12:00:40 -0800 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A1017745E1@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <8E296595B6471A4689555D5D725EBB21030E5A08@xmb-rtp-20a.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dhcwg] dhc wg last call on agentopt-delegate and srsn-optiondrafts Thread-Index: Acc8c0j9DFsgTjxjQx+pwnjKV09XxwATjU0wAF/EdvAAAZKboAACP+LgAADx0RAAAuDnIA== From: "Templin, Fred L" To: , X-OriginalArrivalTime: 22 Jan 2007 20:00:41.0421 (UTC) FILETIME=[FE6537D0:01C73E5F] X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: dhcwg@ietf.org, stig.venaas@uninett.no X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org > By definition, a host does not run routing protocols? Sorry to confuse - as of now, we have (at least) three solution proposals: 1) relay/router configures client that performs reliable exchanges with server for Release/Decline 2) relay/router uses NUD to detect addresses/prefixes that have been Released/Declined w/missing Reply 3) relay/router and client participate in a routing protocol I think cases 1) and 2) allow for the client to be a simple host, and case 3) requires the client to be a router. Do I have this right? Thanks - Fred fred.l.templin@boeing.com _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Wed Jan 24 09:48:52 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9jQ2-00013b-JR; Wed, 24 Jan 2007 09:48:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9jQ1-00013C-VB for dhcwg@ietf.org; Wed, 24 Jan 2007 09:48:09 -0500 Received: from scramble.princeton.edu ([128.112.232.239]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H9jPz-0000hw-KY for dhcwg@ietf.org; Wed, 24 Jan 2007 09:48:09 -0500 Received: from scramble.Princeton.EDU (irwin@localhost) by scramble.Princeton.EDU (8.13.7/8.13.7) with ESMTP id l0OElsE8012219 for ; Wed, 24 Jan 2007 09:48:01 -0500 (EST) Message-Id: <200701241448.l0OElsE8012219@scramble.Princeton.EDU> From: Irwin Tillman To: dhcwg@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 24 Jan 2007 09:47:54 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Subject: [dhcwg] RFC 2131: can a DHCPv4 client (Mac OS X) transition directly from BOUND to INIT then back to BOUND? X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org My reading of RFC 2131 (especially Figure 5) is that a DHCPv4 client cannot transition directly from the INIT state to the BOUND state without passing through the SELECTING state. Under some circumstances, Apple Mac OS X 10.4.x will do just that. That is, the client was BOUND. The client chooses in some circumstances (e.g. following certain sleep/wake or link change events) to transition to the INIT state (rather than INIT-REBOOT). It broadcasts one or more DHCPDISCOVERs. Under some circumstances, after broadcasting the DHCPDISCOVER(s) the client then returns to the BOUND state, continuing to use the IP address from the old lease. Assuming it remains online long enough, it later tries to renew the old lease; as far as the client is concerned, it's BOUND again. My reading of the client state transition diagram (RFC2131 Figure 5) is that this isn't right. The only state in which a client may send a DHCPDISCOVER message is INIT. A client in the INIT state can't transition to the BOUND state without some additional steps that take it through the SELECTING state (e.g. receive DHCPDISCOVER(s), send a DHCPREQUEST, receive a DHCPACK). (I realize that RFC 4039 adds another path from INIT to BOUND using the DHCP Rapid Commit option, but that's not what's happening here.) I've reported this to Apple as a bug (Apple Bug Reporter Problem ID 4904550); Apple has confirmed that the Mac OS X 10.4.x client behaves this way, but they believe RFC 2131 permits this behavior. Any thoughts as to whether RFC 2131 permits this? Irwin Tillman / OIT Network Systems / Princeton University _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Wed Jan 24 13:42:38 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9n4B-0007Lt-1Z; Wed, 24 Jan 2007 13:41:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9n49-0007F7-Hw for dhcwg@ietf.org; Wed, 24 Jan 2007 13:41:49 -0500 Received: from goliath.isc.org ([2001:4f8:3:bb::72]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H9n48-0001ul-79 for dhcwg@ietf.org; Wed, 24 Jan 2007 13:41:49 -0500 Received: by goliath.isc.org (Postfix, from userid 10200) id 31F785A6ED; Wed, 24 Jan 2007 10:41:36 -0800 (PST) Date: Wed, 24 Jan 2007 10:41:35 -0800 From: "David W. Hankins" To: dhcwg@ietf.org Subject: Re: [dhcwg] RFC 2131: can a DHCPv4 client (Mac OS X) transition directly from BOUND to INIT then back to BOUND? Message-ID: <20070124184135.GB6482@isc.org> References: <200701241448.l0OElsE8012219@scramble.Princeton.EDU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200701241448.l0OElsE8012219@scramble.Princeton.EDU> User-Agent: Mutt/1.5.9i X-Spam-Score: -2.8 (--) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org On Wed, Jan 24, 2007 at 09:47:54AM -0500, Irwin Tillman wrote: > Any thoughts as to whether RFC 2131 permits this? It doesn't disallow it, if that's what you're asking. I think you also want to look at RFC4436 (DNAv4), which I think describes where and why this can be done and is (reasonably) safe. To have a problem you need an environment using RFC1918 addresses AND either (VRPP or HSRP) OR (routers with identical mac addresses). I think the solution is not to perform DNAv4 on RFC1918 networks. The objective of DNAv4 is to reduce the time to get back on an old lease if interface state changed but the network did not. In this case if the ARP probe succeeds, then the client knows that it can 'continue being BOUND' on the old address even though it speculatively transmitted a DISCOVER. If the ARP probe fails, it would need to carry on based on the contents of the OFFER. So a DISCOVER is sent to net an OFFER speculatively. The ARP is speculated to suceed, the DISCOVER is a backup speculating the ARP will fail. I probably would have chosen a REQUEST to make it look like an early REBIND, but this has server side implications (since the server must update a database in that case - processing a DISCOVER is much lighter weight). -- David W. Hankins "If you don't do it right the first time, Software Engineer you'll just have to do it again." Internet Systems Consortium, Inc. -- Jack T. Hankins _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Wed Jan 24 15:36:14 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9oqU-0008GK-9b; Wed, 24 Jan 2007 15:35:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9oqS-0008G3-Sf for dhcwg@ietf.org; Wed, 24 Jan 2007 15:35:48 -0500 Received: from scramble.princeton.edu ([128.112.232.239]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H9oqQ-0006Bc-Kr for dhcwg@ietf.org; Wed, 24 Jan 2007 15:35:48 -0500 Received: from scramble.Princeton.EDU (irwin@localhost) by scramble.Princeton.EDU (8.13.7/8.13.7) with ESMTP id l0OKZg9U014820 for ; Wed, 24 Jan 2007 15:35:44 -0500 (EST) Message-Id: <200701242035.l0OKZg9U014820@scramble.Princeton.EDU> From: Irwin Tillman To: dhcwg@ietf.org Subject: Re: [dhcwg] RFC 2131: can a DHCPv4 client (Mac OS X) transition directly from BOUND to INIT then back to BOUND? In-reply-to: <20070124184135.GB6482@isc.org> References: <200701241448.l0OElsE8012219@scramble.Princeton.EDU> <20070124184135.GB6482@isc.org> Comments: In-reply-to message from "David W. Hankins" dated "Wed, 24 Jan 2007 10:41:35 -0800." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 24 Jan 2007 15:35:42 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org On 24 Jan 2007 10:41:35 -0800, David W. Hankins wrote: >I think you also want to look at RFC4436 (DNAv4), which I think >describes where and why this can be done and is (reasonably) >safe. ... > >The objective of DNAv4 is to reduce the time to get back on an >old lease if interface state changed but the network did not. > >In this case if the ARP probe succeeds, then the client knows that >it can 'continue being BOUND' on the old address even though it >speculatively transmitted a DISCOVER. If the ARP probe fails, it >would need to carry on based on the contents of the OFFER. > >So a DISCOVER is sent to net an OFFER speculatively. The ARP >is speculated to suceed, the DISCOVER is a backup speculating >the ARP will fail. > >I probably would have chosen a REQUEST to make it look like an >early REBIND, but this has server side implications (since the >server must update a database in that case - processing a DISCOVER >is much lighter weight). Yes, it does look like DNAv4 (or something similar) is going on here. Looking at RFC 4436 (DNAv4), I see where it permits it can permit a client in the situation I'm seeing to attempt DHCPv4 in parallel with the reachability tests. (Section 2.1, seventh paragraph). That paragraph appears to imply that DHCP attempt is a DHCPREQUEST made from the INIT-REBOOT state, but the explicit details are in the next section. In section 2.2 (paragraph 1), it makes this explicit in the case where the client has an "operable routable IPv4" address (which is the case we're dealing with here). It says that the DHCP attempt is to be a broadcast DHCPREQUEST sent from the INIT-REBOOT state. Paragraph 2 says to use broadcast DHCPDISCOVER from the INIT state if the client doesn't have an operable routable IPv4 address on any network, but that's not the case here. In the situation I'm seeing, the DHCP client (Mac OS X 10.4.x) has an unexpired DHCP lease for a globally routable IPv4 address. So it's an operable routable IPv4 address. So it seems to me that if the DHCP client (in the particular situation I'm seeing) is doing DNAv4 (and it does seem to be doing something like it), it should be broadcasting DHCPREQUEST from INIT-REBOOT, not DHCPDISCOVER from INIT. Irwin Tillman / OIT Network Systems / Princeton University _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Wed Jan 24 16:06:04 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9pJb-0000hp-7r; Wed, 24 Jan 2007 16:05:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9pJa-0000hG-6z for dhcwg@ietf.org; Wed, 24 Jan 2007 16:05:54 -0500 Received: from goliath.isc.org ([2001:4f8:3:bb::72]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H9pJS-0007Sh-Ez for dhcwg@ietf.org; Wed, 24 Jan 2007 16:05:53 -0500 Received: by goliath.isc.org (Postfix, from userid 10200) id 863765A6ED; Wed, 24 Jan 2007 13:05:36 -0800 (PST) Date: Wed, 24 Jan 2007 13:05:36 -0800 From: "David W. Hankins" To: dhcwg@ietf.org Subject: Re: [dhcwg] RFC 2131: can a DHCPv4 client (Mac OS X) transition directly from BOUND to INIT then back to BOUND? Message-ID: <20070124210536.GE6482@isc.org> References: <200701241448.l0OElsE8012219@scramble.Princeton.EDU> <20070124184135.GB6482@isc.org> <200701242035.l0OKZg9U014820@scramble.Princeton.EDU> Mime-Version: 1.0 In-Reply-To: <200701242035.l0OKZg9U014820@scramble.Princeton.EDU> User-Agent: Mutt/1.5.9i X-Spam-Score: -2.8 (--) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0068038347==" Errors-To: dhcwg-bounces@ietf.org --===============0068038347== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="TiqCXmo5T1hvSQQg" Content-Disposition: inline --TiqCXmo5T1hvSQQg Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Wed, Jan 24, 2007 at 03:35:42PM -0500, Irwin Tillman wrote: > Paragraph 2 says to use broadcast DHCPDISCOVER from the INIT state if the client > doesn't have an operable routable IPv4 address on any network, but that's not > the case here. In the situation I'm seeing, the DHCP client (Mac OS X 10.4.x) > has an unexpired DHCP lease for a globally routable IPv4 address. So it's an > operable routable IPv4 address. I'm not sure if 'operable' means that the lease is usable (in which case I would have expected 'unexpired' which I think RFC2131 uses or maybe 'valid'), or 'in operation' (as in actively configured on the interface, in use, able to transmit and receive IP packets). It's my suspicion that 'operable' means 'in operation', but I admit I didn't take this up with the document authors at the time. I have a vague sense that it would be safe in either case from a protocol standpoint (or at least not the client's fault if something goes wrong - even though old ISC DHCP server versions would make things go wrong), so I didn't think nor ask about it. -- David W. Hankins "If you don't do it right the first time, Software Engineer you'll just have to do it again." Internet Systems Consortium, Inc. -- Jack T. Hankins --TiqCXmo5T1hvSQQg Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFFt8ogcXeLeWu2vmoRAsfWAJ9Fyg92T5HEHZyVf2y9T6iMEw5XNACfaUMp DdQ6arrxpe+kqwXD7nntQTQ= =RR8z -----END PGP SIGNATURE----- --TiqCXmo5T1hvSQQg-- --===============0068038347== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg --===============0068038347==-- From dhcwg-bounces@ietf.org Wed Jan 24 17:18:01 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9qQu-0001xH-Hc; Wed, 24 Jan 2007 17:17:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9qQs-0001x3-Rz for dhcwg@ietf.org; Wed, 24 Jan 2007 17:17:30 -0500 Received: from scramble.princeton.edu ([128.112.232.239]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H9qQr-0004UW-LW for dhcwg@ietf.org; Wed, 24 Jan 2007 17:17:30 -0500 Received: from scramble.Princeton.EDU (irwin@localhost) by scramble.Princeton.EDU (8.13.7/8.13.7) with ESMTP id l0OMHR0H015795 for ; Wed, 24 Jan 2007 17:17:27 -0500 (EST) Message-Id: <200701242217.l0OMHR0H015795@scramble.Princeton.EDU> From: Irwin Tillman To: dhcwg@ietf.org Subject: Re: [dhcwg] RFC 2131: can a DHCPv4 client (Mac OS X) transition directly from BOUND to INIT then back to BOUND? In-reply-to: <20070124210536.GE6482@isc.org> References: <200701241448.l0OElsE8012219@scramble.Princeton.EDU> <20070124184135.GB6482@isc.org> <200701242035.l0OKZg9U014820@scramble.Princeton.EDU> <20070124210536.GE6482@isc.org> Comments: In-reply-to message from "David W. Hankins" dated "Wed, 24 Jan 2007 13:05:36 -0800." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 24 Jan 2007 17:17:27 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org On 24 Jan 2007 13:05:36 -0800, David W. Hankins wrote: (Re. RFC 4436, DNAv4): >I'm not sure if 'operable' means that the lease is usable (in which case >I would have expected 'unexpired' which I think RFC2131 uses or maybe >'valid'), or 'in operation' (as in actively configured on the interface, >in use, able to transmit and receive IP packets). I believe they're using the specific "operable address" definition from Section 1.3 (final paragraph): 'In this specification, the term "operable address refers either to a static IPv4 address, or an address assigned via DHCPv4 that has not been returned to the DHCP server via a DHCP RELEASE message, and whose lease has not yet expired.' In the situation I'm seeing, the DHCP client (Mac OS X 10.4.x) has an "operable address." (So the DNAv4 spec says to send DHCPREQUEST in INIT-REBOOT, not DHCPDISCOVER in INIT.) _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Wed Jan 24 17:33:28 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9qg0-0003rt-0L; Wed, 24 Jan 2007 17:33:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9qfz-0003rn-7a for dhcwg@ietf.org; Wed, 24 Jan 2007 17:33:07 -0500 Received: from shell-ng.nominum.com ([81.200.64.181]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H9qfx-0003fr-SA for dhcwg@ietf.org; Wed, 24 Jan 2007 17:33:07 -0500 Received: from mail.nominum.com (mail.nominum.com [81.200.64.186]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by shell-ng.nominum.com (Postfix) with ESMTP id 4C0265687C; Wed, 24 Jan 2007 14:33:01 -0800 (PST) (envelope-from Ted.Lemon@nominum.com) X-Spam-Status: No, hits=0.0 required=8.4 tests=AWL: -0.736,BAYES_99: 3.67,USER_IN_WHITELIST: -30, CUSTOM_RULE_FROM: ALLOW,TOTAL_SCORE: -27.066 X-Spam-Level: Received: from [66.93.162.135] ([66.93.162.135]) (authenticated user mellon@nominum.com) by mail.nominum.com (using TLSv1/SSLv3 with cipher AES128-SHA (128 bits)); Wed, 24 Jan 2007 14:32:59 -0800 In-Reply-To: <20070124210536.GE6482@isc.org> References: <200701241448.l0OElsE8012219@scramble.Princeton.EDU> <20070124184135.GB6482@isc.org> <200701242035.l0OKZg9U014820@scramble.Princeton.EDU> <20070124210536.GE6482@isc.org> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Ted Lemon Subject: Re: [dhcwg] RFC 2131: can a DHCPv4 client (Mac OS X) transition directly from BOUND to INIT then back to BOUND? Date: Wed, 24 Jan 2007 15:32:50 -0700 To: "David W. Hankins" X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: dhcwg@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org On Jan 24, 2007, at 2:05 PM, David W. Hankins wrote: > I'm not sure if 'operable' means that the lease is usable (in which > case > I would have expected 'unexpired' which I think RFC2131 uses or maybe > 'valid'), or 'in operation' (as in actively configured on the > interface, > in use, able to transmit and receive IP packets). It's probably better to think of the entire configuration, rather than just the IP address and the lease on it. So if the device holding that configuration can use it to communicate on the network, it is operable; if it cannot, it is not. And this is true even though the lease has not yet expired. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Thu Jan 25 15:49:01 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HABVl-0006yW-Hc; Thu, 25 Jan 2007 15:47:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HABVk-0006yQ-DD for dhcwg@ietf.org; Thu, 25 Jan 2007 15:47:56 -0500 Received: from tyholt.uninett.no ([2001:700:1::eecb]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HABVi-0007Yw-Jd for dhcwg@ietf.org; Thu, 25 Jan 2007 15:47:56 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by tyholt.uninett.no (Postfix) with ESMTP id E0C35B5AC1 for ; Thu, 25 Jan 2007 21:47:32 +0100 (CET) Received: from tyholt.uninett.no ([127.0.0.1]) by localhost (tyholt.uninett.no [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 21073-01-67 for ; Thu, 25 Jan 2007 21:47:32 +0100 (CET) Received: from [IPv6?2001?700?1?1100?2d54?4507?4fe7?5db8] (unknown [IPv6:2001:700:1:1100:2d54:4507:4fe7:5db8]) by tyholt.uninett.no (Postfix) with ESMTP id 7B5A5B5A9B for ; Thu, 25 Jan 2007 21:47:32 +0100 (CET) Message-ID: <45B91756.3060909@uninett.no> Date: Thu, 25 Jan 2007 21:47:18 +0100 From: Stig Venaas User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: dhcwg Subject: Re: [dhcwg] dhc wg last call on agentopt-delegate and srsn-option drafts References: <45950DDB.3040009@uninett.no> In-Reply-To: <45950DDB.3040009@uninett.no> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at uninett.no X-Spam-Score: -2.8 (--) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org Stig Venaas wrote: > This message announces a wg last call on two drafts. They are > > DHCPv6 Relay Agent Assignment Notification (RAAN) Option > > > and > > DHCPv6 Server Reply Sequence Number Option > . > > The last call will conclude at 1700EST on Mon, 2007-01-15. These drafts did not pass wg last call. It appears we need to further investigate whether there are better approaches, or maybe even whether snooping is sufficient. In particular, draft-stenberg-pd-route-maintenance may help us find or eliminate other approaches. Apart from route injection, there may be other reasons why the relay agent needs this information, e.g. access control. Stig > > Please respond to this WG last call. If you support acceptance of the > documents without change, respond with a simple acknowledgment, so that > support for the documents can be assessed. Lack of discussion does not > represent positive support. If there is no expression of support for > acceptance during the WG last call, the documents will not be advanced > to the IESG. > > draft-ietf-dhc-dhcpv6-agentopt-delegate defines an option sent by a > DHCP server to inform a DHCP relay agent of IPv6 addresses or IPv6 > prefixes that have been assigned or delegated to DHCP clients. The > option makes use of the below srsn-option. This draft is available as > http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-agentopt-delegate-02.txt > > > draft-ietf-dhc-dhcpv6-srsn-option defines a Server Reply Sequence Number > option for DHCPv6. It's sent from server to relay to ensure proper > sequencing of Relay-Reply messages. It's used by the agentopt-delegate > option. This draft is available as > http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-srsn-option-00.txt > > > Stig > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Thu Jan 25 23:04:28 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAIJA-0001EY-Ui; Thu, 25 Jan 2007 23:03:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAIJ9-0001EQ-1x for dhcwg@ietf.org; Thu, 25 Jan 2007 23:03:23 -0500 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HAIJ7-00023O-Qy for dhcwg@ietf.org; Thu, 25 Jan 2007 23:03:23 -0500 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 25 Jan 2007 20:03:21 -0800 X-IronPort-AV: i="4.13,240,1167638400"; d="scan'208"; a="51648367:sNHT43830104" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l0Q43LEP031407 for ; Thu, 25 Jan 2007 23:03:21 -0500 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l0Q43LOA027643 for ; Thu, 25 Jan 2007 23:03:21 -0500 (EST) Received: from xmb-rtp-20a.amer.cisco.com ([64.102.31.15]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 25 Jan 2007 23:03:21 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [dhcwg] 3315 - Reconfigure Key Protocol Date: Thu, 25 Jan 2007 23:03:19 -0500 Message-ID: <8E296595B6471A4689555D5D725EBB210318E6B0@xmb-rtp-20a.amer.cisco.com> In-Reply-To: <8E296595B6471A4689555D5D725EBB2102DD72DB@xmb-rtp-20a.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dhcwg] 3315 - Reconfigure Key Protocol Thread-Index: AccpIrF9CwarY2y6Q6WcvVZ7mc41ogX3BGdQ From: "Bernie Volz \(volz\)" To: X-OriginalArrivalTime: 26 Jan 2007 04:03:21.0415 (UTC) FILETIME=[EB22DD70:01C740FE] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=312; t=1169784201; x=1170648201; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=volz@cisco.com; z=From:=20=22Bernie=20Volz=20\(volz\)=22=20 |Subject:=20RE=3A=20[dhcwg]=203315=20-=20Reconfigure=20Key=20Protocol |Sender:=20 |To:=20; bh=sJTjXOqakfJK7TxrQz2Os8xznu5efA/u0nlOT3bA22g=; b=sIrlwWwZbpAG+8DxQPyfHtCRC+v1e3RHG5fPsEhvH8CrL5By1ZfWUZikXrgUCaP29oCOPzdd lkzTxDhgU58Ir0A+P0BPgdL7Ifc9cI81UdtbB0BW4HVyNLzSiANs7dMm; Authentication-Results: rtp-dkim-2; header.From=volz@cisco.com; dkim=pass (s ig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org Ignore the original message (as luckily it appears it was!). I had confused "plain" MD5 with HMAC-MD5. - Bernie -----Original Message----- From: Bernie Volz (volz)=20 Sent: Tuesday, December 26, 2006 2:19 PM To: Ralph Droms (rdroms); dhcwg@ietf.org Subject: [dhcwg] 3315 - Reconfigure Key Protocol _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Fri Jan 26 06:47:58 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAPXk-0002Eu-3q; Fri, 26 Jan 2007 06:46:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAPXi-0002Em-O1 for dhcwg@ietf.org; Fri, 26 Jan 2007 06:46:54 -0500 Received: from tyholt.uninett.no ([2001:700:1::eecb]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HAPXi-0003lG-7Y for dhcwg@ietf.org; Fri, 26 Jan 2007 06:46:54 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by tyholt.uninett.no (Postfix) with ESMTP id BBE81B5B04 for ; Fri, 26 Jan 2007 12:46:42 +0100 (CET) Received: from tyholt.uninett.no ([127.0.0.1]) by localhost (tyholt.uninett.no [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 30774-01-73 for ; Fri, 26 Jan 2007 12:46:42 +0100 (CET) Received: from [IPv6?2001?700?1?7?215?f2ff?fe35?307d] (sverresborg.uninett.no [IPv6:2001:700:1:7:215:f2ff:fe35:307d]) by tyholt.uninett.no (Postfix) with ESMTP id 99C02B5B02 for ; Fri, 26 Jan 2007 12:46:42 +0100 (CET) Message-ID: <45B9EA22.20506@uninett.no> Date: Fri, 26 Jan 2007 12:46:42 +0100 From: Stig Venaas User-Agent: Mozilla Thunderbird 1.0.7 (X11/20060613) X-Accept-Language: en-us, en MIME-Version: 1.0 To: dhcwg@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at uninett.no X-Spam-Score: -2.8 (--) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Subject: [dhcwg] Adopting draft-dhankins-atomic-dhcp-00 as wg work item X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org There was consensus at the dhc wg meeting in San Diego to adopt draft-dhankins-atomic-dhcp-00 as a dhc wg work item. For details see the minutes at http://www3.ietf.org/proceedings/06nov/minutes/dhc.txt If there are no objections posted to the wg mailing list, the chairs will accept the draft as a wg work item on 2007-02-09. Stig _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Fri Jan 26 10:44:14 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HATEW-0002Oy-QL; Fri, 26 Jan 2007 10:43:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HATEV-0002MH-NI for dhcwg@ietf.org; Fri, 26 Jan 2007 10:43:19 -0500 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HATET-0007eY-DZ for dhcwg@ietf.org; Fri, 26 Jan 2007 10:43:19 -0500 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 26 Jan 2007 07:43:17 -0800 X-IronPort-AV: i="4.13,243,1167638400"; d="scan'208"; a="51673782:sNHT44075120" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l0QFhFfF021325 for ; Fri, 26 Jan 2007 10:43:15 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l0QFhBOO006093 for ; Fri, 26 Jan 2007 10:43:15 -0500 (EST) Received: from xmb-rtp-211.amer.cisco.com ([64.102.31.118]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 26 Jan 2007 10:43:14 -0500 Received: from 10.86.240.204 ([10.86.240.204]) by xmb-rtp-211.amer.cisco.com ([64.102.31.118]) with Microsoft Exchange Server HTTP-DAV ; Fri, 26 Jan 2007 15:43:14 +0000 User-Agent: Microsoft-Entourage/11.3.3.061214 Date: Fri, 26 Jan 2007 10:43:13 -0500 From: Ralph Droms To: dhcwg Message-ID: Thread-Topic: dhc WG last call on draft-ietf-dhc-dhcpv6-ero Thread-Index: AcdBYLAS7pi8OK1TEdunlQARJOT6eg== Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 26 Jan 2007 15:43:14.0648 (UTC) FILETIME=[B10DB580:01C74160] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=943; t=1169826195; x=1170690195; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rdroms@cisco.com; z=From:=20Ralph=20Droms=20 |Subject:=20dhc=20WG=20last=20call=20on=20draft-ietf-dhc-dhcpv6-ero |Sender:=20 |To:=20dhcwg=20; bh=AuoeHZqddKpyCIUkATJ6/EEJ3SLhjnIOYOG4cLEcMXM=; b=lqt5WqIq5M5XLDHlrV4w71s9IeyZdQ9NEUJyt35vlDgjypmxMJK7ymK2cGnhXL3mJVGB3IC0 HvpOAXrssHaNNBa1TNXf8pXxcnPB55wCUsQr+RlyuMQvV+omMZ6u3LFA; Authentication-Results: rtp-dkim-2; header.From=rdroms@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Subject: [dhcwg] dhc WG last call on draft-ietf-dhc-dhcpv6-ero X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org This message announces a WG last call on "DHCPv6 Relay Agent Echo Request Option" . The last call will conclude at 1700EST, Mon, 2007-02-05. Please respond to this WG last call. If you support acceptance of the document without change, respond with a simple acknowledgment, so that support for the document can be assessed. Lack of discussion does not represent positive support. If there is no expression of support for acceptance during the WG last call, the document will not be advanced to the IESG. draft-ietf-dhc-dhcpv6-ero-00.txt defines a Relay Agent Echo Request option for the Dynamic Host Configuration Protocol for IPv6 (DHCPv6). The option allows a DHCPv6 relay agent to request a list of relay agent options that the server echoes back to the relay agent.. This draft is available as http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-ero-00.txt - Ralph Droms _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Fri Jan 26 10:51:35 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HATMA-0007P7-2m; Fri, 26 Jan 2007 10:51:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HATM8-0007P2-Lq for dhcwg@ietf.org; Fri, 26 Jan 2007 10:51:12 -0500 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HATM7-0000fB-BV for dhcwg@ietf.org; Fri, 26 Jan 2007 10:51:12 -0500 Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-2.cisco.com with ESMTP; 26 Jan 2007 07:51:11 -0800 X-IronPort-AV: i="4.13,243,1167638400"; d="scan'208"; a="358008470:sNHT45260514" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-8.cisco.com (8.12.11/8.12.11) with ESMTP id l0QFpANM000498 for ; Fri, 26 Jan 2007 07:51:10 -0800 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id l0QFp1iA001901 for ; Fri, 26 Jan 2007 07:51:10 -0800 (PST) Received: from xmb-rtp-211.amer.cisco.com ([64.102.31.118]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 26 Jan 2007 10:51:07 -0500 Received: from 10.86.240.204 ([10.86.240.204]) by xmb-rtp-211.amer.cisco.com ([64.102.31.118]) with Microsoft Exchange Server HTTP-DAV ; Fri, 26 Jan 2007 15:51:07 +0000 User-Agent: Microsoft-Entourage/11.3.3.061214 Date: Fri, 26 Jan 2007 10:51:05 -0500 From: Ralph Droms To: dhcwg Message-ID: Thread-Topic: dhc WG last call on draft-ietf-dhc-dhcvp6-leasequery Thread-Index: AcdBYclnCBSMGK1VEdunlQARJOT6eg== Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 26 Jan 2007 15:51:07.0667 (UTC) FILETIME=[CAFEAE30:01C74161] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1114; t=1169826670; x=1170690670; c=relaxed/simple; s=sjdkim8002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rdroms@cisco.com; z=From:=20Ralph=20Droms=20 |Subject:=20dhc=20WG=20last=20call=20on=20draft-ietf-dhc-dhcvp6-leasequer y |Sender:=20; bh=SbeYt3ZJWkF9FRy4J+BdI5DwzR9YVMbxTqeEisgpe90=; b=DOOQdUKg8kFtZPCxu2tluUYwqxzJTCKujfUqOjInhcpcf/A3C/+IkLhcfT0FX+oiiRVVORnD jp/HogfveJiYjihzUMnjzIkNwMqs6Q7w9vxR5uVKY+p4fIcrWbJ4oAwa; Authentication-Results: sj-dkim-8; header.From=rdroms@cisco.com; dkim=pass ( sig from cisco.com/sjdkim8002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Subject: [dhcwg] dhc WG last call on draft-ietf-dhc-dhcvp6-leasequery X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org This message announces a WG last call on "DHCPv6 Leasequery" . The last call will conclude at 1700EST, Mon, 2007-02-05. Please respond to this WG last call. If you support acceptance of the document without change, respond with a simple acknowledgment, so that support for the document can be assessed. Lack of discussion does not represent positive support. If there is no expression of support for acceptance during the WG last call, the document will not be advanced to the IESG. draft-ietf-dhc-dhcvp6-leasequery specifies leasequery for the Dynamic Host Configuration Protocol for IPv6 (DHCPv6) which can be used as a means to obtain lease information about DHCPv6 clients from a DHCPv6 server. draft-ietf-dhc-dhcvp6-leasequery specifies the scope of data that can be retrieved as well as both DHCPv6 leasequery requestor and server behavior. draft-ietf-dhc-dhcvp6-leasequery extends DHCPv6. This draft is available as http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcvp6-leasequery-01.txt - Stig Venaas, Ralph Droms dhc WG chairs _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Fri Jan 26 11:17:47 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HATlO-0005JT-Oh; Fri, 26 Jan 2007 11:17:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HATlN-0005GD-4v for dhcwg@ietf.org; Fri, 26 Jan 2007 11:17:17 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HATlL-00067l-74 for dhcwg@ietf.org; Fri, 26 Jan 2007 11:17:17 -0500 Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-3.cisco.com with ESMTP; 26 Jan 2007 08:17:14 -0800 X-IronPort-AV: i="4.13,243,1167638400"; d="scan'208"; a="459969565:sNHT64847600" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-7.cisco.com (8.12.11/8.12.11) with ESMTP id l0QGHEr1011624 for ; Fri, 26 Jan 2007 08:17:14 -0800 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id l0QGH0iA013337 for ; Fri, 26 Jan 2007 08:17:13 -0800 (PST) Received: from xmb-rtp-211.amer.cisco.com ([64.102.31.118]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 26 Jan 2007 11:17:04 -0500 Received: from 10.86.240.204 ([10.86.240.204]) by xmb-rtp-211.amer.cisco.com ([64.102.31.118]) with Microsoft Exchange Server HTTP-DAV ; Fri, 26 Jan 2007 16:17:04 +0000 User-Agent: Microsoft-Entourage/11.3.3.061214 Date: Fri, 26 Jan 2007 11:17:03 -0500 From: Ralph Droms To: dhcwg Message-ID: Thread-Topic: Internet-Drafts Submission Cutoff Dates for the 68th IETF Meeting in Prague, Czech Republic Thread-Index: AcdBZWoLqGg1xK1YEdunlQARJOT6eg== In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 26 Jan 2007 16:17:04.0961 (UTC) FILETIME=[6B36E310:01C74165] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1855; t=1169828234; x=1170692234; c=relaxed/simple; s=sjdkim7002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rdroms@cisco.com; z=From:=20Ralph=20Droms=20 |Subject:=20FW=3A=20Internet-Drafts=20Submission=20Cutoff=20Dates=20for=2 0the=2068th=20IETF=20=0A=20Meeting=20in=20Prague, =20Czech=20Republic=20 |Sender:=20; bh=ArlupoqtUA6+SOKh+OC8HNz4cPdsU4H6BL1bjA+pZO4=; b=FDXnM/jH5ja5yOILp3iSoeJexsQo45ss8v64mQPK04aPj1b7lxJdOAJk5q94X5F7jfAnpKnH JFASCUdARixChoJRPZUcEVSfiHUkkBQILG6qRrmSwLLcVc3WLH9CIDKw; Authentication-Results: sj-dkim-7; header.From=rdroms@cisco.com; dkim=pass ( sig from cisco.com/sjdkim7002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Subject: [dhcwg] FW: Internet-Drafts Submission Cutoff Dates for the 68th IETF Meeting in Prague, Czech Republic X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org ------ Forwarded Message From: Date: Fri, 26 Jan 2007 00:00:02 -0500 To: Subject: Internet-Drafts Submission Cutoff Dates for the 68th IETF Meeting in Prague, Czech Republic There are two (2) Internet-Draft cutoff dates for the 68th IETF Meeting in Prague, Czech Republic: February 26th: Cutoff Date for Initial (i.e., version -00) Internet-Draft Submissions All initial Internet-Drafts (version -00) must be submitted by Monday, February 26th at 9:00 AM ET. As always, all initial submissions with a filename beginning with "draft-ietf" must be approved by the appropriate WG Chair before they can be processed or announced. The Secretariat would appreciate receiving WG Chair approval by Monday, February 19th at 9:00 AM ET. March 5th: Cutoff Date for Revised (i.e., version -01 and higher) Internet-Draft Submissions All revised Internet-Drafts (version -01 and higher) must be submitted by Monday, March 5th at 9:00 AM ET. Initial and revised Internet-Drafts received after their respective cutoff dates will not be made available in the Internet-Drafts directory or announced until on or after Monday, March 19th at 9:00 AM ET, when Internet-Draft posting resumes. Please do not wait until the last minute to submit. Thank you for your understanding and cooperation. If you have any questions or concerns, then please send a message to internet-drafts@ietf.org. The IETF Secretariat FYI: The Internet-Draft cutoff dates as well as other significant dates for the 68th IETF Meeting can be found at http://www.ietf.org/meetings/cutoff_dates_68.html. _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce ------ End of Forwarded Message _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Fri Jan 26 11:21:51 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HATpc-0006sG-Q2; Fri, 26 Jan 2007 11:21:40 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HATpb-0006qe-0M for dhcwg@ietf.org; Fri, 26 Jan 2007 11:21:39 -0500 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HATpY-0006xx-K5 for dhcwg@ietf.org; Fri, 26 Jan 2007 11:21:38 -0500 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-2.cisco.com with ESMTP; 26 Jan 2007 08:21:36 -0800 X-IronPort-AV: i="4.13,244,1167638400"; d="scan'208"; a="358018293:sNHT210139544" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-5.cisco.com (8.12.11/8.12.11) with ESMTP id l0QGLZSI013185 for ; Fri, 26 Jan 2007 08:21:35 -0800 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l0QGLMnX023961 for ; Fri, 26 Jan 2007 08:21:35 -0800 (PST) Received: from xmb-rtp-211.amer.cisco.com ([64.102.31.118]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 26 Jan 2007 11:21:10 -0500 Received: from 10.86.240.204 ([10.86.240.204]) by xmb-rtp-211.amer.cisco.com ([64.102.31.118]) with Microsoft Exchange Server HTTP-DAV ; Fri, 26 Jan 2007 16:21:10 +0000 User-Agent: Microsoft-Entourage/11.3.3.061214 Date: Fri, 26 Jan 2007 11:21:08 -0500 From: Ralph Droms To: dhcwg Message-ID: Thread-Topic: Approval to Post Version -00 Internet-Drafts for the 68th IETF Meeting in Prague, Czech Republic Thread-Index: AcdBZfwTOtD/mK1ZEdunlQARJOT6eg== In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 26 Jan 2007 16:21:10.0871 (UTC) FILETIME=[FDC9C670:01C74165] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1566; t=1169828495; x=1170692495; c=relaxed/simple; s=sjdkim5002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rdroms@cisco.com; z=From:=20Ralph=20Droms=20 |Subject:=20FW=3A=20Approval=20to=20Post=20Version=20-00=20Internet-Draft s=20for=20the=2068th=0A=20IETF=20=20Meeting=20in=20Prague, =20Czech=20Repub lic=20 |Sender:=20; bh=ECaDPwe4afPrdyQjaGKzi8AEAfHQe6mHTkvpuqDOCZE=; b=gXbonFPixsaWmOMpLAn6QxX7rRe3598JUX/MHMyhrH0bTnJ+FF7qQ5MhYVBULpg5G+Ah+fNI 3dLrM8ieuFrREXFWZMvUPW0hdNL6fLfHsu0Z5wXzD7tY3si6Cr6fD1hA; Authentication-Results: sj-dkim-5; header.From=rdroms@cisco.com; dkim=pass ( sig from cisco.com/sjdkim5002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Subject: [dhcwg] FW: Approval to Post Version -00 Internet-Drafts for the 68th IETF Meeting in Prague, Czech Republic X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org WG members - if you plan to submit a -00 dhc WG draft for IETF 68, please let us know as soon as possible so we can pre-approve publication of those drafts. - Ralph ------ Forwarded Message From: Internet-Drafts Administrator Date: Fri, 26 Jan 2007 00:00:02 -0500 To: Working Group Chairs Subject: Approval to Post Version -00 Internet-Drafts for the 68th IETF Meeting in Prague, Czech Republic Dear IETF Working Group Chairs: In order to expedite the processing of the many version -00 I-Ds that the Secretariat receives before an IETF meeting, we ask that you please notify the Secretariat prior to the initial submission cutoff date of all version -00 I-Ds that you expect to approve for posting as WG documents. Please send the filenames of your approved -00 I-Ds to internet-drafts@ietf.org. We would appreciate receiving your list of approved drafts five (5) business days prior to the cutoff date for -00 submissions, or by Monday, February 19th at 9:00 AM ET for the 68th IETF Meeting. Please include the word "Approved I-Ds" in the "Subject" field. This procedure will help to ensure that version -00 I-Ds are posted in a timely manner, allowing more time for review by the public. Thank you for your cooperation in this matter. The Internet-Drafts Administrator FYI: The Internet-Draft cutoff dates as well as other significant dates for the 68th IETF Meeting can be found at http://www.ietf.org/meetings/cutoff_dates_68.html. ------ End of Forwarded Message _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Fri Jan 26 11:24:37 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HATsM-0008IU-9p; Fri, 26 Jan 2007 11:24:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HATsL-0008IO-Ky for dhcwg@ietf.org; Fri, 26 Jan 2007 11:24:29 -0500 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HATsJ-0007Fr-3V for dhcwg@ietf.org; Fri, 26 Jan 2007 11:24:29 -0500 Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-2.cisco.com with ESMTP; 26 Jan 2007 08:24:24 -0800 X-IronPort-AV: i="4.13,244,1167638400"; d="scan'208"; a="358019266:sNHT1364072706" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-7.cisco.com (8.12.11/8.12.11) with ESMTP id l0QGONi7016756 for ; Fri, 26 Jan 2007 08:24:23 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id l0QGOJhs017830 for ; Fri, 26 Jan 2007 08:24:24 -0800 (PST) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 26 Jan 2007 08:24:21 -0800 Received: from kkinnear-wxp.cisco.com ([10.21.98.162]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 26 Jan 2007 08:24:19 -0800 Message-Id: <4.3.2.7.2.20070126112335.035b87c8@email.cisco.com> X-Sender: kkinnear@email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 26 Jan 2007 11:24:33 -0500 To: Ralph Droms , dhcwg From: Kim Kinnear Subject: Re: [dhcwg] dhc WG last call on draft-ietf-dhc-dhcvp6-leasequery In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-OriginalArrivalTime: 26 Jan 2007 16:24:19.0779 (UTC) FILETIME=[6E62D930:01C74166] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1435; t=1169828663; x=1170692663; c=relaxed/simple; s=sjdkim7002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=kkinnear@cisco.com; z=From:=20Kim=20Kinnear=20 |Subject:=20Re=3A=20[dhcwg]=20dhc=20WG=20last=20call=20on=0A=20=20draft-i etf-dhc-dhcvp6-leasequery |Sender:=20; bh=AHMcg35rHKjRZMv87M7ysW/FtC9+ehol4MbvMYunD0k=; b=cPs8aCpMbny3ZAvsLcAgTskrR6HRuDT46VYK/24K4sYuPClyl88otaZpyHgP3leB2i+nUCP4 8unYKZcrVnLQ8Ff09LAIb54BCYUirJXveTG1jijfeAXiyeBY9NGj1gDH; Authentication-Results: sj-dkim-7; header.From=kkinnear@cisco.com; dkim=pass ( sig from cisco.com/sjdkim7002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: kkinnear@cisco.com X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org I approve moving this draft forward without change and advancing it to the IESG. Thanks -- Kim Kinnear At 10:51 AM 1/26/2007, Ralph Droms wrote: >This message announces a WG last call on "DHCPv6 Leasequery" >. The last call will >conclude at 1700EST, Mon, 2007-02-05. > >Please respond to this WG last call. If you support acceptance of the >document without change, respond with a simple acknowledgment, so that >support for the document can be assessed. Lack of discussion does not >represent positive support. If there is no expression of support for >acceptance during the WG last call, the document will not be advanced >to the IESG. > >draft-ietf-dhc-dhcvp6-leasequery specifies leasequery for the Dynamic >Host Configuration Protocol for IPv6 (DHCPv6) which can be used as a >means to obtain lease information about DHCPv6 clients from a DHCPv6 >server. draft-ietf-dhc-dhcvp6-leasequery specifies the scope of data >that can be retrieved as well as both DHCPv6 leasequery requestor and >server behavior. draft-ietf-dhc-dhcvp6-leasequery extends DHCPv6. >This draft is available as >http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcvp6-leasequery-01.txt > >- Stig Venaas, Ralph Droms > dhc WG chairs > > >_______________________________________________ >dhcwg mailing list >dhcwg@ietf.org >https://www1.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Fri Jan 26 11:33:44 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAU0m-0005rW-Rp; Fri, 26 Jan 2007 11:33:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAU0k-0005rE-Pv for dhcwg@ietf.org; Fri, 26 Jan 2007 11:33:10 -0500 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HAU0i-0000dY-Bw for dhcwg@ietf.org; Fri, 26 Jan 2007 11:33:10 -0500 Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-2.cisco.com with ESMTP; 26 Jan 2007 08:33:07 -0800 X-IronPort-AV: i="4.13,244,1167638400"; d="scan'208"; a="358022227:sNHT45047424" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-7.cisco.com (8.12.11/8.12.11) with ESMTP id l0QGX7TK022147 for ; Fri, 26 Jan 2007 08:33:07 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id l0QGX7ho022237 for ; Fri, 26 Jan 2007 08:33:07 -0800 (PST) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 26 Jan 2007 08:33:07 -0800 Received: from [171.69.134.48] ([171.69.134.48]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 26 Jan 2007 08:33:07 -0800 Message-ID: <45BA2D42.808@cisco.com> Date: Fri, 26 Jan 2007 08:33:06 -0800 From: Mark Stapp User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: dhcwg Subject: Re: [dhcwg] dhc WG last call on draft-ietf-dhc-dhcvp6-leasequery References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 26 Jan 2007 16:33:07.0714 (UTC) FILETIME=[A90F5620:01C74167] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1383; t=1169829187; x=1170693187; c=relaxed/simple; s=sjdkim7002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mjs@cisco.com; z=From:=20Mark=20Stapp=20 |Subject:=20Re=3A=20[dhcwg]=20dhc=20WG=20last=20call=20on=20draft-ietf-dh c-dhcvp6-leasequery |Sender:=20; bh=8LbYpTFpOhAJlmeo5vuCT9eAlKo9yMhrF0WdUozGBmA=; b=EgSMHTX7IcuPYfY4oG3aGqxxh6krwuBSVIJ+494pN1tvyaKrIHyEsjR3pmZoKJ6OZILLS2rO uoaPD1iog6rzYXObgShICaS988xgjqOL7zsLmo6Uicvsw9KVy2GHnLE8; Authentication-Results: sj-dkim-7; header.From=mjs@cisco.com; dkim=pass (sig from cisco.com/sjdkim7002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org I support the acceptance of this draft. -- Mark Ralph Droms wrote: > This message announces a WG last call on "DHCPv6 Leasequery" > . The last call will > conclude at 1700EST, Mon, 2007-02-05. > > Please respond to this WG last call. If you support acceptance of the > document without change, respond with a simple acknowledgment, so that > support for the document can be assessed. Lack of discussion does not > represent positive support. If there is no expression of support for > acceptance during the WG last call, the document will not be advanced > to the IESG. > > draft-ietf-dhc-dhcvp6-leasequery specifies leasequery for the Dynamic > Host Configuration Protocol for IPv6 (DHCPv6) which can be used as a > means to obtain lease information about DHCPv6 clients from a DHCPv6 > server. draft-ietf-dhc-dhcvp6-leasequery specifies the scope of data > that can be retrieved as well as both DHCPv6 leasequery requestor and > server behavior. draft-ietf-dhc-dhcvp6-leasequery extends DHCPv6. > This draft is available as > http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcvp6-leasequery-01.txt > > - Stig Venaas, Ralph Droms > dhc WG chairs > > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg > _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Fri Jan 26 11:45:29 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAUC0-0002an-W5; Fri, 26 Jan 2007 11:44:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAUC0-0002ac-CP for dhcwg@ietf.org; Fri, 26 Jan 2007 11:44:48 -0500 Received: from goliath.isc.org ([2001:4f8:3:bb::72]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HAUBz-0002EK-Tx for dhcwg@ietf.org; Fri, 26 Jan 2007 11:44:48 -0500 Received: by goliath.isc.org (Postfix, from userid 10200) id E69E35A6ED; Fri, 26 Jan 2007 08:44:27 -0800 (PST) Date: Fri, 26 Jan 2007 08:44:27 -0800 From: "David W. Hankins" To: dhcwg@ietf.org Subject: Re: [dhcwg] dhc WG last call on draft-ietf-dhc-dhcpv6-ero Message-ID: <20070126164427.GA3731@isc.org> References: Mime-Version: 1.0 In-Reply-To: User-Agent: Mutt/1.5.9i X-Spam-Score: -2.8 (--) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0320213983==" Errors-To: dhcwg-bounces@ietf.org --===============0320213983== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="0OAP2g/MAC+5xKAE" Content-Disposition: inline --0OAP2g/MAC+5xKAE Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jan 26, 2007 at 10:43:13AM -0500, Ralph Droms wrote: > Please respond to this WG last call. If you support acceptance of the > document without change, respond with a simple acknowledgment, so that > support for the document can be assessed. Lack of discussion does not > represent positive support. If there is no expression of support for > acceptance during the WG last call, the document will not be advanced > to the IESG. I support acceptance of the document with *very* minor editorial changes that I'm sure would have been made anyway. However, DHCPv6 [2] does not require the server to do so. As matter of fact, for certain relay agent options, the server is required to "As matter of fact," doesn't read quite right. I suggest "As a matter of fact," or possibly "In fact,". The authors also may want to consider: "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [1]. Naming the RFC before the reference number. It saves the reader =66rom having to perform a lookup (although most of us probably know the number). This is a well written document. It is concise and simple. I think there is actually more 'IETF Cruft' in this document than 'DHCP Signal'. The IPR and Security sections and so forth. It is a needed document, as it vastly simplifies a scary area of DHCPv6 relay agent and server interactions in a nice, simple way. As far as I know, "Echo Request" is not a term used by Verisign's marketing department, which evidently is now one of those things we need to check before sending drafts to the IESG. Their web site's search tool does not put the two words together in the same sentence. Does anyone have a contact at Verisign marketing to determine if they plan to use these words in marketing literature between now and the IESG's review of this draft? The term does appear in google, but is clearly delineated as 'ICMP Echo Request' if not in title, then later in context. There should be no confusion with a DHCPv6 'Relay Agent Echo Request Option', so long as these clear prefixes and suffixes are always present. That is, I do not expect that anyone can reasonably interpret this document such that would leave them to believe that this ERO is intended to carry an ICMP Echo Request. That is too far fetched, even for the IETF. Besides, a 'DHCPv6 Echo Request Option' PDF appears on the second page. I'm not sure where this sarcastic and acrimonous attitude of mine came from this morning. Maybe I just haven't had enough caffeine. --=20 David W. Hankins "If you don't do it right the first time, Software Engineer you'll just have to do it again." Internet Systems Consortium, Inc. -- Jack T. Hankins --0OAP2g/MAC+5xKAE Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFFui/rcXeLeWu2vmoRAi02AJ48WxEw0spCNH22oWVq4BQFvdnkhQCgspWl prCCoSnlHvu82MItT+C8a+4= =dvAJ -----END PGP SIGNATURE----- --0OAP2g/MAC+5xKAE-- --===============0320213983== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg --===============0320213983==-- From dhcwg-bounces@ietf.org Fri Jan 26 12:28:53 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAUsG-000288-3w; Fri, 26 Jan 2007 12:28:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAUsE-00027M-K5 for dhcwg@ietf.org; Fri, 26 Jan 2007 12:28:26 -0500 Received: from goliath.isc.org ([2001:4f8:3:bb::72]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HAUsE-0007Xo-AP for dhcwg@ietf.org; Fri, 26 Jan 2007 12:28:26 -0500 Received: by goliath.isc.org (Postfix, from userid 10200) id 8AA1C5A6ED; Fri, 26 Jan 2007 09:28:21 -0800 (PST) Date: Fri, 26 Jan 2007 09:28:21 -0800 From: "David W. Hankins" To: dhcwg@ietf.org Subject: Re: [dhcwg] dhc WG last call on draft-ietf-dhc-dhcvp6-leasequery Message-ID: <20070126172821.GD3731@isc.org> References: Mime-Version: 1.0 In-Reply-To: User-Agent: Mutt/1.5.9i X-Spam-Score: -2.8 (--) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2062258520==" Errors-To: dhcwg-bounces@ietf.org --===============2062258520== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="JP+T4n/bALQSJXh8" Content-Disposition: inline --JP+T4n/bALQSJXh8 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Fri, Jan 26, 2007 at 10:51:05AM -0500, Ralph Droms wrote: > Please respond to this WG last call. If you support acceptance of the > document without change, respond with a simple acknowledgment, so that > support for the document can be assessed. Lack of discussion does not I support moving this document forward without change (not even editorial ones!). Also, 'leasequery' nets only DHCP-related hits on google, and no hits anywhere on Verisign's website. But of course they could roll something out between now and the IESG's review... -- David W. Hankins "If you don't do it right the first time, Software Engineer you'll just have to do it again." Internet Systems Consortium, Inc. -- Jack T. Hankins --JP+T4n/bALQSJXh8 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFFujo1cXeLeWu2vmoRAgZvAJ4lKH7qypHVuK651MaTLg1iAg6IvQCeJj75 p00G8rGPrGe72EeA+PRuFDk= =q71f -----END PGP SIGNATURE----- --JP+T4n/bALQSJXh8-- --===============2062258520== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg --===============2062258520==-- From dhcwg-bounces@ietf.org Fri Jan 26 12:38:45 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAV1w-0007Hf-5M; Fri, 26 Jan 2007 12:38:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAV1u-0007Fp-8g for dhcwg@ietf.org; Fri, 26 Jan 2007 12:38:26 -0500 Received: from goliath.isc.org ([2001:4f8:3:bb::72]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HAV1t-0000L5-J5 for dhcwg@ietf.org; Fri, 26 Jan 2007 12:38:26 -0500 Received: by goliath.isc.org (Postfix, from userid 10200) id AC31E5A6ED; Fri, 26 Jan 2007 09:38:21 -0800 (PST) Date: Fri, 26 Jan 2007 09:38:21 -0800 From: "David W. Hankins" To: dhcwg@ietf.org Subject: Re: [dhcwg] Adopting draft-dhankins-atomic-dhcp-00 as wg work item Message-ID: <20070126173821.GE3731@isc.org> References: <45B9EA22.20506@uninett.no> Mime-Version: 1.0 In-Reply-To: <45B9EA22.20506@uninett.no> User-Agent: Mutt/1.5.9i X-Spam-Score: -2.8 (--) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0850814114==" Errors-To: dhcwg-bounces@ietf.org --===============0850814114== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Bu8it7iiRSEf40bY" Content-Disposition: inline --Bu8it7iiRSEf40bY Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Fri, Jan 26, 2007 at 12:46:42PM +0100, Stig Venaas wrote: > There was consensus at the dhc wg meeting in San Diego to adopt > draft-dhankins-atomic-dhcp-00 as a dhc wg work item. For details > see the minutes at > http://www3.ietf.org/proceedings/06nov/minutes/dhc.txt > > If there are no objections posted to the wg mailing list, the > chairs will accept the draft as a wg work item on 2007-02-09. As I recall the consensus was to reform the document to move the (extensive) discussion of ISC's implementation into a stripped-down summary in an appendix (if retain it at all) and to expand upon the advice to draft authors. Consequently the draft probably won't be named 'atomic dhcp' after that. I am unsure if I'm going to be able to complete that prior to the IETF 68 cutoff date...very busy at our office here. -- David W. Hankins "If you don't do it right the first time, Software Engineer you'll just have to do it again." Internet Systems Consortium, Inc. -- Jack T. Hankins --Bu8it7iiRSEf40bY Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFFujyNcXeLeWu2vmoRArlMAKCH2CP56LFF/v9xUy/dlIJzyntCnwCcD+4o dFz/wammK0s+C7jyoTohN6I= =+JgR -----END PGP SIGNATURE----- --Bu8it7iiRSEf40bY-- --===============0850814114== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg --===============0850814114==-- From dhcwg-bounces@ietf.org Fri Jan 26 17:13:57 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAZJg-0004KW-HK; Fri, 26 Jan 2007 17:13:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAZJf-0004Hu-An for dhcwg@ietf.org; Fri, 26 Jan 2007 17:13:03 -0500 Received: from pacdcoavas09.cable.comcast.com ([208.17.33.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HAZEs-00081B-EZ for dhcwg@ietf.org; Fri, 26 Jan 2007 17:08:07 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [dhcwg] dhc WG last call on draft-ietf-dhc-dhcpv6-ero Date: Fri, 26 Jan 2007 17:07:21 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dhcwg] dhc WG last call on draft-ietf-dhc-dhcpv6-ero Thread-Index: AcdBYLAS7pi8OK1TEdunlQARJOT6egANaNCg From: "Woundy, Richard" To: "dhcwg" X-OriginalArrivalTime: 26 Jan 2007 22:07:46.0543 (UTC) FILETIME=[68F97FF0:01C74196] X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org I approve. -- Rich -----Original Message----- From: Ralph Droms [mailto:rdroms@cisco.com]=20 Sent: Friday, January 26, 2007 10:43 AM To: dhcwg Subject: [dhcwg] dhc WG last call on draft-ietf-dhc-dhcpv6-ero This message announces a WG last call on "DHCPv6 Relay Agent Echo Request Option" . The last call will conclude at 1700EST, Mon, 2007-02-05. Please respond to this WG last call. If you support acceptance of the document without change, respond with a simple acknowledgment, so that support for the document can be assessed. Lack of discussion does not represent positive support. If there is no expression of support for acceptance during the WG last call, the document will not be advanced to the IESG. draft-ietf-dhc-dhcpv6-ero-00.txt defines a Relay Agent Echo Request option for the Dynamic Host Configuration Protocol for IPv6 (DHCPv6). The option allows a DHCPv6 relay agent to request a list of relay agent options that the server echoes back to the relay agent.. This draft is available as http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-ero-00.txt - Ralph Droms=20 _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Fri Jan 26 17:13:57 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAZJg-0004Kg-R5; Fri, 26 Jan 2007 17:13:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAZJf-0004IS-BE for dhcwg@ietf.org; Fri, 26 Jan 2007 17:13:03 -0500 Received: from pacdcoavas09.cable.comcast.com ([208.17.33.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HAZEr-00081B-5y for dhcwg@ietf.org; Fri, 26 Jan 2007 17:08:06 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [dhcwg] dhc WG last call on draft-ietf-dhc-dhcvp6-leasequery Date: Fri, 26 Jan 2007 17:07:00 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dhcwg] dhc WG last call on draft-ietf-dhc-dhcpv6-ero Thread-Index: AcdBYLAS7pi8OK1TEdunlQARJOT6egANaNCg From: "Woundy, Richard" To: "dhcwg" X-OriginalArrivalTime: 26 Jan 2007 22:07:46.0543 (UTC) FILETIME=[68F97FF0:01C74196] X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org I approve. -- Rich -----Original Message----- From: Ralph Droms [mailto:rdroms@cisco.com]=20 Sent: Friday, January 26, 2007 10:43 AM To: dhcwg Subject: [dhcwg] dhc WG last call on draft-ietf-dhc-dhcpv6-ero This message announces a WG last call on "DHCPv6 Relay Agent Echo Request Option" . The last call will conclude at 1700EST, Mon, 2007-02-05. Please respond to this WG last call. If you support acceptance of the document without change, respond with a simple acknowledgment, so that support for the document can be assessed. Lack of discussion does not represent positive support. If there is no expression of support for acceptance during the WG last call, the document will not be advanced to the IESG. draft-ietf-dhc-dhcpv6-ero-00.txt defines a Relay Agent Echo Request option for the Dynamic Host Configuration Protocol for IPv6 (DHCPv6). The option allows a DHCPv6 relay agent to request a list of relay agent options that the server echoes back to the relay agent.. This draft is available as http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-ero-00.txt - Ralph Droms=20 _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Fri Jan 26 17:13:57 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAZJg-0004Kg-R5; Fri, 26 Jan 2007 17:13:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAZJf-0004IS-BE for dhcwg@ietf.org; Fri, 26 Jan 2007 17:13:03 -0500 Received: from pacdcoavas09.cable.comcast.com ([208.17.33.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HAZEr-00081B-5y for dhcwg@ietf.org; Fri, 26 Jan 2007 17:08:06 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [dhcwg] dhc WG last call on draft-ietf-dhc-dhcvp6-leasequery Date: Fri, 26 Jan 2007 17:07:00 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dhcwg] dhc WG last call on draft-ietf-dhc-dhcvp6-leasequery Thread-Index: AcdBYclnCBSMGK1VEdunlQARJOT6egANHxsw From: "Woundy, Richard" To: "dhcwg" X-OriginalArrivalTime: 26 Jan 2007 22:07:46.0684 (UTC) FILETIME=[690F03C0:01C74196] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org I approve. -- Rich -----Original Message----- From: Ralph Droms [mailto:rdroms@cisco.com]=20 Sent: Friday, January 26, 2007 10:51 AM To: dhcwg Subject: [dhcwg] dhc WG last call on draft-ietf-dhc-dhcvp6-leasequery This message announces a WG last call on "DHCPv6 Leasequery" . The last call will conclude at 1700EST, Mon, 2007-02-05. Please respond to this WG last call. If you support acceptance of the document without change, respond with a simple acknowledgment, so that support for the document can be assessed. Lack of discussion does not represent positive support. If there is no expression of support for acceptance during the WG last call, the document will not be advanced to the IESG. draft-ietf-dhc-dhcvp6-leasequery specifies leasequery for the Dynamic Host Configuration Protocol for IPv6 (DHCPv6) which can be used as a means to obtain lease information about DHCPv6 clients from a DHCPv6 server. draft-ietf-dhc-dhcvp6-leasequery specifies the scope of data that can be retrieved as well as both DHCPv6 leasequery requestor and server behavior. draft-ietf-dhc-dhcvp6-leasequery extends DHCPv6. This draft is available as http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcvp6-leasequery-01. txt - Stig Venaas, Ralph Droms dhc WG chairs _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg F0EC839870F43A6637360BC12ABD4696854@PACDCEXCMB05.cable.comcast.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dhcwg] dhc WG last call on draft-ietf-dhc-dhcvp6-leasequery Thread-Index: AcdBYclnCBSMGK1VEdunlQARJOT6egANHxsw From: "Woundy, Richard" To: "dhcwg" X-OriginalArrivalTime: 26 Jan 2007 22:07:46.0684 (UTC) FILETIME=[690F03C0:01C74196] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org I approve. -- Rich -----Original Message----- From: Ralph Droms [mailto:rdroms@cisco.com]=20 Sent: Friday, January 26, 2007 10:51 AM To: dhcwg Subject: [dhcwg] dhc WG last call on draft-ietf-dhc-dhcvp6-leasequery This message announces a WG last call on "DHCPv6 Leasequery" . The last call will conclude at 1700EST, Mon, 2007-02-05. Please respond to this WG last call. If you support acceptance of the document without change, respond with a simple acknowledgment, so that support for the document can be assessed. Lack of discussion does not represent positive support. If there is no expression of support for acceptance during the WG last call, the document will not be advanced to the IESG. draft-ietf-dhc-dhcvp6-leasequery specifies leasequery for the Dynamic Host Configuration Protocol for IPv6 (DHCPv6) which can be used as a means to obtain lease information about DHCPv6 clients from a DHCPv6 server. draft-ietf-dhc-dhcvp6-leasequery specifies the scope of data that can be retrieved as well as both DHCPv6 leasequery requestor and server behavior. draft-ietf-dhc-dhcvp6-leasequery extends DHCPv6. This draft is available as http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcvp6-leasequery-01. txt - Stig Venaas, Ralph Droms dhc WG chairs _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Sat Jan 27 08:59:43 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAo4k-0007sD-Q7; Sat, 27 Jan 2007 08:58:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAo4i-0007s0-Ob for dhcwg@ietf.org; Sat, 27 Jan 2007 08:58:36 -0500 Received: from paoakoavas10.cable.comcast.com ([208.17.35.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HAo4h-0005uR-Cr for dhcwg@ietf.org; Sat, 27 Jan 2007 08:58:36 -0500 Received: from ([24.40.15.118]) by paoakoavas10.cable.comcast.com with ESMTP id KP-TDCH3.29765687; Sat, 27 Jan 2007 08:58:14 -0500 Received: from NJCHLEXCMB01.cable.comcast.com ([172.24.2.44]) by PACDCEXCSMTP04.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 27 Jan 2007 08:58:14 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [dhcwg] dhc WG last call on draft-ietf-dhc-dhcpv6-ero Date: Sat, 27 Jan 2007 08:57:10 -0500 Message-ID: <2271C950731A734680BA3E2978816F1806DAD642@NJCHLEXCMB01.cable.comcast.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dhcwg] dhc WG last call on draft-ietf-dhc-dhcpv6-ero Thread-Index: AcdBYLAS7pi8OK1TEdunlQARJOT6egAulAmA From: "Brzozowski, John" To: "Ralph Droms" , "dhcwg" X-OriginalArrivalTime: 27 Jan 2007 13:58:14.0654 (UTC) FILETIME=[3060A9E0:01C7421B] X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org I approve. Thank you, John=20 -----Original Message----- From: Ralph Droms [mailto:rdroms@cisco.com]=20 Sent: Friday, January 26, 2007 10:43 AM To: dhcwg Subject: [dhcwg] dhc WG last call on draft-ietf-dhc-dhcpv6-ero This message announces a WG last call on "DHCPv6 Relay Agent Echo Request Option" . The last call will conclude at 1700EST, Mon, 2007-02-05. Please respond to this WG last call. If you support acceptance of the document without change, respond with a simple acknowledgment, so that support for the document can be assessed. Lack of discussion does not represent positive support. If there is no expression of support for acceptance during the WG last call, the document will not be advanced to the IESG. draft-ietf-dhc-dhcpv6-ero-00.txt defines a Relay Agent Echo Request option for the Dynamic Host Configuration Protocol for IPv6 (DHCPv6). The option allows a DHCPv6 relay agent to request a list of relay agent options that the server echoes back to the relay agent.. This draft is available as http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-ero-00.txt - Ralph Droms=20 _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Sat Jan 27 08:59:48 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAo4m-0007sQ-1O; Sat, 27 Jan 2007 08:58:40 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAo4k-0007sE-Oy for dhcwg@ietf.org; Sat, 27 Jan 2007 08:58:38 -0500 Received: from pacdcoavas09.cable.comcast.com ([208.17.33.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HAo4j-0005vQ-G6 for dhcwg@ietf.org; Sat, 27 Jan 2007 08:58:38 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [dhcwg] dhc WG last call on draft-ietf-dhc-dhcvp6-leasequery Date: Sat, 27 Jan 2007 08:57:18 -0500 Message-ID: <2271C950731A734680BA3E2978816F1806DAD641@NJCHLEXCMB01.cable.comcast.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dhcwg] dhc WG last call on draft-ietf-dhc-dhcvp6-leasequery Thread-Index: AcdBYclnCBSMGK1VEdunlQARJOT6egAuUPVA From: "Brzozowski, John" To: "Ralph Droms" , "dhcwg" X-OriginalArrivalTime: 27 Jan 2007 13:58:11.0373 (UTC) FILETIME=[2E6C05D0:01C7421B] X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org I approve. Thank you, John=20 -----Original Message----- From: Ralph Droms [mailto:rdroms@cisco.com]=20 Sent: Friday, January 26, 2007 10:51 AM To: dhcwg Subject: [dhcwg] dhc WG last call on draft-ietf-dhc-dhcvp6-leasequery This message announces a WG last call on "DHCPv6 Leasequery" . The last call will conclude at 1700EST, Mon, 2007-02-05. Please respond to this WG last call. If you support acceptance of the document without change, respond with a simple acknowledgment, so that support for the document can be assessed. Lack of discussion does not represent positive support. If there is no expression of support for acceptance during the WG last call, the document will not be advanced to the IESG. draft-ietf-dhc-dhcvp6-leasequery specifies leasequery for the Dynamic Host Configuration Protocol for IPv6 (DHCPv6) which can be used as a means to obtain lease information about DHCPv6 clients from a DHCPv6 server. draft-ietf-dhc-dhcvp6-leasequery specifies the scope of data that can be retrieved as well as both DHCPv6 leasequery requestor and server behavior. draft-ietf-dhc-dhcvp6-leasequery extends DHCPv6. This draft is available as http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcvp6-leasequery-01. txt - Stig Venaas, Ralph Droms dhc WG chairs _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Sat Jan 27 13:39:44 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAsRl-0005vG-Mt; Sat, 27 Jan 2007 13:38:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAsRk-0005v3-Gs for dhcwg@ietf.org; Sat, 27 Jan 2007 13:38:40 -0500 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HAsRj-0001GX-6f for dhcwg@ietf.org; Sat, 27 Jan 2007 13:38:40 -0500 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 27 Jan 2007 13:38:39 -0500 X-IronPort-AV: i="4.13,246,1167627600"; d="scan'208"; a="112610219:sNHT55014356" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l0RIccpH013069 for ; Sat, 27 Jan 2007 13:38:38 -0500 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l0RIccVT020036 for ; Sat, 27 Jan 2007 13:38:38 -0500 (EST) Received: from xmb-rtp-20a.amer.cisco.com ([64.102.31.15]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 27 Jan 2007 13:38:38 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [dhcwg] dhc WG last call on draft-ietf-dhc-dhcpv6-ero Date: Sat, 27 Jan 2007 13:38:36 -0500 Message-ID: <8E296595B6471A4689555D5D725EBB210318EBF6@xmb-rtp-20a.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dhcwg] dhc WG last call on draft-ietf-dhc-dhcpv6-ero Thread-Index: AcdBYLAS7pi8OK1TEdunlQARJOT6egA4ViXw From: "Bernie Volz \(volz\)" To: "Ralph Droms \(rdroms\)" , "dhcwg" X-OriginalArrivalTime: 27 Jan 2007 18:38:38.0751 (UTC) FILETIME=[5C5222F0:01C74242] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1529; t=1169923118; x=1170787118; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=volz@cisco.com; z=From:=20=22Bernie=20Volz=20\(volz\)=22=20 |Subject:=20RE=3A=20[dhcwg]=20dhc=20WG=20last=20call=20on=20draft-ietf-dh c-dhcpv6-ero |Sender:=20 |To:=20=22Ralph=20Droms=20\(rdroms\)=22=20, =20=22dhcwg= 22=20; bh=28vgiWJoVvU+BMJab/Ch+IWQ+bQllTrLzPb5G1ms4RE=; b=n0/i15sdFLYvFEkkVT4/C6GDIZPO+GOX3u4Vi6JCMERYfFPdYI6qNd1k4OeJUCQpGJ8Jzrmo CNgj+QxKYsn0KsEs1BW6v1HnN5J16Kp3xqGyz5LuRPfdEHSYARy7V+Wh; Authentication-Results: rtp-dkim-2; header.From=volz@cisco.com; dkim=pass (s ig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org Well, for what it is worth (as a co-author), I also approve. I agree with David's comment regarding "As matter of fact". Regarding his other comment on the references, those will be reworked by the rfc-editor anyway -- so not sure it is necesssary. - Bernie=20 -----Original Message----- From: Ralph Droms (rdroms)=20 Sent: Friday, January 26, 2007 10:43 AM To: dhcwg Subject: [dhcwg] dhc WG last call on draft-ietf-dhc-dhcpv6-ero This message announces a WG last call on "DHCPv6 Relay Agent Echo Request Option" . The last call will conclude at 1700EST, Mon, 2007-02-05. Please respond to this WG last call. If you support acceptance of the document without change, respond with a simple acknowledgment, so that support for the document can be assessed. Lack of discussion does not represent positive support. If there is no expression of support for acceptance during the WG last call, the document will not be advanced to the IESG. draft-ietf-dhc-dhcpv6-ero-00.txt defines a Relay Agent Echo Request option for the Dynamic Host Configuration Protocol for IPv6 (DHCPv6). The option allows a DHCPv6 relay agent to request a list of relay agent options that the server echoes back to the relay agent.. This draft is available as http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-ero-00.txt - Ralph Droms=20 _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Sat Jan 27 13:39:44 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAsSE-0005zs-Pj; Sat, 27 Jan 2007 13:39:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAsSD-0005yp-PQ for dhcwg@ietf.org; Sat, 27 Jan 2007 13:39:09 -0500 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HAsSC-0001Kh-G0 for dhcwg@ietf.org; Sat, 27 Jan 2007 13:39:09 -0500 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 27 Jan 2007 10:39:08 -0800 X-IronPort-AV: i="4.13,246,1167638400"; d="scan'208"; a="51733686:sNHT54603804" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l0RId8nr017771 for ; Sat, 27 Jan 2007 13:39:08 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l0RId8OA023232 for ; Sat, 27 Jan 2007 13:39:08 -0500 (EST) Received: from xmb-rtp-20a.amer.cisco.com ([64.102.31.15]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 27 Jan 2007 13:39:08 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [dhcwg] dhc WG last call on draft-ietf-dhc-dhcvp6-leasequery Date: Sat, 27 Jan 2007 13:39:06 -0500 Message-ID: <8E296595B6471A4689555D5D725EBB210318EBF7@xmb-rtp-20a.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dhcwg] dhc WG last call on draft-ietf-dhc-dhcvp6-leasequery Thread-Index: AcdBYclnCBSMGK1VEdunlQARJOT6egA4JRxg From: "Bernie Volz \(volz\)" To: "Ralph Droms \(rdroms\)" , "dhcwg" X-OriginalArrivalTime: 27 Jan 2007 18:39:08.0075 (UTC) FILETIME=[6DCC9FB0:01C74242] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1529; t=1169923148; x=1170787148; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=volz@cisco.com; z=From:=20=22Bernie=20Volz=20\(volz\)=22=20 |Subject:=20RE=3A=20[dhcwg]=20dhc=20WG=20last=20call=20on=20draft-ietf-dh c-dhcvp6-leasequery |Sender:=20 |To:=20=22Ralph=20Droms=20\(rdroms\)=22=20, =20=22dhcwg= 22=20; bh=jy8jTgVTKf3jhZb/pRVqvflBot3bEotRqknkqiN5X1w=; b=DnX8h5G40l7SBdMhMYA3G752XKt1X5x3+EZQkbgDU7D0Fs25hXxcUpnVpO0WCDKei9KyaTDp pPGWwlBeJ6WOHG1LhxSOJO9Gj49oCzAaV7kEB/o4tKJKCUBXVVHhTRKd; Authentication-Results: rtp-dkim-1; header.From=volz@cisco.com; dkim=pass (s ig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.orFrom dhcwg-bounces@ietf.org Sat Jan 27 13:39:44 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAsRl-0005vG-Mt; Sat, 27 Jan 2007 13:38:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAsRk-0005v3-Gs for dhcwg@ietf.org; Sat, 27 Jan 2007 13:38:40 -0500 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HAsRj-0001GX-6f for dhcwg@ietf.org; Sat, 27 Jan 2007 13:38:40 -0500 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 27 Jan 2007 13:38:39 -0500 X-IronPort-AV: i="4.13,246,1167627600"; d="scan'208"; a="112610219:sNHT55014356" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l0RIccpH013069 for ; Sat, 27 Jan 2007 13:38:38 -0500 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l0RIccVT020036 for ; Sat, 27 Jan 2007 13:38:38 -0500 (EST) Received: from xmb-rtp-20a.amer.cisco.com ([64.102.31.15]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 27 Jan 2007 13:38:38 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [dhcwg] dhc WG last call on draft-ietf-dhc-dhcpv6-ero Date: Sat, 27 Jan 2007 13:38:36 -0500 Message-ID: <8E296595B6471A4689555D5D725EBB210318EBF6@xmb-rtp-20a.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dhcwg] dhc WG last call on draft-ietf-dhc-dhcpv6-ero Thread-Index: AcdBYLAS7pi8OK1TEdunlQARJOT6egA4ViXw From: "Bernie Volz \(volz\)" To: "Ralph Droms \(rdroms\)" , "dhcwg" X-OriginalArrivalTime: 27 Jan 2007 18:38:38.0751 (UTC) FILETIME=[5C5222F0:01C74242] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1529; t=1169923118; x=1170787118; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=volz@cisco.com; z=From:=20=22Bernie=20Volz=20\(volz\)=22=20 |Subject:=20RE=3A=20[dhcwg]=20dhc=20WG=20last=20call=20on=20draft-ietf-dh c-dhcpv6-ero |Sender:=20 |To:=20=22Ralph=20Droms=20\(rdroms\)=22=20, =20=22dhcwg= 22=20; bh=28vgiWJoVvU+BMJab/Ch+IWQ+bQllTrLzPb5G1ms4RE=; b=n0/i15sdFLYvFEkkVT4/C6GDIZPO+GOX3u4Vi6JCMERYfFPdYI6qNd1k4OeJUCQpGJ8Jzrmo CNgj+QxKYsn0KsEs1BW6v1HnN5J16Kp3xqGyz5LuRPfdEHSYARy7V+Wh; Authentication-Results: rtp-dkim-2; header.From=volz@cisco.com; dkim=pass (s ig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org Well, for what it is worth (as a co-author), I also approve. I agree with David's comment regarding "As matter of fact". Regarding his other comment on the references, those will be reworked by the rfc-editor anyway -- so not sure it is necesssary. - Bernie=20 -----Original Message----- From: Ralph Droms (rdroms)=20 Sent: Friday, January 26, 2007 10:43 AM To: dhcwg Subject: [dhcwg] dhc WG last call on draft-ietf-dhc-dhcpv6-ero This message announces a WG last call on "DHCPv6 Relay Agent Echo Request Option" . The last call will conclude at 1700EST, Mon, 2007-02-05. Please respond to this WG g List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org For what it is worth (as a co-author), I also approve moving this forward. - Bernie=20 -----Original Message----- From: Ralph Droms (rdroms)=20 Sent: Friday, January 26, 2007 10:51 AM To: dhcwg Subject: [dhcwg] dhc WG last call on draft-ietf-dhc-dhcvp6-leasequery This message announces a WG last call on "DHCPv6 Leasequery" . The last call will conclude at 1700EST, Mon, 2007-02-05. Please respond to this WG last call. If you support acceptance of the document without change, respond with a simple acknowledgment, so that support for the document can be assessed. Lack of discussion does not represent positive support. If there is no expression of support for acceptance during the WG last call, the document will not be advanced to the IESG. draft-ietf-dhc-dhcvp6-leasequery specifies leasequery for the Dynamic Host Configuration Protocol for IPv6 (DHCPv6) which can be used as a means to obtain lease information about DHCPv6 clients from a DHCPv6 server. draft-ietf-dhc-dhcvp6-leasequery specifies the scope of data that can be retrieved as well as both DHCPv6 leasequery requestor and server behavior. draft-ietf-dhc-dhcvp6-leasequery extends DHCPv6. This draft is available as http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcvp6-leasequery-01. txt - Stig Venaas, Ralph Droms dhc WG chairs _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg last call. If you support acceptance of the document without change, respond with a simple acknowledgment, so that support for the document can be assessed. Lack of discussion does not represent positive support. If there is no expression of support for acceptance during the WG last call, the document will not be advanced to the IESG. draft-ietf-dhc-dhcpv6-ero-00.txt defines a Relay Agent Echo Request option for the Dynamic Host Configuration Protocol for IPv6 (DHCPv6). The option allows a DHCPv6 relay agent to request a list of relay agent options that the server echoes back to the relay agent.. This draft is available as http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-ero-00.txt - Ralph Droms=20 _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Sat Jan 27 13:39:44 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAsSE-0005zs-Pj; Sat, 27 Jan 2007 13:39:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAsSD-0005yp-PQ for dhcwg@ietf.org; Sat, 27 Jan 2007 13:39:09 -0500 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HAsSC-0001Kh-G0 for dhcwg@ietf.org; Sat, 27 Jan 2007 13:39:09 -0500 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 27 Jan 2007 10:39:08 -0800 X-IronPort-AV: i="4.13,246,1167638400"; d="scan'208"; a="51733686:sNHT54603804" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l0RId8nr017771 for ; Sat, 27 Jan 2007 13:39:08 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l0RId8OA023232 for ; Sat, 27 Jan 2007 13:39:08 -0500 (EST) Received: from xmb-rtp-20a.amer.cisco.com ([64.102.31.15]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 27 Jan 2007 13:39:08 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [dhcwg] dhc WG last call on draft-ietf-dhc-dhcvp6-leasequery Date: Sat, 27 Jan 2007 13:39:06 -0500 Message-ID: <8E296595B6471A4689555D5D725EBB210318EBF7@xmb-rtp-20a.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dhcwg] dhc WG last call on draft-ietf-dhc-dhcvp6-leasequery Thread-Index: AcdBYclnCBSMGK1VEdunlQARJOT6egA4JRxg From: "Bernie Volz \(volz\)" To: "Ralph Droms \(rdroms\)" , "dhcwg" X-OriginalArrivalTime: 27 Jan 2007 18:39:08.0075 (UTC) FILETIME=[6DCC9FB0:01C74242] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1529; t=1169923148; x=1170787148; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=volz@cisco.com; z=From:=20=22Bernie=20Volz=20\(volz\)=22=20 |Subject:=20RE=3A=20[dhcwg]=20dhc=20WG=20last=20call=20on=20draft-ietf-dh c-dhcvp6-leasequery |Sender:=20 |To:=20=22Ralph=20Droms=20\(rdroms\)=22=20, =20=22dhcwg= 22=20; bh=jy8jTgVTKf3jhZb/pRVqvflBot3bEotRqknkqiN5X1w=; b=DnX8h5G40l7SBdMhMYA3G752XKt1X5x3+EZQkbgDU7D0Fs25hXxcUpnVpO0WCDKei9KyaTDp pPGWwlBeJ6WOHG1LhxSOJO9Gj49oCzAaV7kEB/o4tKJKCUBXVVHhTRKd; Authentication-Results: rtp-dkim-1; header.From=volz@cisco.com; dkim=pass (s ig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org For what it is worth (as a co-author), I also approve moving this forward. - Bernie=20 -----Original Message----- From: Ralph Droms (rdroms)=20 Sent: Friday, January 26, 2007 10:51 AM To: dhcwg Subject: [dhcwg] dhc WG last call on draft-ietf-dhc-dhcvp6-leasequery This message announces a WG last call on "DHCPv6 Leasequery" . The last call will conclude at 1700EST, Mon, 2007-02-05. Please respond to this WG last call. If you support acceptance of the document without change, respond with a simple acknowledgment, so that support for the document can be assessed. Lack of discussion does not represent positive support. If there is no expression of support for acceptance during the WG last call, the document will not be advanced to the IESG. draft-ietf-dhc-dhcvp6-leasequery specifies leasequery for the Dynamic Host Configuration Protocol for IPv6 (DHCPv6) which can be used as a means to obtain lease information about DHCPv6 clients from a DHCPv6 server. draft-ietf-dhc-dhcvp6-leasequery specifies the scope of data that can be retrieved as well as both DHCPv6 leasequery requestor and server behavior. draft-ietf-dhc-dhcvp6-leasequery extends DHCPv6. This draft is available as http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcvp6-leasequery-01. txt - Stig Venaas, Ralph Droms dhc WG chairs _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Sat Jan 27 13:40:45 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAsTg-0006So-Pa; Sat, 27 Jan 2007 13:40:40 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAsTf-0006Si-Vu for dhcwg@ietf.org; Sat, 27 Jan 2007 13:40:39 -0500 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HAsTe-0001Uh-N6 for dhcwg@ietf.org; Sat, 27 Jan 2007 13:40:39 -0500 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 27 Jan 2007 10:40:38 -0800 X-IronPort-AV: i="4.13,246,1167638400"; d="scan'208"; a="51733708:sNHT55303768" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l0RIecmh013301; Sat, 27 Jan 2007 13:40:38 -0500 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l0RIecVT020276; Sat, 27 Jan 2007 13:40:38 -0500 (EST) Received: from xmb-rtp-20a.amer.cisco.com ([64.102.31.15]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 27 Jan 2007 13:40:38 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [dhcwg] Adopting draft-dhankins-atomic-dhcp-00 as wg work item Date: Sat, 27 Jan 2007 13:40:36 -0500 Message-ID: <8E296595B6471A4689555D5D725EBB210318EBF8@xmb-rtp-20a.amer.cisco.com> In-Reply-To: <20070126173821.GE3731@isc.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dhcwg] Adopting draft-dhankins-atomic-dhcp-00 as wg work item Thread-Index: AcdBcNlYBSTOvapPSMmiVkwJemb3sgA0axdA From: "Bernie Volz \(volz\)" To: "David W. Hankins" , X-OriginalArrivalTime: 27 Jan 2007 18:40:38.0207 (UTC) FILETIME=[A385ACF0:01C74242] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1430; t=1169923238; x=1170787238; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=volz@cisco.com; z=From:=20=22Bernie=20Volz=20\(volz\)=22=20 |Subject:=20RE=3A=20[dhcwg]=20Adopting=20draft-dhankins-atomic-dhcp-00=20 as=20wg=20work=20item |Sender:=20 |To:=20=22David=20W.=20Hankins=22=20, =20; bh=gz1FY1Afn3b1Uq/ZVlpI1xz2rpRxJaE381ZU5DUOOS8=; b=hRC06WxJH8gIFigT8UJL24mjuMLAj7j7bt0yb4o36TIhI4NXKQjOydftNCIZXASIGQ8+BS/n Vp6dinPA0PRxQM2qBAE/5F03qmeLEJ9S7HnGDUNKUfjdo3rhQ/NekQES; Authentication-Results: rtp-dkim-2; header.From=volz@cisco.com; dkim=pass (s ig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org I recall the same. But, I also see no reason to allow the reworked draft to be published as a DHC WG work item (rather than first as an indidivual submission). - Bernie=20 -----Original Message----- From: David W. Hankins [mailto:David_Hankins@isc.org]=20 Sent: Friday, January 26, 2007 12:38 PM To: dhcwg@ietf.org Subject: Re: [dhcwg] Adopting draft-dhankins-atomic-dhcp-00 as wg work item On Fri, Jan 26, 2007 at 12:46:42PM +0100, Stig Venaas wrote: > There was consensus at the dhc wg meeting in San Diego to adopt > draft-dhankins-atomic-dhcp-00 as a dhc wg work item. For details > see the minutes at > http://www3.ietf.org/proceedings/06nov/minutes/dhc.txt >=20 > If there are no objections posted to the wg mailing list, the > chairs will accept the draft as a wg work item on 2007-02-09. As I recall the consensus was to reform the document to move the (extensive) discussion of ISC's implementation into a stripped-down summary in an appendix (if retain it at all) and to expand upon the advice to draft authors. Consequently the draft probably won't be named 'atomic dhcp' after that. I am unsure if I'm going to be able to complete that prior to the IETF 68 cutoff date...very busy at our office here. --=20 David W. Hankins "If you don't do it right the first time, Software Engineer you'll just have to do it again." Internet Systems Consortium, Inc. -- Jack T. Hankins _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Sat Jan 27 15:04:09 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAtld-0005xk-2x; Sat, 27 Jan 2007 15:03:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAtlc-0005xf-9m for dhcwg@ietf.org; Sat, 27 Jan 2007 15:03:16 -0500 Received: from mx.isc.org ([2001:4f8:0:2::1c]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HAtlb-00047n-2A for dhcwg@ietf.org; Sat, 27 Jan 2007 15:03:16 -0500 Received: from farside.isc.org (farside.isc.org [IPv6:2001:4f8:3:bb::5]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "farside.isc.org", Issuer "ISC CA" (verified OK)) by mx.isc.org (Postfix) with ESMTP id A960D114029 for ; Sat, 27 Jan 2007 20:03:04 +0000 (UTC) (envelope-from David_Hankins@isc.org) Received: by farside.isc.org (Postfix, from userid 10200) id 80B84E60C4; Sat, 27 Jan 2007 20:03:04 +0000 (UTC) Date: Sat, 27 Jan 2007 20:03:04 +0000 From: "David W. Hankins" To: dhcwg@ietf.org Subject: Re: [dhcwg] Adopting draft-dhankins-atomic-dhcp-00 as wg work item Message-ID: <20070127200304.GB22907@isc.org> References: <20070126173821.GE3731@isc.org> <8E296595B6471A4689555D5D725EBB210318EBF8@xmb-rtp-20a.amer.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8E296595B6471A4689555D5D725EBB210318EBF8@xmb-rtp-20a.amer.cisco.com> User-Agent: Mutt/1.4.2.1i X-Spam-Score: -2.8 (--) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org On Sat, Jan 27, 2007 at 01:40:36PM -0500, Bernie Volz (volz) wrote: > I recall the same. But, I also see no reason to allow the reworked draft > to be published as a DHC WG work item (rather than first as an > indidivual submission). It does feel like we're pushing the process a little far for expedience that isn't necessary. I have no problem making the reworked document a new individual submission so it can be judged on its new merits. -- David W. Hankins "If you don't do it right the first time, Software Engineer you'll just have to do it again." Internet Systems Consortium, Inc. -- Jack T. Hankins _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Wed Jan 31 14:48:21 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCLQi-0003Yj-W1; Wed, 31 Jan 2007 14:47:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCLQh-0003WA-JQ for dhcwg@ietf.org; Wed, 31 Jan 2007 14:47:39 -0500 Received: from goliath.isc.org ([2001:4f8:3:bb::72]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCLQd-0007kx-Sa for dhcwg@ietf.org; Wed, 31 Jan 2007 14:47:39 -0500 Received: by goliath.isc.org (Postfix, from userid 10200) id 11C667D2D; Wed, 31 Jan 2007 11:47:15 -0800 (PST) Date: Wed, 31 Jan 2007 11:47:15 -0800 From: "David W. Hankins" To: dhcwg@ietf.org Subject: Re: [dhcwg] RFC 2131: can a DHCPv4 client (Mac OS X) transition directly from BOUND to INIT then back to BOUND? Message-ID: <20070131194714.GD9514@isc.org> References: <200701241448.l0OElsE8012219@scramble.Princeton.EDU> Mime-Version: 1.0 In-Reply-To: <200701241448.l0OElsE8012219@scramble.Princeton.EDU> User-Agent: Mutt/1.5.9i X-Spam-Score: -2.8 (--) X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a Cc: Irwin Tillman X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0169309499==" Errors-To: dhcwg-bounces@ietf.org --===============0169309499== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="T4sUOijqQbZv57TR" Content-Disposition: inline --T4sUOijqQbZv57TR Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Irwin, I'm sorry that it seems we didn't help you to your satisfaction earlier. We are a group of volunteers, so we often forget that we have 'customers' with time-sensitive needs. In your recent message to unisog [1] you said: | Some time after obtaining a DHCP lease (entering the DHCP BOUND | state), the client sends one or more DHCPDISCOVER packet. This | implies the client has returned to the DHCP INIT state, | relinquishing the old DHCP lease. In some This is not true. DHCPDISCOVER conveys no information to the server except that the client is 'discover'ing the presence (or lack thereof) of DHCP servers on the network that it might receive configuration parameters from, and what those parameters might be. It is absolutely a server's violation of RFC2131 to infer that the client transmitting a DISCOVER has relinquished its lease. The only situation I'm aware of according to RFC2131 in which a server may reasonably understand a client's lease to be relinquished before the expiration time has elapsed is when the client transmits a DHCPRELEASE message (or similarly, DHCPDECLINE, but that's different). However, I am also aware that many servers (including ISC DHCP) have also implemented a catch should clients transmit a DHCPREQUEST message using the same identity as a previous, unexpired binding, but requesting a different binding. A REQUEST really is a demand for a given binding, and therefore the client's indication of its acceptance and intent to use. So this practice has not turned out to have many pitfalls. This is often done in order to free resources the old binding carries but can not possibly still be used, such as domain names or lease limitation counts. I am not aware of any other reasonable circumstances where the client's intent to use a binding it has been given may be inferred. I am also curious as to why you think it is necessary to expire a binding when the client issues a DISCOVER, rather than at the time they issue some other message. | * More importantly, the client transitions directly from the DHCP | INIT state to the BOUND state. I don't believe that's permitted | in DHCP. | | Specifically, Figure 5 in RFC 2131 contains the state transition | diagram for DHCP clients. (There have been some changes due to | later RFCs, but none that are directly relevant to this matter.) | | It makes it clear that a client the only time a DHCP client may send | a DHCPDISCOVER is when it is in the DHCP INIT state, and that there | is no way for a client in the DHCP INIT state to get to the DHCP | BOUND state without the server granting it a lease. It is a mistake to think that any action indicated in the state diagram is a "MUST". It is also a mistake to think you know what state the client is operating in based entirely on the message it transmits or the contents thereof (despite the fact that we do this in at least one place in DHCPREQUEST to sense RENEW vs REBIND). Transmitting a DISCOVER in BOUND state does not make a client fail to implement RFC2131. The behaviour simply is not in the reference one way or the other. | Once a client identified by a unique (client identifier, subnet) | tuple sends a DHCPDISCOVER, any old lease identified by that (client | identifier, subnet) tuple is no longer valid. The client's abandoned | any old lease identified by that tuple. This is unequivocally false. Now, you did point out some client bugs in your message that I hope Apple will fix. But those bugs will only result in servers sending DHCPNAKs, which hopefully the client processes correctly. [1] [unisog] Mac OS X 10.4.x "DHCP client sometimes remains BOUND after sending DHCPDISCOVER" bug January 30, 2007 by Irwin Tillman http://lists.sans.org/pipermail/unisog/2007-January/027056.html -- David W. Hankins "If you don't do it right the first time, Software Engineer you'll just have to do it again." Internet Systems Consortium, Inc. -- Jack T. Hankins --T4sUOijqQbZv57TR Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFFwPJCcXeLeWu2vmoRAnWtAJ9uz1Mq6odfZ9K1qGNqzZxms4OdFgCeLt2i eyCk6Qt3QXg1DFKHfA0HEfU= =VipD -----END PGP SIGNATURE----- --T4sUOijqQbZv57TR-- --===============0169309499== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg --===============0169309499==-- From dhcwg-bounces@ietf.org Wed Jan 31 14:50:06 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCLSj-0004vU-H4; Wed, 31 Jan 2007 14:49:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCLSi-0004vO-4j for dhcwg@ietf.org; Wed, 31 Jan 2007 14:49:44 -0500 Received: from goliath.isc.org ([2001:4f8:3:bb::72]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCLSh-0008Lo-G1 for dhcwg@ietf.org; Wed, 31 Jan 2007 14:49:44 -0500 Received: by goliath.isc.org (Postfix, from userid 10200) id C90CB7D2D; Wed, 31 Jan 2007 11:49:38 -0800 (PST) Date: Wed, 31 Jan 2007 11:49:38 -0800 From: "David W. Hankins" To: dhcwg@ietf.org Subject: Re: [dhcwg] RFC 2131: can a DHCPv4 client (Mac OS X) transition directly from BOUND to INIT then back to BOUND? Message-ID: <20070131194938.GE9514@isc.org> References: <200701241448.l0OElsE8012219@scramble.Princeton.EDU> <20070124184135.GB6482@isc.org> <200701242035.l0OKZg9U014820@scramble.Princeton.EDU> <20070124210536.GE6482@isc.org> Mime-Version: 1.0 In-Reply-To: User-Agent: Mutt/1.5.9i X-Spam-Score: -2.8 (--) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1427339579==" Errors-To: dhcwg-bounces@ietf.org --===============1427339579== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="JYK4vJDZwFMowpUq" Content-Disposition: inline --JYK4vJDZwFMowpUq Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Wed, Jan 24, 2007 at 03:32:50PM -0700, Ted Lemon wrote: > It's probably better to think of the entire configuration, rather > than just the IP address and the lease on it. So if the device > holding that configuration can use it to communicate on the network, > it is operable; if it cannot, it is not. And this is true even > though the lease has not yet expired. Irwin has a point that although we understand the term in this manner, that isn't the text of the rfc's definitions section. Errata? -- David W. Hankins "If you don't do it right the first time, Software Engineer you'll just have to do it again." Internet Systems Consortium, Inc. -- Jack T. Hankins --JYK4vJDZwFMowpUq Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFFwPLScXeLeWu2vmoRAvhVAJ9YEWsD+JSemNKvnl23/9LC084w+ACgj5nz 4aK/cjB41fN3nU9Mg/T9BbQ= =ew3y -----END PGP SIGNATURE----- --JYK4vJDZwFMowpUq-- --===============1427339579== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg --===============1427339579==--